Just been reading various library-related posts, and it occurs to me that we have two alternatives:

1. We write everything from scratch.

  pros: no IP issues, 100% pure D, huge feeling of satisfaction all round
  cons: will take a long time, very difficult to have a coherent suite of
libraries, there'll be a *lot* of debate

2. We wrap existing C libraries, and employ mixed libraries

  pros: get there quicker, may be able to borrow what is good from existing
designs (in terms of sculpting interfaces I mean) and can re-present what is
not, less fatuous debate
  cons: may be seen as incomplete by purists, IP issues in some cases
(although we'd just not use what we couldn't use, so this is a furphy
really)

3. We wrap existing C libraries, with the intent to eventually move them all over to D

  As before, apart from becomes 100% pure D, and we rewrite what we cannot
(freely) borrow

Thoughts?


I also think it's very important to recognise that the best libraries are built by a small team (1-4 people, usually) and that this conflicts with the need to have the libraries mutually compatible. I'm not talking about having everything coupled a la Java, and much of the C++ std library. Frankly I hate coupling, and am left thoroughly underwhelmed by the authors of coupled libraries. (Maybe Walter's done us a big favour by making strings built-in, as this is the biggest source of coupling IMHO. Not that strings are finished by a long chalk, given the comments of many people here.)

So how do we resolve this inherent contradiction:

 1. Decide which approach of the above 1, 2 or 3 is preferred. Obviously
Walter has final say, but I think his desire for success may weigh more
practicality than idealism. (I hope so.) I vote 3.

 2. Decide, hopefully by volunteers, on a panel for review of library
design. The main remit will be to ensure maximum coherence with minimal
coupling, high efficiency, high robustness, high maintainability, yada yada
yada. Hopefully this can be by volunteer. If not, maybe Walter can
_persuade_ them. I would hope there would be people who are experienced in
several areas, compiler design, C, C++ OO, C++ STL, Java, .NET, Python, etc.
etc. as if there are too many from one school it'll have negative
consequences

 3. Have a D.design (or D.library) newsgroup where the discussion for a
particular design is conducted. Simply, if someone has an idea for a
library, they can post a proposal (not an essay, but not a single line
either), and the review panel can discuss it. (Hopefully the number of OT
postings would be minimal.)

In this way, if someone has an idea for a library, they'll be informed quickly as to whether someone else is already doing so, and they'll also be guided as to how to make this library compatible with the existing libraries, and the D "approach" as a whole.

AFAICS, the only difficulty is in deciding what the D "approach" is? And it may be that this will only evolve through such collaboration. This means that we may have a lot of heated debate (steamy kitchen time), but it will hopefully result in a the mother of all standard libraries! (Well, maybe not, but it should be pretty good, nonetheless)


Matthew

Of course, one thing I forgot to mention:

It may still not be time for this. I know I've not added any more stuff to SynSoft.D partly because all the debate about modules, along with other issues of final methods and non-static operators, are just too much of a disincentive.

Being a pragmatist, I will be content to work with features as they stand ("broken" in some opinions), but am hanging back in case they are "fixed".

Is there a possibility of significant change to these fundamental features? If so, is this also holding back others?

It may well be fruitful if there are any people who are similarly waiting to implement libraries for certain fundamental language features to be finalised (arf arf), to list what things they are waiting for. This might provide a focus to these separate issues, as well informing those of us waiting what is likely to change, and what is going to stay just the way it is. Either way, it'll be good to know.

Matthew

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bhrigg$1ufl$1@digitaldaemon.com...
> Just been reading various library-related posts, and it occurs to me that
we
> have two alternatives:
>
> 1. We write everything from scratch.
>
>   pros: no IP issues, 100% pure D, huge feeling of satisfaction all round
>   cons: will take a long time, very difficult to have a coherent suite of
> libraries, there'll be a *lot* of debate
>
> 2. We wrap existing C libraries, and employ mixed libraries
>
>   pros: get there quicker, may be able to borrow what is good from
existing
> designs (in terms of sculpting interfaces I mean) and can re-present what
is
> not, less fatuous debate
>   cons: may be seen as incomplete by purists, IP issues in some cases
> (although we'd just not use what we couldn't use, so this is a furphy
> really)
>
> 3. We wrap existing C libraries, with the intent to eventually move them
all
> over to D
>
>   As before, apart from becomes 100% pure D, and we rewrite what we cannot
> (freely) borrow
>
> Thoughts?
>
>
> I also think it's very important to recognise that the best libraries are built by a small team (1-4 people, usually) and that this conflicts with
the
> need to have the libraries mutually compatible. I'm not talking about
having
> everything coupled a la Java, and much of the C++ std library. Frankly I hate coupling, and am left thoroughly underwhelmed by the authors of
coupled
> libraries. (Maybe Walter's done us a big favour by making strings
built-in,
> as this is the biggest source of coupling IMHO. Not that strings are finished by a long chalk, given the comments of many people here.)
>
> So how do we resolve this inherent contradiction:
>
>  1. Decide which approach of the above 1, 2 or 3 is preferred. Obviously
> Walter has final say, but I think his desire for success may weigh more
> practicality than idealism. (I hope so.) I vote 3.
>
>  2. Decide, hopefully by volunteers, on a panel for review of library
> design. The main remit will be to ensure maximum coherence with minimal
> coupling, high efficiency, high robustness, high maintainability, yada
yada
> yada. Hopefully this can be by volunteer. If not, maybe Walter can _persuade_ them. I would hope there would be people who are experienced in several areas, compiler design, C, C++ OO, C++ STL, Java, .NET, Python,
etc.
> etc. as if there are too many from one school it'll have negative consequences
>
>  3. Have a D.design (or D.library) newsgroup where the discussion for a
> particular design is conducted. Simply, if someone has an idea for a
> library, they can post a proposal (not an essay, but not a single line
> either), and the review panel can discuss it. (Hopefully the number of OT
> postings would be minimal.)
>
> In this way, if someone has an idea for a library, they'll be informed quickly as to whether someone else is already doing so, and they'll also
be
> guided as to how to make this library compatible with the existing libraries, and the D "approach" as a whole.
>
> AFAICS, the only difficulty is in deciding what the D "approach" is? And
it
> may be that this will only evolve through such collaboration. This means that we may have a lot of heated debate (steamy kitchen time), but it will hopefully result in a the mother of all standard libraries! (Well, maybe not, but it should be pretty good, nonetheless)
>
>
> Matthew
>
>
>

In my XML api, I've marked certain sections of code with comments like this:

// TODO: MOVE THIS FUNCTIONALITY TO A TEMPLATE,
//       ONCE TEMPLATES ARE LESS LAME.

So, the progress of features in D is not stopping me from writing my library. If template syntax and semantics improve in six months, I'll do some work on an updated version of my library that uses more templates. If my new templated implementation is faster or uses less memory or is more programmer-friendly than the previous version, I'll release a new version of the library. If not, I won't.

Anyhow, I think it would be a big mistake for library authors to wait until the language is exaaaaaaactly riiiiiiiight before writing their libraries. I think we should write our libraries right now, and, if the language changes, update our libraries to work with the language. But doing it like this means it will be very very important to have well-documented code AND unit tests throughout. As long as we've got that, it shouldn't be too difficult to keep our code in sync with the current state-of-the-art of the language.

--Benji Smith

In article <bhrjhg$1vsd$2@digitaldaemon.com>, Matthew Wilson says...
>It may still not be time for this. I know I've not added any more stuff to SynSoft.D partly because all the debate about modules, along with other issues of final methods and non-static operators, are just too much of a disincentive.
>
>Being a pragmatist, I will be content to work with features as they stand ("broken" in some opinions), but am hanging back in case they are "fixed".
>
>Is there a possibility of significant change to these fundamental features? If so, is this also holding back others?