www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Two "standard" libraries???

reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
I keep hearing discussions to the effect that "D has two standard 
libraries" - by which one invariably means Phobos and Tango.

In what respect is Tango "standard"?

Here's how I see it.  D has one standard library.  That one standard library 
is Phobos.  I.e. Phobos is part of the D standard.  Tango isn't.  Rather, 
Tango is an _alternative_ to the standard library; to call Tango a standard 
library strikes me as nonsense.

Of course, the divide in the community between Phobos users and Tango users 
is real.  I can only agree with Mike Streatfield:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=58294

But I wonder how much different it would be if people didn't regard Tango as 
what it isn't.  I'm not sure if this can be said without implying disrespect 
to the developer(s) of Tango, but for those who want _one_ standard library, 
there's Phobos, which is the _real_ standard library, just as it was before 
Tango was conceived.  The only thing that's complicating matters is people 
deviating from the D standard by writing libraries that depend on Tango and 
are thus incompatible with Phobos....

Comments?

Stewart. 
Sep 14 2007
next sibling parent Derek Parnell <derek psych.ward> writes:
On Fri, 14 Sep 2007 23:35:08 +0100, Stewart Gordon wrote:

 I keep hearing discussions to the effect that "D has two standard 
 libraries" - by which one invariably means Phobos and Tango.
 
 In what respect is Tango "standard"?

The word "standard" can mean a couple of things in this context. (a) The meaning that you have ascribed :- "that which is automatically deployed with each release of the reference compiler (DMD)" and (b) "that which could be automatically deployed with each release of the reference compiler (DMD), but isn't"
 Here's how I see it.  D has one standard library.  That one standard library 
 is Phobos.  I.e. Phobos is part of the D standard.  Tango isn't.

That is how I view the world too.
 Rather, Tango is an _alternative_ to the standard library

And therein lies the problem. There are things in phobos that a good and things in Tango that are good, but we are forced to choose one or the other (unless we like problematic solutions). I want to use some of the great Tango functionality, but not at the cost of losing the phobos stuff, and thus I'm not going to be using Tango. This irks me no end because phobos is still lacking in sorely needed functionality that Tango can supply.
  The only thing that's complicating matters is people 
 deviating from the D standard by writing libraries that depend on Tango and 
 are thus incompatible with Phobos....

From my simple understanding, both phobos and Tango needs some changing in order for them to coexist in the same application. I'm hoping that all the people concerned will address this with some urgency and consideration for each other and the wider D community. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Sep 14 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Stewart Gordon wrote:
 But I wonder how much different it would be if people didn't regard 
 Tango as what it isn't.  I'm not sure if this can be said without 
 implying disrespect to the developer(s) of Tango, but for those who want 
 _one_ standard library, there's Phobos, which is the _real_ standard 
 library, just as it was before Tango was conceived.

Yup. And to be frank, I don't think any member of the Tango team has ever claimed that Tango is a "standard library." However, this is really a semantic issue because the compatibility problem does exist, so for better or worse, it's not really possible to use Tango and Phobos together in the same app at the moment. If you'll forgive my hubris, I /do/ believe the Tango runtime is better than the Phobos runtime, but this basically means that I think it would be foolish to just toss out the Tango runtime and turn Tango into another user-level library. And that's why we are where we are today :-) Sean
Sep 14 2007
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 14 Sep 2007 16:57:22 -0700, Sean Kelly wrote:

 Stewart Gordon wrote:
  >
 But I wonder how much different it would be if people didn't regard 
 Tango as what it isn't.  I'm not sure if this can be said without 
 implying disrespect to the developer(s) of Tango, but for those who want 
 _one_ standard library, there's Phobos, which is the _real_ standard 
 library, just as it was before Tango was conceived.

Yup. And to be frank, I don't think any member of the Tango team has ever claimed that Tango is a "standard library." However, this is really a semantic issue because the compatibility problem does exist, so for better or worse, it's not really possible to use Tango and Phobos together in the same app at the moment. If you'll forgive my hubris, I /do/ believe the Tango runtime is better than the Phobos runtime, but this basically means that I think it would be foolish to just toss out the Tango runtime and turn Tango into another user-level library. And that's why we are where we are today :-)

That is why I mentioned "consideration for each other". Both Walter and the Tango crew will need to give ground and co-operate to arrive at a good outcome for us innocent bystanders. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Sep 14 2007
next sibling parent Mike Streatfield <dnewsgroup.c talyst.me.uk> writes:
Derek Parnell wrote:
 On Fri, 14 Sep 2007 16:57:22 -0700, Sean Kelly wrote:
 
 Stewart Gordon wrote:
  >
 But I wonder how much different it would be if people didn't regard 
 Tango as what it isn't.  I'm not sure if this can be said without 
 implying disrespect to the developer(s) of Tango, but for those who want 
 _one_ standard library, there's Phobos, which is the _real_ standard 
 library, just as it was before Tango was conceived.

