November 27, 2007
Alexander Panek wrote:

>> I honestly hope Phobos will remain what it is - a simple, core library, and I hope it will not "evolve" into a huge framework of JAVA API, or .NET 2 size.
> 
> I'm not sure what the cause of this "fear" is?

A large standard library bulks up the language (where by "language" I mean the actual programming language plus its standard library facilities). Such bulk is undesirable in places where it isn't needed, such as embedded systems or other small scale environments. Since D wants to be a systems programming language a huge, expansive *standard* library seems incompatible with that positioning. At least it does to me.

Of course huge, expansive add-on libraries are a good thing to have as well. I could even imagine a two-tiered standard library (core + additional optional components). So I agree with the OP that a relatively small core library is nice.

Peter
November 27, 2007
On Tue, 27 Nov 2007 06:52:50 -0500
"Peter C. Chapin" <pchapin@sover.net> wrote:

> Alexander Panek wrote:
> 
> >> I honestly hope Phobos will remain what it is - a simple, core library, and I hope it will not "evolve" into a huge framework of JAVA API, or .NET 2 size.
> > 
> > I'm not sure what the cause of this "fear" is?
> 
> A large standard library bulks up the language (where by "language" I mean the actual programming language plus its standard library facilities). Such bulk is undesirable in places where it isn't needed, such as embedded systems or other small scale environments. Since D wants to be a systems programming language a huge, expansive *standard* library seems incompatible with that positioning. At least it does to me.

That doesn't quite answer my question, let me rephrase: why do you think Phobos will ever be developed in that direction?

-- 
Alexander Panek <alexander.panek@brainsware.org>
November 27, 2007
Peter C. Chapin wrote:
> Alexander Panek wrote:
> 
>>> I honestly hope Phobos will remain what it is - a simple, core
>>> library, and I hope it will not "evolve" into a huge framework of
>>> JAVA API, or .NET 2 size.
>> I'm not sure what the cause of this "fear" is?
> 
> A large standard library bulks up the language (where by "language" I
> mean the actual programming language plus its standard library
> facilities). Such bulk is undesirable in places where it isn't needed,
> such as embedded systems or other small scale environments. Since D
> wants to be a systems programming language a huge, expansive *standard*
> library seems incompatible with that positioning. At least it does to me.

Ironically, this is exactly who Tango was designed the way it is.  The runtime can be distributed entirely separate from the user code, and the user code is rarely inter-dependent either.  In my opinion, this grants the best of both worlds.  Embedded programmers can toss all the code they don't need or don't want to port, but it's still available to those with more modest demands.


Sean
November 27, 2007
Peter C. Chapin wrote:
> A large standard library bulks up the language (where by "language" I
> mean the actual programming language plus its standard library
> facilities). Such bulk is undesirable in places where it isn't needed,
> such as embedded systems or other small scale environments.

