The path to unity

[Jarrett Billingsley]

On Fri, Feb 6, 2009 at 6:53 PM, Chad J
<gamerchad at __spam.is.bad__gmail.com> wrote:
> Oh my, here comes another wall of text.
>
> I'm beginning to see the Phobos/Tango split as a very advantageous thing
> for D, even neglecting the benefits in terms of forcing the community
> and designers to think of things like a modular runtime.  The split has
> given us multiple ways to do things.  This could be a detriment if
> you're pretty hardcore purist, but I think it's ultimately a good thing.
>  It is humanistically convenient.  Rather than waging unending religious
> wars we just take all paths at once and call it a day.  I'm seeing it
> this way:  it is a tradeoff between having a bit of standard library
> bloat and having discontent and dissent in the community.  IMO, the
> latter is WAY more troublesome.  At the very least, having this
> multiplicity allows us to appeal to more audiences--a thing that is good
> for both us and the audiences.
>
> And then there's the irony.  In the long run, this stuff should really
> be dynamic linked to save on code space.  Some day in the future we will
> ideally have a D framework that D programs can rely on.  It's kind of
> like the .NET framework except nicer and without the added annoyance to
> the user.  On Linux we have these package managers, so you can rig it so
> that whenever someone installs a D program then the framework is
> automatically installed once-and-for-all and all subsequent D programs
> will just reuse that framework and thus be compact and efficient.  For
> systems where the D framework can't be counted on (Windows), we are back
> to square one where you static link against only what is needed for your
> program.  That's just the cost of an inflexible OS.  If Windows ever
> wants to solve the problem of carrying around massive amounts of
> redundant code, then it will have to adopt a package manager.  So
> ultimately the cost of redundant functionality in the standard/common
> library approaches insignificance as technology progresses.
>
> The only long term cost then is the duplication of developer effort.  I
> feel that as long as this is kept reasonable, it will be proportional to
> the cost of dissatisfaction, lack of evolution, lack of innovation, etc
> that comes from not trying new paths and experimenting.  Humans are not
> ideal creatures.  They are not homogeneous nor are they omniscient.
> They do not have the ability to just look at a problem or a lack of code
> and just see the full optimal solution in crystal clarity in an instant
> and with %100 guaranteed effectiveness.   In these less than ideal
> conditions that we are stuck with, duplicating effort may very well be
> the optimal path.  A number of people will do one thing slightly
> differently, and in all likelihood one of those people will get it right.
>
> So yeah, I'm starting to warm to this idea of forever having multiple
> "standard" libraries for D, and building them on top of even more
> fundamental stuff.  Fundamental stuff that people won't disagree about.
>  It's a good balance between forcibly unifying EVERYTHING or allowing
> unfettered duplication.

I'll have to say that I wholeheartedly disagree.  (You knew this was coming.)

Even if they use a common runtime and small common core, nothing is
compatible between the user portions of the libraries. Sure, you'll be
able to install Phobos and Tango side-by-side without issue, but
honestly, why would you want to do that? Oh, I see - you're using two
third-party libraries, one based on Tango and one on Phobos. But.. it
still doesn't solve the problem. The one library wants std.date.Dates
and the other wants tango.time.Time.Times. Or std.stream.Streams vs.
tango.io.Conduits. The split between the libraries has just moved from
the runtime level up to the user level. Even if they use the same
runtime, Phobos and Tango cannot be used with one another.

Newbs are confused when they first come to the language and find out
there are two standard libraries, and that they have to choose which
one to use.  Worse, if you use one standard library, there's a whole
set of third-party libraries that you just can't use.  The alternative
is for library writers to support both libraries by writing a
compatibility layer - their own standard library! This is just
ridiculous. Not only do D users have to deal with the first-order
problem of which standard library they should use, but they also have
to deal with the second-order problem of which third-party libraries
support which standard library.

It doesn't matter how you sugarcoat it.  It doesn't give people
choices, it gives people _a_ choice - which "version" of D they want
to use: Phobos D or Tango D.  As a library writer, I can't say that I
find that situation, or the idea of writing a compatibility layer for
all but the simplest of functionality, very attractive.