D needs to get its shit together!

[Mike B Johnson via Digitalmars-d]

Seriously! D is starting to gain momentum and if things are not 
stabilized it's going to slow D down.

1 ==>> The VERY FIRST order of business is very simple:

When a new user goes to start using D for the first time, D is a 
PITA to get working! Don't believe me?!?!

Just try getting D installed on all 3 major systems for DMD, LDC, 
GDC, with an IDE, some utilities, possibly arm support(even 
though it's new and expected to have some issues), etc. The 
issues really start popping up when you are trying to use x86 + 
x64. Library issues that result in strange error messages instead 
of "This compiler is not compatible with the phobos v2.4324".

And guess what? This happens to regular users too! They either. 
A) know how to fix them from fixing them in the past or helping 
others(so it doesn't count because the problem still exists) or 
B) have a specific setup that happens to avoid the major 
issues(e.g., just use linux x86) then act like there isn't any 
problems with D.

But no one wants to work on the part of D that deals with these 
problems cause it's boring and most "experts" can deal with the 
problems in a few mins to a few hours... doesn't seem like a huge 
waste of time(even though it is, since it's a waste).

D needs to just work! Library errors, setup problems, IDE 
integration should just work! It seems the changes of it working 
are about 75-85%... that IS LOW! It should be 99%. (And I'm 
talking across the board)

DMD, LDC, GDC, Visual D, Coedit(or whatever the other main IDE's 
are), the utilities(Dustmite, DFormat, etc) should all just work 
seamlessly and without hassle with each other.

What is the main problem? It's very simple: The way the paths are 
stored and retrieved is ancient and prone to bugs and it seems 
there is no clear cut way on how to get everything to find 
everything else. Also, versioning is not always there so even if 
the paths are right, the files in them may not be!

Multiple versions should be able to exist side by side(since D is 
ever changing and sometimes new versions simply don't work like 
they should, then downgrading starts causing problems).


Solution Ideas:

This is a simple problem that needs to be fixed. The installer 
needs to be updated to act as more of a package manager(a 
graphical one for us on windows) that has versioning checks and 
such in it. It doesn't have to be fancy, but should do a bit more 
work than the current on which is basically more trouble then 
just compressing the zip and editing sc.ini by hand.

1. A unified path/directory layout that is unambiguous and every 
D app can rely on.

e.g.,

\Dlang\Compilers\DMD\v2\73.01  (the v2 stuff hence forth replaced 
with <version>
\Dlang\Compilers\DMD\v2\main <- a junction/link to the current 
version, usually the latest

\Dlang\Compilers\DMD\Lib\Phobos\x86\coff\<version>
\Dlang\Compilers\DMD\Lib\Phobos\x86\omf\<version>
\Dlang\Compilers\DMD\Lib\Phobos\x64\coff<version>
\Dlang\Compilers\DMD\Lib\Phobos\x64\omf<version> (even though it 
doesn't exist, just empty, maybe a text file in it stating that 
it is not used for x64)

\DLang\Source\DMD\v...
\DLang\Docs\v...
\DLang\IDEs\VisualD\v...
\DLang\Utilities\DFormat\v...
\DLang\Utilities\DustMite\v...

\DLang\Packages\Derelict\v...
....

and so fourth. I'm not saying it has to be exactly like the one 
above, but the above is unambiguous. One could change compiler 
versions, even have a "master" compiler that simply chooses dmd, 
ldc, gdc, etc and could verify versions if necessary, etc.


Everything gets organized and has a place that is logical and 
hence easy to find, easy to use, and helps in diagnosing 
problems. Versioning and dependencies could be charted. (e.g., a 
change in one version of something doesn't necessarily break it's 
usage with everything else that hasn't been updated, so  we can 
have a table of things that work with each other based on 
versions. We can change, say, the version of DMD to use and the 
front end can consult the master version table to see what 
utilities that work with it and then update all the hard links.

External usages(like windows dlls, link.exe) are all handled. 
They are a) copied from their windows locations. b) noted the 
location they are copied from by adding a text file in the 
directory, etc) (and the installer\manager can refresh everything)

One can install on demand any aspect so everything isn't created 
at once.

As time evolves, this system of organization gets cleaner, 
clearer, and more optimal rather than the current system which 
seems to just be stagnant and relatively broke. It works, for the 
most part, but as time goes on it doesn't get any better at it's 
job. It's usually the same problems over and over and that is why 
you always get a steady stream of users having issues with D due 
to problems that are easily fixable with a little elbow grease 
and thought and a significant amount of desire to get the problem 
fixed[breath!]. Versioning gets better and better. If D1 had this 
type of system, we could simply set the version of to a D1 
compiler and everything would automatically be fixed up. No 
trying to hunt down libraries that work with the correct versions 
and no using utilities that do not work with it. Then with a 
flick of a switch, switch back to D2. With a master site that 
essentially keeps the installation files in a similar 
configuration, the manager just retrieves them... so we don't 
actually have to keep old versions around. We can just download 
them and it will download everything required and their proper 
versions.