When you avoid a breaking change in the early evolution of a language…
There were several hundred kilobytes of existing C source code in the world at the time. SEVERAL HUNDRED KB . What if you made this change to the compiler, and made an existing program wrong? That’s a potentially disastrous breaking change.
You might say “just search all the source code for that pattern” but this was two years before grep was invented! It was as primitive as can be.
It’s fifty years since this mistake was made, and since it has become embedded in popular successor languages we’ll be dealing with its repercussions for fifty more at least, I’d wager.
A very similar statement was made about the usage of tab in Makefiles; I’ve seen it several times, but I think most recently in one of the Nokia/Bell Labs Unix 50 videos (maybe the one linked below, not sure); in any case, it’s substantiated here:
I see more modern problems than needing a few more ()'s.
DDL’s came to mind Compilers that can’t self compile. P-code. Internet needed for
stupid things like help files. PROGRAMS THAT KEEP NEEDEDING HIGHER RES GRAPHICS
EVERY REVISION so you can have bigger ICON’s and smaller work space.
The only modern real mistake would say is 8 bit BYTE’s from IBM’s 360 and 32 bit ints. IBM’s PC is NOT ASCII. ASCII is 7 bit code.
C seemed to be more portable, with K&R than today.
I think I’m particularly ‘lazy’ when it comes to precedence rules. I usually don’t try to remember them and use lots of parenthesis to enforce my own precedence in code.
Of course, this assumes that parenthesis always takes precedence.