Segregating the standard library

[Samuel MV]

> 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.
> 

I have both backgrounds: programmed 50% in C/asm/pascal and 50% in 
java/c#. And I find both extremes annoying:

I liked the original java library structure, it was not too deep nor too 
flat ... C, PHP, etc. libraries seem just a bunch of functions thrown 
randomly ;-)

But at the same time, I hope D's standard library doesn't become a new 
Java or C#, fill with 'AbstractFactoryFactoryNewlineChar' classes and 
10-levels-deep qualifiers ... just to open a socket or to write in a file.

Just look the problems the Java community has with EJB, JSP, servlets, 
struts, ... every year they have to solve the over-complexity they build 
the year before.

> 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.
> 

I want both: char[] for everyday use, and a String class for i18n and 
l10n, easy associative arrays, foreach D-style, Iterators java-style, 
operator-overload, ... I don't want to mess with classes and templates 
if the language can solve my most usual problems more easily. Complex 
solutions should be only for complex problems ...

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

I agree, for that we have std.c

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

I can look D style, neither Java nor C++ :)

> 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.
> 

It's the same in Java, there are classes (like Math), that are just a 
container for lots of static methods, i.e., a kind of C library.

For me there are functionalities that are more easily solved with OOP, 
and other that are with classic procedural programming or functional 
programming. A 'pure' programming paradigm it's not practical, although 
it's nice to sell books ;-)

It'll be ugly if it's done without order. I think we should have 
something like Python's PEP or Java's JSR. One for the language and 
another for the standard library, more community and more order at the 
same time.

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

I totally agree.

> 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.
> 

I think D community is too small to be able to afford that. It'll be 
better to have:

a) one core library only with compiler and language stuff

b) a standard library for basic functionality D-style (console, io, net, 
file, simple math, ... kind of phobos but revised and updated)

c) and over this an OOP library for high-level/complex functionality 
(http, database, xml, windows toolkit, multimedia, ...)

Best regards,

            Samuel.