Dan schrieb:
> I don't like OO things.  They're opague.  I don't understand what they do inside.

Which is pretty much the point of OO. Ideally, however, they'll be so
well documented that you'll understand how to use them. (Granted that's
not always true with Tango, but it's improving.)
It's a way to get complexity out of your head to allow you to
concentrate on your own project-specific complexities.

If you want to understand something in Tango, you can still read the source code. I don't see how this affects a possible standard library choice.

Regards
Sebastian

Sebastian Beschke:
> Which is pretty much the point of OO.

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

The source code of Phobos is a simpler read to me (it's a matter of style too, I presume, not just of higher complexity coming from higher capabilities).

Bye,
bearophile

On Thu, 07 Feb 2008 07:42:42 +0200, Dan <murpsoft@hotmail.com> wrote:

> I found that mildly offensive.  I use Phobos because it's more suited to my needs [read: better for me].

I disliked Tango in the past, but the reasons why I disliked it are now mostly gone. It used to be quite buggy (the first time I used it I got the impression that most of the code was never tested in real-life scenarios), the syntax was too verbose (this was reduced by adding shortcuts like static opCall constructors), and the necessity to use lots of import statements (for which the tango.group package was added).

> 1) I know what it does

I don't understand your point - do you mean, the quality of the documentation, or the straight-forwardness of the source code? Sure, Tango code is more organized, and you need to read more to see what something does for sure (until you understand the general structure of the library), but I don't see a striking (black vs white) difference otherwise.

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

It's been shown numerous times in this newsgroup that some Tango components, like IO and the garbage collector, perform significantly better than the Phobos implementations. This is quite a reason in itself unless performance is a non-issue (why are you using D and not some scripting language anyway, then? :) )

That said, for my last project I've decided to use a mixture of Tango and Tangobos. Tango is missing some Phobos features like Windows registry access and std.dateparse (which allows heuristic parsing of an undefined date format), as well as some minor design flaws (using the Tango library, it's impossible to enumerate all incl. hidden files in a folder). Doing some things in Tango is still not a pretty as with Phobos, for example enumeration of files in a directory. I would have probably successfully completed that project using Phobos alone, if it wasn't for that DDBI has practically dropped Phobos support.

-- 
Best regards,
 Vladimir                          mailto:thecybershadow@gmail.com

On 2008-02-06 23:10:46 -0500, Jesse Phillips <jessekphillips@gmail.com> said:

> The only ones that aren't looking at switching seem to be the
> dead projects. This to me is a big indicator that Tango should take the
> stand. People are going to avoid using Tango because it is not "the"
> standard library.

I haven't used Tango that much, but each time I look at it it takes much more time to find what I need than with Phobos. With Phobos, I generally open the std folder, glance at the file, pick the one that looks like it has what I need, and find what I want in it (most of the time). In tango, this is much more difficult unless you are already familiar with the layout of the library.

Case in point: tango.stdc.stringz; why does that deserve its own module? There are so much tiny modules in Tango that I find it difficult to find what I want. Still tango.stdc.stringz, I wonder why the function to convert to a D string is called fromStringz... I can understand the function's name, but it just seem silly to not call it toString and take advantage of function overloading. In this case I find Phobos approach better: string functions are concentrated in one easy-to-find place. In Tango, you have tango.stdc.stringz, then you have tango.text.convert.<insert your type here>, then you have tango.text.Text, tango.text.Ascii, tango.text.Util and so on. Anyone can guess where the replace function is (within the last three) without looking in each module separately?

Answer: it's in tango.text.Util; tango.text.Text doesn't deal with D strings, it's the home of the Text class (with also has a replace function, although not the one I was searching for) and tango.text.Ascii holds (as one would expect) functions (only four!) relating to character case which are restricted to ASCII domain.

There are also a few stylistic things I don't like about tango: character case for abbreviations for instance (Ascii instead of ASCII?) and the uppercase module names.

Personally, I'd prefer to see Phobos kept as the standard library and improved technically to the level Tango is at now.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Michel Fortin wrote:
> Personally, I'd prefer to see Phobos kept as the standard library and improved technically to the level Tango is at now.

The problem is, you can't keep Phobos and have it improved technically.
 It's just not going to happen, that's the whole reason this thread was
started!

Walter isn't doing his job when it comes to maintaining Phobos, and he isn't opening it up to the contributors who are willing to help!

Also, there's _already_ an existing compatibility layer for Tango that allows you to use the Phobos API with the quality of Tango.

I think we'd all prefer to see Phobos improved technically, but it's just not happening.  And fact is, we have a dedicated team who have put together a quality library, that has a full implementation of Phobos built on top of it (which is also more efficient than Phobos).

