On Monday, 25 January 2016 at 18:11:24 UTC, Dibyendu Majumdar
wrote:
On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu
wrote:
Hot off the press! http://wiki.dlang.org/Vision/2016H1 --
Andrei
Hi,
I am new to D, and having my own language implementation (based
off Lua) - therefore I think I can appreciate some of the
difficulties around getting more contributors to D. For what
its worth below are some thoughts on the H1 2016 priorities.
I am a would be D user - D is a tool that should help me get my
job done. I guess the vast majority of potential users are in
this bracket. To become a contributor requires one of the
following - a) it must be your day job, i.e. someone paying you
to work on the language, or b) you happen to have lots of free
time and deeply interested in D's development, plus have the
skills needed to contribute to D. I think that getting
contributors to the core of D is going to be difficult. Most
other languages/compilers that have big list of contributors
usually have one or more large organisations funding the people
working on the language. Rust, Go, Gcc, Clang, Java, C#, all
fall into this category. I am not sure about Python, but I
suspect companies like Google sponsored a lot of the work done
in Python.
Assuming that above is correct and that you will only have a
handful of people who can contribute to core D - then it seems
to me that the effort needs to be a) least wasteful, and b)
highly focused. Right now, there are multiple implementations
of D compiler - DMD, GDC, LDC, SDC - here you have a bunch of
people who obviously have the time, the knowledge and the
desire to develop D. Yet the effort is spread out into several
different implementations, and therefore wasteful. Why not form
a core group and settle on one implementation and everyone
focus on that? I know this is very hard as no one would be
willing to give up their creation, but for the greater good of
D? Perhaps you could assess each implementation and settle on
the one that has the most technical merit and future proofing?
dmd, gdc, and ldc already share a common frontend. Walter, the
main dmd developer, will never look at the llvm or gcc backends
for legal reasons; the gcc devs likely won't touch anything
that's not GPL; and the ldc devs likely prefer the license or
implementation of llvm. I'm not sure what motivates the sdc
devs, but it's likely having a frontend written in D itself that
is focused on being easily used as a library, which dmd's
recently translated D frontend isn't. Other than sdc, I doubt
there's actually much code duplication going on, so I don't think
this redundancy hurts.
As a D user who wishes to use D as a better C / C++ - my
personal needs are following:
a) D should work on the three major platforms - Windows, Linux
and OSX.
b) It should be possible to write code in D that one would have
written in C / C++ - i.e. let the programmer have full control.
c) A good debugger on all supported platforms is essential for
any complex language.
d) A good IDE is essential to attract users accustomed to
Eclipse, IntelliJ, Visual Studio.
e) A core library that handles the most basic stuff.
f) Ability to easily import C libraries. I struggled with htod
- haven't tried dstep yet - but implementing tooling based on
Clang seems sensible.
I don't think there has ever been a language that would fulfill
all these requirements, let alone an OSS one that was available
free of charge. D gets you some of the way, but it cannot grant
you all your wishes.
The need to have a good standard GUI toolkit is not so great
these days as users are moving away from Desktop applications.
Yeah, a couple toolkits in dub is fine.
I realise that interfacing with C++ seems like a big goal - but
to be honest this isn't important to me. C++ isn't the standard
for cross language interfacing ... C is.
Which is why D long didn't support interfacing with C++. But the
leadership feels there is some untapped market out there that
will warm to D once it can interface with C++ better, and I avoid
C++ like the plague so I can't say if that's true or not. I know
that I personally don't care for such C++ integration- nor do
many in the D community, or they wouldn't be using D already- but
those who do seem to have their ear for now.
