He mentions D, a bit dismissively.
http://esr.ibiblio.org/?p=7724&cpage=1#comment-1912717

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

"[snip]...Then came the day we discovered that a person we incautiously gave commit privileges to had fucked up the games’s AI core. It became apparent that I was the only dev on the team not too frightened of that code to go in. And I fixed it all right – took me two weeks of struggle. After which I swore a mighty oath never to go near C++ again. ...[snip]"

Either no one manages SW in his team so that this "bad" dev could run off and to build a monster architecture, which would take weeks, or this guy has no idea how to revert commit.

I stopped reading at this point.

On Tuesday, 14 November 2017 at 06:32:55 UTC, lobo wrote:
> "[snip]...Then came the day we discovered that a person we incautiously gave commit privileges to had fucked up the games’s AI core. It became apparent that I was the only dev on the team not too frightened of that code to go in. And I fixed it all right – took me two weeks of struggle. After which I swore a mighty oath never to go near C++ again. ...[snip]"
>
> Either no one manages SW in his team so that this "bad" dev could run off and to build a monster architecture, which would take weeks, or this guy has no idea how to revert commit.

ESR got famous for his cathedral vs bazaar piece, which IMO was basically just a not very insightful allegory over waterfall vs evolutionary development models, but since many software developers don't know the basics of software development he managed to become infamous for it… But I think embracing emergence has hurt open source projects more than it has helped it. D bears signs of too much emergence too, and is still trying correct those «random moves» with DIPs.

ESR states «C is flawed, but it does have one immensely valuable property that C++ didn’t keep – if you can mentally model the hardware it’s running on, you can easily see all the way down. If C++ had actually eliminated C’s flaws (that it, been type-safe and memory-safe) giving away that transparency might be a trade worth making. As it is, nope.»

I don't think this is true, you can reduce C++ down to the level where it is just like C. If he cannot mentally model the hardware in C++ that basically just means he has never tried to get there…

I also think he is in denial if he does not see that C++ is taking over C. Starting a big project in C today sounds like a very bad idea to me.

Actually, one could say that one of the weaknesses of C++ is that it limited by a relatively direct mapping to the underlying hardware and therefore makes some types of optimization and convenient programming harder.

*shrug*

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

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.

C is not flawed. It doesn't need a new language to replace it.

If that was the starting point for Go and Rust, then it is ill conceived.

One should also not make the same error, by starting with the premise that we need a simpler language to replace the complexity of the C++ language.

If that was the starting point for Go and Rust, then it is ill conceived.

What we need, is a language that provides you with the flexibility to model your solution to a problem, *as you see fit*.

If that were my starting point, then it's unlikely I'd end up designing Go or Rust. Only something like D can result from that starting point.

I'd like Eric to go write a new article, with that being the starting point.
Because then, it's unlikely he would get away with being so dismissive of D.

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.

Well, in another thread he talked about the Tango split, so not sure where he is coming from.

> That's why we got C++, instead of D. Because the starting point for C++, was the idea that C was flawed.

No, the starting point for C++ was that Simula is better for a specific kind of modelling than C.

> C is not flawed. It doesn't need a new language to replace it.

It is flawed... ESR got that right, not sure how anyone can disagree. The only thing C has going for it is that CPU designs have been adapted to C for decades. But that is changing. C no longer models the hardware in a reasonable manner.

> If that was the starting point for Go and Rust, then it is ill conceived.

It wasn't really. The startingpoint for Go was just as much a language used to implement Plan 9. Don't know about Rust, but it looks like a ML spinoff.

> One should also not make the same error, by starting with the premise that we need a simpler language to replace the complexity of the C++ language.

Why not? Much of the evolved complexity of C++ can be removed by streamlining.

> If that was the starting point for Go and Rust, then it is ill conceived.

It was the starting point for D...

> What we need, is a language that provides you with the flexibility to model your solution to a problem, *as you see fit*.
>
> If that were my starting point, then it's unlikely I'd end up designing Go or Rust. Only something like D can result from that starting point.

Or C++, or ML, or BETA, or Scala, or etc etc...

> Because then, it's unlikely he would get away with being so dismissive of D.

If he is dismissive of C++ and Rust then he most likely will remain dismissive od D as well?

On Tuesday, 14 November 2017 at 06:32:55 UTC, lobo wrote:
> And I fixed it all right – took me two weeks of struggle. After which I swore a mighty oath never to go near C++ again. ...[snip]"

 Reminds me of the last time I touched C++. A friend wanted help with the Unreal Engine. While skeptical the actual headers and code I was going into were... really straight forward. #IfDef's to encapsulate and control if something was/wasn't used, and simple C syntax with no overrides or special code otherwise.

 But it was ugly... it was verbose... it was still hard to find my way around. And I still don't want to ever touch C++ if I can avoid it.

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.

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

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

I think that the date he mentions in that paragraph (2001) speaks a lot for his argument, i.e. completely outdated.

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

Couldn't read that without cringing.