On Thu, 07 Feb 2008 00:42:42 -0500, Dan wrote:

> Jesse Phillips Wrote:
>> I agree that Tango isn't able to keep up with the rapid changes in D2 or D3? But, in my opinion I don't think it has to in order to be called the standard library. D2 has not been released, it has no obligation to provide the same environment as D1.
> 
> Yes, but D1 is stable.  I have program Y that assumes Phobos is the standard library.  As long as stable compilers are released when Phobos is the standard library, those stable D versions will have to stay with Phobos.
> 
> If you guys want Tango to be the standard library, ship it with the dev compiler.
> 
>>The only ones that aren't looking at switching seem to be the
>> dead projects.
> 
> I found that mildly offensive.  I use Phobos because it's more suited to my needs [read: better for me].  The reasons I prefer Phobos are:
> 
> 1) I know what it does
> 2) I understand it's conventions
> 
> The *only* reason I'd consider switching to tango is if the compiled algorithms were *noticeably* faster, or tango offered some feature that I didn't want to spend time figuring out how to implement myself.  I learn things for the purpose of understanding how they work, but if the algorithm is more or less the same, I don't care.
> 
> I don't like OO things.  They're opague.  I don't understand what they do inside.
> 
> Regards,
> Dan

I'd like to give my own response to this. As I stated before I agree that D1 should remain the same. I don't see any reason not to place the Tango/ DMD download on the same page. And I said Tango should take over for D2.

I don't have a quarrel with your chosen style of coding, however it sounds as though your reasons are because you do not want to learn a new style. This is fine too, but it is not a reason to prevent the switch of a standard library. Besides, after having talked with Kris, I believe, he says that the object/function ratio of Phobos vs Tango is about the same.

Lastly I don't think you should be offended. I love the C feeling of Phobos, I still have yet to really use Tango (reading the book now) I've been around since '06. My statements where based on the trends I have observed. There are projects that are still developed under Phobos, but most of the highly active/highly used projects switch/support both.

> I don't have a quarrel with your chosen style of coding, however it sounds as though your reasons are because you do not want to learn a new style.

Well, not unless it's a noticeable improvement inside.  Since I can't really understand the algorithms at play, and they're both roughly the same "ratio of classes to real code", I see no advantages to it; just wasted time learning a new set of sequences of letters.

> This is fine too, but it is not a reason to prevent the switch of a standard library. Besides, after having talked with Kris, I believe, he says that the object/function ratio of Phobos vs Tango is about the same.

Prevent?  Why cause?

> 
> Lastly I don't think you should be offended. I love the C feeling of Phobos, I still have yet to really use Tango (reading the book now)

I was mildly offended by someone saying that only "dead projects" use Phobos; like "only cool kids consume our product".

>I've
> been around since '06. My statements where based on the trends I have observed. There are projects that are still developed under Phobos, but most of the highly active/highly used projects switch/support both.

Yeah, I tried once but ultimately realized I was creating two separate programs from the same source to accomplish the exact same thing; and I found it unneccessarily(sp?) complicating.

Well, if you guys do decide to switch, I'll live.  It's not like I can't learn API's and languages.  I'm at something like 80ish and 37.

Regards,
Dan

On Thu, 07 Feb 2008 19:06:23 -0500, Dan wrote:

> bearophile Wrote:
> 
>> Sebastian Beschke:
>> > Which is pretty much the point of OO.
> 
> The point of OO is to not know what you're doing?  Maybe that's why I'm so averse.
> 
> 
>> I agree, but the lesson here is probably that some people don't understand OO well, or they don't want to use it everywhere, or it doesn't go well with their mindset, or they need to go faster and they want to program in a more C-style, etc.
> 
> It's the mindset, apparently.  I have no preference for syntax.  It's what's inside that counts IMHO, and with OO you have no idea what's inside.
> 
>>Java has OOP only, but D allows other kinds of programming too, so maybe it may be better to not have a std lib that is fully OOP, so it can be used when you program differently (like functional-style). Tango doesn't need to be perfect for everyone, but probably there are ways to modify its structure enough to make it look good enough for most people :-)
> 
> Agreed, but I'm continuing to use Phobos as long as it's better for me, and at the moment it still is.
> 
>> I know very little about Tango still, but I have seen there are lot of people that think some changes may be in order before making it the D std lib :-)
>> 
>> > If you want to understand something in Tango, you can still read the source code.
> 
> Yes, if I want to understand anything in Tango, I need to study.  I already understand Phobos because it's similar to what I already know.
> 
> You say that Tango presents better GC and IO?
> 
> I couldn't possibly allocate 16 consoles and iterate through them without an undefined number of cache misses - because I can't control where they exist.
> 
> I couldn't possibly define classes and use copy-on-write semantics to expand them during runtime; something that was key to my thinking in the Walnut 2.x project.
> 
> I couldn't possibly be informed about the memory footprint of my program, or understand how many mispredicted? branches are taken because of the possibly painful multiple-constructor system.  I also cannot partially instantiate an object if I only need part of it for some rare case.
> 
> I can keep going on the limitations of OO.
> 
> But essentially the point is that unless it's beautiful inside, I don't care how convenient your notation is.  If the insides on which your library is built is "don't look!" then I have trouble believing they're beautiful unless you have a whole slew (like, hundreds) of benchmarks to show me.
> 
> Regards,
> Dan

