Any chance to call Tango as Extended Standard Library

[John Reimer]

Hello IUnknown,

> To D gods,
> 
> Having to learn and choose between two libraries is a big -ve point in
> adopting D. Many people would also like to use D on ARM if possible in
> the future so dividing the library into two parts would help as then
> only the core lib can be linked in.
> 


Yes, this is true.



> Really, D's community needs to grow up and create ONE standard library
> for D2. D2 would be a nice time to break backwards compatibility in
> the libraries.
> 



He he... well, you have to understand the dynamics of this D community to 
understand why the problem exists.  The D community /has/ created such a 
library: it's called Tango for D1.  I doubt the community will implement 
one for D2 until it is stable because the time and effort of chasing experimental 
language design is far too great: that area is completely reserved for the 
D core team and its Phobos.  Even if Tango were complete for D 2.0, the community 
has absolutely no say on whether it becomes the ONE standard library or not. 
 Historically, Tango was a somewhat reactive process resulting from the community 
feeling unable to influence the growth of the standard library and D 1.0.  


This is the point:  it has nothing to do with the D community as far as I 
understand it.  You'll have to talk to the D core team about this one.  They 
control what is and what is not the standard library.   They do tend to accept 
portions from the community, but not to the extent that you are going to 
see a community managed standard library.  The problem tends to be that the 
core team has one set of ideas about D's future while the community (specifically 
Tango for D 1.0) has a different set of ideas.  Sometimes the sets intersect, 
often not...  Sometimes the community has some influence on ideas, sometimes 
not.


The process of communication of this core team with the community is what 
allows the D language design to grow.  But I think it's important to erase 
the notion that the community has to get its act together.   Perhaps both 
the core team and the community should get it's act together, but then who 
speaks for the community (not everyone is involved in the Tango aspect of 
it)?  What's hugely missing is face to face communication between the two 
with the determined purpose of resolving the problem.  I've seen no evidence 
that this will happen beyond the initiation of druntime for d2.0 (a good 
start... but where does it go from there?); but I think the core team, who 
has a vested interest in D, should initiate such a venture soon if they want 
to see D succeed in the long term.


The other thing to remember is that since there is no Tango for D 2.0... 
there is no competing libraries for D 2.0 yet.  So there isn't really an 
issue there, just an odd realization that D 2.0 is a different language then 
D 1.0 where Tango is by far the most popular library.... yep it's complicated.


> A language needs large scale adoption to be successful and its
> implementations must be delivered in a ready to use manner. Many
> people find D interesting but not sufficiently interesting to switch
> away from the pain of C++. If D also has other pain points, how do you
> think it will get adopted? dmd seems lacking on floating point
> optimization. Not many platforms are supported. While platform support
> is an understandable problem and is something that happens over time.
> Having two competing libraries is simply either egoistic or retarded
> from an outsider's perspective.
> 
> Programmers simply don't seem to want to do the necessary work to make
> the software appealing to use. Many people want to use a powerful
> editor like vim, but then find that all the standard features they
> find in other editors are extensions in vim and the simple act of
> finding the right scripts even from vim's homepage is a deterrent.
> 
> Please, the worst thing you can do in deterring a person from trying
> out something new is in giving him options with no clear way to
> choose. Can't you learn this from python? Of often having one way to
> accomplish something? Merge the libs, pretty pretty please.
> 



This is a specific problem with the D langauge design process, and it is 
very hard to know what the solution to it is.  At the very least, maybe it 
would be nice to have the structure of the D design progress layed out on 
a wiki, so newcomers can better understand how D progresses.  This is D's 
handicap.  And I think most people here realize this now.


-JJR