On Tuesday, 14 November 2017 at 19:48:07 UTC, Joakim wrote:
> On Tuesday, 14 November 2017 at 04:31:43 UTC, Laeeth Isharc wrote:
>> He mentions D, a bit dismissively.
>> http://esr.ibiblio.org/?p=7724&cpage=1#comment-1912717
>
> Eh, he parrots decade-old anti-D talking points about non-technical, organizational issues and doesn't say anything about the language itself, who knows if he's even tried it.
>
> As for the the rest, the usual bunk from him, a fair amount of random theorizing only to reach conclusions that many others reached years ago: C has serious problems and more memory-safe languages are aiming to replace it, while C++ doesn't have a chance for the same reason it took off, it bakes in all of C's problems and adds more on top.
>
> He's basically just jumping on the same bandwagon that a lot of people are already on, as it starts to pick up speed.  Good for him that he sees it picking up momentum and has jumped in instead of being left behind clinging to the old tech, but no big deal if he didn't.

I thought this was a much better post in that thread, especially the last two paragraphs:

"Some may claim that the programming language isn’t the place to look for help, but I disagree. If it can prevent language errors in the first place (memory management, type systems) and help me use available resources (concurrency), and deal with expected failure (distribution) then I want it in the flow of the program (my description of what should happen), not in some box bolted onto the side. And it has to be efficient, because I’ve only a few cycles to waste and no IO or memory.

So that’s where I’d look for action in the programming language field – not to improve C, an imperfect solution to yesterday’s problems; I want something that helps with apps that are big, distributed, concurrent, and efficient because those are the more important problems people are solving today and in the future."
http://esr.ibiblio.org/?p=7724&cpage=1#comment-1913062

To the extent microservices push in exactly this direction, D needs to make an effort there.

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

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 ;-)

Right… :-)

> Languages are just part of an evolutionary chain.

Right and C is part of this chain BCPL->B->C, the funny thing is that BCPL was never meant to be used as a language beyond bootstrapping CPL, but given the limited computers of the day BCPL and later C became the default system programming language exactly because it wasn't much of a language and fit rather well with the CPUs of the day (among other things, you could hold the whole compiler in main memory ;-).

But C doesn't fit well with the underlying hardware anymore, even though CPU makers are benchmarking against existing C code and make provisions for the C model. That argument can be used against C++, D and Rust too. :-P

So, if the abstraction no longer match the concrete well then it will make less and less  sense to use it. Overall, I think we over time will see growth in higher level languages designed to map well onto the hardware at the optimization stage. Current languages aren't quite there yet though, and frankly, neither are the CPUs. I think we are in a transition period (wide pipelines in the CPU + GPU is an indicator).

> 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.

Right, but the performance bottle-neck of serial code is now forcing changes in the environment.

> In that circumstance, it must be considered flawed, and evolutionary forces will quickly take care of that.

Not quickly, you have the whole issue with installed base, center of gravity… The mindset of people…

> But a programming language is not flawed, simply because people use it an environment where it was not designed to operate.

Ok, fair enough. BCPL was meant to bootstrap CPL and C was a hack to implement Unix… ;^)

> 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.

I don't think Go is much affected by the corporate… The Go designers appear to be strong-headed and the language design is in line with their prior language designs. I believe they also made the same mistake as D with reallocating buffers "randomly" when extending slices such that you end up with two arrays because the other slices aren't updated. Not very reassuring when a team of people make such correctness blunders. And what about their "exceptions", a dirty hack only added because they are hellbent on not having exceptions… All about the mentality of the designers… put blame where blame is due…

The design of Dart was affected by the corporate requirements according to the designer who called it a "bland language". I think he would have preferred something closer to Smalltalk :-). Dart is probably more important to Google than Go as their business frontend depends on it. And Dart is now getting static typing to the dismay of the original designer (who is in the dynamic camp).

But yeah, it can be interesting to think about how a mix of personalities and external pressure affect 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.

Seems to me that he is looking for something that is easier to deal with than C, but where he can retain his C mindset without having performance issues related to GC. So the bare-bones semantics of Go combined with a decent runtime and libraries that are geared towards network programming probably fits his use case (NTP something?)

> 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...

They exist in embedded devices/SoCs etc. Not sure if it is reasonable to say that they exist on the desktop anymore beyond a mere hygienic backwards-compatibility mentality among CPU designers.

Ola.

