Daniel Henry Holmes Ingalls Jr.: The Live Web. Drag 'n drop in the cloud

You can't fix a broken wheel. Let the downvotes illustrating the ignorance of HN pop culture start.... This web link post, the original NEXT webbrowser as a web page, tries to celebrate and revive the reinvention of the broken wheel. The World Wide Web, browser and html standards are a very broken wheel. Alan Kay, the inventor of personal computing, explains why: link Some of the comments of youtube are fun too. This lecture Alan aimed at this particular audience, the computer science (programming) students at University of Illinois, where they programmed the second browser, the second broken wheel 20 years after Alan and Dan had showed them how do do it better. Dan Ingalls implemented most of Alan Kay's invention of the personal computer, in the following demo's he shows how to fix the webbrowser's broken wheel a bit. The Lively Kernel would be another way to fix html but retain the web. Two demos says it all: link ▶ this video Their Squeak, Etoys and Croquet fixed it completely: Early Croquet demo (there are several others): link Croquet in webbrowser: link Demo of webbrowser replacement: link Squeak and all its predecessors: link Etoys: link

I will not invest any time in improving badly designed software. You can't fix a broken wheel. Your HN newsreader app tries to improve the broken wheel. The least you could have done is make the comment edit field WYSIWYG, make it modeless, see what the text will look like while you type, not after you click update or when you click edit in the tread reader. Your code is just a very limited webbrowser. The webbrowsers, html are a very broken wheel. Alan Kay, the inventor of personal computing, explains why link This lecture Alan aimed at this audience, the computer science (programming) students at University of Illinois, where they programmed this broken wheel 20 years after Alan had showed them how do do it better. Paul Graham should not have based HN (Hacker News) on the web and html but on WYSIWYG, then you would not have had to fix it with your app. The Lively Kernel would be another way to fix html but retain the web. Two demos says it all: link ▶ this video Dan Ingalls implemented most of Alan Kay's invention of the personal computer, in these demo's he shows how to fix the webbrowser's broken wheel a bit. Their Squeak, Etoys and Croquet fixed it completely: Early Croquet demo: link Croquet in webbrowser: link Demo of webbrowser replacement: link Squeak and all its predecessors: link Etoys: link

After Self, the short lineage is Self (~1992, Smith & Maloney) -> Squeak port (Maloney & Ingalls, Etoys/Scratch 1) -> two independent JavaScript reimplementations, plus Squeak-in-the-browser via SqueakJS. I dug into this same question a decade ago and posted a longer treatment -- my email exchange with Alan Kay on MVC vs Morphic vs watchers, plus replies on Self's "soup of objects" UI. Good philosophical complement to the architectural links below: link Self Morphic is not a classical class hierarchy. The handbook describes parallel traits objects (shared behavior) and prototypes (structure), with instances delegating via parent* slots and "copy-down" differential prototypes. Bottom-up: morph copy, tweak, factor shared behavior into a traits object. Worth reading section 7.3 alongside pjmlp's links. link The Squeak port is single-inheritance Smalltalk classes -- closer to what most people mean by "OOP UI toolkit." Etoys is Morphic. Full Squeak Morphic in a browser, no install: link Squeak 6.1 release notes (Objectland, tree morph overhaul): link In JavaScript there are two Morphic implementations people often conflate. Same family, not the same code. Dan Ingalls's Lively Kernel / Lively Web (~2008, Sun) is the full live system: modular core/lively/morphic/ (Halos, Serialization, Scrubbing, Connectors, constraints), plus IDE, parts bin, world persistence. JSConf 2012 demo: link link ▶ this video Jens Monig's morphic.js (~2010, BYOB4/Snap!) is a separate codebase: single-file Canvas kernel (~13k lines), World/Hand/stepping/dirty rects, template peel-off, ScrollFrame inertial pan. Jens names Ingalls's LK as the gold standard but says it is not a direct port -- though fullCopy() was ported almost literally from Squeak, comments included. Snap bundled it from day one (2013-03-16). Standalone extract: link link link link link) On multiple inheritance: neither JS port uses it, and Self Morphic didn't really either. LK cheats with an explicit Trait composition layer (Object.subclass plus Trait(...) mixins). Snap cheats with Squeak-style copying (fullCopy, isTemplate peel-off). The live feel comes from copyable morph trees and shared behavior, not MI. If you want one more readable architecture tour beyond sin-ack's intro, the Self handbook chapter 7 is still the root document; everything else is commentary on it.

