ARGON

[Francois-Rene Rideau]

Here are some random remarks about the now updated Argon pages;
* "OO". Why have "objects called Entities"?
 One of the advantages of OO is precisely that you call anything an object...
* "Invisible persistence". You mean just "persistence".
 I'm not sure about the terms "online storage" and "offline storage".
 I'd say fast but transient chip cache memory
 and slow but permanent magnetic storage memory.
* You don't give any evidence how your language is more (or less)
 crashproofing than Java (so you do think Java is crashproofing? hahahahaha!)
* Clearance codes: will you hardwire that in your "kernel"?
* Efficiency of a portable language: it means a very high-level language,
 hence more time needed to compile. How do you intend to achieve that
 with a bytecode???
* How large is your "flat space"? 16/32/64/96/128/256/512 bit?
 Let's say 64-bit (the most probable today for a flat space,
 see MungiOS, Texas Persistent Store, etc).
 Do you mean that even embedded versions of your system on lesser computers
 will have to cope with that huge address size,
 or do you mean to discard embeddability of your OS?
* You say "no memory protection is necessary".
 You mean that over the full distributed system?
 How will you fight against bugs, crashes, attacks?
* "Cooperative multitasking" you mean the user must be trusted
 to explicitly yield execution?
* "Persistent entities"
 what you describe looks rather like swap.
 Are your swapped objects really persistent (survive a system shutdown)?
 What about active objects: will they persist if I shutdown the computer?
* Why *byte* streams as a means of communication?
 this breaks any type- and semantics- based security!!!
* Loadable modules: do you have any way to check consistency and security
 of modules??
* <<One Interface can be marked as a default. This interface is the one
   used when the user simply says, "Give me that entity">>
 I disagree. This uselessly makes the intrinsic object system
 more complicated.
 In Tunes, the user never sees the entities, but only interface to it
 (have you ever "seen" an memory cell?).
 Hence when you say "give me that entity",
 actually you pointed not to the low-level entity
 but to a particular interface to it.
* Your 24bit text representation is ridiculous!
 you're having a gratuitously non-standard solution for representing text.
 You seriously limit the kinds of possible "character attributes"
 combinations to fit 256 possibilities,
 you build yet another non-standard UNICODE.
 You allow only 4096 characters at a time,
 which makes chinese support altogether useless.
* Your don't detail your type system. I suppose a ML-like type system?
 What kind of modules will you have?
 Will ARGOT be reflective?
 What impact on the type system will that have?
* There is no semantical between your "DO" and your "SEQ"!

Finally, what in your project requires that this be implemented as the OS?
Couldn't you just build it over Linux?
Let's say you need to rebuild a full programming environment.
Why not use an existing micro-kernel like VSTa, Mach,
or an existing OS kernel, like Linux or the HURD?
Are they inadapted to what you want in any sense???

== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"