View mode: basic / threaded / horizontal-split · Log in · Help
May 10, 2009
Re: What's the current state of D?
Walter Bright, el  9 de mayo a las 11:23 me escribiste:
> Leandro Lucarella wrote:
> >D1 is INCOMPLETE (for example pre/post conditions inheritance are
> >missing). I tend to forget which features are there for real what aren't
> >(there are a few, true, but still).
> 
> Array ops weren't there for a long time, many argued that D1 wasn't complete without them, and a few months ago I added them in.
> 
> As far as I can tell, nobody cared about array ops.
> 
> In C++ land, only one compiler actually completely implements C++98, and
> this is after more than 10 years. (Exported templates and template name
> lookup rules remain unimplemented by major compilers.) (P.S. Digital
> Mars C++ does the correct name lookup rules!) The fact is, nobody
> actually cares about those incomplete features. Nobody uses exported
> templates, even if they are using a compiler that supports it.
> 
> So that leaves contract inheritance. I find it hard to see how not
> having it is a showstopper for using D1. Contracts in D haven't been the
> big win I thought they might be at first. They aren't use much at all.
> There are a lot of other issues that do make a big difference, and those
> are the issues that get attention.

Exported templates was unpractical and unimplementable AFAIK (but I guess
you know that better than me). And C++ is an ISO standard language. D is
not. If something is unpractical and unimplementable in D (I don't think
is the case of contract inheritance) why didn't you removed a long time
ago when you decided that it wasn't useful?

And maybe you are right, but the bottom line is how D is perceived. People
usually don't go through the C++98 standard to learn C++, but it goes
through the D specs to learn D. Nobody talks about exported templates in
C++ because they don't exist in reality, but the D specs talks about
features that are missing in what is supposed to be a finished version.
And that makes D looks bad.

> >Another very *BIG* issue is lack of mainstream tools support.
> >C++98 was finished before starting C++0x. A lot of effort was made to make
> >mainstream tools to support C++. Most tools demangle C++ names (even when
> >they aren't standard!). At least GDB should be able to do that, and
> >Valgrind and GNU binutils, if you want people to be comfortable working
> >with D. There are patches here and there but nothing works out of the box.
> 
> GDB does have an official D mode. There are demanglers for
> D identifiers. Can you submit patches for GDB to the official source
> tree?

Official? I don't see any official support for D in GDB. I can only find
this patches:
http://www.dsource.org/projects/gdb-patches/

And this thread about integrating the patches in GDB:
http://www.digitalmars.com/d/archives/digitalmars/D/Getting_D_language_patch_into_GDB_82597.html

But I can't see any mention in the official GDB documentation and
certainly it doesn't automatically recognize D programs as such.

> >I think what D1 is *really* missing is that 2 things: completeness and
> >tools support. Without that is really hard to take it seriously.
> >I think the D team should be working more in that direction before
> >finishing D2. I know is very boring comparing it to making D2, but I think
> >that is what is transmitted from D maintainers: "D1 is boring, don't pay
> >attention to it, D2 is fun, let's play with that!". And this is what
> >happening. People are playing with D2 and forgetting to finish D1.
> 
> It isn't about boring. It's about allocating our very limited resources
> for maximum effect. If I thought that contract inheritance was
> a showstopper for D1, it'd move way up on the priority list. But I have
> a hard time believing it is a showstopper, like array ops turned out to
> not be.

I don't think it's a *showtopper*. I'm trying to explain one of the
reasons I think D is perceived as a toy/incomplete/not-ready-for-business
language. But I certainly think D 1.0 should be finished before 2.0 though
=)

> Most of the work I do on dmd is bug fixes, and nearly all of those wind
> up in D1 as well. It's just not true that D1 is being overlooked or
> ignored, and the D1 changelog should amply illustrate that.
> 
> http://www.digitalmars.com/d/1.0/changelog.html

I know that. Everybody knows that. And I don't think anybody is arguing
that. Lack of bug-fixing is not a mentioned problem AFAIK.

> >The Tango vs. Phobos is still a *BIG* issue for D1. I think don't
> >addressing that is a huge error. It's only hurting D1 and preventing its
> >adoption.
> 
> Doing a merge would be a very breaking change. D2's support for Tango is probably the biggest breaking change in moving D1 code to D2.

