D popularity

[H. S. Teoh]

On Mon, Jan 21, 2013 at 07:09:50PM +0100, monarch_dodra wrote:
> On Monday, 21 January 2013 at 17:56:05 UTC, H. S. Teoh wrote:
> >On Mon, Jan 21, 2013 at 05:32:12PM +0100, monarch_dodra wrote:
> >>The only thing holding me back from D is that it is unreliable.  I'm
> >>not just talking about bugs in Phobos (which can easilly found
> >>and/or fixed).
> >>
> >>I'm talking about all the unreliable voldemort structs, the context
> >>pointers, the delegates, the destructor sequences, memory management
> >>and whatnot.
> >
> >Oh? What's so unreliable about delegates? I find that they work quite
> >well in general.
[...]
> I've stayed away from them mostly, so I may be unfair, but I'm
> mostly thinking about delegates that reference external data via
> context pointers.
> 
> Come to think about it, everything I dislike about about D always
> boils down to "context pointer". That thing is so scary unsafe, and
> can so easily back fire on you :(

Actually, I find delegates to be a big plus in my choosing to adopt D.
They make it a lot of very complex, tedious code very easy to write.
Non-trivial event-driven code is basically unwritable and unreadable
(without lots of hair-pulling and all-nighters, that is) without
delegates. A lot of generic code is impossible without delegates.

I disagree that context pointers are the problem. I think the root of
the problem is that many features in D work very well by themselves, but
their interactions with each other are not well explored, and as a
result there are a lot of bugs when you start leveraging more than one
feature at the same time.

For example, returning delegates that reference local variables works
wonderfully. But if you reference member variables in a struct instead,
then you start getting into trouble -- because the context pointer is
now pointing to an on-stack struct, which risks becoming invalid once
the scope exits.

Another example. Array slicing works wonders; it makes arrays and
strings wonderfully easy -- and I would even say, a pleasure -- to use.
But slice a static array, and suddenly you're treading dangerous ground.
Static arrays can be passed by value on the stack, and return a slice
far enough up the call stack, and you're referencing invalid memory.

Yet another delegate-related example. Declare a delegate directly inside
a function, and everything works just fine. Declare it in a template
alias argument, and suddenly you're treading on incomplete compiler
support -- sometimes the compiler fails to notice that a delegate is
involved, and fails to allocate local variables on the heap instead of
the stack. Or fails to instantiate certain things, and you get a linker
error.

A Phobos example. Most range-based functions assume (at least
unconciously) that ranges are structs, because, well, that's how most
Phobos ranges are built. So passing a range to a function makes a copy
of the range, and the original function can happily go on using the
range, expecting that it hasn't changed. But pass in a class range, and
suddenly you run into problems, because classes are passed by reference.

More examples. Structs by themselves work pretty well, but once you
start nesting the things, or nest classes inside structs or vice versa,
you start getting into uncharted territory and "here be dragons" areas.
Most trivial usages of such combinations tend to have no problems,
because the basic use cases probably have been thought of before. But
travel far enough away from the most trivial cases, and you're in
uncharted territory full of pitfalls.

Enums are another example. Most trivial cases of enums work flawlessly.
But nest them inside a function and sprinkle initializers, and you start
running into compiler bugs that cause linker errors. This is just an
isolated case, of course -- most such cases are easily fixed, but that
begs the question, if they're simple to fix, why weren't they caught
earlier?

It seems that D has too many features, and therefore an exponentially
huge number of possible combinations of features, and therefore a large
part of said combinations have not been tested (or well-tested). So
there still lurks many probably trivial bugs that haven't been found,
just because nobody has happened to use that particular combination of
features yet.


T

-- 
"Maybe" is a strange word.  When mom or dad says it it means "yes", but
when my big brothers say it it means "no"! -- PJ jr.