Vision for the first semester of 2016

[Joakim via Digitalmars-d-announce]

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.