www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why the Standard Library

reply "Zachary Lund" <admin computerquip.com> writes:
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...
Jan 19 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
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
Jan 19 2012
parent reply "Zachary Lund" <admin computerquip.com> writes:
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.
Jan 19 2012
next sibling parent reply "Zachary Lund" <admin computerquip.com> writes:
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.
Jan 19 2012
next sibling parent "Zachary Lund" <admin computerquip.com> writes:
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.
Jan 19 2012
prev sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 19-01-2012 22:26, Zachary Lund wrote:

 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.


Right. But again: Nobody forces you to link to all of Phobos.

-- 
- Alex
Jan 19 2012
prev sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
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
Jan 19 2012
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, January 19, 2012 22:33:30 Alex Rønne Petersen wrote:

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


Most languages have fairly large standard libraries. If anything, Phobos is 

expect large standard libraries. They don't prevent you from using 3rd party 
solutions if you want to, but they make the language a lot easier to use.

- Jonathan M Davis
Jan 19 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Have you ever bought a remote and after unpacking it realized that
batteries were not included?
Jan 19 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
The only thing actually required to build a D app is druntime, which contain=
s threading support (needed so the GC knows how to scan threads spawned by t=
he app), a GC, and compiler support code. When Phobos is built, druntime is b=
undled into it, so only Phobos is actually linked.=20

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 ha=


sn't bothered me much but I figured I might as well get it off my mind.

=20
 Why is there a need for a default "standard" library? I can understand abo=


ut some of the core stuff, but hell, even threads can be handled via a 3rd p=
arty library. Why must Phobos or any library be a part of D itself?

=20
 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 wh=
ich I usually get no viable or any answer at all). More of an ignorant quest=
ion probably but oh well...
Jan 19 2012
prev sibling next sibling parent Trass3r <un known.com> writes:
 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?
Jan 19 2012
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
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.
Jan 19 2012
prev sibling parent reply "F i L" <witte2008 gmail.com> writes:
What I want to know, is why "std.stdio" wasn't named "std.io"... 
*sigh*.. my OCD is going to drive me crazy one day.
Jan 19 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 19-01-2012 23:13, F i L wrote:

 What I want to know, is why "std.stdio" wasn't named "std.io"...
 *sigh*.. my OCD is going to drive me crazy one day.


That *is* a valid concern IMHO.

-- 
- Alex
Jan 19 2012
next sibling parent reply Brad Anderson <eco gnuk.net> writes:
On Thu, Jan 19, 2012 at 3:31 PM, Alex R=F8nne Petersen <xtzgzorex gmail.com=

wrote:



 On 19-01-2012 23:13, F i L wrote:


 What I want to know, is why "std.stdio" wasn't named "std.io"...
 *sigh*.. my OCD is going to drive me crazy one day.


 That *is* a valid concern IMHO.

 --
 - Alex


I proposed Steve Schveighoffer's stdio overhaul take the name std.io and
std.stdio retains its name for backward compatibility.  I can't remember if
the idea was well received.

Regards,
Brad Anderson
Jan 19 2012
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 19 Jan 2012 17:42:27 -0500, Brad Anderson <eco gnuk.net> wrote:


 On Thu, Jan 19, 2012 at 3:31 PM, Alex R=C3=B8nne Petersen  =



 <xtzgzorex gmail.com>wrote:


 On 19-01-2012 23:13, F i L wrote:


 What I want to know, is why "std.stdio" wasn't named "std.io"...
 *sigh*.. my OCD is going to drive me crazy one day.


 That *is* a valid concern IMHO.

 --
 - Alex


 I proposed Steve Schveighoffer's stdio overhaul take the name std.io a=


nd

 std.stdio retains its name for backward compatibility.  I can't rememb=


er  =


 if
 the idea was well received.


It is in the works:

https://github.com/schveiguy/phobos/commit/9ee5034f446877b0e78fec6082710=
84d289f6345

