Hacker News Reader

Comment by speps | Hacker News Reader

Linked from another thread: http://cm.bell-labs.co/who/dmr/chist.html

It explains the memory limits and what happened :)

> After the TMG version of B was working, Thompson rewrote B in itself (a bootstrapping step). During development, he continually struggled against memory limitations: each language addition inflated the compiler so it could barely fit, but each rewrite taking advantage of the feature reduced its size. For example, B introduced generalized assignment operators, using x=+y to add y to x. The notation came from Algol 68 [Wijngaarden 75] via McIlroy, who had incorporated it into his version of TMG. (In B and early C, the operator was spelled =+ instead of += ; this mistake, repaired in 1976, was induced by a seductively easy way of handling the first form in B's lexical analyzer.)

View on HN

Infix parsing chews up a remarkable amount code and memory.

It's scary just how much easier it is to parse languages without infix parsing.

where it takes up the memory in the human brain, where we have more limited working set, than in computers. That is probably why postfix notation is mostly a thing of the past by now in languages intended to be used by humans.

(in (is "prefix notation" (and "alive" "kicking")) "all lisps")

    (-<> "alive"
         (and "kicking")
         (is "prefix notation" <>)
         (in "all lisps"))

But creates a habit of having exactly two individual items for an operation.

Which led us to imperative programming and object oriented programming. Which everybody now recognizes as limited in various artificial ways.

Which we are now struggling to shake off given that the majority of chips have a whopping number of parallel cores.

Programming languages restrain your thinking about your solution space.

I wonder why =+ is so obviously a mistake. It does look vaguely wrong for some reason, but I’m prejudiced by current languages.

I think because it's ambiguous with unary plus (a = +b), since C isn't supposed to have significant whitespace in most circumstances.

You also run into problems with a=*p and a=-b, which are perhaps more likely.

But they could've fixed that by going a=(*p) and a=(-b);

Kind of how we use (*p)->next instead of *p->next where p is node_t**

That seems a little backwards and barbaric, though right?

Imagine if we had to watch out for this as a common pitfall:

    // BUG! Actually subtracts x from current val of neg_x.
    neg_x = -x;

Even moreso, how would these two lines behave? Would they differ in semantics?

    n = -5
    n =- 5

Overall, -= is just so much less ambiguous.

EDIT: To your point about ->, I personally think C would be better if:

    *p->next

parsed as:

    (*p)->next

instead of:

    *(p->next)

but maybe now I'm not thinking through all the parsing impliciations :)

As you note in your edit; we already have to watch for that pitfall :)

so really the best way out is to be as verbose as possible imo; a = a + c or auto nodep = *nodepp; nodep->next;

Compilers and compute performance have grown to make the difference negligible for code output and compilation times but they definitely take a lot of mental complexity out of such scenarios (anything helps when grokking 10k+ lines of code).

I've found struct fields that are pointers far more common than pointers to pointers to structs, so if nothing else it feels like *(p->target) is a more widely useful interpretation of *p->target than (*p)->target would be.

Regarding "n = -5", it would presumably be interpreted as "n=(-5)", same as today. Operators don't have spaces in them. So "n- -5" is "n-(-5)", rather than "n--5" (not valid).

But originally there wasn't a += or =+ lexical token! Those things were scanned as separate tokens, and could be written = +.

So that is problematic; If {a}{=}{-}{b} means a = a - b, then you have no way to write a = -b without parentheses like a = (-b).

>I wonder why =+ is so obviously a mistake

Consider

  x = -5

now how about:

  x =- 5

One makes x negative 5, the other subtracts 5 from it. And under this design of the operator the only difference is a space.

It's the same with +, just that we're not used to seeing unary plus in the wild.

>> x =- 5

I think you mean: x -= 5, which indeed is different.

I'm showing how it would be under the original operator design which was reverted, which was "=-".

Reply on news.ycombinator.com