www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Feedback for this editorial cartoon

reply James Lu <jamtlu gmail.com> writes:
https://ibb.co/w6gQWwJ

What other details could be added? I have some experience with 
using Node.js as a systems language, so I can add that. I don't 
have experience with Go or Rust, so I can add that.

Thanks to the use of symbolic inclusion, I can very easily modify 
this sketch
Jan 26
next sibling parent reply Laeeth Isharc <laeeth laeeth.com> writes:
On Sunday, 26 January 2020 at 18:50:05 UTC, James Lu wrote:
 https://ibb.co/w6gQWwJ

 What other details could be added? I have some experience with 
 using Node.js as a systems language, so I can add that. I don't 
 have experience with Go or Rust, so I can add that.

 Thanks to the use of symbolic inclusion, I can very easily 
 modify this sketch
It's pretty difficult to capture in a couple of dimensions. And whether you should use D very much depends on who you are and what you are trying to achieve. I think the people at Weka really know C++ pretty well. And the build problems they had with D in the beginning are pretty hard to top. But I don't think the technical leadership would say "well, we should have used C++". So one of the more prominent examples of successful use of D within the enterprise happens to have conditions that were quite extreme in relation to your reasons not to use D, and yet their lived experience was quite different. An anomaly like that might make one think about what's missing. You don't necessarily need to port C++ libraries to use them. D does have extern (C++) - it's by no means perfect and has rough edges but it is usable. DPP will work for some things. If you're really good with C++ you can write tools to generate wrappers automatically using libclang, libtooling or cling. And supposing you did have to do a one-off port or writing of manual bindings/wrappers. That's an upfront cost that in economic terms can be amortised over the life of the project. Of course not everyone is in a context where it's possible to think in economic terms; there are social factors at work often. Even then though, one way to address those is to have skin in the game. If someone voluntarily does a lot of preparatory work or work that takes away the technical risk and perceptions of that then social factors might in some cases fade away. Only quite unusual people would do that, it is true. But people adopting D in the enterprise at this point are not entirely ordinary people. I think D is unusual in its range. So a comparison of D versus C++ might be appropriate in some cases, but in others it's D versus C++, python, Perl, bash and VBA! If someone doesn't think they should use D, they probably shouldn't use D. I think you can only persuade people when they are coming towards you anyway, or at least it's much easier that way.
Jan 26
parent reply James Lu <jamtlu gmail.com> writes:
On Monday, 27 January 2020 at 00:19:56 UTC, Laeeth Isharc wrote:
 [...]
 So one of the more prominent examples of successful use of D 
 within the enterprise happens to have conditions that were 
 quite extreme in relation to your reasons not to use D, and yet 
 their lived experience was quite different.  An anomaly like 
 that might make one think about what's missing.

 [...]
 You don't necessarily need to port C++ libraries to use them.  
 D does have extern (C++) - it's by no means perfect and has 
 rough edges but it is usable.  DPP will work for some things.  
 If you're really good with C++ you can write tools to generate 
 wrappers automatically using libclang, libtooling or cling.

 And supposing you did have to do a one-off port or writing of 
 manual bindings/wrappers.
  That's an upfront cost that in economic terms can be amortised 
 over the life of the project.

 [...]
I want to add a "scope of usefulness" axis and a "LANGUAGE for PURPOSE" icons to the picture.
 [...]
 I think D is unusual in its range.  So a comparison of D versus 
 C++ might be appropriate in some cases, but in others it's D 
 versus C++, python, Perl, bash and VBA!
 
 [...]
I agree with the sentiment that "D vs. Not C++" sentiment. I would rewrite the Node.JS game I maintain in D instantly if there were a trustworthy concurrent moving gc available, and if I could get a standalone compiler binary to run without entering sudo.
Jan 27
parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Tuesday, 28 January 2020 at 00:14:30 UTC, James Lu wrote:
 if I could get a standalone compiler binary to run without 
 entering sudo.
You can: https://dlang.org/install.html Bastiaan.
Jan 28
prev sibling next sibling parent reply bauss <jj_1337 live.dk> writes:
On Sunday, 26 January 2020 at 18:50:05 UTC, James Lu wrote:
 https://ibb.co/w6gQWwJ

 What other details could be added? I have some experience with 
 using Node.js as a systems language, so I can add that. I don't 
 have experience with Go or Rust, so I can add that.

 Thanks to the use of symbolic inclusion, I can very easily 
 modify this sketch