ever claimed that Tango is a "standard library." However, this is really a semantic issue because the compatibility problem does exist, so for better or worse, it's not really possible to use Tango and Phobos together in the same app at the moment. If you'll forgive my hubris, I /do/ believe the Tango runtime is better than the Phobos runtime, but this basically means that I think it would be foolish to just toss out the Tango runtime and turn Tango into another user-level library. And that's why we are where we are today :-)

That is why I mentioned "consideration for each other". Both Walter and the Tango crew will need to give ground and co-operate to arrive at a good outcome for us innocent bystanders.

In terms of more established languages, what seems to happen is that a core of the language is established as "standard". If someone implementing a compiler fails to implement the standard core properly, they are rightly taken to task over it. One of the things going for languages like Java and C# is the sheer amount of features in this core language set, which effectively constitute the language. In other words, functionality you can guarantee will be there when you pick up an editor and start coding. On top of the core language features are modules/libraries which extend the core features. These don't have to be standardised, but will of course be affected by what's in that core set. Without a fairly stable set of core features you won't find long-standing proven libraries which use those features. My point is that when you have two libraries seen as "standard" (you can argue over the meaning of the word all day, it probably won't change the public image of what's happening), which implement two different sets of core functionality, you hurt the acceptance of the language by confusing people and rendering code which seems to be written for the same language incompatible. One of the decisions the team I'm working on has had to make this summer was whether to use Phobos or Tango as the core of our system. What I found was that my colleagues and I essentially had to learn another style of coding to be able to use Tango effectively, after having used Phobos for a few weeks. We chose to use Tango because it had some features we found useful, specifically the collection classes if I remember rightly. We did miss bits from Phobos, in particular the zip file reading code, which Tango doesn't seem to have an equivalent for yet (though the VFS components would seem to be heading in that direction). Given that D seems to be a language whos development is driven by how it's used and the needs of the people using it, it is possible to back an argument that two different core libraries can exist together side-by-side. However, looking in from the outside, Tango seems to fold in a lot more of these core features that people want than Phobos, simply because there are people working on it. I'm not sure what the solution is, but I would definitely see the lack of a single "standard" library as a major concern in the uptake of the language. In my opinion the definition of a core set of functinality should be as much a part of a language's definition as the syntax.
Sep 14 2007
prev sibling parent reply =?ISO-8859-1?Q?Carsten_S=F8rensen?= <cso rift.dk> writes:
Derek Parnell wrote:
 That is why I mentioned "consideration for each other". Both Walter and the
 Tango crew will need to give ground and co-operate to arrive at a good
 outcome for us innocent bystanders.

I couldn't agree more. I turned up late at the D party, and I have to say - this place is on FIRE. Good vibes. Tell your friends, cos this is where it's happening. But man, I wish those two guys in the corner would just get along you know? They're just ruining the mood. Seriously, as a late comer is pretty difficult to choose between phobos and tango, because you really do have to make a choice here. Either you stick with the default and its defects or the new kid and try to forget about all the other software out there. There are so many libraries I'd like to use, but it seems none are compatible. Diversity here is NOT a good thing. Sun fought Microsoft over this very issue and won (thank God). D needs ONE standard library to succeed. What I would like to see is tango being adopted as _the_ standard library for D. Clean slate. Possibly with a phobos compatibility layer. If that's not possible, simply drop phobos and force people to use to use tango with D 3.0. It might seem like a big deal, there's well over 100.000 posts on these groups, but seriously - compared to the C++, Ruby, Python or any other community we're tiny, and it's now the decision has to be made. Best regards, Carsten Sørensen
Sep 14 2007
next sibling parent reply Brad Anderson <brad dsource.org> writes:
Carsten Sørensen wrote:
 Derek Parnell wrote:
 That is why I mentioned "consideration for each other". Both Walter and the
 Tango crew will need to give ground and co-operate to arrive at a good
 outcome for us innocent bystanders.

