On Sat, 07 Feb 2009 04:43:05 +0300, Jarrett Billingsley
<jarrett.billings...@gmail.com> wrote:
On Fri, Feb 6, 2009 at 6:53 PM, Chad J
<gamerc...@__spam.is.bad__gmail.com> wrote:
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.
I'll have to say that I wholeheartedly disagree. (You knew this was
coming.)
Even if they use a common runtime and small common core, nothing is
compatible between the user portions of the libraries. Sure, you'll be
able to install Phobos and Tango side-by-side without issue, but
honestly, why would you want to do that? Oh, I see - you're using two
third-party libraries, one based on Tango and one on Phobos. But.. it
still doesn't solve the problem. The one library wants std.date.Dates
and the other wants tango.time.Time.Times. Or std.stream.Streams vs.
tango.io.Conduits. The split between the libraries has just moved from
the runtime level up to the user level. Even if they use the same
runtime, Phobos and Tango cannot be used with one another.
Newbs are confused when they first come to the language and find out
there are two standard libraries, and that they have to choose which
one to use. Worse, if you use one standard library, there's a whole
set of third-party libraries that you just can't use. The alternative
is for library writers to support both libraries by writing a
compatibility layer - their own standard library! This is just
ridiculous. Not only do D users have to deal with the first-order
problem of which standard library they should use, but they also have
to deal with the second-order problem of which third-party libraries
support which standard library.
It doesn't matter how you sugarcoat it. It doesn't give people
choices, it gives people _a_ choice - which "version" of D they want
to use: Phobos D or Tango D. As a library writer, I can't say that I
find that situation, or the idea of writing a compatibility layer for
all but the simplest of functionality, very attractive.
Well put, thank you. Everyone finds this situation annoying. That's the Number One
problem of the D (remember "top five" poll?).
The problem as I see it is that there is an overlapping functionality in Phobos
and Tango (std.stream.Stream/tango.io.Conduit etc).
The solution as I see it to redesign Phobos and Tango by removing dead (buggy,
unsupported) code, separating libraries functionality and removing duplication.
I'd remove from Phobos:
std.
openrj
bigint (old one, by Janice)
regexp
socket
xml
much, much more (see more complete list in my previous post[1]).
and suggest/force users use tango instead.
What's left in Phobos? A fundamental part *only*:
std.
math (including IEEE and BigInteger) [2]
range
traits
algorithm
contracts
atomics (arguably)
date/time (arguably)
So /any/ D compiler distribution would contain:
core (druntime)
std (phobos)
tango
'druntime' would provide an essential functionality to run D programs on other
platforms: gc, compiler, runtime, etc.
std - provide simple and generic functionality, that can be used in conjunction
(unix style): algorithm, range, contracts, math[2], some helpers/utils, etc.
tango - extended functionality: network, io (including console io), xml, etc
Tango would depend on Phobos (which is now *very* tiny) and both depend on
druntime. I believe Tango will greatly benefit from using contracts, ranges and
algorithms, that are absent from it.
Competition is good, but only at early stages. Tenders/Bids are only exist to
choose the best one and stick with it - the others are dropped at some point.
The same thing should happen with Tango/Phobos now - inferior functionality
should be dropped in favor or superior one. (It doesn't necessarily mean that
either Phobos or Tango should be dropped entirely, but rather some modules -
std.regexp vs. tango.text.Regex, std.socket vs tango.net.*, etc).
Does anyone agree/disagree with me? Anyone see other solutions? Please, don't
stay away from discussion.
PS. Andrei is about to finish TDPL. What does it say about Phobos, Tango and the
situation around "std libraries"?
What part of Phobos does it cover? I *really* hope it doesn't say much about
anything apart from std.range/algorithm/traits/contracts.
---
[1]
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=82553
Please, read it if you didn't yet.
[2] 'math' is a common but not an essential to run HelloWorld so should be
moved to std; tango removes tango.math entirely and uses std.math instead. No
'common' namespace would be needed as it is Phobos/std which is 'common'.