In my almost 10 years of using D I have not come across any compiler bugs that I couldn't easily work-around tbh. Even more so today I rarely get experience one and I have multiple different types of D projects with thousands of lines of code. And that's despite me almost exclusively using Windows which is often the platform left behind by the D community. Like every time I see someone reporting a bug for the compiler here on the forums it's always some obscure scenario that isn't a scenario you usually get into and often there are work-arounds. That isn't to say D doesn't have problems etc. but I think your little graphic is exaggerating a lot about the state of D.
Jan 26
parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Monday, 27 January 2020 at 03:05:57 UTC, bauss wrote:
 Like every time I see someone reporting a bug for the compiler 
 here on the forums it's always some obscure scenario that isn't 
 a scenario you usually get into and often there are 
 work-arounds.
The threat profile of compiler bugs is rarely "we can't move forward with this functionally", but that's not the problem - the problem is "we assumed this works and now our code crashes in production and makes us look bad." And work-arounds rely on you remembering to apply them - not every compiler bug is a crash at compiletime. D has had more than its fair share of miscompilation bugs. And those obscure scenarios are usually reductions of more complex but individually plausible projects. Of course it looks obscure with the business case filed off.
Jan 26
next sibling parent bauss <jj_1337 live.dk> writes:
On Monday, 27 January 2020 at 05:54:20 UTC, FeepingCreature wrote:
 On Monday, 27 January 2020 at 03:05:57 UTC, bauss wrote:
 Like every time I see someone reporting a bug for the compiler 
 here on the forums it's always some obscure scenario that 
 isn't a scenario you usually get into and often there are 
 work-arounds.
The threat profile of compiler bugs is rarely "we can't move forward with this functionally", but that's not the problem - the problem is "we assumed this works and now our code crashes in production and makes us look bad." And work-arounds rely on you remembering to apply them - not every compiler bug is a crash at compiletime. D has had more than its fair share of miscompilation bugs. And those obscure scenarios are usually reductions of more complex but individually plausible projects. Of course it looks obscure with the business case filed off.
C++ has compiler bugs too, D isn't alone in that domain. In fact GCC has more open bugs than D currently does. (According to a quick search.) I would say that D probably has more "critical" bugs though, so I'll give that one. But I do think this is still biased towards C++ and isn't being fair on D.
Jan 27
prev sibling next sibling parent bauss <jj_1337 live.dk> writes:
On Monday, 27 January 2020 at 05:54:20 UTC, FeepingCreature wrote:
 On Monday, 27 January 2020 at 03:05:57 UTC, bauss wrote:
 Like every time I see someone reporting a bug for the compiler 
 here on the forums it's always some obscure scenario that 
 isn't a scenario you usually get into and often there are 
 work-arounds.
The threat profile of compiler bugs is rarely "we can't move forward with this functionally", but that's not the problem - the problem is "we assumed this works and now our code crashes in production and makes us look bad." And work-arounds rely on you remembering to apply them - not every compiler bug is a crash at compiletime. D has had more than its fair share of miscompilation bugs. And those obscure scenarios are usually reductions of more complex but individually plausible projects. Of course it looks obscure with the business case filed off.
C++ has compiler bugs too, D isn't alone in that domain. In fact GCC has more open bugs than D currently does. (According to a quick search.) I would say that D probably has more "critical" bugs though, so I'll give that one. But I do think this is still biased towards C++ and isn't being fair on D.
Jan 27
prev sibling parent reply James Lu <jamtlu gmail.com> writes:
On Monday, 27 January 2020 at 05:54:20 UTC, FeepingCreature wrote:
 [...]
 And those obscure scenarios are usually reductions of more 
 complex but individually plausible projects. Of course it looks 
 obscure with the business case filed off.
 [...]
I imagine 'we need to urgently ship this feature to unblock another team, but compiler bugs stop us' might be a common scenario too.
Jan 27
next sibling parent bauss <jj_1337 live.dk> writes:
On Tuesday, 28 January 2020 at 00:15:55 UTC, James Lu wrote:
 On Monday, 27 January 2020 at 05:54:20 UTC, FeepingCreature 
 wrote:
 [...]
 And those obscure scenarios are usually reductions of more 
 complex but individually plausible projects. Of course it 
 looks obscure with the business case filed off.
 [...]
I imagine 'we need to urgently ship this feature to unblock another team, but compiler bugs stop us' might be a common scenario too.
Just stay at a version of the compiler you know works and then only upgrade once you can actually afford to spend time fixing such quirks.
Jan 27
prev sibling parent norm <norm.rowtree gmail.com> writes:
On Tuesday, 28 January 2020 at 00:15:55 UTC, James Lu wrote:
 On Monday, 27 January 2020 at 05:54:20 UTC, FeepingCreature 
 wrote:
 [...]
 And those obscure scenarios are usually reductions of more 
 complex but individually plausible projects. Of course it 
 looks obscure with the business case filed off.
 [...]
