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.


 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.
 


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 

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


Sorry,my mistake. I mean D 2.x
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.


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?




 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 next 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
prev sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Alexander Panek Wrote:

 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


When you have 130+ people working on the system at any one time, probably 250+
touching it at one point or another and 7+ years of development, it's sort of
impossible to keep everything conformed to one style.
Sep 17 2007