I couldn't agree more. I turned up late at the D party, and I have to say - this place is on FIRE. Good vibes. Tell your friends, cos this is where it's happening. But man, I wish those two guys in the corner would just get along you know? They're just ruining the mood. Seriously, as a late comer is pretty difficult to choose between phobos and tango, because you really do have to make a choice here. Either you stick with the default and its defects or the new kid and try to forget about all the other software out there. There are so many libraries I'd like to use, but it seems none are compatible. Diversity here is NOT a good thing. Sun fought Microsoft over this very issue and won (thank God). D needs ONE standard library to succeed. What I would like to see is tango being adopted as _the_ standard library for D. Clean slate. Possibly with a phobos compatibility layer. If that's not possible, simply drop phobos and force people to use to use tango with D 3.0. It might seem like a big deal, there's well over 100.000 posts on these groups, but seriously - compared to the C++, Ruby, Python or any other community we're tiny, and it's now the decision has to be made.

*sigh* When you see a post from Sean Kelly saying that both parties are working toward this very goal of consolidation, does that mean nothing? I guess I appreciate the re-re-iteration of the point that "two is bad" by multiple posters, but give the parties involved some time. It's been three weeks since their meeting at the conference. Everyone came out of that room fairly optimistic and w/o daggers in their back (i.e. they *are* getting along and not ruining any mood). Walter has a better appreciation of how much is actually in Tango, and the Tango folk were able to gather first-hand Walter's main points of concern. So they got busy between then and now... no big deal. I imagine Sean's pluggable runtime and gc talk did wonders, and Derek's post about giving ground is right on. They will both have to do so. So we sit here patiently, and in the end, we will get the best of both? Sounds like a deal to me. Maybe we all just chill out? I can't imagine that learning some of the things in Tango that aren't in Phobos would be a *bad* thing... So head on over to Tango's wiki and pick up a chapter and wail on it. Logging, clustering, i/o, networking, collections, math... http://www.dsource.org/projects/tango/wiki/Manual BA
Sep 14 2007
parent Mike Streatfield <dnewsgroup.c talyst.me.uk> writes:
Brad Anderson wrote:
 
 When you see a post from Sean Kelly saying that both parties are working
 toward this very goal of consolidation, does that mean nothing?
 
 I guess I appreciate the re-re-iteration of the point that "two is bad"
 by multiple posters, but give the parties involved some time.  It's been
 three weeks since their meeting at the conference.  Everyone came out of
 that room fairly optimistic and w/o daggers in their back (i.e. they
 *are* getting along and not ruining any mood).  Walter has a better
 appreciation of how much is actually in Tango, and the Tango folk were
 able to gather first-hand Walter's main points of concern.  So they got
 busy between then and now... no big deal.  I imagine Sean's pluggable
 runtime and gc talk did wonders, and Derek's post about giving ground is
 right on.  They will both have to do so.  So we sit here patiently, and
 in the end, we will get the best of both?  Sounds like a deal to me.
 

Well, awesome then :) - Mike
Sep 15 2007
prev sibling parent reply BLS <nanali nospam-wanadoo.fr> writes:
Carsten Sørensen schrieb:
 What I would like to see is tango being adopted as _the_ standard
 library for D. Clean slate. Possibly with a phobos compatibility layer.
 If that's not possible, simply drop phobos and force people to use to
 use tango with D 3.0. 

Drop Phobos. Vote++. Rationale- PRO Tango : 1) Tango is community driven (more or less) Phobos is not. 2) Tango's functionality grows with every litte update, Phobos is at a stand still. Pro Phobos : 1) Is allways up to date with the latest D compiler. General : 1) The D library situation is still lousy. Standard-GUI, Database, DTL, communication ... So having two "standard libraries" is a complete waste of time and human resourses. Bjoern
Sep 15 2007
next sibling parent reply Sean Kelly <sean f4.ca> writes:
BLS wrote:
 
 Pro Phobos :
 1) Is allways up to date with the latest D compiler.

Personally, I don't think this is much of an issue. It rarely takes me more than an hour to update Tango after a DMD release, assuming I'm online when it happens. Sean
Sep 15 2007
parent BLS <nanali nospam-wanadoo.fr> writes:
Sean Kelly schrieb:
 BLS wrote:
 Pro Phobos :
 1) Is allways up to date with the latest D compiler.

Personally, I don't think this is much of an issue. It rarely takes me more than an hour to update Tango after a DMD release, assuming I'm online when it happens. Sean

Bjoern
Sep 15 2007
prev sibling parent reply Jascha Wetzel <firstname mainia.de> writes:
BLS wrote:
 Carsten Sørensen schrieb:
 What I would like to see is tango being adopted as _the_ standard
 library for D. Clean slate. Possibly with a phobos compatibility layer.
 If that's not possible, simply drop phobos and force people to use to
 use tango with D 3.0. 

Drop Phobos. Vote++. Rationale- PRO Tango : 1) Tango is community driven (more or less) Phobos is not. 2) Tango's functionality grows with every litte update, Phobos is at a stand still. Pro Phobos : 1) Is allways up to date with the latest D compiler. General : 1) The D library situation is still lousy. Standard-GUI, Database, DTL, communication ... So having two "standard libraries" is a complete waste of time and human resourses. Bjoern

