Lisp Machines

Have any of you ever used a Lisp Machine? I've heard that it was a glorious experience because of how well-integrated it was: the system-wide debugger, the editor with hypertext authoring features, the command line with GUI elements. Was it actually that good? Which features were the best and what do you miss from them on modern computers?

Isn't that basically emacs? body too short

>>40130 It's possible. All those things could be done with C too so it's not unbelievable. I heard they were slow, but if the software was ported that wouldn't be an issue, java must be way slower.

Didn't, but you can try it yourself: https://interlisp.org/

>>40130 >Was it actually that good? The Lisp Machines (well, at least Genera/Zetalisp) were a lot better architectured than current systems; I do not know whether to attribute that to the various Lisp Machines being exceptionally high quality or everything else being exceptionally low quality, making the Lisp Machines appear better only in comparison. >Which features were the best and what do you miss from them on modern computers? I particularly think the ability for the whole system's sources to be dynamically viewed and modified at runtime puts it above all current operating systems in terms of how comprehensible it is. All current operating systems rely on many poorly documented black boxes which means programming anything for them is more a game of guesswork and trial-and-error rather than actual problem solving. .. The ironic issue of course is that lots of software for the lisp machines (specifically Zetalisp/Genera) was proprietary, which removed a lot of the appeal from them in my opinion. I also think Symbolics as a corporation was pretty definitively evil as they choked out any competition in the Lisp Machine space rather than trying to be collaborative; one of the many causes of the eventual downfall of Lisp Machines as far as I know. There's also a blatant security issue with the whole system being accessible and modifiable at runtime; there are a few papers on how to implement a Lisp system with higher security and containment, but I am not aware of an existing Lisp Machine which properly implemented said features. (doi/10.5555/220725) nonetheless makes an interesting read.

>>40131 Kind of like Emacs meets Matlab, if that makes any sense. >>40146 Something I find interesting about a lot of older dynamic languages was how integrated they were into their environments. You generally didn't "write a program"; instead, you issued the commands you wanted the computer to carry out directly. The only extant language I can think of that's like this is Unix shell script, and even then, people don't use that in the same way they used, say, BASIC back in the 80s.

>>40177 General purpose operating systems caused this loss of development environments. Now everything is lowest common denominator just existing on top of the existing operating system environment. People have trouble even getting it to work at all on operating systems, integrating the application properly into the operating system has been made so difficult and finicky that "works on my machine, only" is the standard expectation. Making an program actually work across machines is a huge effort and learning process.

>>40197 >Making an program actually work across machines is a huge effort and learning process. There's so many programming blogposts and videos out there supposedly teaching you how to get lighting fast programs, and 9 out of ten times, they're talking about stuff that only makes sense for one specific language running on one specific hardware configuration, typically an extremely modern one with SIMD instructions, a large cache and multiple cores. It's fuarrrking infuriating, especially since none of them seem to know how limited their advice actually is

Genera you can run it in a VM the copyright holders still hack at it and mainly were running it on OSX there is another version that uses an HP VM emulator There is a third that uses centos and an older X11 protocol Modern Equivalent would be: GUIX or Debian(guix) - StumpWM - SBCL - EMACS It is was waaay ahead and captured all of compute prior and was the ACME of its time (the ancients were genius) and it is still very interesting but All the progress has been captured and yyou can look at the genera code too (MIT might have it)