I imagine 'we need to urgently ship this feature to unblock another team, but compiler bugs stop us' might be a common scenario too.
I'm sceptical, have you honestly been in this situation yourself? From my experience using D in production we have never had a compiler bug that blocked our work. We upgrade the compiler every 6 months. The last bug encountered that meant we could not upgrade was in 2015 -- can't remember or be bothered to check the exact version. It did not block us because we always test the new compiler before pulling the switch, as we do for our C++ and Python code as well. Cheers, Norm
Jan 27
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Sunday, 26 January 2020 at 18:50:05 UTC, James Lu wrote:
 https://ibb.co/w6gQWwJ

 What other details could be added? I have some experience with 
 using Node.js as a systems language, so I can add that. I don't 
 have experience with Go or Rust, so I can add that.

 Thanks to the use of symbolic inclusion, I can very easily 
 modify this sketch
I don't agree with the picture in my opinion. I think that D and C++ have about the same complexity for beginners. You can program very C like in both C++ and D. However, when you start to tread into more complex territory, this is when the complexity of C++ exponentially increase. C++ projects tend to become spaghetti faster. D reduces this complexity compared to C++. Big projects with a lot of files will probably benefit from D as D is more compact, readable and requires less files. The libraries of D are usually more convenient as well. The reason I wouldn't use D in project is stability and availability of D programmers. All D compilers have bugs and are not as stable as GCC or Clang and I would not use D for mission critical projects and in this case C/C++ is a better choice for now. It also depends on the projects. C/C++ is still king in low level programming and D has hard times to compete here. With applications it depends. D is held back by not having a true multi platform GUI library. C++ has Qt for example. When it comes other types of programs then D is really a viable option. The picture is kind of simplistic and therefore cannot explain the complex decisions why a project should use C++ or D.
Jan 27
parent reply drug <drug2004 bk.ru> writes:
On 1/27/20 12:52 PM, IGotD- wrote:
 Big projects with a lot of files will probably benefit from D as D is 
 more compact, readable and requires less files. The libraries of D are 
 usually more convenient as well.
I have two implementation of one project in D and C++. D version contains less files and their content is shorter (less boiler plate code) and D version has a bit more functionality. Making proof of concept in D (in my domain at least) is more pleasant and productive due to meta programming.
 
 The reason I wouldn't use D in project is stability and availability of 
 D programmers. All D compilers have bugs and are not as stable as GCC or 
I completely agree to low availability of D programmers but don't agree to statement about stability. Both D and C++ compilers have bugs. I stumbled only once at gcc bug but that was a real problem. D compiler bugs were much more easy to solve/workaround.
Jan 27
parent reply Craig Dillabaugh <craig.dillabaugh gmail.com> writes:
On Monday, 27 January 2020 at 10:12:06 UTC, drug wrote:
 On 1/27/20 12:52 PM, IGotD- wrote:
 Big projects with a lot of files will probably benefit from D 
 as D is more compact, readable and requires less files. The 
 libraries of D are usually more convenient as well.
clip
 I completely agree to low availability of D programmers but 
 don't agree ....
If I were managing a D project I personally wouldn't have any qualms about hiring skilled C++ developers who expressed a willingness to learn D. I bet in many cases it would only be a matter of weeks before they were more productive in D than they were with C++ for most run-of-the-mill coding tasks. Writing more advanced code might take longer. While D certainly has some differences to C++ I think the skill sets are highly transferable.
Jan 27
parent drug <drug2004 bk.ru> writes:
On 1/27/20 8:55 PM, Craig Dillabaugh wrote:
 If I were managing a D project I personally wouldn't have any qualms 
 about hiring skilled C++ developers who expressed a willingness to learn 
 D.  I bet in many cases it would only be a matter of weeks before they 
 were more productive in D than they were with C++ for most 
 run-of-the-mill coding tasks. Writing more advanced code might take 
 longer. While D certainly has some differences to C++ I think the skill 
 sets are highly transferable.
I'm totally agree to you too. But this is a workaround and doesn't negate low availability of D programmers. This complicates hiring a bit but this complexity is reasonable I think.
Jan 27
prev sibling parent Basile B. <b2.temp gmx.com> writes:
On Sunday, 26 January 2020 at 18:50:05 UTC, James Lu wrote:
 https://ibb.co/w6gQWwJ

 What other details could be added? I have some experience with 
 using Node.js as a systems language, so I can add that. I don't 
 have experience with Go or Rust, so I can add that.

 Thanks to the use of symbolic inclusion, I can very easily 
 modify this sketch
I dont understand this representation. Easy Hard, should give a kind of vector. In my opinion this stinks. You don't get if something is best.
Jan 27