ESR on post-C landscape

Paulo Pinto pjmlp at progtools.org
Wed Nov 15 09:17:11 UTC 2017


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




More information about the Digitalmars-d-learn mailing list