-Steve
Jan 19 2012
parent reply "Jesse Phillips" <jessekphillips+D gmail.com> writes:
On Thursday, 19 January 2012 at 22:49:52 UTC, Steven 
Schveighoffer wrote:

 It is in the works:

 https://github.com/schveiguy/phobos/commit/9ee5034f446877b0e78fec608271084d289f6345

 -Steve


Be sure to change the module declaration.
Jan 19 2012
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 20 Jan 2012 01:46:43 -0500, Jesse Phillips  
<jessekphillips+D gmail.com> wrote:


 On Thursday, 19 January 2012 at 22:49:52 UTC, Steven Schveighoffer wrote:

 It is in the works:

 https://github.com/schveiguy/phobos/commit/9ee5034f446877b0e78fec608271084d289f6345

 -Steve


 Be sure to change the module declaration.


Oh don't worry, I'll be sure to compile it before submission :D

But thank you anyway!  I have a lot of cleanup to do in there.

-Steve
Jan 20 2012
prev sibling parent reply Derek <ddparnell bigpond.com> writes:
On Fri, 20 Jan 2012 09:31:12 +1100, Alex R=F8nne Petersen  =

<xtzgzorex gmail.com> wrote:


 On 19-01-2012 23:13, F i L wrote:

 What I want to know, is why "std.stdio" wasn't named "std.io"...
 *sigh*.. my OCD is going to drive me crazy one day.


 That *is* a valid concern IMHO.


I thought that the name std.stdio reflected that the module is in the  =

standard library (std.) and that the module contains standard I/O member=
s  =

rather than extraordinary I/O members, which may be contained in another=
  =

module that is also in the standard library.

In other words, the 'std' is not a duplication because it has two meanin=
gs  =

depending on the context. "std." refers to it being in the standard  =

library and "stdio" refers the the members *of that module* being standa=
rd  =

i/o stuff and not special i/o stuff.

-- =

Derek Parnell
Melbourne, Australia
Jan 19 2012
parent reply "F i L" <witte2008 gmail.com> writes:
 It is in the works: 
 https://github.com/schveiguy/phobos/commit/9ee5034f446877b0e78fec608271084d289f6345


Ha! That's awesome. When do you think this update will take 
effect?


Derek wrote:

 I thought that the name std.stdio reflected that the module is 
 in the standard library (std.) and that the module contains 
 standard I/O members rather than extraordinary I/O members, 
 which may be contained in another module that is also in the 
 standard library.

 In other words, the 'std' is not a duplication because it has 
 two meanings depending on the context. "std." refers to it 
 being in the standard library and "stdio" refers the the 
 members *of that module* being standard i/o stuff and not 
 special i/o stuff.


Then why isn't "std.math" not "std.stdmath"? Default (or 
"standard") libs should have names without qualifiers (seeing as 
how they're in the standard library already). Libs with extra or 
uncommon utilities should be the ones with naming pre/post 
affixes, eg, "std.io" and "std.iospecial".
Jan 19 2012
next sibling parent Derek <ddparnell bigpond.com> writes:
On Fri, 20 Jan 2012 10:33:33 +1100, F i L <witte2008 gmail.com> wrote:


 Derek wrote:

 I thought that the name std.stdio reflected ...


 Then why isn't "std.math" not "std.stdmath"?


Please don't misunderstand me. I wasn't defending the name, just stating  
what I thought the rationale behind it was.


-- 
Derek Parnell
Melbourne, Australia
Jan 19 2012
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 19 Jan 2012 18:33:33 -0500, F i L <witte2008 gmail.com> wrote:


 It is in the works:  
 https://github.com/schveiguy/phobos/commit/9ee5034f446877b0e78fec608271084d289f6345


 Ha! That's awesome. When do you think this update will take effect?


I first have to show it's a) better and b) a drop-in replacement :)

I am slowly working on it when I have time.  But the implementation is  
mostly finished (from my previous version that everyone hated), it just  
needs to be designed correctly.

-Steve
Jan 19 2012