Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malleable computing, Emacs, and you

yummymelon.com

Post reply on HN
Print view View original

21–30 of 57 posts

Re: Malleable computing, Emacs, and you

#21

Post by scroot »

Barrin92 wrote: post #15
pjmlp wrote: post #8

Yet another one rediscovers the way Lisp machines, Smalltalk, Cedar and Oberon were envisioned, and we never really got it in mainstream computing. Nice article.

I genuinely do wonder why that has been the trajectory. When you look at the almost futuristic vision of interacting with living, programmable software objects and environments that evolve over time and you get a glimpse of it in Emacs, Pharo or Oberon (worth mentioning Free Oberon, fun to play around with https://free.oberon.org/en/ think it was on the frontpage recently), how did we go back to dead text files again…

> I genuinely do wonder why that has been the trajectory.

The simple answer here is still likely the best one: Smalltalk and Lisp Machine systems were expensive and proprietary right at the same time that Unix and C became free (and therefore ran everywhere)

Re: Malleable computing, Emacs, and you

#22

Post by Jtsummers »

Barrin92 wrote: post #15
pjmlp wrote: post #8

Yet another one rediscovers the way Lisp machines, Smalltalk, Cedar and Oberon were envisioned, and we never really got it in mainstream computing. Nice article.

I genuinely do wonder why that has been the trajectory. When you look at the almost futuristic vision of interacting with living, programmable software objects and environments that evolve over time and you get a glimpse of it in Emacs, Pharo or Oberon (worth mentioning Free Oberon, fun to play around with https://free.oberon.org/en/ think it was on the frontpage recently), how did we go back to dead text files again…

> how did we go back to dead text files again?

We never went away from it. It's how a significant amount of computer use has always been. Smalltalk, Oberon, Lisp Machines (mentioned by sibling), they were always minority systems.

There was a brief time when maybe home computers could have leaned this way, but that lasted until VisiCalc. What sold computers was software that turned them from clay to be molded by the user into a defined tool. People prefer appliances (or were convinced to prefer appliances), and appliances make more money for businesses than distributing programs as a Smalltalk package would have.

Re: Malleable computing, Emacs, and you

#23

Post by pjmlp »

scroot wrote: post #21
Barrin92 wrote: post #15

Earlier quoted context omitted.

I genuinely do wonder why that has been the trajectory. When you look at the almost futuristic vision of interacting with living, programmable software objects and environments that evolve over time and you get a glimpse of it in Emacs, Pharo or Oberon (worth mentioning Free Oberon, fun to play around with https://free.oberon.org/en/ think it was on the frontpage recently), how did we go back to dead text files again…

> I genuinely do wonder why that has been the trajectory. The simple answer here is still likely the best one: Smalltalk and Lisp Machine systems were expensive and proprietary right at the same time that Unix and C became free (and therefore ran everywhere)

Yes, and porting them on top of UNIX wasn't the same thing, while still being commercial.

Even with commercial UNIXes, it was extra on top of standard UNIX developer SKU.

Same with Ada, by the way.

Re: Malleable computing, Emacs, and you

#24

Post by kickingvegas »

CharlesW wrote: post #16
kickingvegas wrote: post #6

OP here. Happy to answer any questions about my post in this thread.

Out of curiosity, are you now or have you ever been a "Mac person"? I'm curious if you've ever gone down the rabbit hole on Apple's history of technologies for what I think you'd call "malleable computing" at the OS level, like Open Scripting Architecture/AppleScript and now App Intents?

Short answer, yes I am a Mac guy. AFAIK, both AppleScript and Shortcuts/Intents are mechanisms Apple has provided to support orchestration between apps. I do not consider them “malleable computing” mechanisms as they do not allow for adapting and reshaping the apps themselves. That said, AppleScript and Shortcuts are only as useful as the support given to them by 3rd party apps, which IMHO has always been mid.

Re: Malleable computing, Emacs, and you

#25

Post by kickingvegas »

AloysB wrote: post #14
kickingvegas wrote: post #6

OP here. Happy to answer any questions about my post in this thread.

Great article, TIL vtable. Amazing how much value you got with 400 LoC (even though it's relying on multiple libraries).

Seeing how much functionality I could get from just 400 LoC was one of the motivations for writing this post.

Re: Malleable computing, Emacs, and you

#26

Post by dharmatech »

sroerick wrote: post #2

This is a good discussion of these principles. Largely inspired by Emacs, I built an interpreted lisp which runs in a web server and stores the AST Postgres. It gives me this kind of malleable computing and a Lispy feel with very little overhead. Instead of calling an API, agents can just use functions in a REPL. They can also write new views and improve the program if they run into an issue. Honestly, pretty amazing…

This sounds so cool! Do you have this shared somewhere?

Re: Malleable computing, Emacs, and you

#27

Post by miki123211 »

__d wrote: post #3

There’s an interesting middle ground: not fully malleable software, where the end user has full customisation ability but requires full programming skill, but eg the Unix tool model where prebuilt utilities can be composed with a simple syntax. Pre-existing (or importable) ELisp functions are kinda similar, just a slightly higher level of user skill.

Another approach to this is "build mechanism, not policy" (also of Unix philosophy fame).

Encapsulate the hard parts in libraries, ship the topmost layer as codegen templates that depend on those libraries, and let agents / devs modify that topmost layer to their heart's content. This often beats putting everything in libraries and having to expose customization points everywhere.

This is the approach taken by the Shadcn UI library (which became popular just as agents entered the scene), but it generalizes far beyond UI.

Re: Malleable computing, Emacs, and you

#28

Post by miki123211 »

paulryanrogers wrote: post #9
cfiggers wrote: post #5

AutoHotkey adds a malleable computing layer to Windows.

Meh, it's better than nothing. Though not a great interface or DSL.

Hammerspoon (Mac) is much better. It's basically Lua, with access to all the MacOS automation APIs.

Re: Malleable computing, Emacs, and you

#29

Post by miki123211 »

Barrin92 wrote: post #15
pjmlp wrote: post #8

Yet another one rediscovers the way Lisp machines, Smalltalk, Cedar and Oberon were envisioned, and we never really got it in mainstream computing. Nice article.

I genuinely do wonder why that has been the trajectory. When you look at the almost futuristic vision of interacting with living, programmable software objects and environments that evolve over time and you get a glimpse of it in Emacs, Pharo or Oberon (worth mentioning Free Oberon, fun to play around with https://free.oberon.org/en/ think it was on the frontpage recently), how did we go back to dead text files again…

The Smalltalk approach doesn't really integrate well with anything else.

If you treat data and code the same, it's hard to separate code from data. If you're writing a program for a single machine on which it should be used, that's fine, but if you want to write your code once and run it across many machines, that's a problem.

ERP systems are a bit like this; system owners (businesses) are often able to change any part of the system they want. Predictably, this makes version upgrades an incredible pain and often locks companies into an unsupported proprietary fork of a 20-year-old version of their CRM.

Re: Malleable computing, Emacs, and you

#30

Post by pjmlp »

kickingvegas wrote: post #10
pjmlp wrote: post #8

Yet another one rediscovers the way Lisp machines, Smalltalk, Cedar and Oberon were envisioned, and we never really got it in mainstream computing. Nice article.

NGL, whenever I work with Cocoa APIs, I wistfully think of another timeline where we get a system-level SmallTalk style REPL and ecosystem accessing all of it.

In a way this is what Powershell offers in Windows.

On Mac using something like PyObjC, maybe coupled with Xonsh, could do the trick.

Post reply on HN