On Wednesday, 15 November 2017 at 09:00:38 UTC, Joakim wrote:
> problems; I want something that helps with apps that are big, distributed, concurrent, and efficient because those are the more important problems people are solving today and in the future."
> http://esr.ibiblio.org/?p=7724&cpage=1#comment-1913062
>
> To the extent microservices push in exactly this direction, D needs to make an effort there.

I'm not sure if most distributed computing require D/C++/Rust level of efficiency. Erlang isn't exactly efficient or convenient, but people still use it… for semantic reasons.

Seems like this is an area where high level protocol verification would be more important than C-style coding. And since such tools are on the way (as static semantic analysis) it will be difficult to provide good library solutions for that field.

On Wednesday, 15 November 2017 at 09:26:49 UTC, Ola Fosheim Grøstad wrote:
>
> I don't think Go is much affected by the corporate…

Umm....

"We made the language to help make google more productive and helpful internally" - Rob Pike

https://www.youtube.com/watch?v=sln-gJaURzk
2min:55sec

To be honest, it's really hard for me to be critical of something that (The) Ken Thompson was involved in ;-)

...but I've gotta speak the truth. sorry Ken. But Go sucks.

On Wednesday, 15 November 2017 at 10:40:50 UTC, codephantom wrote:
> On Wednesday, 15 November 2017 at 09:26:49 UTC, Ola Fosheim Grøstad wrote:
>>
>> I don't think Go is much affected by the corporate…
>
> Umm....
>
> "We made the language to help make google more productive and helpful internally" - Rob Pike

I know, I followed the debate for a while, but that sounds much more like a defence of their own minimalistic aesthetics (which they don't deny) than a corporate requirement. With a different team Go most certainly would have exceptions and generics, like Dart. Makes no sense to claim that their server programmers are less skilled than their front end programmers?

On Tuesday, 14 November 2017 at 11:55:17 UTC, codephantom wrote:
> The reason he can dismiss D, so easily, is because of his starting premise that C is flawed. As soon as you begin with that premise, you justify searching for C's replacement, which makes it difficult to envsion something like D.
>
> That's why we got C++, instead of D. Because the starting point for C++, was the idea that C was flawed.
>

Actually, I got that wrong.

Perhaps the mistake C++ made, was concluding that 'classes' were the "proper primary focus of program design" (chp1. The Design and Evolution of C++).

I have to wonder whether that conclusion sparked the inevitable demise of C++.

Eric should be asking a similar question about Go ..what decision has been made that sparked Go's inevitable demise - or in the case of Go, decision would be decisions.

this is what did it for me:

a := b

On Thursday, 16 November 2017 at 02:12:10 UTC, codephantom wrote:
> On Tuesday, 14 November 2017 at 11:55:17 UTC, codephantom wrote:
>>[...]
>
> Actually, I got that wrong.
>
> Perhaps the mistake C++ made, was concluding that 'classes' were the "proper primary focus of program design" (chp1. The Design and Evolution of C++).
>
> I have to wonder whether that conclusion sparked the inevitable demise of C++.
>
> Eric should be asking a similar question about Go ..what decision has been made that sparked Go's inevitable demise - or in the case of Go, decision would be decisions.
>
> this is what did it for me:
>
> a := b
interface{} definitely

On Thursday, 16 November 2017 at 02:12:10 UTC, codephantom wrote:
> Perhaps the mistake C++ made, was concluding that 'classes' were the "proper primary focus of program design" (chp1. The Design and Evolution of C++).

No, classes is a powerful modelling primitive. C++ got that right. C++ is also fairly uniform because of it. Not as uniform as Self and Beta, but more so than D.

People who harp about how OO is a failure don't know how to do real world modelling...

> I have to wonder whether that conclusion sparked the inevitable demise of C++.

There is no demise...

> Eric should be asking a similar question about Go ..what decision has been made that sparked Go's inevitable demise - or in the case of Go, decision would be decisions.

Go is growing...

> a := b

A practical shorthand, if you dont like it, then dont use it.

On 16/11/2017 6:35 AM, Ola Fosheim Grostad wrote:
> On Thursday, 16 November 2017 at 02:12:10 UTC, codephantom wrote:
>> Perhaps the mistake C++ made, was concluding that 'classes' were the "proper primary focus of program design" (chp1. The Design and Evolution of C++).
> 
> No, classes is a powerful modelling primitive. C++ got that right. C++ is also fairly uniform because of it. Not as uniform as Self and Beta, but more so than D.
> 
> People who harp about how OO is a failure don't know how to do real world modelling...

Thing is, it is a failure, the way most people use it.
When used correctly it is a very nice additive to any code base.
It just can't be the only one.