tooling quality and some random rant

[Nick Sabalausky]

"golgeliyele" <usuldan at gmail.com> wrote in message 
news:ij7s2p$1ld0$1 at digitalmars.com...
>
>I am relatively new to D. As a long time C++ coder, I love D. Recently, I 
>have started doing some coding with D.
>

Welcome.  I'm another C++ -> D refugee :)


> - Some option names are single characters and some are full words. Quality 
> tooling will support a short and a long option for most of
> these.

That's really not a matter of "quality", it's just a common Unix convention.


> - Some options have values separated from the option names via '=' some 
> via *nothing*. The latter is just unacceptable. Look at this:
> -offilename. First of all, you better list this as -of<file-name> so that 
> one can understand where the option name ends. Second, not
> allowing space or requiring = after the option name is messy and looks 
> unprofessional.

Yea, that is kinda ugly. I wouldn't go so far as to call it "unacceptable" 
though. I've always gotten by fine with it. An improvement on that would 
certainly be welcomed though.


> - All options start with '-', yet the help option starts with '--'.

I'm sure that's just to be consistent with the option to get help from 
pretty much every other command-line app out there. There's a lot of 
different switches that are sometimes accepted by certan programs for help, 
like /? or -h, but the one that you can always count on nearly anywhere 
is --help.


> - Option description text seems to be left aligned, yet there are 3 
> exceptions
>

It all looks left-aligned to me, but I'm using the Win version. Maybe it's 
different for OSX. Seems weird that it would be though.


> The error reporting has issues as well. I noticed that the compiler leaks 
> low level errors to the user. If you forget to add a main to your
> app or misspell it, you get errors like:
> ====
> Undefined symbols:
>  "__Dmain", referenced from:
>      _D2rt6dmain24mainUiPPaZi7runMainMFZv in 
> libphobos2.a(dmain2_513_1a5.o)
> ====
> I mean, wow, this should really be handled better.
>

That's not the compiler, that's the linker. I don't know what linker DMD 
uses on OSX, but on Windows it uses OPTLINK which is written in 
hand-optimized Asm so it's really hard to change. But Walter's been 
converting it to C (and maybe then to D once that's done) bit-by-bit (so to 
speak), so linker improvements are at least on the horizon.

AIUI, on Linux, DMD just uses the GCC linker, and GCC unfortunately doesn't 
know anything about D name mangling, just C/C++.  Might be true of OSX as 
well, I don't know though.


> Another annoyance, for me anyway, is that the DMD compiler outputs the .o 
> files without the package directory hierarchy. I like to
> organize my code as 'src/my/package/module.d'. And I want to set my output 
> directory to 'lib' and get 'lib/my/package/module.o'.
> But DMD generates 'lib/module.o'. I setup my project to build each .d file 
> into a .o file as a separate step. I don't even know if this is
> the desired setup. But that seems to be the way to make it incremental. I 
> couldn't find any definitive information on this in the DMD
> compiler web page. It says:
> "dmd can build an executable much faster if as many of the source files as 
> possible are put on the command line.
>
> Another advantage to putting multiple source files on the same invocation 
> of dmd is that dmd will be able to do some level of cross-
> module optimizations, such as function inlining across modules."
>
> Yes, but what happens when I have a project with million lines of code? Is 
> the suggestion to recompile it every time a file changes?
>

D compiles a few orders of magnitude faster than C++ does. Better handling 
of incremental building might be nice for really large projects, but it's 
really not a big issue for D, not like it is for C++.

Not long ago, the Google Go people were bragging about their super-fast 
compile times, but D turned out to be even faster.


> I am sure there are various other warts about tooling and I know Walter 
> and co. are working on more important stuff like 64-bit
> support, etc. However, if D wants to be successful it needs to excel in 
> all dimensions. I am sure there are people who are willing to
> improve little things like these that make a difference.
>
> IMO, despite all the innovations the D project brings, the lack of pretty 
> packaging and presentation is hurting it. I have observed
> changes for the better lately. Such as the TDPL book, the github move, the 
> new web page (honestly, the digitalmars page was and still
> is a liability for D), and may be a new web forum interface(?).
>


Additional volunteers to help out are always welcome!