Dear Uuus:
First, my thanks to all who took the time to reply to my newbie questions!
>Phil>The solution is really quite obvious if you don't think about
>Phil>filesystems. Just forget that there is a filesystem.
Yeah, but in my case that means getting rid of some 20 years of prejudice, from
CP/M to Solaris...
I keep on telling my students to think about Musashi's advice on fencing:
"The best stance is no stance, the best technique is no technique",
but it seems that I haven't paid much attention myself! :-)
>Lennart>Basically, a good OS for the future would be Zope3 + a kernel. ;)
Sounds promising indeed.
>Ziggy> Agreed, registries are bad.
>Lennart>Registries are good.
Registries *can be* good if implemented properly and used for sensible purposes
-- like any other technology.
But if I am getting the concept properly, there will be neither unixish
configuration files nor M$-type registries in Uuu - ?
>Phil>I'm not sure I understand the situation here. The "text processing
>Phil>function" does indeed return the letter. This might be to the user, or
>Phil>it might be to a calling function. It's the same thing.
Re-thinking all this, I get the idea that Uuu is *the* solution to the age-old
problem of file format compatibility
-- a thing to be much emphasized much more strongly, as incompatible file
formats are everyone's bugbear.
(Excepting Billyboy, of course, who makes money out of them.)
What I was first thinking of was the following: The user is fundamentally
different from any function,
even in the absence of the notorious shell layer, and data -- whether wrapped
up and peppered with executable code into objects, or "primitive"
-- is something intangible. To the calling function, the letter is just another
object, that's fine:
letter = text_editor()
But how can we pass this object to the user, and how is the user expected to
deal with it?
If text_editor() is pure, side-effect free, haskelly function which does really
nothing except for creating and returning a letter object,
the direct invocation at the Python prompt
>>>text_editor()
will cause the returned letter object to get lost. Thus we would need side
effects to do something useful.
But I hope that I have grasped your concept by now. Is something like
>>>LetterToGrandma = text_editor()
followed by
>>>RevisedLetterToGrandma = text_editor( LetterToGrandma )
and finally
>>>send_to_printer( RevisedLetterToGrandma )
>>>LetterToGrandma = RevisedLetterToGrandma.clone()
>>>RevisedLetterToGrandma.erase()
going to be the way, with LetterToGrandma and RevisedLetterToGrandma being
references to persisting objects?
If so, I have now understood what you are talking about. :-)
Actually much simpler than file systems!
And I am also very curious about what the user interface is going to look like.
A graphical browser which displays all the objects in namespace, with each
object's methods being available as a pop-up menu,
and the built-in functions such as "send_to_printer" as desktop icons for
drag'n'drop, would seem straightforward, but maybe you already have some better
ideas?
At any rate, how can a namespace with 50'000 components be handled efficiently?
Just like one with 50 components, sure. But how is this going to be hammered
into something "user-friendly"?
Likewise, will other nodes and their namespaces (that is to say, all components
of the namespace which have a certain public_visibility flag set)
appear as objects, or maybe functions returning lists of objects, in my own
namespace? I think this would be a very nice starting point for distributed
computing.
>Phil> In contrast, in Unununium I would do something more like
>Phil> "mpg123(grassgreen)".
>Lennart>Or maybe grassgreen.play()?
>Lennart>Or, adapt(grassgreen, IMediaPlayer).play() ?
A very interesting remark. Re-phrase it like this: Are actions and their
targets going to be kept apart as in the functional languages, or bundled as in
the OO languages?
In my opinion, "mpg123" is an entity which is clearly distinct from
"grassgreen", so I am inclined to prefer Phil's suggestion.
Lennart's second suggestion, however has the benefit of being most flexible; is
"send_to_printer( RevisedLetterToGrandma )" unambiguous?
Maybe "send_to_printer( RevisedLetterToGrandma.PostScript_representation() )"
would be better and avoid the necessity to decide *what* is going to be
printed...
>Phil>Nothing can protect you from yourself.
Agreed. The "Alabama virus" ("Please send this message, up to and including the
final period, to everyone you know, then take a hammer and beat up the
computer.")
will crush *any* system if the user is dumbass enough. One might add, though,
that system designers and sysops are nevertheless expected nowadays to keep
this from happening, but that's off-topic.
Once we are advanced enough to worry about marketing arguments, we'll be
happy...
>Phil>Can a small pain in my toe trigger the circulation to my arms to stop
>Phil>and make them fall off? Let's hope not.
Well, there's acupuncture and all that stuff ;-) .
-- Ruediger Marcus
PS. I know most of you will object to this, but I suggest that appropriate
measures be taken to secure all the rights to this approach ASAP.
Call me paranoid if you like, I am more worried that I may not be paranoid
enough. The Uuu page is listed at www.windows-sucks.com, and from the fact that
M$ themselves are running a page named www.linux-sucks.com you may infer that
they are aware of what is going on!
PPS. As for myself, I am neither a troll nor a sneak, and ready to provide any
legal or illegal proof, including an oath to be taken on the head of Billyboy
(if placed before me in a silver dish), that I am not involved with any
software company whatsoever. :-))
--
Diese E-Mail wurde mit http://www.mail-inspector.de verschickt
Mail Inspector ist ein kostenloser Service von http://www.is-fun.net
Der Absender dieser E-Mail hatte die IP: 129.206.124.135
|
