Facebook open sources flint, a C++ linter written in D

Sergei Nosov sergei.nosov at gmail.com
Tue Feb 25 05:00:54 PST 2014


On Tuesday, 25 February 2014 at 11:22:23 UTC, bearophile wrote:
> Andrei Alexandrescu:
>
>> http://www.reddit.com/r/programming/comments/1yts5n/facebook_open_sources_flint_a_c_linter_written_in/
>
> 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.<
>
> Bye,
> bearophile

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.


More information about the Digitalmars-d-announce mailing list