The path to unity

[Chad J]

Jarrett Billingsley wrote:
> On Fri, Feb 6, 2009 at 3:59 PM, Sean Kelly <sean at invisibleduck.org> wrote:
>> == Quote from Bill Baxter (wbaxter at gmail.com)'s article
>>> On Sat, Feb 7, 2009 at 1:54 AM, grauzone <none at example.net> wrote:
>>>>> Hmmmmm.  Name for a common namespace...... How about.... "common".
>>>> Every time you introduce a new standard namespace, a bunch of innocent
>>>> existing D programs might become invalid.
>>>>
>>> I do in fact have a top level package called "common" where I put a
>>> bunch of code that is common to my various projects.   But I would
>>> happily rename it in a heartbeat if it meant greater unification
>>> between Phobos and Tango.  'Tis a small price to pay.
>> druntime already has "core", is there truly a need for a second top-level
>> namespace?
> 
> The math library almost unarguably belongs in core, since it's just
> giving you access to more capabilities of the processor, more or less.
>  I'm just worried about the extent to which this might end up going.
> stdc is already kind of pushing it; it's not really central to the
> language or to runtime operation.  I'd rather not see more stuff
> shoved into core that isn't core.

I think that might be the point of the extra layer, extraneous though it
may seem.

Oh my, here comes another wall of text.

I'm beginning to see the Phobos/Tango split as a very advantageous thing
for D, even neglecting the benefits in terms of forcing the community
and designers to think of things like a modular runtime.  The split has
given us multiple ways to do things.  This could be a detriment if
you're pretty hardcore purist, but I think it's ultimately a good thing.
 It is humanistically convenient.  Rather than waging unending religious
wars we just take all paths at once and call it a day.  I'm seeing it
this way:  it is a tradeoff between having a bit of standard library
bloat and having discontent and dissent in the community.  IMO, the
latter is WAY more troublesome.  At the very least, having this
multiplicity allows us to appeal to more audiences--a thing that is good
for both us and the audiences.

And then there's the irony.  In the long run, this stuff should really
be dynamic linked to save on code space.  Some day in the future we will
ideally have a D framework that D programs can rely on.  It's kind of
like the .NET framework except nicer and without the added annoyance to
the user.  On Linux we have these package managers, so you can rig it so
that whenever someone installs a D program then the framework is
automatically installed once-and-for-all and all subsequent D programs
will just reuse that framework and thus be compact and efficient.  For
systems where the D framework can't be counted on (Windows), we are back
to square one where you static link against only what is needed for your
program.  That's just the cost of an inflexible OS.  If Windows ever
wants to solve the problem of carrying around massive amounts of
redundant code, then it will have to adopt a package manager.  So
ultimately the cost of redundant functionality in the standard/common
library approaches insignificance as technology progresses.

The only long term cost then is the duplication of developer effort.  I
feel that as long as this is kept reasonable, it will be proportional to
the cost of dissatisfaction, lack of evolution, lack of innovation, etc
that comes from not trying new paths and experimenting.  Humans are not
ideal creatures.  They are not homogeneous nor are they omniscient.
They do not have the ability to just look at a problem or a lack of code
and just see the full optimal solution in crystal clarity in an instant
and with %100 guaranteed effectiveness.   In these less than ideal
conditions that we are stuck with, duplicating effort may very well be
the optimal path.  A number of people will do one thing slightly
differently, and in all likelihood one of those people will get it right.

So yeah, I'm starting to warm to this idea of forever having multiple
"standard" libraries for D, and building them on top of even more
fundamental stuff.  Fundamental stuff that people won't disagree about.
 It's a good balance between forcibly unifying EVERYTHING or allowing
unfettered duplication.


- Chad