4 ms·
Every time I see something like this, I'm also reminded of this demo of the Xerox Alto from a few years back. I'll link to the start of the most relevant piece:
by ryukafalz 4y ago
Every time I see something like this, I'm also reminded of this demo of the Xerox Alto from a few years back. I'll link to the start of the most relevant piece: https://youtu.be/AnrlSqtpOkw?t=549 https://youtu.be/AnrlSqtpOkw?t=549
I'm always struck by the useful directions that desktop computers were going in the 70s, and how computing could be so much better than it is right now. But we've veered so off-course from all of this, away from composability and towards independent boxes ("applications") that can't talk to each other at all.
Emacs is in some ways the best thing we have today in the other direction, but it pales in comparison to what's possible.
- vfclists 4y agoWhat Emacs users want is a version of Smalltalk with a superior keyboard driven experience, featuring which-key et al. > I'm always struck by the useful directions that desktop computers were going in the 70s, and how computing could be so much better than it is right now. But we've veered so off-course from all of this, away from composability and towards independent boxes ("applications") that can't talk to each other at all. This is the consequence of deliberate corporate agendas, but many people are still in denial of that. The worse thing that happened to this kind of computing was the policy of forcing everything through the web interface, which was deliberately crippled to let the industry majors to get a heads up in browser based software.
- msla 4y ago> What Emacs users want is a version of Smalltalk with a superior keyboard driven experience, featuring which-key et al. No, more like Interlisp, which is kinda like Smalltalk in terms of being an active environment, only without having to deal with... you know... Smalltalk in order to use it. Plus, there's something to be said for a plan that's probably now mostly forgotten, to re-write Emacs to use Guile as its language and compile other languages to Guile so programmers could extend it in any of multiple languages and they'd all interoperate. The target language doesn't have to be Guile, of course; the modern conception would likely involve WASM and/or LLVM bitcode. https://www.emacswiki.org/emacs/GuileEmacs https://www.emacswiki.org/emacs/GuileEmacs
- snamellit 4y agoInterestingly TJ Devries just did something like that for neovim. He made a transpiler from vim9script to Lua to allow compatibility. I found that around neovim there is a similar crafting vibe you find around Emacs.
- vfclists 4y agoAnd they've got Fennel and some Fennel based frameworks to enable them to configure the Vim settings in a Lisp.
- abudabi123 4y ago> Emacs is in some ways the best thing we > have today in the other direction, but > it pales in comparison to what's > possible. Imagine joining Blender, sensors, actuators, voice assist, Ai, lisp, Emacs. If a project could attract the backers Blender is getting to explore and document design possibilites for Emacs that's a move in a better direction.
- ykonstant 4y agoYes, yes, yes and yes. I am glad to see this sentiment expressed here!
- agumonkey 4y agoI wonder if the sidefx houdini guys knew about smalltalk and if kay and his team ever saw houdini. The universal connecting data is very similar (and one of the most pleasurable thing ever)
- jll29 4y agoVery true. From one vantage point, things look like this: 1970s: The Visionaries - showing us how the future (of desktop computing) can look like. 2023: pre-1970s state stuff has become pervasive, runs faster and is cheaper, but not nearly at the level of sophistication that the 1970s had. (State of the art is still free clones of Unix, a 1960s OS.) So where is the course correction? And where are the 2023 ideas that as look far into the future from today as the J.C.R. Lickliders, D. Engelbarts, T. Nelson and A. Kays of the day? (Thankfully, in some areas, things look better - e.g. mobile phones, robotics, machine learning applications etc., so the point here is only valid about destop HCI progress.)