umm, you do realize that Tango is open source? You can look, and make it better. This is also true with Phobos though. When I call call a string function to std.string.split() how do I know how its beautiful inside? I can't it could be the worst splitting algorithm "random split." I would have to look at the code in the function, just like I would have to look at the code in a class.

"Tim Burrell" <tim@timburrell.net> wrote in message news:fog54s$67a$1@digitalmars.com...
> Ameer Armaly wrote:
>> If we can get a systemm for accepting submitions to Phobos going, what if we made Tango a sort of expansion pack on top of it? I.E. Phobos addresses all the basic stuff, and Tango ditches all its standard library-ish code and becomes the "extended library" if you will. The way I see it the standard library should be fairly comprehensive without going in to actual nitches; that ought to be left to whatever expansion pack we put together. Thoughts?
>
> Not a bad idea!  Personally I'd still like to see the Tango standard library stuff as the base -- IMO it's higher quality, and more complete.
>
> That being said, what you suggested would be a great start, and could be enough to get Phobos where we need it to be.  Either way, a system for getting more people involved with Phobos development would be really good.
>
> The thing is, this is a huge part of the problem right now -- Phobos is currently closed, and isn't being maintained.
>
> My original proposition of adopting Tango as the standard library of choice was resting on the assumption that Walter isn't really all that interested in giving Phobos the attention it deserves (which is fine!). If that's not true (also fine!), then what you suggest is definitely something I'd be okay with.
>
> Unfortunately Walter hasn't weighed in on the subject, so it's hard to know what to believe.
>
> Come on Walter, let's hear it!  Speak up!
Definitely. Until Walter makes some kind of move we're mostly left to our
own musings, though I guess we could all just radically break off if we were
so desperate.
This definitely ought to be a topic at the next D conference; any musings on
that so far?

On Wed, 06 Feb 2008 10:49:17 -0400, Tim Burrell wrote:

> Hey all,
> 
> It seems that even though Phobos is open source, it's difficult for people to contribute to.  Patch submissions aren't being accepted as readily as they should be, and bugs remain even months after having a fix submitted by users.
> 
> Not to mention that it's confusing for new users to have to deal with two standard libraries.  I think it would be a really good thing for the language as a whole if there were only one standard library.
> 
> My personal opinion is that Walter should let go of Phobos and adopt Tango as the official standard library.  I know there are people out there that prefer the Phobos API over Tango's, but I have a feeling that if Walter asked the Tango people to maintain the Tangobos base as the official standard library for D they would be okay with that.
> 
> It would be a win-win situation for everyone, including Walter.  His time would get to be spent more on D itself, as he would likely only need to oversee the standard library in terms of input regarding the API and patchset accepts.
> 
> The community would gain a huge win because there would only be one unified standard library.
> 
> Phobos users would still be able to use the Phobos API but would gain the benefits of using an API that they feel they can contribute to, and that has a proven track record of being responsive to fixing bugs. They'd also gain the ability to use the odd Tango class when desired.
> 
> And Tango users wouldn't have to deal with using a non-standard library as the basis for their app, plus the ability to use the odd bit of the Phobos API would be nice now and again as well.
> 
> I really feel strongly that a move toward a single standard library is the right thing to do for D.  There's very few cons to such a move and a great many pros.
> 
> Anyone else have any thoughts on the matter?
> 
> Tim.

I would like to express why I think Walter is silent in the matter. The standard library would be a big change. This is to say there are a lot of people that stick with the library that comes with the compiler. A switch of the standard lib would cause a ripple effect that would disturb those that don't use Tango. While this is doable it is not something to hastily do.

It is quit possible that some time in the future Tangos momentum slows and Phobos surpasses as the mainly used library. We don't want to be switching back and forth as the community takes a liking to one or the other.

There are areas that Tango falls behind in and it would be best to have them addressed before such a switch. I think any action should wait for the release of D2, but I think the choice as to what will be expected to happen should be declared now.

dominik:
> walter did AWHILE ago Bigint implementation for zortech I believe, wouldn't it be nice to make it a part of D, not library per se? Be ti simple BCD implementation, I don't care, but I care for BigInt.

