What are the worst parts of D?

[H. S. Teoh via Digitalmars-d]

On Wed, Sep 24, 2014 at 10:23:48PM -0700, Walter Bright via Digitalmars-d wrote:
> On 9/24/2014 10:08 PM, H. S. Teoh via Digitalmars-d wrote:
> >If you like building real airplanes out of Lego pieces, be my guest.
> >Me, I prefer using more suitable tools. :-P
> 
> I spend very little time fussing with make. Making it work better
> (even to 0 cost) will add pretty much nothing to my productivity.

Oh? Let's see. One time, while git bisecting to track down a dmd
regression, I was running into all sorts of strange inconsistent
behaviour from dmd. After about a good 15-30 mins' worth of frustration,
I tracked down the source of the problem to make not cleaning up
previous .o files, and thus producing a corrupted dmd which contained a
mixture of who knows what versions of each .o left behind from previous
git bisect steps. So I realized that I had to do a make clean every time
to ensure I'm actually getting the dmd I think I'm getting. Welp, that
just invalidated my entire git bisect session so far. So git bisect
reset and start over.

Had dmd used a reliable build system, I wouldn't have wasted that time,
plus I'd have the benefit of incremental builds instead of the extra
time spent running make clean, and *then* rebuilding everything from
scratch. Yup, it wouldn't *add* to my productivity, but it certainly
*would* cut down on my *unproductivity*!

Now, dmd's makefile is very much on the 'simple' end of the scale, which
I'm sure you'll agree if you've seen the kind of makefiles I have to
deal with at work. Being simple means it also doesn't expose many of
make's myriad problems. I've had to endure through builds that take 30
minutes to complete for a 1-line code change (and apparently I'm already
counted lucky -- I hear of projects whose builds could span hours or
even *days* if you're unlucky enough to have to build on a low-end
machine), only to find that the final image was corrupted because
somewhere in that dense forest of poorly-hackneyed makefiles in the
source tree somebody had forgotten to cleanup a stray .so file, which is
introducing the wrong versions of the wrong symbols to the wrong places,
causing executables to go haywire when deployed.

Not to mention that some smart people in the team have decided that
needing to 'make clean' every single time following an svn update is
"normal" practice, thus every makefile in their subdirectory is
completely broken, non-parallizable, and extremely fragile. Hooray for
the countless afternoons I spent fixing D bugs instead of doing paid
work -- because I've to do yet another `make clean; make` just to be
sure any subsequent bugs I find are actual bugs, and not inconsistent
builds caused by our beloved make. You guys should be thankful, as
otherwise I would've been too productive to have time to fix D bugs. :-P

And let's not forget the lovely caching of dependency files from gcc
that our makefiles attempt to leverage in order to have more accurate
dependency information -- information which is mostly worthless because
you have to make clean; make after making major changes anyway -- one
time I didn't due to time pressure, and was rewarded with another
heisenbug caused by stale .dep files causing some source changes to not
be reflected in the build. Oh yeah, spent another day or two trying to
figure that one out.

Oh, and did I mention the impossibility of parallelizing our builds
because of certain aforementioned people who think `make clean; make` is
"normal workflow"? I'd hazard to guess I could take a year off work from
all the accumulated unproductive times waiting for countless serial
builds to complete, where parallelized builds would've saved at least
half that time, more on modern PCs.

Reluctance to get rid of make is kinda like reluctance to use smart
pointers / GC because you enjoy manipulating raw pointers in high-level
application code. You can certainly do many things with raw pointers,
and do it very efficiently 'cos you've already memorized the various
arcane hacks needed to make things work over the years -- recite them in
your sleep even. It's certainly more productive than spending downtime
learning how to use smart pointers or, God forbid, the GC -- after you
discount all the time and effort expended in tracking down null pointer
segfaults, dangling pointer problems, memory corruption issues, missing
sizeof's in malloc calls, and off-by-1 array bugs, that is.

To each his own, I say. :-P


T

-- 
People tell me that I'm skeptical, but I don't believe them.