digitalmars.D.announce - Attractive Chaos' blog entry: Timeline of the D programming language
- Andrei Alexandrescu (3/3) Feb 28 2012 Found this today:
- bearophile (5/9) Feb 28 2012 I don't agree. If we try to do that too much, we freeze the warts of lan...
- Jonathan M Davis (16/34) Feb 28 2012 Ideally, in the long run at least, existing Phobos APIs wouldn't be chan...
- bearophile (5/8) Feb 28 2012 The problem is not just Phobos, but D itself, that needs some fixes.
- Piotr Szturmaj (2/6) Feb 28 2012 +1 (especially for BIG modules)
- Marco Leise (2/10) Mar 02 2012 These threads get repetitive :) I mention OpenGL again, which has a revi...
Found this today: http://attractivechaos.wordpress.com/2012/02/28/timeline-of-the-d-programming-language/ Andrei
Feb 28 2012
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
On Tuesday, February 28, 2012 17:45:09 bearophile wrote:Andrei Alexandrescu: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 DavisFound 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.
Feb 28 2012
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
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
Am 29.02.2012, 02:58 Uhr, schrieb bearophile <bearophileHUGS lycos.com>:Jonathan M Davis: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.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
Mar 02 2012