On Wednesday, 15 November 2017 at 02:05:27 UTC, codephantom wrote:
On Tuesday, 14 November 2017 at 16:38:58 UTC, Ola Fosheim
Grostad wrote:
It [C]is flawed... ESR got that right, not sure how anyone can
disagree.
Well I 'can' disagree ;-)
Is a scalpel flawed because someone tried to use it to screw in
a screw?
Languages are just part of an evolutionary chain.
No part of the chain should be considered flawed - unless it
was actually flawed - in that it didn't meet the demands of the
environment in which it was initially conceived. In that
circumstance, it must be considered flawed, and evolutionary
forces will quickly take care of that.
But a programming language is not flawed, simply because people
use it an environment where it was not designed to operate.
If I take the average joe blow out of his comfy house, and put
him in the middle of raging battle field, is Joe Blow flawed,
because he quickly got shot down? What's flawed there, is the
decision to take Joe Blow and put him in the battlefield.
Corporate needs/strategy, skews ones view of the larger
environment, and infects language design. I think it's infected
Go, from the get Go. I am glad D is not being designed by a
corporate, otherwise D would be something very different, and
far less interesting.
The idea that C is flawed, also skews ones view of the larger
environment, and so it too infects language design. This is
where Eric got it wrong, in my opinion. He's looking for the
language that can best fix the flaws of C.
In fact C has barely had to evolve (which is not a sign of
something that is flawed), because it works just fine, in
enviroments for which it was designed to work in. And those
enviroments still exist today. They will still exist
tomorrow..and the next day...and the next..and...
So language designers..please stop the senseless bashing of C.
Why does anyone need array index validation anyway? I don't get
it. If you're indexing incorrectly into an array..you're a fool.
btw. The conditions under which C evolved, are well documented
here. It's a facinating read.
https://www.bell-labs.com/usr/dmr/www/chist.pdf
Quite fascinating indeed.
"Although the first edition of K&R described most of the rules
that brought C’s type structure
to its present form, many programs written in the older, more
relaxed style persisted, and so
did compilers that tolerated it. To encourage people to pay more
attention to the official language
rules, to detect legal but suspicious constructions, and to help
find interface mismatches undetectable
with simple mechanisms for separate compilation, Steve Johnson
adapted his pcc compiler
to produce lint [Johnson 79b], which scanned a set of files and
remarked on dubious constructions."
"Two ideas are most characteristic of C among languages of its
class: the relationship
between arrays and pointers, and the way in which declaration
syntax mimics expression syntax.
They are also among its most frequently criticized features, and
often serve as stumbling blocks
to the beginner. In both cases, historical accidents or mistakes
have exacerbated their difficulty.
The most important of these has been the tolerance of C compilers
to errors in type."
"On the other hand, C’s treatment of arrays in general (not just
strings) has unfortunate
implications both for optimization and for future extensions. The
prevalence of pointers in C programs,
whether those declared explicitly or arising from arrays, means
that optimizers must be
cautious, and must use careful dataflow techniques to achieve
good results. Sophisticated compilers
can understand what most pointers can possibly change, but some
important usages remain
difficult to analyze."
There are quite a few snippets to take from it, but I will
finalize with the design goals regarding the spirit of C for ANSI
C11 instead.
"12. Trust the programmer, as a goal, is outdated in respect to
the security and safety programming communities. While it should
not be totally disregarded as a facet of the spirit of C, the C11
version of the C Standard should take into account that
programmers need the ability to check their work. "
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2021.htm