After Self, the short lineage is Self (~1992, Smith & Maloney) -> Squeak port (Maloney & Ingalls, Etoys/Scratch 1) -> two independent JavaScript reimplementations, plus Squeak-in-the-browser via SqueakJS. I dug into this same question a decade ago and posted a longer treatment -- my email exchange with Alan Kay on MVC vs Morphic vs watchers, plus replies on Self's "soup of objects" UI. Good philosophical complement to the architectural links below: link Self Morphic is not a classical class hierarchy. The handbook describes parallel traits objects (shared behavior) and prototypes (structure), with instances delegating via parent* slots and "copy-down" differential prototypes. Bottom-up: morph copy, tweak, factor shared behavior into a traits object. Worth reading section 7.3 alongside pjmlp's links. link The Squeak port is single-inheritance Smalltalk classes -- closer to what most people mean by "OOP UI toolkit." Etoys is Morphic. Full Squeak Morphic in a browser, no install: link Squeak 6.1 release notes (Objectland, tree morph overhaul): link In JavaScript there are two Morphic implementations people often conflate. Same family, not the same code. Dan Ingalls's Lively Kernel / Lively Web (~2008, Sun) is the full live system: modular core/lively/morphic/ (Halos, Serialization, Scrubbing, Connectors, constraints), plus IDE, parts bin, world persistence. JSConf 2012 demo: link link ▶ this video Jens Monig's morphic.js (~2010, BYOB4/Snap!) is a separate codebase: single-file Canvas kernel (~13k lines), World/Hand/stepping/dirty rects, template peel-off, ScrollFrame inertial pan. Jens names Ingalls's LK as the gold standard but says it is not a direct port -- though fullCopy() was ported almost literally from Squeak, comments included. Snap bundled it from day one (2013-03-16). Standalone extract: link link link link link) On multiple inheritance: neither JS port uses it, and Self Morphic didn't really either. LK cheats with an explicit Trait composition layer (Object.subclass plus Trait(...) mixins). Snap cheats with Squeak-style copying (fullCopy, isTemplate peel-off). The live feel comes from copyable morph trees and shared behavior, not MI. If you want one more readable architecture tour beyond sin-ack's intro, the Self handbook chapter 7 is still the root document; everything else is commentary on it.

I have been using Emacs as my daily driver for about a decade. It's the closest thing we have to a "popular" Smalltalk environment. The desire to bring everything into Emacs is the same desire I felt after experiencing what computing could be in Smalltalk. One of the really striking things that you're confronted with in a modern Smalltalk is the Morphic UI system. Imagine that, with one click, you could drop into a new window with a live inspector and a (very freeform, repl-ish that's not a repl) REPL loaded into the internal context of any button, window, pane, scrollbar, you name it that you can see right now. (Even my own vocabulary is stifled with the traditional UI/UX we have now!) Now imagine you can do that on any application on your computer. Now imagine you can drag those subcomponents around, rearrange them, drag them onto new windows, modify their code, spawn new ones, and so on all while the thing keeps running and functioning. If you break something, it's okay. The debugger pops up and allows you to do the same thing that you did when you inspected the widget for any point in the frame in the stack trace. Yes, you can debug, live, multiple levels of your stack trace at the same time, that have live, editable versions of the code as well. You don't have to imagine it. You can see it here [1] or just download a Smalltalk system yourself. If the Smalltalk community focused on building some tooling to allow you do develop other languages inside a Smalltalk image based editor, I don't think even Emacs could compete. --------------------------------------------------------------------- As far as what kinds of weird would be fun, I always find new interaction paradigms fun. That's one of the things I loved the most about Acme. It's kind of crazy how versatile and adaptable "execute the highlighted text in the shell" is as a core interaction loop. If you want to search files for something, just type `grep` in front of the word, select them all, and then you get a new buffer with the results. Which are, of course, editable and executable in the same way. The two most common places I see experimentation in this are in Linux window managers and programming languages. I've tried StumpWM, i3, and AwesomeWM before. I wish there were more people experimenting with non-tiling things. The person behind this project is doing some very cool stuff [2]. There are tons of people making cool, small (and large) new programming languages like Idris, Janet, Lean, and Pony and lots of people still using really cool old programming languages like APL (or J or K or BQN), Forth, and Scheme (Racket is great, Gerbil built on Gambit is insanely good for a one person project). I see some insanely cool stuff about prototype languages doing staged metaprogramming (lookup Collapsing Towers of Interpreters if you want to read about something really cool, i.e. compiling out the costly abstractions in infinite towers of reflective interpreters), dependently typed experiments, and other wild shit. Surprisingly, there seems to be a lot (sadly meaning only 2-3 actually separate movements) going on in the "OS space" too with immutable/declarative system specification. I'm referring of course to Nix and Guix and things like Fedora Silverblue and OpenSUSE MicroOS. That's gaining steam quickly. I personally find the Nix language rather fun and interesting in its own right, but I think I'm on the minority side of that. Broadening out past that, hell I don't know. That's why I put the call out to everyone else :D [1] ▶ this video [2] link

Sounds more like "the challenge of using a mish-mash of non-integrated tools with no interface". Developers could definitively solve this by moving away from 70+ year old abstractions (files, terminal) towards things more in line with Smalltalk ideas. But I guess it's better to make thousands of beginners suffer each year, instead of admitting that the current way of doing things is conceptually flawed and outdated. link link ▶ this video link (And no, there is nothing special about copy-pasting commands and Unix pipelines that cannot be easily recreated in UI if the UI is designed to be programmable. )