• Matthew Wilson (53/53) Aug 18 2003 Just been reading various library-related posts, and it occurs to me tha...
• Matthew Wilson (30/83) Aug 18 2003 Of course, one thing I forgot to mention:
• Benji Smith (18/26) Aug 19 2003 In my XML api, I've marked certain sections of code with comments like t...

"Matthew Wilson" <matthew stlsoft.org> writes:

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

"Matthew Wilson" <matthew stlsoft.org> writes:

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

Benji Smith <dlanguage xxagg.com> writes:

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?