drop phobos? no way! what's wrong with joining the runtime libs? import std.string; import tango.io.FilePath; => everybody happy
Sep 15 2007
next sibling parent BLS <nanali nospam-wanadoo.fr> writes:
Jascha Wetzel schrieb:
 BLS wrote:
 Carsten Sørensen schrieb:
 What I would like to see is tango being adopted as _the_ standard
 library for D. Clean slate. Possibly with a phobos compatibility layer.
 If that's not possible, simply drop phobos and force people to use to
 use tango with D 3.0. 

Drop Phobos. Vote++. Rationale- PRO Tango : 1) Tango is community driven (more or less) Phobos is not. 2) Tango's functionality grows with every litte update, Phobos is at a stand still. Pro Phobos : 1) Is allways up to date with the latest D compiler. General : 1) The D library situation is still lousy. Standard-GUI, Database, DTL, communication ... So having two "standard libraries" is a complete waste of time and human resourses. Bjoern

drop phobos? no way! what's wrong with joining the runtime libs? import std.string; import tango.io.FilePath; => everybody happy

LOL ! What about DTL ? DTL Tango, DTL Phobos ? No Sir...
Sep 15 2007
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jascha Wetzel" <firstname mainia.de> wrote in message 
news:fcguut$dvj$1 digitalmars.com...
 drop phobos? no way!
 what's wrong with joining the runtime libs?

 import std.string;
 import tango.io.FilePath;

 => everybody happy

I wouldn't say "everybody happy." I think it's terrible. You still have two libraries that provide more or less the same functionality but with two completely different designs. Conceptually it just doesn't make sense, even if they can be used together. Tango is meant to _supplant_ phobos, not _work along side it_.
Sep 15 2007
parent reply "Peter C. Chapin" <pchapin sover.net> writes:
Jarrett Billingsley wrote:

 I wouldn't say "everybody happy."  I think it's terrible.  You still have 
 two libraries that provide more or less the same functionality but with two 
 completely different designs.  Conceptually it just doesn't make sense, even 
 if they can be used together.  Tango is meant to _supplant_ phobos, not 
 _work along side it_. 

Personally I don't have a problem with two different libraries that do more or less the same thing getting used together. It happens a lot. Suppose library X uses (for example) XML library A, and library Y uses XML library B. A program wishing to use both X and Y ends up using, indirectly, two different XML libraries. So what? The problem here is that Phobos and Tango can't both (easily) be used in the same program. Once that matter is fixed then the problem is solved as far as I can see. Peter
Sep 15 2007
next sibling parent reply Regan Heath <regan netmail.co.nz> writes:
Peter C. Chapin wrote:
 Jarrett Billingsley wrote:
 
 I wouldn't say "everybody happy."  I think it's terrible.  You still have 
 two libraries that provide more or less the same functionality but with two 
 completely different designs.  Conceptually it just doesn't make sense, even 
 if they can be used together.  Tango is meant to _supplant_ phobos, not 
 _work along side it_. 

Personally I don't have a problem with two different libraries that do more or less the same thing getting used together. It happens a lot. Suppose library X uses (for example) XML library A, and library Y uses XML library B. A program wishing to use both X and Y ends up using, indirectly, two different XML libraries. So what?

Well... if XML lib A and XML lib B have different features, and/or do things in a slightly different way then it is possible that the program that uses them both may end up with that different behaviour in one or more places which could be frustrating for users, imagine.. "why can't I do <X> <here>, I can do it <there>" Also, it just doesn't sit well with me to duplicate functionality like that, it just _feels_ wrong. Regan
Sep 16 2007
parent reply "Peter C. Chapin" <pchapin sover.net> writes:
Regan Heath wrote:

 Personally I don't have a problem with two different libraries that do
 more or less the same thing getting used together. It happens a lot.
 Suppose library X uses (for example) XML library A, and library Y uses
 XML library B. A program wishing to use both X and Y ends up using,
 indirectly, two different XML libraries. So what? 

Well... if XML lib A and XML lib B have different features, and/or do things in a slightly different way then it is possible that the program that uses them both may end up with that different behaviour in one or more places which could be frustrating for users, imagine.. "why can't I do <X> <here>, I can do it <there>" Also, it just doesn't sit well with me to duplicate functionality like that, it just _feels_ wrong.

