The path to unity

[Denis Koroskin]

On Sat, 07 Feb 2009 04:43:05 +0300, Jarrett Billingsley <jarrett.billingsley at gmail.com> wrote:

> 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.

Well put, thank you. Everyone finds this situation annoying. That's the Number One problem of the D (remember "top five" poll?).

The problem as I see it is that there is an overlapping functionality in Phobos and Tango (std.stream.Stream/tango.io.Conduit etc).
The solution as I see it to redesign Phobos and Tango by removing dead (buggy, unsupported) code, separating libraries functionality and removing duplication.

I'd remove from Phobos:

std.
  openrj
  bigint (old one, by Janice)
  regexp
  socket
  xml
  much, much more (see more complete list in my previous post[1]).

and suggest/force users use tango instead.

What's left in Phobos? A fundamental part *only*:

std.
  math (including IEEE and BigInteger) [2]
  range
  traits
  algorithm
  contracts
  atomics (arguably)
  date/time (arguably)

So /any/ D compiler distribution would contain:

core (druntime)
std  (phobos)
tango

'druntime' would provide an essential functionality to run D programs on other platforms: gc, compiler, runtime, etc.
std - provide simple and generic functionality, that can be used in conjunction (unix style): algorithm, range, contracts, math[2], some helpers/utils, etc.
tango - extended functionality: network, io (including console io), xml, etc

Tango would depend on Phobos (which is now *very* tiny) and both depend on druntime. I believe Tango will greatly benefit from using contracts, ranges and algorithms, that are absent from it.

Competition is good, but only at early stages. Tenders/Bids are only exist to choose the best one and stick with it - the others are dropped at some point. The same thing should happen with Tango/Phobos now - inferior functionality should be dropped in favor or superior one. (It doesn't necessarily mean that either Phobos or Tango should be dropped entirely, but rather some modules - std.regexp vs. tango.text.Regex, std.socket vs tango.net.*, etc).

Does anyone agree/disagree with me? Anyone see other solutions? Please, don't stay away from discussion.

PS. Andrei is about to finish TDPL. What does it say about Phobos, Tango and the situation around "std libraries"?
What part of Phobos does it cover? I *really* hope it doesn't say much about anything apart from std.range/algorithm/traits/contracts.

---
[1] http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=82553
Please, read it if you didn't yet.

[2] 'math' is a common but not an essential to run HelloWorld so should be moved to std; tango removes tango.math entirely and uses std.math instead. No 'common' namespace would be needed as it is Phobos/std which is 'common'.