[oblio]

That period lasted what, 10 years after Unix was created? And we'll be stuck with those decisions decades if not centuries.

Similar story with the design of QDOS / MS-DOS / Windows and nowadays with Android. Both designed for super underpowered machines that basically went away less than a decade after they were launched and that will be hobbled because of those early decisions for a long, long time.

[compiler-guy]

We will be hobbled with these decisions for a long time precisely because the complete package of trade offs the designers made were so successful.

If they had gone for wart-free on properly powered hardware, they would be stuck back in Multics land or living with the gnu Hurd—cancelled for being over budget or moving so slowly that projects that actually accomplish what the users need overtake them.

Do I wish that C had fixed its operator precedence problem? Sure. But the trade offs as a total package make a lot of sense.

[pjmlp]

Some would say,

https://multicians.org/history.html

Instead we pile mitigations on top of mitigations, with hardware memory tagging being the last hope to fix it.

[colejohnson66]

Is there an explanation on why C’s operator precedence is weird? Such as: why does the bitwise AND have higher precedence than logical AND?

[compiler-guy]

There is, and it is amusing

“In retrospect it would have been better to go ahead and change the precedence of & to higher than ==, but it seemed safer just to split & and && without moving & past an existing operator. (After all, we had several hundred kilobytes of source code, and maybe 3 installations....)“

https://www.lysator.liu.se/c/dmr-on-or.html

[briantakita]

> why does the bitwise AND have higher precedence than logical AND?

Why is this precedence weird? Bitwise AND tends to be used to transform data while a logical AND tends to be used for control flow.

[colejohnson66]

I meant equals having a higher precedence than bitwise AND.

As in:

    if (x & 2 == 2)

...is actually parsed as:

    if (x & (2 == 2))

...which isn’t intuitive.

[compiler-guy]

See the above example from dmr himself

[briantakita]

> that will be hobbled because of those early decisions for a long, long time.

Perhaps this is why a programmer would want to rewrite a system & tout "funny success stories" about the effort & results?

https://news.ycombinator.com/item?id=25844428

> Why couldn't you just upgrade the dependencies once then set up the same CI/CD you're presumably using for Svelte so that you can them upgrade versions easily?

Because the existing system was painful & time/energy intensive to upgrade. It happens with tight coupling, dependency hell, unchecked incidental complexity, architecture churn, leaky abstractions, etc...

Maintenance hell & > 1 month major version upgrades tend to occur with large, encompassing, first-mover frameworks, often built on a brittle set of abstractions, as they "mature" & "adapt" to the competition. e.g. Rails, Angular...