I agree that it may not be an ideal arrangement but if the alternative is for the programmer to rebuild library X or library Y from scratch that might be much worse. Assuming such an effort is prohibitively expensive, the programmer may have little choice but live with two libraries duplicating functionality. Also keep in mind that in my scenario library X and library Y were developed independently by competing vendors; there is no chance of convincing the X developers to use the same XML support library as the Y developers are using. Peter
Sep 16 2007
parent reply Alexander Panek <a.panek brainsware.org> writes:
I honestly doubt this case is happening very often.
Sep 16 2007
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Peter C. Chapin Wrote:

 Also keep in mind that in my scenario library X and library Y were
 developed independently by competing vendors; there is no chance of
 convincing the X developers to use the same XML support library as the Y
 developers are using.

Alexander Panek Wrote:
 I honestly doubt this case is happening very often.

Well, if the product I'm working on is any metric, it happens quite frequently. We use three different database vendor's databases to store different types of data (only one we have to pay licensing fees for). Count in engineering/test/tools code, we probably use 5+ different XML implementations. And this is just one product that integrates with a number of others. Heck, while the main system is *only* in Java and C++ with a legacy SOAP database API in Perl, and one minor subsystem in Python, the engineering and test teams have tools written in about 10 different programming languages (no D as far as I know). So judging by that, in a larger system, I expect there to be significant redundancy in tools used.
Sep 16 2007
parent Alexander Panek <a.panek brainsware.org> writes:
Robert Fraser wrote:
 Peter C. Chapin Wrote:
 
 Also keep in mind that in my scenario library X and library Y were
 developed independently by competing vendors; there is no chance of
 convincing the X developers to use the same XML support library as the Y
 developers are using.

Alexander Panek Wrote:
 I honestly doubt this case is happening very often.

Well, if the product I'm working on is any metric, it happens quite frequently. We use three different database vendor's databases to store different types of data (only one we have to pay licensing fees for). Count in engineering/test/tools code, we probably use 5+ different XML implementations. And this is just one product that integrates with a number of others. Heck, while the main system is *only* in Java and C++ with a legacy SOAP database API in Perl, and one minor subsystem in Python, the engineering and test teams have tools written in about 10 different programming languages (no D as far as I know). So judging by that, in a larger system, I expect there to be significant redundancy in tools used.

Point taken. Though, in all my naive idealism, I dare to say that the system you're working in is pretty "diverse" in its entirety. :P
Sep 16 2007
prev sibling parent reply =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Alexander Panek wrote:
 I honestly doubt this case is happening very often.

Just install Apache, mod_php and mod_python. There, in five minutes you've got multiple expat, mysql, regexp librares and lots of incompatibilities between them. I have this setup on my computer because I create some websites in PHP and others in Python.
Sep 16 2007
parent reply Alexander Panek <a.panek brainsware.org> writes:
Julio César Carrascal Urquijo wrote:
 Alexander Panek wrote:
 I honestly doubt this case is happening very often.

Just install Apache, mod_php and mod_python. There, in five minutes you've got multiple expat, mysql, regexp librares and lots of incompatibilities between them. I have this setup on my computer because I create some websites in PHP and others in Python.

It's PHP. I don't suspect anything clean from /that/, honestly. [This statement is to be taken with a grain of salt. I've been working much with PHP, and it's just a beast. A very, very ugly beast. With horns'n such.]
Sep 16 2007
parent =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Alexander Panek wrote:
 It's PHP. I don't suspect anything clean from /that/, honestly. [This 
 statement is to be taken with a grain of salt. I've been working much 
 with PHP, and it's just a beast. A very, very ugly beast. With horns'n 
 such.]

OK. Don't count PHP then. Apache and Python both have different AND separate Regex libraries. Not to count runtime, threading, etc... I mean, Apache and Python are both open source. They could very well use the same regex library but they don't and you have to use two different syntax. The point is that it's not an uncommon case as it has been stated.
Sep 17 2007
prev sibling parent John Demme <me teqdruid.com> writes:
Peter C. Chapin wrote:

 Jarrett Billingsley wrote:
 
 I wouldn't say "everybody happy."  I think it's terrible.  You still have
 two libraries that provide more or less the same functionality but with
 two
 completely different designs.  Conceptually it just doesn't make sense,
 even
 if they can be used together.  Tango is meant to _supplant_ phobos, not
 _work along side it_.

Personally I don't have a problem with two different libraries that do more or less the same thing getting used together. It happens a lot. Suppose library X uses (for example) XML library A, and library Y uses XML library B. A program wishing to use both X and Y ends up using, indirectly, two different XML libraries. So what? The problem here is that Phobos and Tango can't both (easily) be used in the same program. Once that matter is fixed then the problem is solved as far as I can see. Peter

Here's a compatibility issue I used to have all the time when I used phobos + mango... XML Lib A uses std.stream streams for i/o. HTTP Servlet engine B uses mango.io streams for i/o... Now I can't interface them. It might be possible to write a wrapper class to translate calls from one to the other, but this isn't always possible or efficient since std.stream != tango.io for a reason- the fundamental design is different. -- ~John Demme me teqdruid.com
Sep 16 2007
prev sibling parent Ender KaShae <astrothayne gmail.com> writes:
Jascha Wetzel Wrote:

 BLS wrote:
 Carsten Sørensen schrieb:
 What I would like to see is tango being adopted as _the_ standard
 library for D. Clean slate. Possibly with a phobos compatibility layer.
 If that's not possible, simply drop phobos and force people to use to
 use tango with D 3.0. 

Drop Phobos. Vote++. Rationale- PRO Tango : 1) Tango is community driven (more or less) Phobos is not. 2) Tango's functionality grows with every litte update, Phobos is at a stand still. Pro Phobos : 1) Is allways up to date with the latest D compiler. General : 1) The D library situation is still lousy. Standard-GUI, Database, DTL, communication ... So having two "standard libraries" is a complete waste of time and human resourses. Bjoern

