Visual D 0.3.32 maintenance release

Artur Skawina art.08.09 at gmail.com
Thu May 24 12:08:42 PDT 2012


On 05/24/12 15:52, Steven Schveighoffer wrote:
> On Thu, 24 May 2012 09:30:01 -0400, Don Clugston <dac at nospam.com> wrote:
> 
>> On 13/05/12 21:28, Walter Bright wrote:
>>> On 5/13/2012 5:31 AM, Rainer Schuetze wrote:
>>>> With the workflow of bugzilla/svn it was just copy and pasting the diff
>>>> into the bug report. I understand it is easier on Walter's side, though.
>>>
>>> Yes, it is definitely easier on my side.
>>>
>>> But consider that the number of contributions to dmd has increased by at
>>> least a factor of 10 since we moved to github means that, in general,
>>> contributors find it easier, too.
>>
>> As I've said before -- that is true for DMD but not for Phobos.
>> Rate of contributions to Phobos is basically the same as when it was in svn.
>> Would be good to know why.
> 
> Phobos is perfect.
> 
> :)

It's simple - if something doesn't work right in phobos, it gets redone
properly in user code, and then that phobos part is not needed anymore,
and it's almost never referred to anymore.
Compare with compiler problems - the user usually cannot work around bugs
or deficiencies, and even when it is possible - it usually carries some
kind of cost. So most compiler issues get reported and even sometimes
fixed, but this happens much less with the library; there it's easier to
just fix/rewrite the broken thing and be done with it.

The fact that D's std lib is so tiny, and practically every part of it has
several serious design problems (never mind implementation bugs) means it
gets used for learning and toy/example "programs". Once you start "real"
coding, the std lib might get a chance for some simple noncritical low-pri
tasks, such as debugging logs (and note that even that will often backfire),
but will rarely, if ever, be used for anything else. When you know you can
code a working solution in a few minutes, why risk spending time checking
if it exists in phobos, then learning how to use it from usually not very
helpful docs, fully realizing that most likely the library implementation
will be unusable, either because of a design flaw, bugs or a prohibitively
expensive implementation?
So paradoxically the low quality and tiny scope of phobos means that it
gets less contributions.

There are also other issues, like process, that hinder contributions, but
those aren't specific to phobos. And the mythical backward compatibility, 
which - for a niche language with not a single mainstream compiler, not
one alternative compiler (backends don't count), no specification and
(statistically) no users, that constantly evolves, requiring adjusting code
for almost every compiler and library release - is not nearly as important
as it is made out to be.

IOW it's a chicken-and-egg problem - phobos needs to improve in order to
receive a larger amount of improvements. Which is why things like a sane
(and open, but that should go w/o saying) development process would make
the most difference. But, realistically, even if all such issues would be
fixed today, it would still take at least several years before a solid
std library would start taking form. [1]

artur

[1] And what if GDC is merged into GCC during that time? It's not an unlikely
scenario and one everyone should hope for. But, in practice, this will mean
that DMD is no longer the reference compiler and the std library and runtime
are effectively forked. I'd much prefer that as much as possible of the
necessary language and stdlib changes to be done while Walter is still in some
kind of control. And there are a lot changes left to be done.


More information about the Digitalmars-d-announce mailing list