Andrei's list of barriers to D adoption

[Bruno Medeiros via Digitalmars-d]

On 06/06/2016 09:15, Russel Winder via Digitalmars-d wrote:
>> * Tooling is immature and of poorer quality compared to the
>> > competition.
> This is true.
>
> We have too many half-finished attempt at things, basically because
> everything is volunteer, not directly associated with work, activity.
> Nothing wrong with this per se, but an obvious explanation why it is
> so. Unless an oirganization or seven put some work-oriented effort into
> the tooling, nothinkg will change.
>
> I would suggest three ways forward:
>
> 1. Get effort on the IntelliJ IDEA and CLion plugin. Kingsley has made
> a start. I suggest using his work as a basis and doing a new version
> written in Kotlin instead of Java. Kotlin will be easier than Java for
> D people to work with and easy for Java people to work with.
>
> 2. Get effort on the DDT Eclipse plugin. Bruno has declared it
> finished, which is fine, but I would say it should not be treated that
> way.
>
> 3. Have one lightweight D realized cross platform IDE. Qt us probably
> the best widget set to use for this. My model here is LiteIDE which is
> a Qt-based Go IDE realized in C++. It should of course be realized in
> Go, but there are no Qt bindings for Go, only QML ones.
>

If anything is to be done about improving the IDE tooling, it should be 
work on a tool like D Completion Daemon (DCD) - that is, an IDE-agnostic 
tool for code completion and other language analysis functionality 
(find-references, refactor, etc.)

The IDE space is just too fragmented - there are now even more popular 
IDEs that than say 5 years ago - like VS Code, Atom, etc.. Even 
SublimeText is a relatively recent player.  As such it's not feasible to 
be focusing a work on just a few IDEs. You have to make the core of IDE 
functionality available in an IDE-agnostic tool.

VSCode for example has even defined a language-agnostic protocol for 
such language servers: 
https://github.com/Microsoft/vscode-languageserver-protocol/ , and there 
is work in a few other IDEs to adopt that protocol as well, and write 
their own IDE client implementation (Eclipse for example, but it's all 
very early stages).


In any case, this is all of secondary importance, IMO. The GC issue is 
much more critical. If people think D has a worthwhile future for 
building apps in real world scenarios, then the tooling will get there 
eventually, it will catch up. But if people think other languages will 
work much better for their needs (like Rust or others), no amout of 
exceptional tooling will make a difference.


BTW, "finished" is not the right word to describe the state of DDT, if 
anything it's now in maintenance mode. (actually not that different from 
what it has been in the last 1 year or so)

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros