dylan (was Re: hehehe)

[Francois-Rene Rideau]

>>: Faré
>: Tril

>> * Dylan, that suffers from having a one global type hierarchy
>>  (like most existing object systems), [...]
> What is bad about having a global type hierarchy?  What is the
> alternative?

Many alternatives:
* No hierarchy.
 Why need such stuff at all?
 Just because the popes of OO can only think in terms of hierarchies
 doesn't mean we should follow them (you know the type?
 the kind of consultants who earn money from pondering on problems,
 and teaching stuff that'll get you into more trouble
 so that you may purchase more books, courses and consulting from them).
 Take a book in OO methodology (especially about "Design Patterns"),
 and burn it, as a symbolic protest gesture.

 We can have objects without such thing as inheritance.
 We can achieve whatever we want using interfaces, explicit delegation, etc.
 As I said earlier, we you cannot constraint order (structure)
 into always being order (hierarchy); we do not get to constrain the way
 information is to be coded, but to discover how it is naturally encodable,
 so we need understand the natural structure of programming,
 rather than begin with a stupid dogma about hierarchies,
 and forcing everything into that dogma.

* Local hierarchies.
 Remember: Tunes must scale towards a global system,
 and you do NOT want behavior of your objects being silently modified
 by an unknown programmer somewhere in the world.
 So a global type hierarchy is DEFINITELY NOT what we want.
 The very need for a one true hierarchy is what makes
 maintenance of C++ programs a real mess.
 CLOS allows dynamic modifications of hierarchy,
 but at the cost of performance.
 In any case, it is already true that the hierarchies of different programs
 written in a same language are, well, different (or otherwise unrelated),
 which means that these programs can't dynamically exchange objects,
 but only raw data, least havoc be wroken.

 Tunes must provide a way for arbitrary programs
 to communicate semantically rich content,
 and this "one program, one hierarchy" kluge isn't going to help.
 Instead, we must provide a unifying structure,
 so that IF hierarchies there are,
 they must be dynamically manipulatable like any other language construct,
 instead of being "global to a program" (a notion that doesn't exist in Tunes).

* Static hierarchies.
 All ambiguities, etc, are resolved statically
 at the time an expression is compiled: that is, the meaning of a sentence
 depends on the compile-time context in which it was uttered, not on
 the runtime context in which it is remembered (for execution or whatever).
 Compare with spoken language: when you say something, the meaning of it
 does not depend on misquotations of it by others in fallacious contexts
 (although, using reflection, people may still do such misquotations,
 that in some cases may have interesting effects;
 still, it doesn't make you mean something else than you meant).

 Actually, there can be much niftier desambiguation and/or DWIM mechanisms
 than just plain hierarchies: using nicknames, pronouns, implicit conversions,
 colloquial expressions, improper forms, understatement, etc, etc.
 In the extreme case, we could program in something very much like english,
 and the computer system would translate it and disambiguate it into a program.
 Of course, unless you fully trust the translator,
 you'd better check that the translated program really does what you mean,
 before you execute it (and/or you execute it in a failsafe mode
 were all operations are revertible).

Best regards,

[ "Faré" | VN: Уng-Vû Bân | Join the TUNES project!   http://www.tunes.org/  ]
[ FR: François-René Rideau | TUNES is a Useful, Nevertheless Expedient System ]
[ Reflection&Cybernethics  | Project for  a Free Reflective  Computing System ]
Science is a process based on an attitude of logic, imagination and doubt.