How is that? Most runtime code is not used by the user directly. And for
this item I think not merging it does more damage than introducing
a breaking change (is much better to introduce a breaking change to solve
this problem than to add a predefined Posix version ;).

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
May 10, 2009
Re: What's the current state of D?
Brad Roberts, el  9 de mayo a las 12:31 me escribiste:
> Leandro Lucarella wrote:
> > 
> > Another very *BIG* issue is lack of mainstream tools support.
> > 
> > C++98 was finished before starting C++0x. A lot of effort was made to make
> > mainstream tools to support C++. Most tools demangle C++ names (even when
> > they aren't standard!). At least GDB should be able to do that, and
> > Valgrind and GNU binutils, if you want people to be comfortable working
> > with D. There are patches here and there but nothing works out of the box.
> 
> A critical error that keeps being made.. in MOST compiled languages, the authors
> of the compilers are not the ones that are producing the eco-systems above them.
>  Even for the VM based languages, the language/compiler/runtime authors rarely
> venture much above those.  Eclipse isn't a sun invention, nor are any of the
> other development environments.  Microsoft is about the only one that produces
> an large tool chain, but the groups that do the various parts are different.
> The compiler team doesn't produce (or in many cases even use) Visual Studio.
> 
> Etc..

I know that, but the "language" should push forward in that direction.
I don't know why this happen with D, what can be made to improve the
situation, but I think putting all the attention in D2 doesn't help, and
doesn't encourage people to work on D1.

I've decided to work in D1 GC instead of D2 partially because of this.
I think D1 is a great language, very *very* close to be complete. It's
a shame to through that because D2 is cooler. For example, I can't use
D for work. I can't convince my bosses to use D when you have to compile
your own toolchain to get a debugger that works with it. C++ sucks, but
I'm stucked with that as long as it has better tools support than D. And
I think this is where D1 can start taking off, when it's ready for
busyness, because unfortunatelly is really hard to produce things for
D just as a hobby.

And why this only happen to D? Really, don't you even ask yourselves?
I think there is a "social" problem with D, or a "leadership" problem.
I think people is not encouraged to work on D1.

> So, want the tool chain to mature.. go to work.  Work with the GDB community to
> build and incorporate changes.  The same with all the things you want to see
> changed or created.

Unfortunatelly I'm putting my work in the GC now. I was so annoyed a weak
ago about not being able to use gdb, valgrind or nm with D that
I downloaded valgrind to see how hard it would be to add D support to it,
but I had to desist because I don't have the time right now.

> > I think what D1 is *really* missing is that 2 things: completeness and
> > tools support. Without that is really hard to take it seriously.
> > 
> > I think the D team should be working more in that direction before
> > finishing D2. I know is very boring comparing it to making D2, but I think
> > that is what is transmitted from D maintainers: "D1 is boring, don't pay
> > attention to it, D2 is fun, let's play with that!". And this is what
> > happening. People are playing with D2 and forgetting to finish D1.
> 
> If you've gotten the impression that "d1 is boring" is the message from whatever
> this "the d team" (team suggests many people, but there's really just a tiny few
> involved -- this isn't microsoft or sun with hundreds of worker ants) is, then
> you're impression is off.  The message is "d1 is only receiving bug fixes -- and
> only those with the right balance of risk/reward".

When I say "D team" I mean Walter, Andrei and Bartoz mostly, maybe Don and
Seam too =)

The impression is what it is. It can't be off. If something gives an
impression it doesn't matter if you don't want to make that impression,
that's the point (I know this maybe has no sense as it is written, english
is not my first language and I don't know how to explain it better).

And I think ignoring that that impression is made, when every month (or
weak!) there is a thread about it, is dumb.


-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Es mas posible, que un elefante maneje un cero km a que un camello
habite un departamento de un ambiente.
	-- Peperino Pómoro
May 10, 2009
Re: What's the current state of D?
Brad Roberts, el  9 de mayo a las 12:31 me escribiste:
> If there's things that need to change in what the compiler emits, Walter has
> shown himself to be willing to rapidly change them where the required changes
> are clearly described in terms of both 'what' and 'why'.  In other words, "it's
> broken" isn't sufficient but "if the frobble was changed to frobnosticator for
> each wobble, it would work" results in the next release having that change made.

BTW, here is something that should be fixed in the compiler to improve GNU
binutils support =)
http://d.puremagic.com/issues/show_bug.cgi?id=2932

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Un paracaidista, que no deja de caer.
Lo que me lleva hacia arriba, es lo que me tira hacia abajo.
May 10, 2009
Re: What's the current state of D?
Leandro Lucarella wrote:
> Brad Roberts, el  9 de mayo a las 12:31 me escribiste:
>> If there's things that need to change in what the compiler emits, Walter has
>> shown himself to be willing to rapidly change them where the required changes
>> are clearly described in terms of both 'what' and 'why'.  In other words, "it's
>> broken" isn't sufficient but "if the frobble was changed to frobnosticator for
>> each wobble, it would work" results in the next release having that change made.
> 
> BTW, here is something that should be fixed in the compiler to improve GNU
> binutils support =)
> http://d.puremagic.com/issues/show_bug.cgi?id=2932
> 

