Phobo's migration

Jack Stouffer via Digitalmars-d digitalmars-d at puremagic.com
Wed Jun 22 12:02:38 PDT 2016


On Wednesday, 22 June 2016 at 17:55:11 UTC, Joerg Joergonson 
wrote:
> How is that? That makes no sense. If Phobo's is production 
> ready as claimed then freezing it can't make it automagically 
> non-production ready, can it?

D cannot afford to be stagnant in a time of fierce language 
competition. C++ almost died off completely outside of a couple 
of niches because it stood still for so long. D does not have the 
momentum to carry it for even a half year of no improvements.

> I didn't say they wernt, but they are being done on phobos

Honest question: have you ever looked into Kaizen and lean 
management https://en.wikipedia.org/wiki/Kaizen? Because stopping 
everything in Phobos and waiting for "breakthroughs" is a dead on 
arrival plan. A continuous improvement process is much more 
viable, realistic, and likely to produce good results.

That's what the D development process does without even being 
explicit about it. Each release is better than the last one. 
Perfect? Never. Better? Always.

> which is suppose to be done. The fact that Stopwatch, Monotime, 
> TickDuration are all screwed up, etc... proves that there are 
> problems.

That specifically proves there are problems in std.datetime sure, 
and they're being fixed as TickDuration is marked for deprecation.

> The fact that Phobo's is trying to become nogc but isn't yet 
> also shows it has a ways to go.

Right, so let's keep working on it, not freeze it and not 
duplicate thousands of man hours of work for no reason.

> That gives us plenty of time, right?

Plenty of time to keep fix bugs like we currently are, sure.

> Phobos is obviously poorly designed, hacked together
> manipulated

This isn't obvious at all, I think D's take on iterators (ranges) 
is the best iterator design out there right now. D code is also 
faster than most of it's competitors (excluding C++ in some 
cases) and more readable to boot.

> and in a constant flux of regressions, bugs

Bugs and regressions are bad; I'm not going to disagree.

But, have you looked at the bug list for most OSS projects? D is 
not atypical, compare:

D, 4073 open issues: 
https://issues.dlang.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&limit=0&list_id=209089&order=changeddate%20DESC&product=D&query_format=advanced&resolution=---&version=D2

LLVM, 8536 open issues: 
https://llvm.org/bugs/buglist.cgi?bug_status=__open__&content=&product=&query_format=specific&order=bug_status%2Cpriority%2Cassigned_to%2Cbug_id&limit=0

Firefox, roughly 22,000, bugzilla is unable to return the full 
list so it's hard to get real numbers: 
https://bugzilla.mozilla.org/reports.cgi?product=Firefox&datasets=UNCONFIRMED&datasets=NEW&datasets=ASSIGNED&datasets=REOPENED

You also failed to mention how stopping development on Phobos 
would help in this regard. Bugs will still happen and need to be 
fixed.

> additions

Great! New, well designed features come to users quickly in D.

> and removals

IMO it's better to remove things than to maintain broken things 
and sacrificing readability and usability on the altar of 
backwards compatibility. D gives 12 - 18 month deprecation 
periods, and considering that a new release typically lands every 
two months, that's extremely generous.

> Have you every used .NET considerably?

Nope; mac user.



More information about the Digitalmars-d mailing list