drop phobos? no way! what's wrong with joining the runtime libs? import std.string; import tango.io.FilePath; => everybody happy

that is my personal opinion
Sep 15 2007
prev sibling parent reply "David Wilson" <dw botanicus.net> writes:
On 15/09/2007, Sean Kelly <sean f4.ca> wrote:

 it's not really possible to use Tango and Phobos
 together in the same app at the moment.  If you'll forgive my hubris, I
 /do/ believe the Tango runtime is better than the Phobos runtime, but
 this basically means that I think it would be foolish to just toss out
 the Tango runtime and turn Tango into another user-level library.  And
 that's why we are where we are today :-)

I asked about this on IRC recently and didn't get a satisfying response - beyond the extra functionality available in Phobos (which is a great thing, of course), is there anything that really substantiates the claim to "better" about the runtime part? Specifically I noticed the GC had the Digital Mars copyright notice, and on asking you about this, you told me that the two GCs were (paraphrasing) "essentially the same". In that case, what is left in the Tango runtime that is "better" that justifies it being more than just a really complete class library? As a very-newcomer to D, the Tango/Phobos choice was the first and most bitter lemon I have had to chew on yet, and I'm still not sure I really understand the differences. It seems to me with D's language features (e.g. alias), one or the other could very easily be melded into shape for perfect compatibility with the other, given that both codebases will have very similar semantics given their shared ancestry. I understand that Phobos is a very slowly evolving library, but in the face of the community's desire to scale D to a world-class programming language, that can only be a good thing. At the very least to compete in an environment like that, Tango would need much stricter change controls (say, a committee) to ensure changes weren't being made "on whim" and actually had some community benefit. Finally I have a stylistic issue regarding Tango: despite its relatively small size, the package nesting is already sufficient to confuse me; I find it difficult to delve in and find what I'm looking for. The disparity and feeling of seeming emptiness that Phobos gives may be uncomfortable at first, but when you realize there is no superhierarchy of classes and packages, and nearly any module in it is self contained, it suddenly becomes a much friendlier environment. I recently invested a number of months in learning C# - the language took all of a few days to pick up, but the .NET BCL (much like the C++ STL) is one abstract, self-referencial beast that I simply never expect to master. Compared with that, my week-long experience with Phobos has got me to the point where I know where almost everything I need on a daily basis is already. Just a newcomer's $.2. Thanks to Digital Mars for a wonderful language, and the Tango team for healthy competition! David.
 Sean

Sep 16 2007
next sibling parent kris <foo bar.com> writes:
David Wilson wrote:
 On 15/09/2007, Sean Kelly <sean f4.ca> wrote:
 
 it's not really possible to use Tango and Phobos
 together in the same app at the moment.  If you'll forgive my hubris, I
 /do/ believe the Tango runtime is better than the Phobos runtime, but
 this basically means that I think it would be foolish to just toss out
 the Tango runtime and turn Tango into another user-level library.  And
 that's why we are where we are today :-)

I asked about this on IRC recently and didn't get a satisfying response - beyond the extra functionality available in Phobos (which is a great thing, of course), is there anything that really substantiates the claim to "better" about the runtime part? Specifically I noticed the GC had the Digital Mars copyright notice, and on asking you about this, you told me that the two GCs were (paraphrasing) "essentially the same". In that case, what is left in the Tango runtime that is "better" that justifies it being more than just a really complete class library?

