Feedback on Átila's Vision for D

Russel Winder russel at winder.org.uk
Thu Oct 17 08:26:50 UTC 2019


On Wed, 2019-10-16 at 14:53 +0000, Atila Neves via Digitalmars-d wrote:
[…]
> 
> I'm not sure how many D users currently use CLion, would like to 
> or willing to pay for it even if such a plugin existed.

Just at the moment, I'd probably say: none. The D plugin is not at a stage
where it is usable to do debugging.

Free CLion licences can be obtained from JetBrains for people working on FOSS
projects. IDEA and PyCharm have free and pay for versions, CLion and GoLand
allow for free licences for the pay for edition. As for other JetBrains
products, I have no idea, these are the four I use.

> I also don't know how different that is/would be from people 
> currently using VisualD.

It would be a plugin for CLion instead of for Visual Studio.

As far as I am aware Visual Studio is not available on Linux.
 
> Is that it, though? go fmt? *That's* the "tooling"?
> 

Clearly not, it is just one of the tools. Consider someone saying "dfmt is the
totality of the D tooling".

> And yet, as far as I can remember or am aware of, Go managed to 
> get very popular despite not having an officially blessed IDE 
> from the get-go. Correct me if I'm wrong, but the way I remember 
> it is the users came first, then IDE solutions showed up to cater 
> to the new clientele.

This is true, but the fashion for Go is not a simple piece of history to
unravel. And remember large numbers of people considered Emacs, VIM, Atom,
etc. completely and totally inadequate for the task of writing lots of Go
code. Some started writing a plugin for IntelliJ IDEA, and when JetBrains saw
an income stream appearing they took it over and created GoLand.

> I disagree. Emacs in 2019 is vastly different from what it was in 
> the 90s, never mind the 80s. I don't think I miss anything from 
> an IDE while using Emacs to write D except for refactoring 
> support. Anything I'd personally care about, anyway.

Possibly but many still consider Emacs and VIM to be inadequate to the task of
being an IDE. Just because you are happy using it and it alone doesn't
necessarily apply to the programmers we want to get using D. VSCode, CLion,
and their ilk are what a lot of people expect to be able to use as IDEs. 

(I emphasise CLion here over IntelliJ IDEA because CLion is the JetBrains IDE
that supports using gdb and lldb.)
 
> We had IDEs before that. I learned C by typing it into Borland's 
> IDE and only transitioned to gcc via DJGPP, which emulated 
> Borland's TUI.

Borland Delphi is arguably the first IDE to have taken off big time. and yet
it wasn't till the 2000 that we got Eclipse, NetBeans, and then later still
IntelliJ IDEA.

And of course there were C (and sort of C++) environments for development and
ICE of embedded system software. But they were always very expensive.

> Obvious for some. Eclipse infuriated me so much I went back to 
> Emacs and I haven't looked back since.

And that is fine; personal choice is important in these things. You chose to
return to The One True Editor™ (and kitchen sink) as your "IDE". But you must
recognise there are many for whom "no IDE means no using the language". If
VSCode and one of four of five plugins is the only offering for a D IDE then
opportunity to collect more users is being missed.

The D plugin to IntelliJ IDEA, but more realistically CLion – Rust started and
is still usable in IntelliJ IDEA but added CLion to get debugging – is a lot
of the way there, but not sufficient to be usable. The volunteers working on
this try to do a great job, but they are volunteers. I keep trying to suggest
to JetBrains they should take this plugin on board as an official one, but
unlike Rust and Go, they see no future income stream from any D investment.

> People's preferences differ, however, and I'm trying to 
> understand what it is that doesn't work for them with the options 
> they have right now.

Restricting people to Emacs and VSCode is to advertise that "this is what we
use, if you do not like it, go away". D support has gone beyond this, there is
the beginnings of what could be an excellent CLion plugin. If D is to appeal
to C, C++, and Rust programmers who use CLion (and there are a great number of
them), then there needs to be a working plugin. This isn't going to happen
based on volunteers only. Which seems to indicate it isn't going to happen.
Which effectively means the D community is turning it's back on a whole ready-
made audience of potential users.

> I assume JetBrains took over the Rust plugin because it'd make 
> them money. I'm not sure we could say the same thing.

JetBrains only do things for income stream reasons these days, the evangelism
of the early 2000s is a thing of the past. Except they readily give free IDE
licences to anyone provably working on FOSS projects.

If the D community is of the view that Go and Rust can make IDE vendors money,
but D will never be able to, then D will remain a small, relatively unused
programming language. If being niche and relatively unused is what the D
community want then fine, but stop all the bluster about appealing to C, C++,
Go, Rust, and Python developers. 

> This is another thing I read a lot that I'm not sure what it 
> means. I'm aware of dub's faults, but if we eliminated them, what 
> would make cargo better? I've used cargo and still don't know. 
> Could you please elaborate on what you like about cargo that 
> you'd like to see in dub?

Go and Rust emphasised using Git, Mercurial, and Breezy repositories as
packages from the outset. Go chose not to add a central repository, Rust chose
to add one. Rust's choice was the correct one for supporting developers. In
hindsight, Go has had problems with packages from the outset based on the
initial workspace model. Slowly over the decade Go is finding ways forward.
Rust got it right from the beginning, once they had stripped down the standard
library and emphasised use of the central repository – if only Phobos could be
stripped right back to the absolute necessary and everything else provided via
the central repository. Obviously not all is good in Rust-land, just as with
Python and PyPI, the central repository is not curated, and this leads to
horrible messes. Ceylon got this more right, but it is a language few have
heard of and even fewer use.

Dub does not allow for use of Git, Mercurial, or Breezy repositories only the
uncurated (and therefore potentially problematic) central repository. OK so
you can do Git checkouts as a separate activity and use local filestore
references, but this is not feasible for packages in the central repository.

Dub builds packages to a location outside the project being worked on. Cargo
pulls sources to such a central non-project place and then compiles into a
project specific location. Dub tries to store all compiled version out of
project in the same area as the sources. Does this matter? Isn't Dub making
things easier to share? Sort of, sort of, and no. Dub stores all compilations,
but hides them and presents only the last compilation easily. This makes
things hard to work with for non-Dub tooling. Cargo makes it a lot easier, at
the expense of lack of sharing but always compiling everything into the
project area.

Cargo uses TOML, Dub uses SDL (or if you are masochistic JSON). 'nuff said.
QED.

Dub seems to have become the de facto, and indeed de jure, standard for D
build, and yet somehow Cargo is just assumed by all Rust programmers whereas
Dub is a source of contention and ill-will in the D community.

Dub's biggest problem is that there are many in the D community who will not
use it – and they are vocal about it. The solution is not censorship, the
solution is for Dub to evolve very rapidly so that these vocal people have the
rug pulled from under them, i.e. their complaints become invalid.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20191017/db4397cc/attachment-0001.sig>


More information about the Digitalmars-d mailing list