45 comments

[ 2.6 ms ] story [ 103 ms ] thread
I couldn't think of a worse clickbait title than this. The quote has nothing to do with C.
LOL. That's right. Well observed. Just the "origins of C" would be a lot more honest. I also liked the commentary on theory and practice, which could have something to do with C and UNIX and the whole story.
The quote seems to apply to the origins of C upon reading.

> One minor quibble was Strachey’s objection to the grammar of “IF … THEN … ELSE” statements. “I cannot allow my name to be associated with a definite recommendation to use ignorantly incorrect English,” was his view, as Hartley later wrote for Annals of the History of Computing. Strachey preferred “OR,” which conflicted with the way “OR” was used in nearly every other programming language in existence. Nonetheless, his preferences carried the day, and the CPL reference manual included “OR” in the place where users would have expected “ELSE.”

That seems like a pretty stupid thing to do--perhaps not at the time by the 'do'ers.

Sure, somebody admitted to doing something stupid, but the title is clearly meant to attract all the C bashers by pretending the quote is from someone who was involved in the development of C.
Maybe language changed since then, but to me 'else' sounds right and 'or' sounds wrong:

    IF (condition) THEN (do-this) ELSE (do-that).
I think 'or' would not go with alternative commands, but with an alternative condition:

    IF (condition) THEN (do-this) OR (other-condition) THEN (do-that).
If you don't want to use 'else' then 'otherwise' would sound idiomatic, too.
Remember that there’s already two commonly used elements of logic and programming (bitwise OR, logical OR) that may well form part of condition/other-condition, so while if/then/or may (subjectively) scan a little better in isolation, I think “else” might have been the right call
I don't remember this in BCPL, so I presume it was one of the changes from CPL?
I hadn't thought about it before, but I'd have gone with:

> IF THEN OTHERWISE

Which avoids overloading OR and maintains better grammar.

But I suspect shorter words were preferable when space was a premium everywhere not least on the display itself.

WHEREUPON x PURSUANT y CONTRARIWISE z
Wherefore art thou utilizing contrarwise? Dost thy senses leave thee?
twitch

"Utilize" first arose in 1807 if Merriam-Webster is to be believed, well past the period you're quoting; and "dost" should agree with the number of its noun "senses". ("dost" is second-person, but you need something third-person.) In this context I also don't really like the continuous present of "are you utilizing", but I can't put words to why. I believe "hast thou taken leave of thy senses" is actually recorded to be idiomatic.

By the way, ChatGPT suggests (where I've fixed its analogous error in the word "doth"):

> Pray tell, wherefore dost thou employ the term 'contrariwise'?

I remember saving this code from somewhere.

  #include <stdio.h>

  #define PREACH printf
  #define SHOULD_GOD_WILL if
  #define EACH_AND_EVERY_CREATURE_UNDER_GODS_LIGHT for
  #define OTHERWISE else
  #define RETRIBUTE return
  #define ALONG_WITH &&
  #define THUS }
  #define LET {

  int main() LET
      EACH_AND_EVERY_CREATURE_UNDER_GODS_LIGHT (int i = 0; i < 100; i++) LET
          SHOULD_GOD_WILL (i % 5 == 0 ALONG_WITH i % 3 == 0) LET
              PREACH("Fizzbuzz!\n");
          THUS OTHERWISE SHOULD_GOD_WILL (i % 5 == 0) LET
              PREACH("Buzz!\n");
          THUS OTHERWISE SHOULD_GOD_WILL (i % 3 == 0) LET
              PREACH("Fizz!\n");
          THUS OTHERWISE PREACH("%d\n", i);
      THUS

      RETRIBUTE 0;
  THUS
Haskell uses `otherwise`. Example use:

  greater x y
    | x > y     = x
    | otherwise = y
In Haskell's case, this is a conditional syntax that's alternative to if-then-else, so `else` was already taken. `otherwise` is just a conventional constant for `True` that's chosen for readability.
Which lets you write gems like:

    if otherwise then not
(comment deleted)
According to the article, the stupid thing was developing a new language just because you built a new computer. But the efforts in developing this new language (CPL) are what lead to C.
There is a neat history of the early syntax of conditional expressions here https://github.com/e-n-f/if-then-else/blob/master/if-then-el... titled “if-then-else had to be invented”. It seems “else” originated in Algol 60 as a hasty translation from German. The CPL project started in the early 1960s when it was not yet certain that Algol-style block structure and keywords would become the common basis of most programming languages.
The article does talk a lot about the origins of C, so it's fair for that to be in the title. We can make it more accurate by throwing in CPL and BCPL too.
Agreed. The title is garbage (Ars should know better).

But the article is a good History of C and worth a read.

I'm sure Strachey was a decent bloke in person but this bit gave me some unpleasant flashbacks to certain former colleagues:

> Almost immediately, they had some difficulty prioritizing, as David Barron noted of Strachey, “It was characteristic of him to insist on minor points of difference with the same force that he insisted on major points.”

It's amazing that some people never learn that "choose your battles" is more than just a cliche saying.
Got whole Althusser who copied from mao which got china. United Front (which fund Confucius college) is still an approach.

I hate them and communist in general, but please war of position or war based on position is key to the dark side winning.

For the china example, Mao has instructed and except one disobedient general never fought the war against japan. And said thank you then of invading china afterward.

Back to this I posted. I think that early pioneer many of these have issue of fighting all or select whatever he thought important. That is why they did this in the first place I think. Some ok some not. And you hope the idea or company spread around enough (mouse-windows to Steve) that someone did it and fight the right strategy war. Free source to open source is another example.

It’s better to not be an asshole. But it’s mostly okay to be an asshole too. The world needs more than just ultra-agreeable people. I reckon grudge-holding is way more destructive to teams than abrasiveness. There’s lots to be said in favor of the asshole who moves past a conflict as soon as it’s over.
Its unnecessary conflict. If everything is the same level of disagreement, what are you _actually_ arguing and what do you just _happen_ to be arguing? You give the other party no capacity to gauge your actual level of interest. It makes the entire process that much harder for everyone and wastes the "argument budget" on ultimately meaningless stuff. Its a very similar idea to being "penny wise, pound foolish".
People are a variety of ways. A healthy culture can accommodate that variety within reason. I reckon we’ve become a little too focused on agreeableness as a culture. Not that you should strive to be an asshole. But some people are just naturally blunt and abrasive. And that’s okay. A lot of the trouble is in people’s reactions to that, since thick skin seems to be on long-term decline too.

I’m not sure we’re disagreeing about anything. What you wrote is good advice to someone who’s too argumentative.

Right, but its basically hoping that human nature fundamentally changes rather than just not making big deals about things which dont matter. The article is a great example. The anecdote is that he argued aggressively against "IF, THEN, ELSE" because its _grammatically incorrect_ even though every other language used it. He suggests "IF, THEN, OR", which is _just as bad but also different_! So now we are wasting time/energy debating this thing and the suggestion isnt even good! So how am I supposed to interpret this as the "non arguer" in this scenario? That you put the quality of the product first, or that you just want to "win" the argument in _every single scenario_? I'm likely to interpret it as the latter and now we are in a worse spot as a team because, again, I can't assume you are not just arguing for the sake of arguing in the future.
> There’s lots to be said in favor of the asshole who moves past a conflict as soon as it’s over.

I think I used to fit something like this description. I was very blunt about disagreements but I was always well intentioned and forgiving. Sometimes people took the bluntness too seriously and couldn't see that I was trying to help them.

I've since softened up somewhat. In retrospect I think some of the bluntness was a symptom of externally imposed stress.

Ability to work and communicate with abrasive people is a valuable skill as well. I get to practice it here on HN sometimes.

I try to ignore the tone and insults and reply as if nothing was happening. Easier to do through text than through voice or in person. It's smart to move any discussion to a written medium in order to reply calmly and create a paper trail.

> Almost immediately, they had some difficulty prioritizing

I have worked with very smart people who had no ability to prioritize. It's always fascinated me and I wonder what is at the root of this problem.

I think its largely a combination of "shiny things" syndrome, procrastination, and estimation being hard. You will have a tendency to want to do the shiny things first because they are new/interesting, you will tend to put off the nebulous/harder bits, and you will not realize certain things are much bigger than you thought.

Procrastination is the biggest one for otherwise well-meaning/smart people in my opinion.

Lack of need and practice, I suspect. And they may be prioritizing, but simply by different unstated (and perhaps subconcious) criteria than mere importance.

Someone struggling with an exam might first prioritize the questions they're confident in answering quickly to improve their grade. Someone who will ace the exam regardless of order can simply power through without needing to waste time "prioritizing" that could instead be spent on answering the questions.

Someone who is smart/driven/competent enough to generally complete their projects in time and under budget has no need to prioritize features based on need - if they do prioritize, they may prioritize based on ease of overal implementation. That might mean prioritizing the "less important" / less defined items before the more important / more fleshed out aspects. Eliminating unknowns and variables up front in this way might lead to less time "wasted" on refactoring and redesigning.

(comment deleted)
Consider that maybe he had some form of Asperger's.

The lack of ability to prioritize is because every single detail is consider important. Which is why he gain the reputation of writing perfect programs.

Choosing your battles is good in the interpersonal relationships; but Mother nature does not choose battles when enforcing its laws, it doesn't say "well... right now we should suspend gravity because there are bigger fish to fry".

From that perspective there are not major or minor points, there are only points. So, what might seem petulant for neurotypical people, for Asperger's people is much more black and white; which is a blessing and a curse. but you will thank me later.

Or obsessive-compusive personality disorder, which is what I have.

I tend to either care entirely about something or not at all, and the only standard is "perfect" (there are no visible ways something can be improved) – "good enough" doesn't really make sense emotionally. And even though I'm completely self-aware and I recognize this as it's happening, it's difficult to control what I feel.

It's very frustrating. I sometimes wonder at how much more I'd enjoy things and how much more progress I'd make at work and with my hobbies if there weren't these... unbidden demands that take time to satisfy, the stress that the demands cause, and the constant internal battle between what I want to do or know I ought to do and the arbitrary need for something to be a certain way.

It's weird that this is a point to make in any form when it comes to C, which, as a language, is certainly very aloof and non-judgemental over what you want to do. (IE undefine behavior, non safety, nul terminated strings)
> Consider that maybe he had some form of Asperger's.

Far be it from me to armchair diagnose someone, but the "Strachey had always displayed a talent for the sciences but rarely applied himself" is a story told over and over again for those with undiagnosed neurodivergence.

Turing suggested that, as a first step, he write a program that would enable the Ferranti Mark I to simulate itself....The trace program Strachey wrote included over a thousand instructions—at the time it was the longest program that had ever been written for the Ferranti Mark I. Strachey had it up and running after pulling an all-nighter, and when the program terminated, it played “God Save the King”

How many 'computer programmers' could do this in today's world?

> How many 'computer programmers' could do this in today's world?

They're numbered in the thousands.

> Strachey had always displayed a talent for the sciences but rarely applied himself.

I would guess any experienced programmer with adhd would and has done the same multiple times.

On reading that C has "BCPL semantics with a lot of SMALGOL syntx" , I was really curious to see some examples of SMALGOL programs. I found this [1] which describes what is taken out of ALGOL to make SMALGOL, and searches for "example ALGOL programs" work ok. But how can I see some non-trivial SMALGOL programs?

[1] https://dl.acm.org/doi/pdf/10.1145/366813.366843

On C, compilers in the 90's sucked up a bit, and the code wasn't much better.

Consider this:

https://github.com/gwf/CBofN

This code crashed CWM under OpenBSD 7.2, but it worked under FVWM. And, still, the fractal generating time was atrocious.

I could reimplement the figures in PostScript and yet render them faster under GhostScript than the C binaries against Xlib.

> Like Unix, C was a success born of failure. In both instances, programmers took the best parts of projects that were doomed because they sought to do too much. Multics, which spawned Unix, was—at its peak—only used on about 80 computers worldwide, and CPL, which ultimately led to C, was abandoned by Cambridge researchers in 1967 without being completed.

Unfortunately for C and Unix, it turned out that features like memory safety (PL/I) and ring security/ACLs/MAC (Multics) were actually good ideas.

Of course memory-safe C/C++ compilers/ABIs/runtimes are possible and seem like a very good idea - certainly if you have the hardware (CHERI) or are willing to take a performance hit (probably acceptable considering that computers are fast enough to run apps in JavaScript/Python/Java/etc..)

Unfortunately Linux inherited Unix's security architecture and we've ended up with a hodgepodge of stuff like SELinux, AppArmor, hypervisors, containers, gVisor, etc. to try to fix it. And of course it usually runs on vulnerable hardware which has prioritized speed over security.

> Unfortunately for C and Unix, it turned out that features like memory safety (PL/I) and ring security/ACLs/MAC (Multics) were actually good ideas.

Yeah, but perhaps the real misfortune was how small the obsolete PDP-10s that DMR, BWK, Ken Thompson, et. al. were working with.