That being said, most people do prefer the Tango API over Phobos, so if the majority of the D community is saying "let's do this!", and given that there's really no reason not to (ie people who like Phobos can still use Phobos), AND given that Walter has proven he's not interested in doing a proper job at maintaining Phobos, it just doesn't make sense to keep it around.

Tim.

Dan wrote:
> 
> I don't like OO things.  They're opague.  I don't understand what they do inside.

Functions are opaque too, isn't that the point?


Sean

On Thu, 07 Feb 2008 15:49:01 +0200, Michel Fortin <michel.fortin@michelf.com> wrote:

> Still tango.stdc.stringz, I wonder why the function to convert to a D string is called fromStringz... I can understand the function's name, but it just seem silly to not call it toString and take advantage of function overloading.

Try it. Function overloading across modules just doesn't work.
Even worse, if a function is declared private in one module, it will still collide with another public function of the same name - I guess that's a compiler bug.

-- 
Best regards,
 Vladimir                          mailto:thecybershadow@gmail.com

bearophile wrote:
> Sebastian Beschke:
>> Which is pretty much the point of OO.
> 
> 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. 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 :-) 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 :-)

I know I've said this before, but to me, the important thing is that a library could be efficiently and easily applied to my needs.  And I believe this has more to do with the assumptions the library makes than whether it uses functions or objects.  For example, let's say that I want to copy a file and I don't want any memory to be allocated in the process nor do I want an exception thrown if a failure occurs, but instead I want a return value to indicate the failure.  If the only means provided for this by the library allocates a buffer to do so then I'm sunk.  And if the routine or routines throw on failure then I have to trap the exceptions, which means a loss of efficiency.

The Tango library was designed to make as few assumptions as possible about intended use, and thus it is very modular.  It does have a fairly considerable learning curve in some cases as a result, but in exchange, I feel that it can be easily molded to the programmer's needs in many more cases than would otherwise be possible.  Don't like objects? Create wrapper functions to do the operations which require them.  Doing so is trivial and it must only be done once.  In exchange, it is quite likely that you won't be fighting the API because it made invalid assumptions about how it should be used.

>> If you want to understand something in Tango, you can still read the source code.
> 
> The source code of Phobos is a simpler read to me (it's a matter of style too, I presume, not just of higher complexity coming from higher capabilities).

The source code of Tango is definitely more spread out, so you will likely have to look at more files to sort out how to do something than you would in Phobos.


Sean

Michel Fortin wrote:
> I haven't used Tango that much, but each time I look at it it takes much more time to find what I need than with Phobos. With Phobos, I generally open the std folder, glance at the file, pick the one that looks like it has what I need, and find what I want in it (most of the time). In tango, this is much more difficult unless you are already familiar with the layout of the library.

There is a book about D+Tango, and it's really a good reference. Apart from that, the online documentation is being worked on. It's not so easy to keep the documentation up-to-date by automated ddoc generation while putting it in a reasonable format right now. That's a lack that is known. If you have any ideas how to improve it, they are very welcome.

> Case in point: tango.stdc.stringz; why does that deserve its own module?

Because you just need that functions, sometimes, without anything else from tango.stdc .

> There are so much tiny modules in Tango that I find it difficult to find what I want.

That's true. The tango.group packages try to address this. Have you looked at them yet? Maybe you can come up with something you'd need additionally?

> Still tango.stdc.stringz, I wonder why the function to convert to a D string is called fromStringz... I can understand the function's name, but it just seem silly to not call it toString and take advantage of function overloading. In this case I find Phobos approach better: string functions are concentrated in one easy-to-find place. 

It's not always ideal to have everything in one place. Contextual grouping (tango.group) in combination with selective modules is probably  better - besides actually /using/ D's namespace/module features.

> In
> Tango, you have tango.stdc.stringz, then you have tango.text.convert.<insert your type here>, then you have tango.text.Text, tango.text.Ascii, tango.text.Util and so on. Anyone can guess where the replace function is (within the last three) without looking in each module separately?
> 
> Answer: it's in tango.text.Util; tango.text.Text doesn't deal with D strings, it's the home of the Text class (with also has a replace function, although not the one I was searching for) and tango.text.Ascii holds (as one would expect) functions (only four!) relating to character case which are restricted to ASCII domain.

Where would you put or expected it?

> There are also a few stylistic things I don't like about tango: character case for abbreviations for instance (Ascii instead of ASCII?) and the uppercase module names.

It's a one convention that was chosen in an early stage - one of many, where none fits everyone perfectly.

Michel Fortin wrote:
> 
> Answer: it's in tango.text.Util; tango.text.Text doesn't deal with D strings, it's the home of the Text class (with also has a replace function, although not the one I was searching for) and tango.text.Ascii holds (as one would expect) functions (only four!) relating to character case which are restricted to ASCII domain.

tango.text.Text used to be tango.text.String but was changed when we switched Object.toUtf8 to Object.toString, for obvious reasons.


Sean