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.