>>40146 This is a weird way to phrase things. Sure there was bad blood between Symbolics and and LMI, but that was for business reasons. Both collaborated with the smaller systems like Xerox. The arguments started in earnest around standardization, and to be blunt Symbolics deserved it. They were selling the most machines to the most customers. (Plus standardization was a much bigger deal back then.) If they walked, the other lisps epuld have died sooner, not later. >>40177 Yep, lest we forget: >Literally by making it possible to make the GUI better. Many don't know or have forgotten, but when the PARC team showed Jobs their new mouse-first GUI, Jobs carried over essentially nothing back to the Mac except for its superficial appearance, and only a pale shadow of the features left behind ever got copied back in. Preface example: I'm assuming you're using NT-Windows or Linux over OSX so it's not really relevant, but the original Alto had a mouse with three buttons, and made heavy use of combined presses and keyboard shortcuts to combinatorially explode what the mouse could do at any one time. Alan Kay had been in the audience for Englebart's NLS demo, and saw he was much more effective with his hands either on the keyboard or on a mouse *and macro pad*; the PARC team even built and used their own version to make pointing an operation that actually compared in power to what you want to do with it. The LispM was similar: with its three mouse buttons, four bucky keys, and small swarm of mode modifiers, Symbolics' electronics ebgineers could reportedly operate their in-house chip design suite both faster than any other product and almost entirely without needing to key in commands. Years later, AutoDesk for DOS would gain breakthroufh legendary status on the LispM's shoulders through letting you do the same type of commanding at a fraction of the effectiveness through the keyhole interface of the AutoLISP command line. The Mac, though? One mouse button, and intentionally as few modifiers as possible to keep the power of the machine from scaring away Jobs' target market. Microsoft and the Unixen of the time mildly improved from Apple's intentionally botched abortion, but got not even halfway to filling in Jobs' tar pit. You don't hate GUIs, you hate GUIs designed for emotional children. But this would matter much less if Jobs had copied over any of the rest of what made the Alto worth copying, such as the actual thing PARC invented and wanted to show people: The Smalltalk-80 live object GUI model. In the Smalltalk "operating system" (technically the thing that would become Mesa was the real OS, but its job for now was just to run an optimizing disc-paging interpreter S-80 sat on top of), everything you can interact with is a live, almost-pure messaging object system, and so can be modified and improved by the user on the fly. For example, when Ingalls was showing Jobs their officework suite, Jobs commented how he didn't like the look of text selection, which at the time inverted the color of whatever block of text was selected so you got a black "hole" in the paper-like screen with white text, Ingalls spent a few seconds modifying how the selection class messaged and positioned the rectangle display class and immediately had a new behavior where the text was surrounded with a black outline, across the whole system, with no recompilation and no efficiency loss thanks to Alto's bytecode-optimized custom cpu. Smalltalk's true-object system design made it trivial to do this with any element at any time. LispMs were similar: As he wished, the user could point the Lisp Listener at any element of any data on-screen, and get back a readout of its Sexp data as it sat in memory together with hyperlinks to all of its calling source provided by the integrated debugger. After modifying it any which way, the Listener would inject itself into the links into and out of the cooresponding binaries and simulate the new behavior between the rest of the code on-the-fly, while the incremental compiler quickly and automatically replaced just what the listener needed with native-speed object code. Again, obviously from the description this applied to literally everything. Want to hose the system builtins? Get the right permissions and it's a few commands away. Want to *repair* the system builtins after a bad patch hoses them, while everything's live in memory, so it's like nothing ever happened and nothing is lost? There's war stories of lispers attaching a fresh listener and doing exactly that while the rest of the wirld thought core dumps were a valuable and innovative step forward. Point is, it's not PARC's fault Jobs hadn't seen a GUI before he went to visit them, and didn't get what made this new breed so much more notable than what came before. If the point of a GUI is to make your work more efficient, your OS has done half a job no matter what it's like until they give the user the complete power to tailor it to upping the efficiency of your particular workflow quickly, on the fly, and reversibly/harmlessly so everyone can experiment freely. As Alan Kay describes it, when they built the Alto GUI they would do their systems work in the morning, go off to a Palo Alto garden bar and get reasonably drunk at lunch, and come back to build and A/B each other on tens to hundreds of interface modifications and prototypes until close. Later they built a whole 2000 Altos, each costing as much as a car, and a whole networked lab to run them in, to bring in crowds of people and observe how they used the system to make improvements. Not only did it work (MS Office was invented at PARC, the first standard graphics circuit builder and simulator was invented by a teenager on an Alto, half of Adobe's software suite today started as PARC systems, etc.) but it probably can't be done another way. No matter who my vendor is, they have no clue in what particular or peculuar ways I want their OS to enable me to use my hardware, so they can't hope to ensure their GUI is specific enough to enable me without also being too bloated to not get in anyone else's way, just as the user in the OP's video experienced. Far better to build it out of a system that can be efficiently modified and streamlined by everyone efficiently than continue putting everyone in the same Mac box because it's "sleek" and "standard" and "efficient". Completeness beats simplicity, and interface simplicity beats implementation simplicity.

>>40130 The local computer club i frequent got a old lisp machine (a symbolics (i think)), however its missing its keyboard. Thinking of giving reversing it a try. Not sure if there is schematics on the net or not tho, and i dont remember the model, but i can ask in our IRC.

>>40287 amazing. gotta rebuild it in the future sometime. historical accidents and losses due to them are so outraging to me