On Tuesday, 17 March 2015 at 21:16:38 UTC, Carl Sturtivant wrote:
Characterizing the problem as "Go versus D" is framing it to
D's disadvantage. Broadly speaking Go is one thing & D is many
things.
The whole difficulty with D encountered by a person choosing
which of (e.g.) Go and D to use lies in this difference. D as a
whole is overwhelming in this situation.
D may be spoken naturally in many different ways. This is its
strength. We need to make this strength accessible to
outsiders. If an outsider can speak D at first in a way
somewhat familiar from their previous experience, that will
provide accessibility.
We may classify outsiders as coming from C, C++, Java, Python,
Go and more. Make your own list.
Each kind of outsider needs to see an approximate reflection in
D of the machinery of their usual means of expression and its
attendant conceptual models, plus exciting possibilities to
improve and extend these. This reflection must be made workable
on all scales, from details of idioms and techniques up to the
big picture.
An outsider needs a well developed specialized way in! One that
is designed for that specific class of outsider. Given such, in
the short run the D written by one class of outsider will be
quite different in its use of the language to that written by
another, which will be quite different again to that written by
contributors to phobos.
We should accept this. They may expand their horizons within D
later. The community may find ways to help such people do this,
for example by gently suggesting better parts of D to use for
technical parts of their purposes when they post to the forums.
In the meantime they have come to D because there was a
relatively efficient way for them to do that, not a bewildering
collection of possibilities that deflected them to the
certainties of the overly prescribed ways of (e.g.) Go.
Now consider outsiders from C, C++, Java, Python, Go.
I'll leave you to consider C, C++. The articles
http://dlang.org/ctod.html
http://dlang.org/cpptod.html
http://dlang.org/pretod.html
have made a detail-oriented start with tacit assumptions about
what is going on at wider scales. These languages are closely
entangled with D's development, and so are special cases given
better treatment. These could be expanded into an entire
introduction to D for C outsiders and an entire introduction to
D for C++ outsiders.
Java is not too hard especially given the design of D's
classes. Java is almost a small sublanguage of D.
Python and Go are harder. But D is a system programming
language with [long list of powerful abstraction facilities,
many supported paradigms, "wonderfulness of D"]. And as such
one may hope it is possible to arrange to program in D in
Pythonesque or Goish ways. Especially if this provides a way
for D to win rather than lose out to these languages, by
providing an incremental way in.
The yield facility in Python can serve as a first example here.
This is not a part of the D language. The Fiber class in
core.thread can be made to emulate it with additional
superstructure with some effort. But this is exactly the kind
of effort an outsider from Python is not immediately equipped
to make. Go's goroutine and its attendant machinery could be
examined with a similar end in view.
What all of this suggests is that some library code may need to
be written to accomodate the way into D for a class of
outsiders. The administration of where such goes needs to make
it simple to import with a standard D installation. And if D is
too inflexible to provide something important via a library, as
is possibly the case with yield, serious consideration should
be given to (don't scream) adding it to the language.
In conclusion, D is not gaining the traction it deserves as a
potential lingua franca. I am making the case that we need to
treat it as several programming languages for the purpose of
making it rapidly usable by typical outsiders. D-python,
D-java, D-whatever --- facets of D.
This entails library additions, and possibly language
additions. This entails a lot of writing of documentation, in
effect a small book for each facet of D.
There is much to be decided about how this could be best done.
I will not pursue that here. But I do believe something
approximately like this is the only way for D to start to win
out when someone decides whether to use (e.g.) Go or D in a new
situation, or even whether to use D or stay back in Python with
all of its disadvantages. The complex cliff face of D needs
some overtly navigated paths for all kinds of explorers.
I think this is a good approach. The beauty of D is that it can
be a lot of different things to different people. Do you have any
examples yet, as in "D for Python programmers"? E.g. loops:
Python:
for item in list:
print "The item is %s" % item
D:
import std.stdio : writefln;
foreach(ref item; list) {
writefln("The item is %s", item);
}