Then why does Java thrive in such environments, i.e. cell phones, etc.? (okay, J2ME is a bit smaller than J2SE, but it's a far cry bigger than the C stdlib)

IMHO, the bigger the standard library, the better in most cases. Standard library code is well-reviewed and tested, so you can generally count on it more than 3rd party libraries, open source or not. Arguably more importantly, having a standard way of doing things makes code more consistent, reducing incompatibilities and portability issues. Further, if everyone knows the standard library (or a piece of it), a new developer can join the team and be instantly familiar with how to craft their code, and what the existing code does, without reading extensive documentation.
November 27, 2007
Robert Fraser a écrit :
> Peter C. Chapin wrote:
>> A large standard library bulks up the language (where by "language" I
>> mean the actual programming language plus its standard library
>> facilities). Such bulk is undesirable in places where it isn't needed,
>> such as embedded systems or other small scale environments.
> 
> Then why does Java thrive in such environments, i.e. cell phones, etc.? (okay, J2ME is a bit smaller than J2SE, but it's a far cry bigger than the C stdlib)
> 
> IMHO, the bigger the standard library, the better in most cases. Standard library code is well-reviewed and tested, so you can generally count on it more than 3rd party libraries, open source or not. Arguably more importantly, having a standard way of doing things makes code more consistent, reducing incompatibilities and portability issues. Further, if everyone knows the standard library (or a piece of it), a new developer can join the team and be instantly familiar with how to craft their code, and what the existing code does, without reading extensive documentation.

Agreed. The bigger (in scope) the standard library will be, the better: Java and Perl success are directly linked to the breadth of their 'standard library'.

For embedded purpose: D itself is not suitable to 16bit CPU, so it'd be at least 32bit CPU, and the current standard library with its GC usage is already not suited either to very small memory targets.

So for embedded targets where D can be useful I think that a standard library the size of Java's one would be ok.

I hope that many parts of Tango will be added to Phobos but being carefully made coherent with Phobos 'style'.

renoX




November 27, 2007
Reply to Alexander,

> On Mon, 26 Nov 2007 16:20:05 -0800
>
> In any case: is this what the d.D.bugs newsgroup is about? Can you
> also reply on the NG and bugzilla tracks it automatically as response
> in the tracker?
> 

yes, but I usualy try to add the comment directly.

> --
> Alexander Panek <alexander.panek@brainsware.org>


November 27, 2007
Walter Bright wrote:
> 
> http://www.dsource.org/projects/phobos
> 
> Thanks to Brad Roberts for doing the organizational work, and Brad Anderson for hosting.

Good news! I'm glad we are moving in the right direction. There is likely still a lot to go, but changes such as these are better made in small increments anyways.


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
November 27, 2007
On Tue, 27 Nov 2007 18:45:38 +0000 (UTC)
BCS <ao@pathlink.com> wrote:

> Reply to Alexander,
> 
> > On Mon, 26 Nov 2007 16:20:05 -0800
> >
> > In any case: is this what the d.D.bugs newsgroup is about? Can you also reply on the NG and bugzilla tracks it automatically as response in the tracker?
>
> yes, but I usualy try to add the comment directly.

Aah, I see. Well, that's a killer feature, definitely. :)

--
Alexander Panek <alexander.panek@brainsware.org>
November 28, 2007
"Sean Kelly" <sean@f4.ca> wrote in message news:fihf60$2m70$1@digitalmars.com...
> Peter C. Chapin wrote:
>> Alexander Panek wrote:
>>
>>>> I honestly hope Phobos will remain what it is - a simple, core library, and I hope it will not "evolve" into a huge framework of JAVA API, or .NET 2 size.
>>> I'm not sure what the cause of this "fear" is?
>>
>> A large standard library bulks up the language (where by "language" I mean the actual programming language plus its standard library facilities). Such bulk is undesirable in places where it isn't needed, such as embedded systems or other small scale environments. Since D wants to be a systems programming language a huge, expansive *standard* library seems incompatible with that positioning. At least it does to me.
>
> Ironically, this is exactly who Tango was designed the way it is.  The runtime can be distributed entirely separate from the user code, and the user code is rarely inter-dependent either.  In my opinion, this grants the best of both worlds.  Embedded programmers can toss all the code they don't need or don't want to port, but it's still available to those with more modest demands.

Yes indeed. It was one of the very early decisions, and guided lots of subsequent discussion and/or partitioning of Tango functionality :)


November 29, 2007
Sean Kelly wrote:

> Ironically, this is exactly who Tango was designed the way it is.  The runtime can be distributed entirely separate from the user code, and the user code is rarely inter-dependent either.  In my opinion, this grants the best of both worlds.  Embedded programmers can toss all the code they don't need or don't want to port, but it's still available to those with more modest demands.

That's a nice approach, of course. Still... if Tango was standard and if a third party was building a fresh implementation of D, it would be "necessary" to provide the entire library (in order to conform to the standard) even if the intended audience only wanted a fraction of it.

The C standard distinguishes between "hosted" and "freestanding" implementations as one way of handling this issue. I guess this is the same as the two-tiered approach I mentioned earlier.

Still, as was mentioned elsewhere, since D is garbage collected targetting extremely small machines such as 8 bit microcontrollers with 16K of RAM (for example) is probably not in D's future anyway. Thus standard library size might not be that big a deal for it.

Peter