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