Is all this Invarient **** er... stuff, premature optimisation?

[Me Here]

Sean Kelly wrote:

> == Quote from Me Here (p9e883002 at sneakemail.com)'s article
> > Phobos vs. Tango
> > I definitely don't want the dead weight of pointless OO wrappers or deeply
> > nested hierarchies. Nor the "everything must be OO" philosophy.
> > Once I regain access to std.string for my char[]s, (and a simple,
> > expectation conformant rand() function :), I'll be happy.
> 
> Please don't discount Tango based on what has been said about it in this
> forum.  I know for a fact that Walter, for example, has never even looked
> at Tango (or he hadn't as of a few weeks ago anyway).  In truth, the percentage
> of classes to functions in Tango is roughly the same as in Phobos... Tango is
> just a much larger library.  If you're interested in algorithms and string operations,
> I suggest looking at tango.core.Array and tango.text.*.  The former is basically
> C++'s <algorithm> retooled for D arrays, and the latter holds all the string-specific
> routines in Tango.
> 
> 
> Sean

The primary basis of my immediate decision regarding Tango was it incompatibility 
with Phobos as outlined in 

    http://www.d-riven.com/index.cgi?tango-phobos

(And several other first page hits when googling for "D Tango Phobos")

Beyond that, I'm in favour of OO when only when it truly benefits me. That is, 
when it manages state that I would otherwise *have* to manage myself. 

That, for example, does not mean simply substituting an object handle for an OS handle.
Nor caching of derived values unless their derivation is truly expensive.
Nor the use of getters and setters to avoid direct manipulation of attributes,
unless there is some genuine value-add from doing so. 
OO-dogma that they will isolate the library from speculative future changes in the 
underlying OS calls (that have been fixed in stone for 1 or4 decades or more) 
do not cut much ice with me.

I'm also not fond of all-in-one library packaging. Seems to me that there is enough 
information in the source code to allow libraries to be packaged as discrete dlls/sos 
and to only statically link against those required. But that may be a tool chain problem
rather than anything to do with Tango.

It should be possible to substitute one implementation of a std.* library for another,
without it being an all or nothing change. I should be able mix'n'match between 
implementations of std.* packages. 

For example, with the std.string problem I've been having. If I use

    import std.string;

    char[] a = readln();
    a.toupper();

it should work. If I do

    import std.string.immutable;

it wouldn't.

One of the things that force me to go away from D a couple of years ago was the ever changing state of the
libraries. Not the internal, implementations or occasional bugs, but the constantly changing interface definitions. 

It becomes impractical to develop a major project when you're constantly rewriting major chunks of code to accommodate 
the latest set of group think on the best way to package the OS and "C lib" functionality.

Back then, I put it down to the necessary gestation of a new language, and moved away to get my project done. 
I've now come back and find that the same situation exists. The answer to an essentially trivial problem is to write
and entire new library. Or rather, since the library I need was already a part of Phobos with D 0.-something
resurrect and old library. 

And that's the most worrying thing of all. The removal of the existing library from Phobos because the main proponents 
suddenly drank the cool aid of Invariant strings--especially for reasoning that I still find entirely specious--does not bode well
for ongoing stability

I had hoped that during my two years away, that at least the interfaces would have become standardised, 
even if the implementations varied from release to release. But if whole chunks of functionality can suddenly 
disappear from the library, at the same time as major new chunks of very desirable functionality are added to the language,
on the whim of 1 or 4 major players getting religion, then I'm really not sure that D is, or will ever be, 
ready for anything other than academic exploration of compiler technology.

Reading that back. the independence of Tango begins to be more attractive, even if I have a distaste for the 
"everything must be OO" philosophy that (apparently) underlies it. Maybe I'll pull a copy and look for myself.

For my current needs, I'm just looking for C speed with having to manage my own memory

For the project I went away from D for 2 years ago, and came back hoping for stability, my own personal
research project come memorial folly to be, I don't think D is yet ready for that. Maybe D1 if it doesn't 
becomes completely unsupported.  

In the interim I've "done the rounds" of an amazing variety of languages. From the functional brigade, 
Haskell, OCaml, Mozart/Oz, Erlang  et al. and various of the newer dynamic languages. They all have their 
attractions, but most are spoilt by some level of dogma. Haskell with is purity. Python with the whole 
significant whitespace thing. P6 with unix-first, and non-delivery. 

Mostly, the dynamics lack the low-level control and performance I need. I've been seriously working with
structured assembler to achieve the low level control and performance I want, but doing everything yourself
just takes you off into far to many interesting side projects. Implementing your own memory management 
could occupy a lifetime; especially if you consider the possibility and advantages of using (wait for it) a 
segmented architecture. Most older programmers memory of segmented memory stems from the 16-bit Intel
days and they (almost) universally eschew any notions of it now a 32-bit (and 64-bit) flat memory models are available.
But there are some very interesting possibilities in combining 32-bit segments and virtual memory.

D is my last best hope of avoiding the assembler route and trying to do it all myself. Walter's pragmatism stood out
in my early experience of both the language and library design--al be it that they kept changing;)--but I was really 
expecting (hoping) for greater stability by this point. 

Ooh. Did I write all that? Still. It has persuaded me to at least go look at Phobos, even if it is done with a jaundiced eye.
A stable, even if philosophically distasteful, implementation of the staples is better than a philosophically desirable but 
whimsically changing one.

Cheers for prompting me to re-think my blanket dismissal. b.








--