I'd like to have such bignum lib in the std lib. If someone here knows of a *working* bignum lib, please tell me, because I have tried many but none works.

Muti precision integral values are very useful, not for crypto purposes as some say, but because they don't overflow, so you can use them without caring of that *large* class of bugs (a certain percentage, like 10-30%, of all bugs comes from integral type overflows/underflows). Reducing that cognitive burden has the side effect of speeding up coding a bit too, because you can focus your minds on other things.
Experience shows that on modern CPUs a certain (often large) percentage of the code doesn't need to be optimized a lot (this is why scripting languages are so used today), while you can use fixnums in the speed critical sections of the code.
Said that, the DMD can grow smarter: it can infer some of the situations where a bigint doesn't actually needs to be a bigint (silly example: for(bigint i =0; i < 100; n++) {}) and it can replace them with fixnums :-) This can probably speed up the code enough, so people will use them in a more relaxed way, and this will reduce bug count even more :-) I don't know how much easy such bound inferring is, and how much it can slow down the compiler.

Bye,
bearophile

Jesse Phillips wrote:
> I would like to express why I think Walter is silent in the matter. The standard library would be a big change. This is to say there are a lot of people that stick with the library that comes with the compiler. A switch of the standard lib would cause a ripple effect that would disturb those that don't use Tango. While this is doable it is not something to hastily do.

You're right a lot of people do stick with the lib that comes with the compiler, and that's precisely why this issue is so important.  The fact that Phobos isn't being actively maintained is also likely to cause a ripple effect -- this is an issue, that if left undealt with, could be something that ends up making or breaking D as a mainstream language.

And, don't forget that even if a switch to Tango were to occur, it could be done so that it doesn't disturb users of the Phobos API!

Agreed though, that it's not something that should be done hastily, or without much consideration.  I have my opinion on the matter, but all I really want is to push the issue enough to ensure that Walter knows that a good majority of the community believes something needs to happen here, and that this is an issue that needs addressing.

