6 ms·
Malleable computing, Emacs, and you
- sroerick 2mo agoThis 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 stuff. Being able to design a program specifically for the workflow I want is pretty neat. There's some vibeslop jank, but Emacs is a little bit jank too.
- dharmatech 2mo agoThis sounds so cool! Do you have this shared somewhere?
- sroerick 2mo agohttps://pricklypear.rocks/ https://pricklypear.rocks/ Thank you for checking it out! Fair warning, it's vibeslop and I really don't have a clue what I'm doing. I have very little background in compilers or FP or really anything. I'm honestly just shocked at how well it works. If you want to kick the tires on it or even if you just find it interesting, please feel free to reach out! I'm kind of obsessed with this thing now, and would love and appreciate any feedback
- __d 2mo agoThere’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.
- miki123211 2mo agoAnother 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.
- jolmg 2mo ago> Another approach to this is "build mechanism, not policy" (also of Unix philosophy fame). Might be more recognized from the X Window System design principles rather: > Provide mechanism rather than policy. In particular, place user interface policy in the clients' hands. https://en.wikipedia.org/wiki/X_Window_System_protocols_and_architecture#Design_principles https://en.wikipedia.org/wiki/X_Window_System_protocols_and_... It wasn't part of the original Unix philosophy, but I see that went through several revisions.
- gritzko 2mo agoJavaScript did this for the Web back in the day. I work on a malleable git-compatible SCM right now. First I put all the performance-critical parts into a native lib, then happily built my own git(hub) in JavaScript. Tastes differ, someone else may build it completely differently. I believe this is the right architecture for the LLM age. https://github.com/gritzko/beagle https://github.com/gritzko/beagle
- NetOpWibby 2mo agoI love the look of the status output.
- gritzko 2mo agoThanks! It is mathematically rigorous https://replicated.live/blog/status https://replicated.live/blog/status
- cfiggers 2mo agoAutoHotkey adds a malleable computing layer to Windows.
- paulryanrogers 2mo agoMeh, it's better than nothing. Though not a great interface or DSL.
- cfiggers 2mo ago2.0 fixes a ton of stuff over 1.0, but yeah you're not wrong. Between custom keybinds, hot strings, and pop-up menus I have literally hundreds of tiny AHK scripts running 24/7. I'm pretty sure there's stuff I've literally forgotten is an AHK vs an actual part of Windows. It's all just ingrained in my muscle memory at this point.
- miki123211 2mo agoHammerspoon (Mac) is much better. It's basically Lua, with access to all the MacOS automation APIs.
- maleldil 2mo agoHammerspoon is amazing, and LLMs are very good at writing configuration for it. I'm quite happy with my config.
- kickingvegas 2mo agoOP here. Happy to answer any questions about my post in this thread.
- tgbugs 2mo agoDid you look into the existing org-sync package? I know the use case is slightly different but I think it still works.
- kickingvegas 2mo agoWasn't aware of org-sync until now. That said for my use case I still would not use it as I didn't want to setup another GH authentication token for another client. YMMV.
- tgbugs 2mo agoDefinitely understandable, the proliferation of api creds and ways of passing them in is a major pain point.
- AloysB 2mo agoGreat article, TIL vtable. Amazing how much value you got with 400 LoC (even though it's relying on multiple libraries).
- kickingvegas 2mo agoSeeing how much functionality I could get from just 400 LoC was one of the motivations for writing this post.
- CharlesW 2mo agoOut 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?
- 4b11b4 2mo agoI love emacs
- pjmlp 2mo agoYet another one rediscovers the way Lisp machines, Smalltalk, Cedar and Oberon were envisioned, and we never really got it in mainstream computing. Nice article.
- kickingvegas 2mo agoNGL, 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.
- Barrin92 2mo agoI 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/ https://free.oberon.org/en/ think it was on the frontpage recently), how did we go back to dead text files again? I always have to think the "the world if" meme when I think about what would have happened if the whole Engelbart, Licklider, Alan Kay school of thought had won out
- scroot 2mo ago> 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)
- beepbooptheory 2mo agoThis is nice but not even a mention of the rather robust existing solution here with Magit Forge? https://github.com/magit/forge https://github.com/magit/forge
- jake_and_fatman 2mo agoUseless without local/remote sync. Also kind of obvious is the preferability of composeable UNIX programs over heavily locked down monoliths, hardly calling for a Fred Brooks style exegesis.
- frumiousirc 2mo ago> For Markdown to Org translation, Pandoc will be used. Hmm, pandoc? Surely.... M-x org-import-<TAB> Damn, why does this family of functions not yet exist?
- WillAdams 2mo agoThis sort of thing is why the terminal commands pbpaste and pbcopy in NeXTstep/Mac OS X as well as Services are so powerful. That said, I wonder what the successor to emacs looks like (or what the next generation of it will improve).
- mark_l_watson 2mo agoGreat 'scratch my own itch' story and I like the framing of Emacs and Elisp as Malleable Software.
- jacobfromrough 2mo agoI'm preparing a talk on malleable software for a product management audience, and I've noticed just how hard of a concept it is to grasp outside of engineering. Us engineers are used to the tools we use being flexible. It's only as we need tooling to be palatable to other audiences they become more constrained. For non technical people, malleable may as well mean complicated. We're going to see this change, but breaking this concept out of engineering is an uphill battle.