Thread overview
Re: D popularity
Jan 21, 2013
H. S. Teoh
Jan 21, 2013
H. S. Teoh
Jan 21, 2013
Rob T
Jan 21, 2013
Walter Bright
Jan 21, 2013
F i L
Jan 21, 2013
Namespace
Jan 21, 2013
H. S. Teoh
Jan 21, 2013
Jonathan M Davis
January 21, 2013
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
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
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
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
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
> 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
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
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