On Tuesday, 25 February 2014 at 11:22:23 UTC, bearophile wrote:
Andrei Alexandrescu:


An interesting comment from Reddit:

klusark>I've been trying to build this for the past hour. It requires folly. folly requires some "double-conversion" library, but you can't use the default version, you have to build it with scripts from folly's source. After I finally get folly to get past configure stage I get some random python error in one of the build scripts. I just gave up at this point. I'm sure I could get it working, but the time isn't worth it.<


It's kind of strange (to say the least) that a D project depends on folly and gtest - the C++ libraries. I understand that flint is not purely a D project. It also builds the C++ binary and library which depends on this stuff.

But I find it important to separate the 2. And the D version should be made as easy to setup as possible. That is - no friggin autotools, makefiles and folly/boost/gtest dependencies.

I honestly think that this stuff stands in the way of the D's adoption big time. And this flint project should really be separated into C++ and D part. With D part using unittests, phobos and dub. So using it would be as simple as "dub build" and "dub test".

The difference would be even more noticeable with a neighbor C++ project requiring all that autotools nonsense.

Being a C++ developer for a decade now, personally, I can handle the D adoption curve since in its current state it's not worse than C++'s anyway. But every time I feel really awkward recommending D to someone else. Since I know they will encounter many problems which require arcane (to newcomer's mind) knowledge.

Maybe another valuable example would be a "go fix" alternative. After every release I hear the voices "It broke every line of my code", "This release is a behemoth", "D was never and will never be stable", etc. And I really think that if it could be handled by "dub fix" - nobody would ever complain.

At DConf 2013 Andrei told to that question something like - "What do you actually want? A bash script in the error message to fix that for a whole project? Well, I guess this could be done."

So, to summarize, I guess my point is, that today's tools work so smooth and with such low entering cost, that an old-dog-C++-programmer considers it magic and doesn't really value it accordingly. And since the D crowd is mostly the old-dog-C++-programmers crowd - this aspect is really "underlooked". But the (sad or great or mere) fact is that today's students are not old-dog-C++-programmers and they have really hard time using D today. So hard, that they would actually rather use Python or Go (oh, my) or Haskell (sic!) instead of D in their work.

Reply via email to