1. 17
  1.  

  2. 8

    Reading this is like listening to a reissue of some old post-punk (say) LP and realizing how ahead of its time it was — how it was doomed to failure because listeners didn’t get it or because the band didn’t have the gear to make the sounds they heard in their heads; but how influential it was, and how it still sounds fresh.

    Like the old saying about the Velvet Underground: “only a few people listened to their music, but everyone who did started their own band.”

    NewtonScript was heavily inspired by Self, a radical streamlining of Smalltalk that introduced prototypes. JavaScript’s object model came from either NewtonScript or directly from Self. JSON came from Javascript, of course. So some aspects of the Newton data model have become ubiquitous.

    I’ve become fascinated by the Soup lately, partly through links posted here. Such a radical and necessary idea, to do away with the filesystem. To make on-disk data the same stuff as in-memory data, and structured enough to be shareable across applications. Now I find myself sketching designs for something similar. If the Newton could do it in 1994, albeit fatally hamstrung by primitive hardware, we can do it today.

    1. 4

      soups were indeed awesome. I think that many ideas from the newton were way ahead of its time and wish people would revisit them. You might enjoy Using a Prototype-based Language for User Interface:The Newton Project’s Experience (PDF) and Soups on the Newton

      1. 1

        Thanks! I read the second one a few days ago, but the paper is new to me.

        1. 1

          Do you know if any info has leaked out about the Newton OS internals? It sounds as though soups were memory-mapped, and the stored format of frames matched the in-memory format, so that NewtonScript could work directly with soup data without having to copy. I’ve been building some similar things, but I’d love to know more about how they did it.

          1. 4

            Just the papers, but I’m happy to answer questions.

            There were two different ways of storing objects: heaps and soups.

            An object in ROM or an application package was stored in the heap format (that is, the same as the runtime heap in RAM) so a direct pointer would work. With a couple of caveats…

            There were “magic pointers” for well-known ROM objects so you could build an application with, e.g., a proto slot pointing to the prototype button object, and have that work on different ROMs. Those were resolved by the object system on every reference. Application packages were stored in heap format that was divided into compressed 1k pages. The decompression process relocated the embedded pointers based on the current base address of the package.

            Soups were completely different. There was a low-level blob store that had several different implementations, notably RAM (only on the 1xx models), ROM, and NOR Flash. The latter was a transactional store and also had to handle all the crazy flash stuff about erasing pages, etc. The blob store just maintained a flat container of binary blobs, each with an opaque integer ID.

            The object store was implemented on top of the blob store interface. Each stored object had a top-level frame, which was serialized (deeply) into a compressed byte stream format (sort of like JSONB) and stored in a blob. The objects were indexed with B-trees, each node of which was a blob.

            In the heap, a stored object was represented by a “fault block” containing the store reference and ID of its serialized object. If the runtime needed to look inside a fault block, the stored object would be deserialized into heap objects. The fault block was still there but the frame get/set operations would recognize it and skip over it to the actual top-level frame. (See the swizzling paper for the general idea.)

            BTW, the heap and serialization formats are documented. The “streaming” format is nearly the same as the soup blob format. Main difference is symbols were stored separately in the soup so as not to waste space on common symbols.

      2. 6

        Author here — I already answered some questions on the orange site, and happy to answer more here if there are any.

        1. 4

          The Newton was a fantastic platform. I really enjoyed developing for it back in the day.

          There was really nothing with that kind of operating system and application runtime that you could hold in your hand.

          It ultimately failed but many of the ideas, concepts and people defined a long stream of innovation. Very similar to General Magic.

          1. 2

            I liked this tweet from the @chatur_shalabh

            Interesting stuff.

            “Objects are self-describing.”

            “Binary objects and arrays have a special “type” slot that must contain a symbol reference. This slot is used to attach type information to these objects.”

            “There are no “windows”, just views that look like windows”