A great illustration of a less than ideal bug report.  "A tool breaks in some
way, fix the compiler."  It's entirely possible that dmd is producing the wrong
thing, but there's an definite lack of specificity about what's wrong on the
compiler side.  Those errors are coming out of the linker.  It's not even
particularly clear that the bug is with dmd and not the new linker (one that's
not shipped as the default linker on any distribution yet, unless I've lost
track again).  In other words, it's not at all surprising to me that the bug
report hasn't received a lot of attention yet.

Prioritization is a difficult exercise, and there's no way everyone will ever be
happy.

Later,
Brad
May 10, 2009
Re: What's the current state of D?
Leandro Lucarella wrote:
> Official? I don't see any official support for D in GDB. I can only find
> this patches:
> http://www.dsource.org/projects/gdb-patches/

Dwarf has an official value for the language, DW_LANG_D = 0x13.


> How is that? Most runtime code is not used by the user directly. And for
> this item I think not merging it does more damage than introducing
> a breaking change (is much better to introduce a breaking change to solve
> this problem than to add a predefined Posix version ;).

Tango chose to use a number of incompatible names and a fundamentally 
different class hierarchy for the same thing(s).
May 10, 2009
Re: What's the current state of D?
torhu wrote:
> On 10.05.2009 00:05, mpt wrote:
>> I keep making 2 mistakes in my D programs, and fixing them feels
>> troublesome.
>>
>> 1. Null references. I get a segfault and gdb is useless (ldc thing 
>> maybe).
>> 2. Exceptions. It prints the msg nicely, but it's unhelpful in tracing
>> the real cause of error.
>>
>> Shouldn't there be an automatic null check for references and stack
>> traces? Sometimes I think I'm using the wrong tool as others have
>> solutions for these.
> 
> Tango trunk has stacktrace functionality for both Windows and linux I 
> think.  There's also a Phobos backtrace patch.

Though the Linux one just prints out the addresses and not the line 
numbers. Licensing issues with linking to libbfd to extract that 
information.
May 10, 2009
Re: What's the current state of D?
Nick Sabalausky wrote:
> About the null references, most people seem to agree that the right way to 
> fix that is with some sort of "non-nullable". But there's a lot of 
> disagreement on exactly how non-nullables should work.

And whether they *can* work. D2 has struct constructors, so structs can 
have non-nullable fields, but you can't have an array of non-nullable 
elements (you can set the length, and suddenly your non-nullable-element 
array has a bunch of nulls in it). Similarly, no arrays of structs 
containing non-nullable types, etc.

There are a lot of things to look into with non-nullables, and Walter 
doesn't have the time.
May 10, 2009
Re: What's the current state of D?
Christopher Wright wrote:

>> About the null references, most people seem to agree that the right way
>> to fix that is with some sort of "non-nullable". But there's a lot of
>> disagreement on exactly how non-nullables should work.
> 
> And whether they *can* work. D2 has struct constructors, so structs can
> have non-nullable fields, but you can't have an array of non-nullable
> elements (you can set the length, and suddenly your non-nullable-element
> array has a bunch of nulls in it). Similarly, no arrays of structs
> containing non-nullable types, etc.

