Here we go...

I'm an experienced C/C++ programmer and am very close to refusing to program C++ (does this happen to all C++ programmers at some point?), which is why I'm looking at alternatives. Obviously, D is the best candidate (for me) at the moment.

What disturbs me is the fact that every new language introduces a new 'standard' library. And it's mostly the success of the standard library that determines the language's faith. It's one thing to learn a new syntax, but with each new language we also have to learn a new library. This wastes a lot of time, probably more than learning the language itself. Why is there no single, cross-language standard library? .NET?

In this respect, I think Microsoft's got it right with their .NET framework: whatever language you use, there's only one 'standard library'. Python's library (the default modules) is also very extensive and I'm convinced it's one of the reasons for that language's success: whatever you want to make, most work has probably been done already in some module or other.

And then there's D with Phobos. Of course, D has all rights to have its own library, in its own structure, framework, hierarchy. Similar to other languages, Phobos should be the key to D's success. But it gets confusing. Phobos has some problems and lacks functionality. Great, problems can be fixed and functionality can be added. But I've noticed that there are two more 'standard libraries': Ares and Mango. (Perhaps Mango's not really a standard library, but just count the number of times people need something and it happens to be in Mango; shouldn't it be standard?)

"Great! Freedom of choice! Through competition, the alternatives will
evolve: the consumer wins!"
Either that, or it will split the 'consumers', and we'll have 'outages'
before you know it.

I'm really confused. How much of D is actually Phobos? Are the things I don't like in D actually shortcomings in Phobos? Wouldn't D be better with Ares, or Mango included, or merged? Yes, they can be downloaded and added, but don't underestimate the power of 'out-of-the-box'. Would Python have succeeded without all those modules? "Just go to python.org and get what you need!" Would you, really?

Which brings me back to a post of mine some time ago. At that time I suggested to port Phobos 'back' to C++. Ridiculous? Stay with me.

Porting Phobos to C++ would not only make it a cross-language library, but also familiarize people with the library's layout and help acceptance of D: imagine knowing a C++ Phobos and only afterwards getting to know D. Having a C++ Phobos would also be a first conversion step for existing C++ projects towards D. By the time DMD reaches 1.0, a C++ project using Phobos would be ported to D in no time. Having a larger user base would also help standardize and stablize Phobos, another benifit to the D community. But perhaps keeping two implementations of the same library is undoable.

I like D, but I'm reluctant to invest time in getting to know Phobos. I don't like C++ (or C# for that matter) but it just seems a good 'investment' to spend time getting familiar with the .NET framework.

Language... Library... Language.. Library.. Why can't I have both? Like that guy that liked Python, but also liked the .NET framework. He ended up writing his own MSIL language (Boo) based on python. I definately don't want to write another language! Couldn't if I wanted to.

My point? Something must be done about D's standard library. A repository would be a good start. That's a plus for Ares and Mango. And the treshold should be lowered. This can be achieved by either porting the D standard library to other languages, or by adopting the structure of another common library.

My suggestions:
* merge Phobos, Ares and Mango into one helluva standard library
* adopt either the .NET framework or the python modules structure

Of course, D's standard library must remain in native code. I'm only suggesting adopting another library's structure.

Do react.

L.

Lionello Lunesu wrote:
> 
> I'm really confused. How much of D is actually Phobos? Are the things I don't like in D actually shortcomings in Phobos? Wouldn't D be better with Ares, or Mango included, or merged? Yes, they can be downloaded and added, but don't underestimate the power of 'out-of-the-box'. Would Python have succeeded without all those modules? "Just go to python.org and get what you need!" Would you, really?

A lot of D is in Phobos, in the 'internal' area.  Ares includes all this as well, but rearranged into dmdrt (runtime) and dmdgc (garbage collector) sub-libraries.  Beyond that Ares contains little more than what is needed to build and run a D application, most of which is also present in  Phobos, so there would be little reason to include Ares in Phobos... excepting perhaps std.atomic.

I'll reply to the rest later.  I'm running late and need to get out of the house :-)


Sean

