Any chance to call Tango as Extended Standard Library

[Andrei Alexandrescu]

Daniel Keep wrote:
> 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.

Nice comparison, but maybe a tad exaggerated. The two libraries are 
different in a number of ways, and reuniting them together might be 
difficult as they sometimes present different ways of approaching 
similar problems. For example, I'm not sure how code in std.algorithm 
could help containers or streams in Tango (as it should), or how to 
reconcile std.algorithm with std.core.array.

One other issue is that phobos2 has the mixed blessing of a clean slate, 
or at least a slate that can be partially cleaned as needed without 
worrying about breaking backwards compatibility. D2 has made a definite 
departure from some of the styles and idioms of D1, and with the advent 
of the new threading model that departure will only be more pronounced. 
The capabilities of a language strongly influence its standard library, 
and at best Phobos2 will espouse and promote the idioms that we strove 
to make possible. After all, we wanted to introduce new features because 
they'd help in writing good code, so the standard library should take 
advantage of them almost by definition. That's why phobos is not being 
"ported" to D2, it is being rewritten for D2.

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

Well, I am really looking forward to deprecating the Stream interfaces. 
I think it's an ok design (alright: I actively dislike certain parts of 
it), it's just that a much better design can be put forth with D2's 
capabilities.

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

Sweet. I mean salty.

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

In wake of some recent trials, it looks like I/O can be sped up without 
necessarily giving up on C compatibility. The range design, which will 
be central to much of Phobos2 (notably I/O) will pay close attention to 
not stand in the way of streamlined transfers.

In my opinion an embarrassment of riches isn't necessarily bad. It was 
real bad only when using one library precluded using the other.

Speaking of D2 in general, I think 2009 will be a big year. There has 
been a lot of great work done on D2 in the past couple of years, but 
quite little to show for it in terms of code and publications. This has 
frustrated Walter and myself at times, but when we talked about it we 
always reached the conclusion that we have a sound plan and that 
sometimes you just have to keep on working for those mythical delayed 
rewards. Well, this year it looks like at least some of those rewards 
will materialize.  Speaking of Phobos2 in particular, if I manage to 
execute at least part of my vision on Phobos2, it will become a powerful 
and thoroughly pleasant to use library.


Andrei