The point of non-nullables would be to detect improper usage at
compile-time, right? Then I don't believe this problem has an elegant
solution until compilers can do a rigorous control-flow analysis.
Specifying default pointer values other than null doesn't seem very nice.

Nonetheless, a good step forward would be to recognize the distinction
between `null' and `uninitialized'. Reading a variable that's uninitialized
is an error. Reading a null pointer is fine, but dereferencing it is an
error.

This effectively solves your non-nullable problems, but you'd basically be
replacing them with another problem. In general, you can only know if a
variable is initialized at run-time. And then only if you reserve memory
for the `uninitialized' state.

So effectively, what's the difference between that and the original null
reference problem? You'd basically get the runtime error when you read the
pointer, but before you dereference it.

Until compilers are smart enough.

-- 
Michiel Helvensteijn
May 10, 2009
Re: What's the current state of D?
Michiel Helvensteijn wrote:
> ...
> 
> The point of non-nullables would be to detect improper usage at
> compile-time, right? Then I don't believe this problem has an elegant
> solution until compilers can do a rigorous control-flow analysis.
> Specifying default pointer values other than null doesn't seem very nice.

You don't need control-flow analysis.  You just need a type system which
supports nullables like D2's supports const.

> Nonetheless, a good step forward would be to recognize the distinction
> between `null' and `uninitialized'. Reading a variable that's uninitialized
> is an error. Reading a null pointer is fine, but dereferencing it is an
> error.

Uninitialised variables is only a symptom.  The larger issue is that it
doesn't make sense for most functions to accept null object arguments.
It's quite rare, at least in my code, to have a function that can do
anything sensible with "nothing" other than HCF [1].

> This effectively solves your non-nullable problems, but you'd basically be
> replacing them with another problem.

No, it doesn't.

> ...
> 
> So effectively, what's the difference between that and the original null
> reference problem? You'd basically get the runtime error when you read the
> pointer, but before you dereference it.
> 
> Until compilers are smart enough.

The whole point of having non-nullable types is so that you can't even
STORE a null in the first place.  We already have a runtime check, and
it's not good enough.  The major issue is that it notifies us of a
problem at a time when we generally do not have any useful information
on how to solve it.

The problem isn't dereferencing nulls.  It's when they get STORED that's
the problem.

 -- Daniel


[1] HCF - Halt and Catch Fire; old instruction on the PDP machines. :P
May 10, 2009
Re: What's the current state of D?
Walter Bright, el  9 de mayo a las 22:05 me escribiste:
> Leandro Lucarella wrote:
> >Official? I don't see any official support for D in GDB. I can only find
> >this patches:
> >http://www.dsource.org/projects/gdb-patches/
> 
> Dwarf has an official value for the language, DW_LANG_D = 0x13.

I'm talking about GDB. GDB has no official D support. There was a thread
in the NG asking for possible copyright issues to include the GDB patch
upstream, and it had no answer for example. I don't think you *have* to
answer that mail, but I think helping this kind of things happening
instead of ignoring them is good for D promotion too =)

> >How is that? Most runtime code is not used by the user directly. And for
> >this item I think not merging it does more damage than introducing
> >a breaking change (is much better to introduce a breaking change to solve
> >this problem than to add a predefined Posix version ;).
> 
> Tango chose to use a number of incompatible names and a fundamentally
> different class hierarchy for the same thing(s).

How many people is using that? How bad would it be to call the next
version of DMD that include the Tango/Druntime runtime D 1.100 or
something (is really hard to pick right version numbers under the version
scheme you use[*]) to make clear there is compatibility break in that
version?

Seriously, there were several (silly) compatibility breaks since 1.0 was
out, I think is a huge issue that deserves it...


[*] I really wonder how would you call D2 when it's stable. You will just
   say D 2.134 is D2 final/stable? I think this is another problem with
   D, version naming is really confusing and lame. You can't know
   anything from a D version number. And DMD compiler and D specs are too
   much coupled. It would be nice to have separate version numbers if you
   really want to encourage some kind of D standard and compiler vendors
   to start making D compilers.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
MATAN AL PERRO: DICEN QUE ESTABA POSEIDO POR EL DEMONIO...
	-- Crónica TV
3 4 5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home