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
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/


 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.


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
next sibling 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