Segregating the standard library

[Benji Smith]

Bill Baxter wrote:
> What should the overall goal be?  A tight unified hierarchical set of 
> packages like those found in Java/C#.NET?  Or a more loose and ragtag 
> library collection with a flat namespace, more like Python/Perl?

Also, I wonder whether it's possible to offer a really standardized 
standard library to such a diverse collection of developers.

Those of us from a Java/C# background have been trained to expect 
DescriptiveNamingConventions rather than terse names like "atoi" and 
"szptr". We also tend to use exceptions rather than error codes. And we 
prefer interfaces to operator overloads. We don't mind using templates 
for collections, but template metaprogramming doesn't interest us much.

Personally, I'd rather have a String class than a char[]. I'd rather 
have a great HashMap implementation than built-in associative arrays. 
And I'd rather that foreach expected an Iterable object than a delegate, 
provided through an operator-overload. I use pointers occasionally in C# 
(for packing primitive data into arrays at runtime), but I'm generally 
more comfortable with references.

Anyhow...

If the D standard library looks like a re-vamped C library, I'll be 
disappointed.

But if it looks like Java, the C++ crowd will be annoyed.

At the same time, the standard library can't be a weird Frankenstein 
amalgamation of Java-style code and C-style code. Then no one would be 
happy.

I really think the D standard library will be very small and minimal, 
providing some humble set of necessary core functionality.

When people go looking for libraries (or when they author libraries 
themselves), they'll lean toward the programming paradigm they're most 
comfortable with. Some developers will prefer the C-style of coding, 
while others will tend to use Java/C# style libraries.

I don't think there's anything wrong with that, but I think it's inevitable.

--benji