14 Mar
2023
14 Mar
'23
2:48 a.m.
On 3/13/23, Clem Cole <clemc(a)ccc.com> wrote:
Too many people try to "fix" programming languages, particularly academics
and folks working on a new PhD. Other folks (Gnu is the best example IMO)
want to change things so the compiler writers (and it seems like the Linux
kernel developers) can do something "better" or "more easily." As
someone
(I think Dan Cross) said, when that happens, it's no longer C. Without
Dennis here to say "whoa," - the committee is a tad open loop. Today's
language is hardly the language I learned before the "White Book" existed
in the early/mid 1970s. It's actually quite sad. I'm not so sure we are
"better" off.
I'd rather see programming language standards committees restrict
their activity to regularizing existing practice. Let vendors and
others innovate by adding non-standard extensions. Then take those
that are really useful and adopt them as part of the standard. But
the committee itself should not be doing design. We all know what
they say about "design by committee", and it's all too true.
Programming language standards committees also tend to suffer from
what I call the "dog and fire hydrant" problem. The committee members
are like a pack of dogs, with the standard being the fire hydrant.
Each dog doesn't consider the fire hydrant "theirs" until they've
pissed on it. Programming languages get treated the same way by
standards committee members.
-Paul W.