www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Attractive Chaos' blog entry: Timeline of the D programming language

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Found this today:

http://attractivechaos.wordpress.com/2012/02/28/timeline-of-the-d-programming-language/


Andrei
Feb 28 2012
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 Found this today:
 
 http://attractivechaos.wordpress.com/2012/02/28/timeline-of-the-d-programming-language/

From the blog post:
As an outsider, I think the first priority for D is to quickly stabilize the
compiler and the standard library to convince everyone that programs written
now will still be compiled years later.<

I don't agree. If we try to do that too much, we freeze the warts of language and of Phobos, for a small gain. Programmers that want warts and language stability know where to find it (elsewhere), and even languages much older than D (like C++11) break compatibility with the past to improve. So I think D has to fix its small warts (most of them are already in Bugzilla, like array syntax, vector op syntax, override, property, and so on), Phobos needs to not be ice-frozen because the experience of real world usage suggests better APIs. I think Phobos APIs need to be less frozen. Bye, bearophile
Feb 28 2012
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, February 28, 2012 17:45:09 bearophile wrote:
 Andrei Alexandrescu:
 Found this today:
 
 http://attractivechaos.wordpress.com/2012/02/28/timeline-of-the-d-programm
 ing-language/

As an outsider, I think the first priority for D is to quickly stabilize
the compiler and the standard library to convince everyone that programs
written now will still be compiled years later.<

language and of Phobos, for a small gain. Programmers that want warts and language stability know where to find it (elsewhere), and even languages much older than D (like C++11) break compatibility with the past to improve. So I think D has to fix its small warts (most of them are already in Bugzilla, like array syntax, vector op syntax, override, property, and so on), Phobos needs to not be ice-frozen because the experience of real world usage suggests better APIs. I think Phobos APIs need to be less frozen.

Ideally, in the long run at least, existing Phobos APIs wouldn't be changing much. Changing them breaks code, and it sucks to have to refactor a bunch of code because of changes to the standard library. _New_ stuff can continue to be added, and it may be that newer APIs will always be in a bit more flux as they settle down, but we really do need a relatively fixed set of APIs in order to avoid breaking people's code. There's plenty still in Phobos that needs to be reworked before it approaches any kind of real frozen state (e.g. std.xml and std.stream), but we _do_ need to evolve Phobos to the point that breaking changes are rare. And we may want to eventually move to a model where we version things such that breaking changes only occur on major versions, and you can rely on nothing breaking with minor ones, rather than treating all versions the same. Regardless, the current lack of stability is a huge problem. It's more or less inevitable as we still iron things out, but it's something that we need to grow out of. - Jonathan M Davis
Feb 28 2012
parent reply bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 There's plenty still in Phobos that needs to be reworked before it approaches 
 any kind of real frozen state (e.g. std.xml and std.stream), but we _do_ need 
 to evolve Phobos to the point that breaking changes are rare.

The problem is not just Phobos, but D itself, that needs some fixes. Regarding Phobos, there are Phobos modules that contain many good insights, ideas, and some design gems. But you can't release similar large things in one go, and then assume their API is frozen. I think the development style of Phobos has to change. I like the suggestion of putting modules into an experimental package, and to keep them there for some months, let users use them and find suboptimal parts, to avoid freezing what's unbaked still :-) Bye, bearophile
Feb 28 2012
parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
bearophile wrote:
 I like the suggestion of putting modules into an experimental
 package, and to keep them there for some months, let users use them
 and find suboptimal parts, to avoid freezing what's unbaked still
 :-)

+1 (especially for BIG modules)
Feb 28 2012
prev sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 29.02.2012, 02:58 Uhr, schrieb bearophile <bearophileHUGS lycos.com>:

 Jonathan M Davis:

 There's plenty still in Phobos that needs to be reworked before it approaches
 any kind of real frozen state (e.g. std.xml and std.stream), but we _do_ need
 to evolve Phobos to the point that breaking changes are rare.

The problem is not just Phobos, but D itself, that needs some fixes. Regarding Phobos, there are Phobos modules that contain many good insights, ideas, and some design gems. But you can't release similar large things in one go, and then assume their API is frozen. I think the development style of Phobos has to change. I like the suggestion of putting modules into an experimental package, and to keep them there for some months, let users use them and find suboptimal parts, to avoid freezing what's unbaked still :-) Bye, bearophile

These threads get repetitive :) I mention OpenGL again, which has a review board and extensions. Add ext.collections and at a later point review it, improve it and move it to std.collections... kind of. Orange, xmlp, Windows bindings, dcollections and similar could have been in the releases earlier with the users knowing that they are subject to change. I hope for better feedback to the developers of such extensions as well, when there is a greater exposure to other programmers.
Mar 02 2012