Why the Standard Library

[Alex Rønne Petersen]

On 19-01-2012 22:22, Zachary Lund wrote:
> On Thursday, 19 January 2012 at 19:06:41 UTC, Alex Rønne Petersen wrote:
>> On 19-01-2012 19:52, Zachary Lund wrote:
>>> I've been wondering in the back of my mind for awhile now and it really
>>> hasn't bothered me much but I figured I might as well get it off my
>>> mind.
>>>
>>> Why is there a need for a default "standard" library? I can understand
>>> about some of the core stuff, but hell, even threads can be handled via
>>> a 3rd party library. Why must Phobos or any library be a part of D
>>> itself?
>>>
>>> I'm unfamiliar with the reason for C++ having a standard library as well
>>> (which I bring up when people bitch about poor design or something
>>> similar which I usually get no viable or any answer at all). More of an
>>> ignorant question probably but oh well...
>>
>> Without a standard library, interoperation between libraries becomes a
>> huge pain, because there's no standard interface/design for various
>> things such as threads, containers, bigints, networking, file I/O, etc.
>>
>> Not to mention, if a standard library didn't exist, you'd have to
>> adapt your build system to whatever arbitrary amount of libraries you
>> need to use.
>
> C++ has interoperability between containers and allocators which have
> done much good. However, they hardly have any libraries that force
> preferential design that doesn't require flexible implementation.

If you're using two libraries that use completely different container 
design (for who knows what reason), interoperability becomes annoying.

>
> Things like bigint and networking are not based on optimized or flexible
> implementation but on ease of use. You generally choose a BigInt library
> that is the easiest to use, not the one that has the most flexibility
> when it comes to which implementation it uses or the one that is most
> optimized. Also, I'm not sure who would reuse the std.socket design.
> There are plenty of libraries that give a more robust and clean
> interface to sockets.

std.bigint is based on both. It has highly optimized inline asm where it 
makes sense and speeds the code up.

As for sockets: I agree that the design is not the most ideal in Phobos. 
I'm sure that it can still be improved, however, and that once this 
happens, it will become much easier to use for many different purposes.

(In particular, I'd love to see some IOCP and AIO support.)

IOW, you're right: std.socket doesn't make much sense as a universal 
library just *yet*. But I do think it's one of those Nice To Have things 
for simple use cases.

>
> I don't mind robustness but I do not like being forced onto a
> preferential design (which doesn't require flexible implementation)
> simply because it is in the "standard". I do not think the etc.curl or
> std.bigint promote library interoperability. Thus, I do not think these
> modules belong in the library considered "standard".

Nobody forces you to follow the designs. Hell, in one of my projects, I 
implemented containers without basing them on ranges and iterators, 
completely deviating from most standards.

>
> Also, libraries aren't really that big of a pain to add to a build
> system. It's generally just a matter of finding where the library is. On
> Linux, this is simple. On Windows, it generally requires either
> environmental variable or user input. I don't see any way around this
> nor do I find putting everything into one glob of a library a solution.

On Windows, it also involves building the libraries in the first place. 
On Linux, you just invoke a package manager (very convenient). Either 
way, no; one huge glob of a library is not a solution to all of the 
world's problems, but I don't see it as a *problem* either. It's not 
like importing one module imports all of Phobos into your program.



Regardless of your preferences, the majority of the D community likes to 
have a standard library, so there's no reason to just stop shipping it 
(even though I don't think that's what you're suggesting).

-- 
- Alex