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

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.

-- 
- Alex

Have you ever bought a remote and after unpacking it realized that batteries were not included?

The only thing actually required to build a D app is druntime, which contains threading support (needed so the GC knows how to scan threads spawned by the app), a GC, and compiler support code. When Phobos is built, druntime is bundled into it, so only Phobos is actually linked.

Sent from my iPhone

On Jan 19, 2012, at 10:52 AM, "Zachary Lund" <admin@computerquip.com> 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...

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

:D
Do you know what a chaos there was before a standard array type was introduced with std::vector?

Le 19/01/2012 19:52, Zachary Lund a écrit :
> 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...

For several reasons.

First, some feature can interract with one another. For exemple, Thread are supported by the language as a feature in D. GC must be aware of thread. It interract with shared/immutable and so on.

The experience of threading in C or C++ is a godd reason to think a standard lib is a good thing.

Second, you'll find generic piece of code that are usefull in almost every programs. And every libs. If everyone use it's own implementation, you ends up with two phenomena :
 - Most implementation are low quality, testing is spreaded and more bugs are produced and less discovered. If all languages user use the same implementation of that given feature, it is likely that all important bugs are discovered fast and fixed fast too. This is effort mutualisation.
 - You ends up mixin several implementation of the same things in your program. This can be a nighmare because you have to convert thoses stuff all the time to pass it from lib A to piece of code B. C and C++ string are a good exemple of that in C++ code.

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.

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.

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

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 Thursday, 19 January 2012 at 21:22:23 UTC, 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.
>
> 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.
>
> 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".
>
> 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.

I also forgot to mention about library reuse. You don't tend to use BigInt libraries all the time. In 6 years of programming, I've not used a single one. Nor have I used regex in a C program. Nor have I needed the constant use of MD5 hashing. And I sure as hell did not need the constant use of CURL or ZLib nor have I ever even used those libraries.

Third post a charm.

I'm not meaning to rant and my question for the most part has already been answered (however much I disagree with it). I probably won't provide much more input. Thanks for answering my question.

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