I think you misunderstood the point of Sebastian and bearophile's posts. Structured programming, as I'm sure you know, is about interface over implementation. You read the documentation of a function, or class, or whatever, which can gauruntee [I spelled that so bad the spell checker isn't suggesting the correct one...] a specific interface (here are my preconditions and postconditions), because in the vast majority of cases you shouldn't care how it's implemented, as long as it works correctly and at a reasonable speed. It's not a "don't look" philosophy at all, it's a "you shouldn't have to look". That's Tango's philosophy, as well as Phobos's, as well as most APIs over the last 20 or so years AFAIK.

If you want to look at the implementation, both Tango and Phobos are open source, so go ahead. It's not more difficult or taboo to look at Tango's source than it is to do so at Phobos's.

Demanding hundreds of benchmarks is slightly unreasonable IMO; there are already some benchmarks (I doubt there will ever be hundreds) showing that Tango's IO is faster than Phobos's, and Phobos has adopted the Tango GC, so there must be something to that. However, from an implementation/algorithmic standpoint, it makes sense that Tango's IO model would be faster since it attempts to reduce allocation by extensive use of memory slicing.

Your points on memory allocation, in particular, seem founded on incorrect assumptions. Kris could tell you a lot better than I could (since I don't even use Tango often, let alone develop it), but much of the IO model is based on avoiding allocation and GC usage whenever possible. While Tango has a couple more explicit "new"s in there, Tango does significantly fewer implicit allocations of buffers. This also leads to better cache locality.

Finally, while you make many valid points as far as heap-allocated memory go, what exactly does that have to do with object-oriented programming? D supports stack-allocated classes, and many Phobos functions do heap allocation (mainly of dynamic arrays). If you're using either library, or really any libraries written for a language with built-in garbage collection, it's rather difficult to avoid heap usage at all. If that's what you're trying to do, you're probably going to have to re-implement much of the functionality yourself anyway.

While I agree that you should use whatever library you're more comfortable with and suits your style, I believe you might be misinformed about some of the issues you bring up, in particular the amount of memory allocations performed in Tango and Phobos, and Tango's design philosophy.

Dan wrote:
> bearophile Wrote:
> 
>> Sebastian Beschke:
>>> Which is pretty much the point of OO.
> 
> The point of OO is to not know what you're doing?  Maybe that's why I'm so averse.
> 
>> I agree, but the lesson here is probably that some people don't understand OO well, or they don't want to use it everywhere, or it doesn't go well with their mindset, or they need to go faster and they want to program in a more C-style, etc. 
> 
> It's the mindset, apparently.  I have no preference for syntax.  It's what's inside that counts IMHO, and with OO you have no idea what's inside.
> 
>> Java has OOP only, but D allows other kinds of programming too, so maybe it may be better to not have a std lib that is fully OOP, so it can be used when you program differently (like functional-style). Tango doesn't need to be perfect for everyone, but probably there are ways to modify its structure enough to make it look good enough for most people :-)
> 
> Agreed, but I'm continuing to use Phobos as long as it's better for me, and at the moment it still is.
> 
>> I know very little about Tango still, but I have seen there are lot of people that think some changes may be in order before making it the D std lib :-)
>>
>>> If you want to understand something in Tango, you can still read the source code.
> 
> Yes, if I want to understand anything in Tango, I need to study.  I already understand Phobos because it's similar to what I already know.
> 
> You say that Tango presents better GC and IO?
> 
> I couldn't possibly allocate 16 consoles and iterate through them without an undefined number of cache misses - because I can't control where they exist.
> 
> I couldn't possibly define classes and use copy-on-write semantics to expand them during runtime; something that was key to my thinking in the Walnut 2.x project.
> 
> I couldn't possibly be informed about the memory footprint of my program, or understand how many mispredicted? branches are taken because of the possibly painful multiple-constructor system.  I also cannot partially instantiate an object if I only need part of it for some rare case.
> 
> I can keep going on the limitations of OO.
> 
> But essentially the point is that unless it's beautiful inside, I don't care how convenient your notation is.  If the insides on which your library is built is "don't look!" then I have trouble believing they're beautiful unless you have a whole slew (like, hundreds) of benchmarks to show me.
> 
> Regards,
> Dan

Ameer Armaly wrote:
> "Tim Burrell" <tim@timburrell.net> wrote in message news:fochd0$30te$1@digitalmars.com...
>> Hey all,
>>
>> It seems that even though Phobos is open source, it's difficult for
>> people to contribute to.  Patch submissions aren't being accepted as
>> readily as they should be, and bugs remain even months after having a
>> fix submitted by users.
>>
>> Not to mention that it's confusing for new users to have to deal with
>> two standard libraries.  I think it would be a really good thing for the
>> language as a whole if there were only one standard library.
>>
>> My personal opinion is that Walter should let go of Phobos and adopt
>> Tango as the official standard library.  I know there are people out
>> there that prefer the Phobos API over Tango's, but I have a feeling that
>> if Walter asked the Tango people to maintain the Tangobos base as the
>> official standard library for D they would be okay with that.
>>
>> It would be a win-win situation for everyone, including Walter.  His
>> time would get to be spent more on D itself, as he would likely only
>> need to oversee the standard library in terms of input regarding the API
>> and patchset accepts.
>>
>> The community would gain a huge win because there would only be one
>> unified standard library.
>>
>> Phobos users would still be able to use the Phobos API but would gain
>> the benefits of using an API that they feel they can contribute to, and
>> that has a proven track record of being responsive to fixing bugs.
>> They'd also gain the ability to use the odd Tango class when desired.
>>
>> And Tango users wouldn't have to deal with using a non-standard library
>> as the basis for their app, plus the ability to use the odd bit of the
>> Phobos API would be nice now and again as well.
>>
>> I really feel strongly that a move toward a single standard library is
>> the right thing to do for D.  There's very few cons to such a move and a
>> great many pros.
>>
>> Anyone else have any thoughts on the matter?
>>
> If we can get a systemm for accepting submitions to Phobos going, what if we made Tango a sort of expansion pack on top of it? I.E. Phobos addresses all the basic stuff, and Tango ditches all its standard library-ish code and becomes the "extended library" if you will. The way I see it the standard library should be fairly comprehensive without going in to actual nitches; that ought to be left to whatever expansion pack we put together. Thoughts?
> 
> It's good to be back by the way; getting settled at college can take a while with classes and the like.
>> Tim. 
> 
> 

Bad thought. Tango's IO model, in particular, is very different and IMO, much better/faster. On the other hand, the C feel of Phobos's IO is more comfortable for some people, and making that a bunch of wrapper functions is no better, since then you have two APIs for one thing.

Moritz Warning wrote:
> On Thu, 07 Feb 2008 00:58:50 +0000, Moritz Warning wrote:
> 
>> Just some thing I have missed to be mentioned in this discussion. I hope
>> I can contribute some some interesting/productive perspective.
> 
> Before sb. points out that I forgot to realize that Phobos doesn't get enough fixing despite patch are available (thanks to the effort of users!)...
> It's a pity that Phobos bugs/fixes doesn't get more attention from
> the maintainers. :|
> But it doesn't make Tango a more suitable library for that purpose.

Yes it does. Bugs inhibit the usability of a library, and everyone has to use the standard library. So a buggy library is a poor candidate for the standard library, especially when there's an alternative that's much  more reliable.