Newton's storage - a different Object Soup

Software
1

Nearby, in the discussion about Computer Language Magazine, @HCS says:

I am looking for [a 1990] article by J.D. Hildebrand entitled “Object Soup”.

Newton logo from wikipedia:
image

I searched, and found something quite different: Apple’s Newton didn’t have a filesystem, but stored user data in an “object soup” - some kind of collection of objects which have access methods, I think.

Wikipedia describes it as a shallow database.

Ian Robinson has a tutorial on Newton Data Storage saying:

Unlike traditional operating systems such as the MacOS and Windows NT there is no file system and therefore no files in the Newton Operating System. Data is instead stored in opaque collections like a database in entities known as soups. Each entry in a soup can be likened to a record in a database and each data member in an entry (known as a slot) can be likened to a field in a database. Unlike database records entries in a soup do not all have to have the same slots. To retrieve data entries from the soups you don’t access them directly but rather send queries to the soups which return cursor objects. You then use the cursor object to get copies of individual entries in the soup. You can then do whatever you want with the copies. The original entries in the soups are not modified unless you overwrite them with your changed copy.

And a document on Symbian’s design principles talks about it thusly:

Instead of a conventional file system the Newton employed an ‘object soup’ storage model.

and quotes Charles Davies as saying:

We had a normal file system on the Series 3. When we went to C++, we talked a lot about persistent models of object-oriented programming, and we went for stream storage. We narrowly rejected SQL in favor of stream storage. I remember the design ideas around at the time, and it was done in the interests of efficiency. Different applications were having to save the same system objects and we were having to duplicate that code. So for something like page margins, which was a system structure, if that object knew how to serialize itself, that would solve the problem. You do that by having serialization within the object, so objects that might reasonably want to be persisted could persist themselves. And that was in the air, I mean Newton had its soup at that time which I think was object-oriented, and there was a belief at that time that object-oriented databases were it, and that objects ought to be seen as something that existed beyond the lifetimes of processes.

There’s a footnote leading to a citation with this DOI

Hildebrand, J. D. (1994) Object Magazine 3:6 (February 1994). NY USA:
SIGS Publications
The article is called Object Soup but I haven’t yet found it. I wonder how similar it could be to the editorial in Computer Language - it’s talking about a toolbag of small programming techniques, not about persistent storage.

1 Like
2

Note that the ARM6 MMU had features, such as sub-page permissions, that were added to help support Newton’s object soups. There was a Byte magazine article that had some details about this.

Alan Kay likes to point out that there are no such things as files and directories (folders). There are only bytes on disks (or Flash). Anything else is a simulation that the computer is creating. And these days there are normally multiple layers of simulations.

If you insist on using files as the building blocks, then you have to add features like OLE or HTML so something in one file can point to another file (or at something in that other file). The alternative is to design something from the ground up with the features you need, even if programmers find it “unnatural”.

3 Likes
3

Very interesting - so there was! Quite a technical article:
Call to ARM by Dick Pountain (BYTE November 1992, p293)

The most radical aspect of the ARM610 is its MMU, which combines a sophisticated conventional virtual memory controller with a novel scheme for partitioning memory along object-oriented lines. This aspect of the chip’s design is the subject of a patent held by Apple Computer and licensed to ARM.

4

I think Multics Os had the first implementation of objects, but it was not called that then.

5

Coincidentally, I was reading this paper over the last few days about the properties that define Smalltalk and Unix and how they relate to one another despite being superficially very different:

6

This is a very interesting comparison.

It reminded me of an interview I gave over the phone to a newspaper in 1985 (available in Portuguese) where I explained that the children’s Logo computer project had evolved into a Smalltalk computer. The reporter had never heard of it so I asked if he was familiar with a few things and the only one he knew was Unix. So I made an analogy between Unix programs exchanging bytes over pipes and Smalltalk objects exchanging messages. This got filtered down to:

Curently Fábio and Jecel have an even more ambitious project: they are designing a 32 bit micro for the SmallTalk (sic) programming language - a powerful programming philosophy created by Xerox from the US, which doesn’t require any knowledge of computing. “Now we are on the right track”, says Jecel. “SmallTalk (sic) ideas are used in Apple’s Macintosh, in the Unix operating system, but we want to create a pure Small Talk (sic) machine”.

1 Like
7

The idea of object soup doesn’t sound all that different from the IndexedDB API that’s available in current web browsers. A data base can have a number of “Stores,” which are analogous to files or tables, and a Store can have a number of “Objects,” which in the simplest case can be POJOs (Plain Old JavaScript Objects), but most browsers are able to serialize quite a few of other objects as well. Stores can have a number of indexes which are based on properties of the objects in the store.