Any chance to call Tango as Extended Standard Library

[dsimcha]

== Quote from Daniel Keep (daniel.keep.lists at gmail.com)'s article
> Piotrek wrote:
> > Lars Ivar Igesund wrote:
> >> Tango will stay Tango (and tango.*). The above naming assumes that
> >> Tango will depend on Phobos, and it will not.
> >>
> >
> > I see.
> >
> > Cheers
> (Note: speaking as merely an infrequent contributor to Tango; my opinion
> is my own and does not reflect on those of the Master Dancers, or the
> ruling council of glittery-shoed programmers.)
> (Warning: semi-rant ahead.)
> The problem is that Phobos and Tango are diametrically opposed in almost
> every conceivable way.  Bringing them together would be like trying to
> bring matter and anti-matter together; you're just going to blow
> yourself up.
> It's best if you think of Phobos as being Python and Tango as being
> Java.  Phobos implements a relatively flat (if messy) hierarchy of
> simple, fat classes.  For example, IO is done using the Stream
> interfaces, each one implements all the methods you'd probably need to
> work with streams.
> Tango, on the other hand, implements a very deep (if confusing)
> hierarchy of simple, component interfaces that get plugged together.
> Unlike Phobos, IO in Tango has many layers and components, each of which
> is very narrowly defined, allowing you to plug them together however you
> like.
> The problem is that neither of these approaches is WRONG.  They're both
> valid and arguably better in certain circumstances.  What's more, the
> continued existence of both shows that there are people who believe in
> each of them (not necessarily at the same time, but there you go.)
> So let's say we combined them into std.* and stdex.*.  Why is Tango
> stdex?  Why isn't Tango std.* and Phobos stdsimple?
> Ok, ignoring egos, the problem is that they wouldn't work together
> anyway.  An old favourite of mine is (again, sorry about this) IO.
> Phobos strives to be compatible with the C IO library; so you can
> interleave Phobos and C IO calls and it's all gravy.
> Tango takes C out the back and shoots it before burying it upside-down
> at a crossroads with a steak through the heart and salting the earth.
> You CAN mix Tango and C IO calls, but you really have no idea what order
> the output's going to arrive in.
> I remember Andrei getting antsy about this a while back; why break
> compatibility?!  Because Tango's IO was faster this way.  Neither one of
> them was 'right' because they both had legitimate points of view.
> Really, it all boils down to this: there *is no* one right way.  Yes,
> it's more confusing.  But it's a problem with programming in general;
> programming is all about looking at your options and making a decision
> on the matter.
>   -- Daniel

Wow.  Excellent analysis.  One thing I'd like to add is that Phobos tends to be
much more focused on the bleeding edge, with pretty much all development happening
on the D2 branch, while Tango is more focused on targeting stable compilers.
Also, another way I would summarize the situation is that Phobos focuses on first
making simple operations simple first and foremost, and then worries about making
complicated operations possible, while Tango does just the opposite.

I've said this before, but I think it's not so bad for D to have two standard
libraries with different design philosophies, at least in principle, though the
inability to use both side by side on D1 is obviously a bad thing.  There are
times when I like the Phobos "keep it simple, stupid" approach and times when I
want Tango's "everything but the kitchen sink" approach.  There are a few things
that I think would help a lot here:

1.  Both Phobos and Tango should adopt these opposite design philosophies, which
are true de facto anyhow, officially.  This will prevent excessive feature envy
and duplication of effort and allow newcomers to determine which is best for their
everyday use.

2.  The creation of druntime so that Phobos and Tango can be used side by side is
a huge step forward.  Once D2 is out of alpha and Tango is ported to D2, people
will be able to use their preferred lib most of the time and the other when their
preferred lib has some missing functionality.  This will also greatly simplify 3rd
party libs.