CoreObject is intended to be one of the foundation pieces of Etoile. The current roadmap calls for an experimental version in 0.3, a stable interface in 0.4, and a completely stable version in 0.5. “What is CoreObject? Basically, it’s a replacement for a filesystem as a programmer and user interface. Files (in the UNIX sense of the word) never were a good abstraction; an untyped series of bytes is no use to anyone. The operating system needs to deal with things like this, but programmers shouldn’t have to. We already have a much nicer abstraction than a file; the object. Unlike files, objects have all of the structure and introspection that we want in order to be able to interact with them programatically. In EtoilE, we want to treat everything as an object, and objects as first-class citizens.”
I stopped reading after “Objective-C”.
It’s so… passè.
yeah, so passè, as if the best Mac OS X applications were not created with that language…
i could have sworn that files are a kind of object, so where does this “hate” for files come from?
i could have sworn that files are a kind of object, so where does this “hate” for files come from?
It’s not hate per se, it’s just that files are not a particularly great abstraction compared to object serialization (mind you, automatic object serialization has its own problem too, but it’s anyway definitely a step up from the unorganized binary blob that is a file).
In any way, CoreObject is cool because it does most of the work for you, and we are lazy. Beside, using CoreObject as a middleware you could imagine changing the way objects are actually saved/loaded without the app knowing it (that’s what EOF more or less did);
Using a common way of storing structured information also opens lots of interesting way for collaboration among apps (e.g. a la NewtonOS).
I stopped reading after “Objective-C”.
It’s so… passè.
Idiot.
Edited 2007-07-22 19:12
sounds like i need to read up on some theory…
I disagree on the file issue. Files are a perfectly good abstraction for what they are — a low-level OS mechanism. I don’t think object-serialization is a particularly appropriate abstraction for that sort of thing. The real problem is that for far too long, its been really the only abstraction available. At the application level, you really want to use something higher-level.
As for the “idiot” bit, I agree. One day, people will realize the genius of Alan Kay, but until then, this is the sort of thing we have to put up with…
>>One day, people will realize the genius of Alan Kay, but until then, this is the sort of thing we have to put up with…<<
Well, one could say that Ruby is Smalltalk with a more C-like/Perlish syntax to avoid the ‘syntax shock’ for people which are used to other languages..
My own pet peeve with Smalltalk beside the syntax is the variable declaration separated from the initialisation: the ‘nil-state’ which is triggered by this is quite ugly.. Strange, that they don’t have fixed it yet.
Nothing new under the sun, but interesting nonetheless. Who knows me, will remember my talks about something named “CABOOM” that never came to be… the ideas were more or less the same.
Sounds to me like naive, metaphorico-maniac mumbo jumbo from the 80s. There are already some solid high level interfaces over stored data : that’s what all sorts of database systems are (relational, object-oriented, etc). There are object serialization functionalities in standard APIs of Java and .NET. There are gazillions of file meta-data systems in use for decades, including the well recognized MIME, and several that are to be built int the next versions of Mac OS X, Windows, major Linux desktop environments… There is XML, its DTDs, schemas and namespaces. And anyway, in the big picture, filesystems tend to be abstracted out as just one level of a memory persistence system that seamlessly include everything from L1 cache down to network storage, including local RAM, etc.
I agree that it’s definitely not a new idea, and that there are numerous systems that more or less provide the same functionalities (starting from Smalltalk images nearly 30 years ago). Doesn’t mean that it’s mumbo jumbo and useless
, to the contrary… on this particular area, what etoile would like to achieve in the end is probably closer to NewtonOS.
An interesting related project is also the SPEEDOS system, based on the MONADS PC:
http://www.informatik.uni-ulm.de/rs/projekte/SPEEDOS/
quote:
Key Monads Concepts used in the SPEEDOS Project.
* Persistent Virtual Memory
* Protected Semantic Files
* Uniform Software Modules
* Distributed Shared Virtual Memory
* Secure Persistent Processes
* Directories as User Level Software
* Directories as a Basis for Secure Communication
* Distributed Secure Directories
Other Key Concepts used in the SPEEDOS Project.
* Protected Segments in a Paged Virtual Memory
* Implementing SPEEDOS in a System with Short Virtual Addresses
* Protection based on Bracket Routines
* Access Control Based on Bracket Routines: Some Examples
* Confinement with Call Bracket Routines
* Confinement of Objects
* Examples of Confinement of Objects
* Rule Based Confinement
* Environmental Instructions and their Confinement
* Confinement of Capabilities
The linked article reminded me of the SPEEDOS concepts of semantic files and persistent virtual memory.
…pretty high-level. It would be interesting to hear more about the design and practical implementation points.
Ridiculous. The ability to treat files as an untyped series of bytes is one of the best of all computing memes there ever were, and it’s not going anywhere.
I deal with data sets that grow by over 30GB every day. I don’t have the disk space to store the data in question in anything other than its native format, I don’t have the system memory to wrap a object around every record, and I don’t have the processing power to noodle around with constant serialization and de-serialization. Making everything object-oriented gives me plenty of overhead but no practical advantages.
Did I mention that I have to move big chunks of this data in and out of existing software systems like MATLAB, LabVIEW, and R, and that anything that makes this procedure even slightly more difficult is a direct attack on my productivity, not an aid?
This isn’t an anti-OOP rant: I like OOP, in its proper context. This is a rant against system developers who are so dazzled by their vision of the proper level of abstraction in an operating system that they’d rather render the entire system unusable for high-throughput applications than allow programmers to use or discard those abstractions as they see fit.
Ridiculous. The ability to treat files as an untyped series of bytes is one of the best of all computing memes there ever were, and it’s not going anywhere.
Er… indeed. Files won’t go anywhere
— adding new possibilities doesn’t remove the existing ones ! And beeing “compatible” to existing codebase is why we are using Objective-C rather than Smalltalk…