May 10, 2009 Re: What's the current state of D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brad Roberts | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brad Roberts | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Leandro Lucarella | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Leandro Lucarella | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to torhu | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Christopher Wright | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Michiel Helvensteijn | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
Copyright © 1999-2021 by the D Language Foundation