The path to unity

John Reimer terminal.node at gmail.com
Fri Feb 6 21:59:29 PST 2009


Hello Chad,

> Jarrett Billingsley wrote:
> 
>> On Fri, Feb 6, 2009 at 6:53 PM, Chad J
>> <gamerchad at __spam.is.bad__gmail.com> wrote:
>>> another wall of text.
>>> 
>> 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.
>> 
> But they CAN be used together, Tangobos style.  There is one bad
> problem
> with exclusive features like IO handling tripping over each other a
> bit.
> That is annoying.
> The other possible issue is when passing types between the user level
> and the third party lib: which std lib type to use?  I'd like to know
> just how often std lib types are used in library interfaces.  I
> suspect it's almost never.  Even then, it wouldn't stop compilation if
> you have something like Tangobos.
> 
>> 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.
>> 
> I do agree that this situation sucks.  Library writers need to be able
> to pick one and be confident that people who prefer the other library
> will still be able to use their code and with no odd quirks or gotchas
> either.  This is why I see the two standard libraries becoming
> completely non-exclusive, thus allowing programs to link against and
> use both at the same time.
> 


If I may speak bluntly, the idea of having two "standard" libraries is practically 
an oxymoron.  Furthermore, by definition a standard library is meant, at 
least to some extent, to enforce some sort of stricture on style and format 
of a language usually in the interest of elegance, power, and efficiency: 
such things will never appeal to everyone, although the designer of it hopes 
that his contribution will be attractive and useful to most.  Furthermore, 
every language and library carries with it a intrinsic message of "correctness" 
and "truth".  There should be no pretense that it delivers the ultimate unification 
of all paths or that it is absent of any so-called "religion" (I still continue 
to be a little suprised whenever I read this in D's mission statement).  


Tango and Phobos are direct demonstrations of different ideals about what 
D should represent.  There is no real escaping this conflict with feathery 
thoughts about everything and everybody being able to work together.  Well... 
I should say, one can think this way, but it won't make the problems go away 
because the social and political aspects of these things are often more influential 
than the technical.   It is possible to redefine a problem out of existance, 
but it's generally a very unsafe thing to do.


So... I don't know how adopting multiplicity in terms of the "standard" library 
can be convenient.  If you want multiplicity, developers should already have 
that option in third party libraries, a place where the choice should remain 
to avoid conflict with a language's central goals.


I think D's biggest problems have always been poor management of its social 
and political aspects.  These problems inevitably develop wherever a group 
of people gather.  This is one reason why Tango appeared in the first place. 
 That said, managing those aspects are some of the hardest things to do in 
any endeavor... perhaps because this inevitably means, at some point, you 
have to step on someone's toes.


-JJR





More information about the Digitalmars-d mailing list