View mode: basic / threaded / horizontal-split · Log in · Help
January 21, 2013
Re: D popularity
On Mon, Jan 21, 2013 at 07:01:29PM +0100, Zhenya wrote:
> >Oh? What's so unreliable about delegates? I find that they work quite
> >well in general.
> 
> This for example:
> http://d.puremagic.com/issues/show_bug.cgi?id=5710

Yeah, that one falls under my category of "put two features together and
get into unexplored buggy territory". Unfortunately, D's current
implementation seems to have a lot of problems in this category. :-(


T

-- 
People tell me that I'm skeptical, but I don't believe it.
January 21, 2013
Re: D popularity
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.
January 21, 2013
Re: D popularity
On Monday, 21 January 2013 at 18:40:15 UTC, H. S. Teoh wrote:
> 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.

I have to wonder if many of the features can be generalized down 
into less features without sacrificing anything.

To solve the problem of instability, we need to stabilize the 
language, which is easy to do, and can be done in a way that does 
not prevent progress. All you need is to release a "stable" 
language specification along with a corresponding stable 
reference compiler that only implements the associated stable 
language release. The stable release is then fine tuned as bug 
reports come in over the course of a year (or whatever is 
required). The language development can proceed normally through 
an unstable branch. The next release can be tested through a 
semi-stable beta branch.

We're trying to develop a process to achieve this sort of thing, 
but unfortunately the language specification has not yet been 
integrated into the process. Hopeful the development process will 
be expanded to include the language spec in the near future, as 
it is a critical component that cannot be left out.

--rt
January 21, 2013
Re: D popularity
On 1/21/2013 12:31 PM, Rob T wrote:
> I have to wonder if many of the features can be generalized down into less
> features without sacrificing anything.

Yeah, well, that's the major thing about any language design!
January 21, 2013
Re: D popularity
On Monday, 21 January 2013 at 20:48:22 UTC, Walter Bright wrote:
> On 1/21/2013 12:31 PM, Rob T wrote:
>> I have to wonder if many of the features can be generalized 
>> down into less
>> features without sacrificing anything.
>
> Yeah, well, that's the major thing about any language design!

and on that note I hear the C++ community (at least one key 
member) is proposing a:

    auto add(auto a, auto b) {
        return a + b;
    }

pretty-template syntax! I wouldn't feel right if C++ had 
something that elegant and D did not *wink* *wink* :-)
January 21, 2013
Re: D popularity
> and on that note I hear the C++ community (at least one key 
> member) is proposing a:
>
>     auto add(auto a, auto b) {
>         return a + b;
>     }
>
> pretty-template syntax! I wouldn't feel right if C++ had 
> something that elegant and D did not *wink* *wink* :-)

Could you explain why this is necessary? D templates are far 
better than C++ templates and accomplish these task already.
January 21, 2013
Re: D popularity
On Mon, Jan 21, 2013 at 09:53:35PM +0100, F i L wrote:
> On Monday, 21 January 2013 at 20:48:22 UTC, Walter Bright wrote:
> >On 1/21/2013 12:31 PM, Rob T wrote:
> >>I have to wonder if many of the features can be generalized down
> >>into less
> >>features without sacrificing anything.
> >
> >Yeah, well, that's the major thing about any language design!
> 
> and on that note I hear the C++ community (at least one key member)
> is proposing a:
> 
>     auto add(auto a, auto b) {
>         return a + b;
>     }
> 
> pretty-template syntax! I wouldn't feel right if C++ had something
> that elegant and D did not *wink* *wink* :-)

D already has that:

	auto add(T,U)(T a, U b) {
		return a + b;
	}

In fact, D does it one step better with signature constraints:

	auto add(T,U)(T a, U b)
		if (is(typeof(a+b)))
	{
		return a + b;
	}

That way, the compiler won't even bother to instantiate the template if
the two types can't be added in the first place.


T

-- 
Life would be easier if I had the source code. -- YHL
January 21, 2013
Re: D popularity
On Monday, January 21, 2013 21:53:35 F i L wrote:
> and on that note I hear the C++ community (at least one key
> member) is proposing a:
> 
> auto add(auto a, auto b) {
> return a + b;
> }
> 
> pretty-template syntax! I wouldn't feel right if C++ had
> something that elegant and D did not *wink* *wink* :-)

It's been discussed before and rejected.

- Jonathan M Davis
Top | Discussion index | About this forum | D home