If you have time enough to learn D, then you should have time enough to learn phobos. ( http://www.digitalmars.com/d/phobos/phobos.html ) Phobos is really simple. Merging phobos, ares, and mango would not make phobos any easier to learn.

I can't imagine C++ developers would want to use Phobos as their standard library, since they already have their own + STL + boost, and they most likely don't want to be forced to use the garbage collector.

I don't think the D community has the resources to create a cross platform version of the .NET libraries anyway. Same for python.

> My point? Something must be done about D's standard library. A repository would be a good start. That's a plus for Ares and Mango. And the treshold should be lowered. This can be achieved by either porting the D standard library to other languages, or by adopting the structure of another common library.
>
> My suggestions:
> * merge Phobos, Ares and Mango into one helluva standard library
> * adopt either the .NET framework or the python modules structure

I think it's universally acknowledged that Phobos must change and grow. Even though it's still in beta, D is very usuable, while its library lets it down (I've found myself preferring to reinvent the wheel rather than try to cope with its bugs and shortcomings).

What should constitute a standard library? It is perhaps worth considering other standard libraries. J2SE/J2EE and the .NET framework (and to some extent Delphi's VCL) cover a vast swathe of ground, from base types to collections, from I/O to HTTP, from XML processing to databases, from graphics to windowing. But the C++ standard library restricts itself more or less to containers and memory. Ruby and Python seem to fall somewhere between the two camps. Where should Phobos draw the line?

Looking at Boost - it began as a repository and over time evolved into a comprehensive library, parts of which are to be brought into a future C++ standard. I think copying Boost's model would prove too slow if the aim is to improve Phobos now. However, Walter, single-handedly, won't be able to build a library the size and scale of others mentioned above.

So as I see it, the solution is for the community to club together and build its own ideal standard library, and if it ends up remaining unofficial, so be it - D users would at least have a single, deep, compendious library to code against. What would the cons be of taking this path (design by committee isn't always a curse)?

As for basing your library on other language's libraries, there'd be numerous pitfalls you'd need to avoid. Do you slavishly clone every aspect? What about differences in behaviour? Users would probably expect it to function the same as the API they're accustomed to (I think we've seen some of this already with DWT and DFL). And so on. But such an approach could provide a good, solid springboard.

In this day and age, I reckon a practical, valuable standard library should include, on top of what Phobos provides, modules that cover character encoding (and conversions), globalisation (calendars, cultures), Internet/HTTP (with asynchronous I/O), databases (SQL etc), and XML (stream-based readers and writers, a DOM implementation, schemas, XSLT, XPath).

One consideration - what's the consensus on distributing shared binaries with a library? Certainly this would speed things up, like the writing of the XML packages, which could sit atop libxml2 (and in fact I have already done this).

John.

Lionello Lunesu wrote:
> 
> I like D, but I'm reluctant to invest time in getting to know Phobos. I don't like C++ (or C# for that matter) but it just seems a good 'investment' to spend time getting familiar with the .NET framework.

It's important to learn to use the tools you plan to use to complete your particular project.  If you're writing D code, that may be some or all of Phobos, or it may be none of it.  Same goes for the .NET library.

> Language... Library... Language.. Library.. Why can't I have both? Like that guy that liked Python, but also liked the .NET framework. He ended up writing his own MSIL language (Boo) based on python. I definately don't want to write another language! Couldn't if I wanted to.

Someone was working on an MSIL compiler for D.  The project was doing pretty well the last time I heard about it, too, though it's been a while since then.

> My point? Something must be done about D's standard library. A repository would be a good start. That's a plus for Ares and Mango. And the treshold should be lowered. This can be achieved by either porting the D standard library to other languages, or by adopting the structure of another common library.

Ares was created to serve a twofold purpose: first, some folks were unhappy with the overall "feel" of Phobos for one reason or another and wanted to try and address those issues, and second, response from Walter regarding library submissions has been a bit too slow on occasion for the rabid newsgroup posse, and it seemed like a community-driven effort might be more accessible.  That said, I'm not particularly interested in seeing Phobos, Ares, or Mango ported to another language, largely because I'm using D because I prefer it to those other languages.  In a world full of procedural languages, the reasons to choose one over another typically come down to tool support or style preference.

> My suggestions:
> * merge Phobos, Ares and Mango into one helluva standard library
> * adopt either the .NET framework or the python modules structure
> 
> Of course, D's standard library must remain in native code. I'm only suggesting adopting another library's structure.

All of the libraries you've mentioned are still evolving.  If there's something you like or don't like about one of them, by all means post feedback.  And if you're interested in porting another library to D, feel free to do so.  The greatest barrier to progress is a lack of free time ;-)


Sean

Sean Kelly wrote:
> Someone was working on an MSIL compiler for D.  The project was doing pretty well the last time I heard about it, too, though it's been a while since then.
> 

Deja Augustine was doing a great job with that, but unfortunatelly he doesn't seem to be working on it any more.

Although having a MSIL D compiler would be great. I am often forsed to program in .NET and it would be wonderfull to be able to do that in my favourite language.

On Tue, 22 Nov 2005 22:21:40 +0100, Ivan Senji <ivan.senji_REMOVE_@_THIS__gmail.com> wrote:

>Deja Augustine was doing a great job with that, but unfortunatelly he doesn't seem to be working on it any more.
>
>Although having a MSIL D compiler would be great. I am often forsed to program in .NET and it would be wonderfull to be able to do that in my favourite language.

I requested (quite politely of course) that Deja Augustine release the source to the D community so we could continue to develop it. Unfortunately I never heard back from him.

I know a thing or two about MSIL but I lack the experience to write a full parser and compiler. I could not start a project such as this, but I could definitely improve on existing code if it were available.

Chris

> A lot of D is in Phobos, in the 'internal' area.  Ares includes all this as well, but rearranged into dmdrt (runtime) and dmdgc (garbage collector) sub-libraries.  Beyond that Ares contains little more than what is needed to build and run a D application, most of which is also present in Phobos, so there would be little reason to include Ares in Phobos... excepting perhaps std.atomic.

Seperating the core D stuff from the rest is a good start. And 'atomic' sounds like something that I'd put in a standard library (D has 'synchronized', so something like 'atomic makes sense). By the way, how is 'synchronized' done? Is it also done by the library?

L.

"clayasaurus" <clayasaurus@gmail.com> wrote in message news:dlvkg7$2a4k$1@digitaldaemon.com...
> If you have time enough to learn D, then you should have time enough to learn phobos. ( http://www.digitalmars.com/d/phobos/phobos.html ) Phobos is really simple. Merging phobos, ares, and mango would not make phobos any easier to learn.

Learning D is all about learning Phobos, that's my point. The language is just too easy : ) The problems start then you notice something missing in Phobos and start looking at other libs, and you find out that also Ares and Mango have file-IO. And then there's also the CRT, yet another way of doing things.

> I can't imagine C++ developers would want to use Phobos as their standard library, since they already have their own + STL + boost, and they most likely don't want to be forced to use the garbage collector.

I'm a c++ developer and I don't use STL / Boost (which leaves "own" :-). And nobody's forcing anybody. I would love to get familiar with Phobos and garbage collection in my current C++ projects. Surely I'm not alone?

> I don't think the D community has the resources to create a cross platform version of the .NET libraries anyway. Same for python.

I disagree. The only thing you'd have to do is use a similar module/class structure. It's not even needed to implement the complete .NET framework (the "compact .NET framework"?) to get started. It's just so people don't have to look to far to know how to go about doing something.

In my original post I forgot to mention the fact that in D+Phobos there are in fact many ways of doing the same thing. You can even use the ol' CRT, or worse mix CRT / Phobos. In fact, some parts of Phobos appear to be using CRT. The CRT is the first lib I'd through out of the window. It's nice to have it somewhere, in case you want to port an existing project.

L.

I think it's universally acknowledged that Phobos must change and grow. Even
> though it's still in beta, D is very usuable, while its library lets it down (I've found myself preferring to reinvent the wheel rather than try to cope with its bugs and shortcomings).

That can't be right. Who wants to do that? If the solution to problems in Phobos is 'to reinvent the wheel' it's clear that there's something wrong somewhere.

> What should constitute a standard library? It is perhaps worth considering other standard libraries. J2SE/J2EE and the .NET framework (and to some extent Delphi's VCL) cover a vast swathe of ground, from base types to collections, from I/O to HTTP, from XML processing to databases, from graphics to windowing. But the C++ standard library restricts itself more or less to containers and memory. Ruby and Python seem to fall somewhere between the two camps. Where should Phobos draw the line?

Defining this would indeed be a good start. But also the other functionality (not in Phobos) should be given direction.

> Walter, single-handedly, won't be able to build a library the size and scale of others mentioned above.

Of course. My concern is that Phobos stays as is and that 'other functionality' will only be available in 'third party' libraries, scattered among multiple, overlapping libraries. Your linked exe ends up having 4 different 'open file' functions.

> So as I see it, the solution is for the community to club together and build its own ideal standard library, and if it ends up remaining unofficial, so be it - D users would at least have a single, deep, compendious library to code against. What would the cons be of taking this path (design by committee isn't always a curse)?

I think that's perfect! And whiule designing this new library, why not adopt an existing library's structure? Should also save some time since you don't spend much time thinking about the API, classes, interfaces.

> As for basing your library on other language's libraries, there'd be numerous pitfalls you'd need to avoid. Do you slavishly clone every aspect?

I think the positive aspects of slavishly cloning the structure outweigh the negative. Familiarity for many people is a greater benefit (to them, and therefor to the language) than being able to optimize special cases.

> What about differences in behaviour? Users would probably expect it to function the same as the API they're accustomed to (I think we've seen some of this already with DWT and DFL). And so on. But such an approach could provide a good, solid springboard.

By adopting an existing API you obviously adopt its behaviour. The behaviour
of the function is in fact more important than it's name or the module it's
in. Thinking about it, I think it's the behaviour of functions that takes
the longest to learn. Does it throw? Does it accept null? What if....?
As for DWT, DFL: they should both have adopted WTL or Windows Forms, or VCL
or something :-)

> In this day and age, I reckon a practical, valuable standard library should include, on top of what Phobos provides, modules that cover character encoding (and conversions), globalisation (calendars, cultures), Internet/HTTP (with asynchronous I/O), databases (SQL etc), and XML (stream-based readers and writers, a DOM implementation, schemas, XSLT, XPath).

I agree. Seems Phobos has a long way to go.

> One consideration - what's the consensus on distributing shared binaries with a library? Certainly this would speed things up, like the writing of the XML packages, which could sit atop libxml2 (and in fact I have already done this).

I don't know what the consensus is but I wouldn't mind ; )  It surely beats the rewriting the whole lib in D.

L.