Jarrett Billingsley wrote: > On Fri, Feb 6, 2009 at 3:59 PM, Sean Kelly <[email protected]> wrote: >> == Quote from Bill Baxter ([email protected])'s article >>> On Sat, Feb 7, 2009 at 1:54 AM, grauzone <[email protected]> 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