I perhaps answered /some/ of this in a recent post: <quote> Without hitting on a whole lot of detail, the Tango runtime support (which includes threads, exceptions, etc) has always been beyond what Phobos offered. For example, Tango has fibers (Mik & Sean). That needs to be tied into the GC also (which it is), and makes the runtime layer incompatible with the Phobos equivalent. Tango also has internal support for exception backtraces which hooks in with, for example, the Flectioned library from Thomas. The import path structure (or lack thereof) within the Phobos library, along with the namespace collisions, unfortunately lends itself to a lack of modularity and scalability. The Tango GC was both very fast and known to be free of deadlock, while the Phobos one was not until comparatively recently etc. etc. These are not intended as criticisms of Phobos, but they and many more became reason enough to take the path that the Tango folks did. </quote>
 As a very-newcomer to D, the Tango/Phobos choice was the first and
 most bitter lemon I have had to chew on yet, and I'm still not sure I
 really understand the differences. It seems to me with D's language
 features (e.g. alias), one or the other could very easily be melded
 into shape for perfect compatibility with the other, given that both
 codebases will have very similar semantics given their shared
 ancestry.

That's what Tangobos does?
 I understand that Phobos is a very slowly evolving library, but in the
 face of the community's desire to scale D to a world-class programming
 language, that can only be a good thing. At the very least to compete
 in an environment like that, Tango would need much stricter change
 controls (say, a committee) to ensure changes weren't being made "on
 whim" and actually had some community benefit.

It already has quite strict change controls. Changes generally have to get past three people to make it into the library. New submissions are scrutinized carefully. We generally set the 'bar' pretty high in a number of ways. Those three people have learned to work effectively with each other (often surprisingly so), such that we often preempt the need to have long discourses over x or y or z. That aspect helps to avoid getting mired in the quicksand of endless reviewing. FWIW: from both a social and an engineering perspective, Tango is and has been a highly educational and fun journey. It was really quite odd to find ourselves all sitting on the same seat in the back of taxicab the other week (we'd not met before: Sean and I had to describe what we'd be wearing ... Larsivi coincidently met Sean after his somewhat distinct name had shown up on a notice board at the airport ...)
 Finally I have a stylistic issue regarding Tango: despite its
 relatively small size, the package nesting is already sufficient to
 confuse me; I find it difficult to delve in and find what I'm looking
 for. The disparity and feeling of seeming emptiness that Phobos gives
 may be uncomfortable at first, but when you realize there is no
 superhierarchy of classes and packages, and nearly any module in it is
 self contained, it suddenly becomes a much friendlier environment.

As a team, we've had this concern also. The hierarchy does make sense, but it can be deep in places. Something needs to be done in this regard, but it's not as simple as (say) dump everything into one folder ;) Thankfully, Tango is deliberately loosely coupled. There have been times where we have "energetically" discussed retaining or dropping a specific /convenience/ method or function if it caused cross-coupling to occur in an expensive manner. A lot of Tango is actually free-standing, or very close to it. Having said that, Tango is also far broader and deeper than the dmd library (the user-level library seems to have 414 'module' keywords). If dmd had all the same functionality, dropped into one folder, you might have different problems?
 I recently invested a number of months in learning C# - the language
 took all of a few days to pick up, but the .NET BCL (much like the C++
 STL) is one abstract, self-referencial beast that I simply never
 expect to master. Compared with that, my week-long experience with
 Phobos has got me to the point where I know where almost everything I
 need on a daily basis is already.
 Just a newcomer's $.2.

All valid and good input! I'm not sure how we'll resolve that, but suggestions are really welcomed; especially in the form of a Ticket :P (Tickets enable us to track things much better)
 Thanks to Digital Mars for a wonderful language, and the Tango team
 for healthy competition!

Welcome!
Sep 16 2007
prev sibling parent Sean Kelly <sean f4.ca> writes:
David Wilson wrote:
 On 15/09/2007, Sean Kelly <sean f4.ca> wrote:
 
 it's not really possible to use Tango and Phobos
 together in the same app at the moment.  If you'll forgive my hubris, I
 /do/ believe the Tango runtime is better than the Phobos runtime, but
 this basically means that I think it would be foolish to just toss out
 the Tango runtime and turn Tango into another user-level library.  And
 that's why we are where we are today :-)

I asked about this on IRC recently and didn't get a satisfying response - beyond the extra functionality available in Phobos (which is a great thing, of course), is there anything that really substantiates the claim to "better" about the runtime part?

