"golgeliyele" <[email protected]> wrote in message news:[email protected]... > >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!
