GEN,ORG far13

[Francois-Rene Rideau]

Hello, fellow moose-programmers !
(see, I've been prolific this week to catch up with my not answering for
two weeks)(but you weren't much chatty this week)

-- ORG - moose organization - part --
 I see that my message numbering isn't used.
Well, I know that it isn't pretty, and I don't like it myself;
but I think we should find a means to file messages by subject
and author, and then stick to it. The format should allow future
automatic treatment by a filing software which would record
messages by author, subject, keywords, votes, sub-problems,
then link messages to replies, question to answers, and
maintain (with a moderator's help, here) for each problem an
up-to-date sum of all that have said (and not cancelled/replace)
about that problem.
 In this message's subject, GEN stands for general principles,
that is moose philosophy and what we expect it to do (not how
it will; no details).

-- GEN - moose general principle - part --

In his message "OO ?" (6/3/93), Gary Duzan sez:

> [description of a spinlocks]
> [about the "moose" name]
> [about capabilities]
Thank you for your explanations.
Maybe someone should detail on capabilities and how they are
implemented, to compare with the dictionary point of view.

>>> An OO operating system does NOT mean (IMHO) that all the support for OO
>>> langauges should be built into the OS (and certainly not into the kernel)
>>> To me it means that the OS should provide some operations that make it easy
>>> to implement persistant objects.
>> What do you call "some operations", and "persistant objects". To me,
>> you have no OOed OS if every language is going to completely reimplement
>> their objects; you only have an OS with an annoying OOed interface (as
>> with the Mac for many aspects).
>  It is not our job to provide standard objects to every existing and
> future object-oriented language. We have to draw a line between the
> system and the applications somewhere. Also, I see no need to impose a
> class heirarchy on the system itself. We should create a space in which
> independent objects can exist, operate, and interact via tightly
> controlled interfaces. We can then integrate the interface into
> languages as required. I don't agree that persistence is the primary
> goal, but it is a good one.
 (Again, can you detail on object persistence then, as compared to
the generic object format I propose ?)
 I must explain my point of view, as I don't know if we disagree on a
(fundamental) choice, or if we just don't understand each other (or
worse: if both).

 To me, an OS is an interface between the programs (that is, nearer or
farther, the user) and the hardware, and for programs between each other.
 We see with previous systems that what wasn't proposed as a standard with
the basic system (as is delivered with the system package) could never
get properly dynamically exchanged; hardly can it be filed if there is an
international standard (example: pictures, more recently sound, in the
near future, animations). No high-level standard could be achieved as no
generic enough language was found to EFFICIENTLY replace all others (and
it most probably never exist), and a high-level standard cannot support
inter-platform data communication. So
 For example DOS don't manage anything;
 To show how embedding code and data IS useful, you can imagine how
horrible it is for an user to see that existing apps don't have ALL
the required features to treat his data, and that he only have choice
between rewriting his own app (which even if he can will take a great
amount of time and/or money, and won't even allow him to communicate
his data to others !), or manually maintaining references through a huge
database and not having the app do correctly the work expected and having
your data take much more place than needed and still be limited in
single entry size. Let me give you an example I know well before
I continue with general ideas.

 My mother and I currently ARE in this case with DOS,Unix and MacOS alike.
My mother works in vietnamese and in french. But if most french accents are
present in most character 128-256 ASCII extension (though not with a
standard coding and with conversion problems, unsolved when text is
embedded in a non all ASCII file), vietnamese characters aren't: if you
want a code for each letter-accent combinatin, that's 131 characters to
add to ASCII). Under all systems, vietnamese specific text processors exist.
Each includes commands the same as existing text-processors under the
same system; but it won't be able to use improvements of the orgininal
editor, and the author will have to maintain it manually (if he would);
moreover, you can't use the standard format together with the vienamese
format (as they are incompatible) so you must have two distinct programs
(and you may know that lemacs, for example is 16 MB) on your disk and/or
running in memory. That's properly ridiculous. Moreover, each software
has its own coding, so that you have to translate from one to the other
through external utilities (and no 'you change it in a window, and it is
updated in the other' stuff possible), when they exist, because the one
who designed his format wasn't aware of what the others did.
  Utilities under DOS allow to remap the ASCII set and the keyboard to use
vienamese; so you can use a standard DOS software with vienamese, provided
you don't use french at the same time (as my mother does), and provided
the software goes through standard calls from screen/keyboard IO, which
fewer and fewer software do, as DOS calls are slow, stupid, uncomplete,
bugged, etc. So in practice, those utilities aren't very useful. There
also are Unix vietnamese terminals, which is better, but their facilities
won't apply with standard 7 bit unix software, and you can't use french,
etc. Only the Mac is good at this and largely beats all the others, as you
can add your own fonts and keyboard settings; my mother now uses MS Word 5
(that is a STANDARD software) and with a vietnamese font, and can send it
to her colleagues, and use it in ANY C.A.P. program (whereas with a few
bugs to correct manually, which may or may not be corrected in another
version). (the same may exist under MS Losedows, but local keyboard
remapping may not be as good, and I couldn't find utilities to do
keyboard&font editing&installing as with the Mac).
 Of course, every software has its own format, and you can't always
find a translator from a format to another. Moreover, translation
becomes impossible when the text is embedded in a non ASCII only file
(say, my mother dbase file containing the (huge) list of her books in
english, french, and (what is most important) vietnamese, about VN).

 Well, every one doesn't have the same problem, and the vietnamese problem
can be (partly) solved with unicode. But there are many many similar
problems (for example mathematical and/or symbolic expressions and graphs).
And you can be sure there will always be a need for new data formats. So
if the system doesn't allow a standard generic interface for data AND
accompanying code, you will forever have to recompile your apps each
time you want to include a new data format, provided the app was built
to accept change (because IT had the OO system the OS failed to implement)
and you have the app's sources (not all are public) and someone was
patient enough to implement a patch for each application you use.
When the gap between end-user objects and system capabilities becomes too
large, there will just be another funny groups like moose who'll want to
rewrite the system again from top to bottom !
 That's no fun. Object embedding should NOT be let entirely to application
writers or we're not getting anywhere. Of course apps should be able to
use as they will local variables; of course they can publish new object
formats; but there should be a format-describing standard so that
automatic format translation (including real-time exchange with the 'same'
object being accessed in different formats in more than one window) is
easy with as few user work as possible (none is ok). Of course you can't
foresee everything; that's why the format itself must be extensible, and
flexible; it should not so much describe how raw data is organized (which
can be horrible; see a LZ compressed sequential access only file), but
how it can be accessed, and what properties it has (logical propeties,
scheduling limitations, quick or slow aspects); it should be generic
so that you can build general purpose apps (to stick to my example,
the database should be able not only to keep french/vietnamese data, but
also to sort it the french/vietnamese way, which is not a mere
lexicographical on the letter order, as yo take accent order after
letter order, and letter order not being harware coding number order,
as some letters have been deplaced above the 7 bit limit).
 You won't ever be able to dynamically manage data, and/or to manage
subdata otherwise, so that the system is unuseful. We're not building
a system JUST to implement a new trick we like; we're also building a
useful and easy system for the end-user, both computer-scientist or not.

 Moreover, I don't see what a NEW OS would bring but that. All the rest,
Unix that; and Unix is widely spread, and has good implementations on
any computer, including PC's (see linux), Mac's, Amiga's, etc. You just
want standard calls for threading, small files, your language and/or
a GUI ? Just write (yet another :-) library to do it and a server to
centralize calls from multiple end-users; don't bother rewriting all the
system. And most probably an existing extension of Unix does it; you
just have to find it on the net and recompile it. You don't find it
standard or extensible enough ? Haha ! Then now YOU ask for the standardness
and extensibility you previously refused when writing the system.

 Well, I hope moose is not going to correct only implementation problems
(that is just better implementing what was to slow/clumsy under previous
systems), but also and mostly conceptual problems (that is, what makes
other systems a nuisance to use, and what forces you to go round the system
instead of using it).

		     ,
		  Fare,
	200% time moose programmer,
	   computing day-dreamer.

P.S. I dont have time to re-rea all that, so excuse me if there are mistakes,
mistypes, omissions, etc. An added correction may come.