Library standardization

[Lars Ivar Igesund]

Koroskin Denis wrote:

> First of all, I don't want to start Tango vs. Phobos vs. ??? flame war.
> But the way Tango or Phobos envolves is not the best one.
> 
> Current situation is, someone writes code, probably nice one, and it is
> added
> to main trunk. Problem is, interface is implementation driven, not
> otherwise.
> It is not discussed. And thats bad. Tests first, then code, Kent Beck
> said. Of course, implementation can affect interface, but only after
> trial.

You don't have a perfectly correct image of how Tango evolves - writing code
certainly is far from enough for inclusion in Tango. Everything that is
included is heavily scrutinized - to the degree that is possible in an open
source project. Without a short cut in process here and there, Tango would
never see a single addition.

> 
> I mean, what we need is a detailed document (probably, wikified one) with
> detailed library interfaces, their rationale, use cases, examples, stress
> tests but NO implementation! Implementation is important, too, but only to
> end
> users, and not for standardization. Reference implementation will follow,
> I promise. It shouldn't be fast, it should be CORRECT and standard
> compliant in
> the first place, and it should pass D Library Stress Test.

While it is very important considering the interface that should be used,
cementing it _prior_ to implementation is crazy, and not at all good for
neither usability or the implementation itself. FWIW, though, we do invite
users to be involved in such processes - we even use our wiki for it and we
have several going. As of now, the success of it is somewhat contended -
mostly because that would mean that a lot of people will need to have the
necessary mental bandwidth (which already is limited since this is an open
source project).

> We need some kind of committee that would endorse that. And a separate
> newsgroup
> section. Drafts should be stored in wiki.

Design by committee has a bad reputation in D it seems, and until D actually
reach a higher level of usage, this will not be a thing to be possible to
consider. And even if D gets there, I'm certainly not sure that design
processes such as that described above is smart. Even Java's JSR's (which
may or may not be considered successful), are almost always based on
existing implementations, and got there because the initial implementation
had seen some success.

> As such, my suggestion is to revive digitalmars.dtl group!
> The condition is it should be regularly monitored by Walter/Andrei or any
> other
> person, that will be assigned for a duty.

Similar things has been suggested many times, some times also for a similar
topic, but nope - won't happen.

> 
> We should discuss and answer the following questions:
> 
> - How DTL should be organized (bunch of files or structured like in
> Java/C#/Tango)?
> - What modules should it consist of?
> - What classes does it provide?
> - What interfaces these classes expose?
> - What feature set of D should it use?
> - Templates vs. Object Oriented approach

I personally thought that this kind of development died sometime in the
80's. You certainly wouldn't get a single code of implementation in the
next 3 years (at least).
 
> The library should document all these. Extensive set of functional and
> unit tests should also be provided.

Indeed, that should be a goal of any library, and it even is for Tango - but
beyond what is possible to extract automatically, there is a hard limit -
because we're operating in an open source environment.

> Reference implementation for D1/D2 will exist. However, library should be
> design driven, not implementation driven.

If anything, the development of a library should be funtionality/usability
driven. Design driven is madness - what happens if after implementation all
the design turns out to suck? Like the initial versions of the JRE... You
have then spent extraneous amounts of time on something that is not usable.
Having the design discussions among the brightest minds won't help this -
even they cannot offhand know which designs will work, although a team
experienced with a language may get a notion of that after some years.

> Any module/class/method should be removed if Walter is not satisfied with
> it.
> Invariant should be held, that at any given moment Walter is satisfied
> with every piece of the library.

It is long since obvious that Walter will not get involved into any heavy
library lifting.

> I believe this is the only way we can create single powerful standard
> library.

You would get a single non-existing standard library.

As it is now, you have two alternatives, at least one of which are well
designed (but of course not perfect).

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango