objects and TUNES system

> Stefan Monnier <stefan.monnier@epfl.ch> writes:
>> In systems such as unix, most tools are designed to work with text,
>> so it's a pain to deal with anything else than text. But if every
>> tool would be designed to deal with objects, ...




> Then you would have Objix? (And objixions, etc.)
      No, you'd have TUNES.




> Seriously, every time I work with "objects" I begin by (or end up
> having to) write code to read/write a text format for debugging (at
> least).
      This is a flaw not in the requirement for having "objects" (that is,
for a common frame to exist that can express just any computer abstractions
one needs), but the lamedom of existing software tools.


      Let us analyze why people use text:
% people want to be able to manipulate objects it at will.
This isn't possible, because there exist currently no reliable standard
communicable way of making the object encoding completely abstract to
the user. Sure you could write your own tool, but then you'll be the only
one to be able to access your objects, and these will be tied to the
hardware/OS platform you're working on.
% they want "sources" to be sure to regenerate and debug the state of
a computer from human-understandable files in case of a crash.
This again is related to existing systems being so unsecure that no one
can trust them to remember old working states of the systems, and to keep
logs.
% they fear for the need to write themselves some program to reencode
their files when they will have to upgrade some software. They don't
trust such a thing to work, or the cost is too high for them: not everyone
knows how to program, and achieving to get the specs of some encoding,
not to talk about understanding them, is often much too expensive in
time/money. The same happens as of extensibility: once a decision was
taken, existing compiler tools make it static and unamendable, least
all data is lost.


      All these are the same: existing OSes completely lack security and
reliability. You just cannot trust the OS to communicate securely anything
but text. [Communication here encompasses communicating to a future self].
This is why cybernetically, existing OSes are not worth much.
      Sticking to text is everything we can do for now, but we must
prepare the future. When bandits make the world unsecure, you can stay
in your home or castle indefinitely, until it is eventually stormed, leaving
the fields uncared for; or you can organize an army or militia to fight and
eliminate the bandits, so you can live securely thereafter.
      Just building "object systems" on top of existing OSes won't lead
anywhere. For reliable persistent object systems to exist, they must
replace current OSes. Thus, this is one of the aims of the TUNES project.


      To solve all these problems, we must have some system you can trust.
% Objects must come with everything that's needed to use them in every
condition: object editors as well as programmable object interface.
Objects must come with deconstructors so they can be automatically
translated into any other encodings to be used in other contexts.
% You must be able to rely on your persistent storage not to crash and
lose everything, and to save most reliably logs of stable states of the
computer. And for object debugging, object-aware debuggers must exist.
% To allow upgradability the system must provide higher-order tools
to manipulate encodings not just raw data; objects must come not only
with programs to manipulate them, but these programs themselves must be
manipulable so the object encoding can be upgraded. And for extensibility
the system must be dynamic.


      All this impose constraints not only on individual objects, but on
the whole object system, which must be higher-order (manipulate
not only objects, but their interface, not only the interface, but
specifications) and even reflective (so the system be upgradable itself).
For proofs as well as extensibility to be possible, the module system must
also be fine-grained. And for fine grain to be efficient, the system
must be able to do dynamic partial evaluation.


      Unless all these requirements are fulfilled, there can be no usable
object system. As an example, C++ is pure crap that has nothing of these.
Oberon, Dylan, and suches lack higher-order programming. They forget that
objects are useless if they can't be combined reliably, and you can't
rely on a combination just because some deterministic type signature matches.
      TUNES will make "object" programming possible, but it will have to
completely replace operating systems by its own components.




> How many times have the advantages of plain text been re-
> discovered? One recent example: mark-up language standards.
      Here is a statement of software "wisdom" that is quite misleading:
because current systems make text preferrable to other encodings, you
imply that they are whatever the conditions are.
      *That* is the problem with tradition: people learn to do and
repeat things without understanding them. This is fine, because good
things can happen and be selected before they are fully understood.
But when people blindly follow tradition "because this is the way"
(people have long killed other people or sacrificed them to gods with
such statements), there is no more progress. Let's go beyond traditional
wisdom, and *understand* things when we can (we is the case).


      A short history of text encodings (ASCII came rather late, and
ASCII extensions were settled only recently) would show that text
has not always been reliable or even existed. If you want things
you can touch and see, use punched cards !
      What is important is there being a standard, and the objects be
easily manipulable and communicable. Besides ASCII, no standard exist
that are expressive enough (picture, audio and motion picture files
are fine, but they are not as expressive as text can be, or at very
expensive price, and without easy manipulability).
      So no, what holds currently is not an absolute truth. What counts
is standards an meta-tools. These cannot be built upon existing systems,
so new systems will eventually appear and replace the existing lamedom.
Why will they ? Because they are more useful in the long run. So the laws
of evolution tell us that eventually, they will overcome, be it tomorrow,
next year, next decade, or next century.
      In some twenty years if not before, we will both look back at the days
of all-ASCII with a pinch of nostalgy...


-- , , _ v ~ ^ --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
-- ' / . --
Join the TUNES project for a computing system based on computing freedom !
TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"
--

Return to the comp.compilers page.
Search the comp.compilers archives again.