Many of the differences are really quite subtle, and to be honest, I don't even remember what half of them are. I've tried to come up with a laundry list in the past, but haven't been very successful. However, I will try to answer your questions below.
 Specifically I noticed the GC had the Digital Mars copyright notice,
 and on asking you about this, you told me that the two GCs were
 (paraphrasing) "essentially the same". In that case, what is left in
 the Tango runtime that is "better" that justifies it being more than
 just a really complete class library?

The easiest thing to point to would be the threading package. It is deadlock-free, as far as I know, as it the threading/GC integration. The same cannot be said of Phobos, last I checked. This is one of the most frequently mentioned items when I ask people why they switched to Tango from Phobos. Another difference I personally feel is very important is simply the modular design. Basically all of Ares' users were using it for kernel development and other such projects, and the structure of the library (which has been refined since Ares) simplifies such things. As for the rest, the differences are all fairly subtle. The Tango runtime contains customization points in various different areas--a custom assert handler can be bolted in, for example. But I will admit that the quality of the Phobos runtime has improved in the year and a half since Tango development began, and the code differences between the two are smaller now than they used to be.
 As a very-newcomer to D, the Tango/Phobos choice was the first and
 most bitter lemon I have had to chew on yet, and I'm still not sure I
 really understand the differences. It seems to me with D's language
 features (e.g. alias), one or the other could very easily be melded
 into shape for perfect compatibility with the other, given that both
 codebases will have very similar semantics given their shared
 ancestry.

For the most visible features of the Tango runtime, look at these modules: http://www.dsource.org/projects/tango/docs/current/tango.core.BitManip.html http://www.dsource.org/projects/tango/docs/current/tango.core.Exception.html http://www.dsource.org/projects/tango/docs/current/tango.core.Memory.html http://www.dsource.org/projects/tango/docs/current/tango.core.Runtime.html http://www.dsource.org/projects/tango/docs/current/tango.core.Thread.html
 I understand that Phobos is a very slowly evolving library, but in the
 face of the community's desire to scale D to a world-class programming
 language, that can only be a good thing. At the very least to compete
 in an environment like that, Tango would need much stricter change
 controls (say, a committee) to ensure changes weren't being made "on
 whim" and actually had some community benefit.

Tango was created largely because community involvement in Phobos development has been frustratingly difficult. Its design will remain in flux until it reaches 1.0 because we very much want to avoid breaking changes, deprecation, etc, after that point. I am hoping we will get enough feedback before then that the design is fairly well tested and proven so this does not happen.
 Finally I have a stylistic issue regarding Tango: despite its
 relatively small size, the package nesting is already sufficient to
 confuse me; I find it difficult to delve in and find what I'm looking
 for. The disparity and feeling of seeming emptiness that Phobos gives
 may be uncomfortable at first, but when you realize there is no
 superhierarchy of classes and packages, and nearly any module in it is
 self contained, it suddenly becomes a much friendlier environment.

Personally, I feel that the IO features in Tango are quite confusing, simply because there are so many options available. This is one area where Tango definitely caters to expert programmers more than novice programmers, and I do feel we could do better to make this package more accessible to new users. Documentation is obviously a huge (and needed) portion of this, but some additional convenience features may be appropriate as well. But it is difficult for us to know exactly what areas to address. User feedback is invaluable for finding trouble spots here and in all other areas of the project--documentation included. Sean
Sep 17 2007
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Stewart Gordon wrote:

 Here's how I see it.  D has one standard library.  That one standard 
 library is Phobos.  I.e. Phobos is part of the D standard.  Tango 
 isn't.  Rather, Tango is an _alternative_ to the standard library; to 
 call Tango a standard library strikes me as nonsense.

Actually there are two versions of this standard library, just as there is two versions of the standard compiler: DMD and GDC. Phobos and gPhobos are much more similar than Phobos and Tango, but different enough for the changes to get somewhat annoying... So beyond the standard and alternative libraries, we also have: the reference compiler/library and the portable compiler/library. --anders
Sep 15 2007
parent Sean Kelly <sean f4.ca> writes:
Anders F Björklund wrote:
 Stewart Gordon wrote:
 
 Here's how I see it.  D has one standard library.  That one standard 
 library is Phobos.  I.e. Phobos is part of the D standard.  Tango 
 isn't.  Rather, Tango is an _alternative_ to the standard library; to 
 call Tango a standard library strikes me as nonsense.

Actually there are two versions of this standard library, just as there is two versions of the standard compiler: DMD and GDC. Phobos and gPhobos are much more similar than Phobos and Tango, but different enough for the changes to get somewhat annoying... So beyond the standard and alternative libraries, we also have: the reference compiler/library and the portable compiler/library.

Good point. Tango minimizes these differences by reducing them to two separate compiler runtime libraries. It makes for a much saner design. Sean
Sep 15 2007