The insane amount of introspection available to you in a Smalltalk image, and the way every bit of text becomes a potential button or action in Acme just put the lack of creativity in modern interfaces. I say all this as a Haskell and Nix fan as well, so I'm very in-tune to the benefits of functional purity and reproducibility in a computing system. It really makes the silo-ed world of isolated microservices, containers, and walled "garden" ecosystems seem really sad.
I guess this is my way of saying, that we should all try to do things differently. Haskellers, go learn Smalltalk. It's not a big deal that things mutate things when you can literally inspect every object as its running, including the debugger :D. Smalltalkers (or Rubyists or whatever is closest) go learn Haskell. Sometimes boundaries are GOOD. Formality can be very helpful when it comes to organizing, designing, and reasoning about your stuff!
And we should all try to do something weird.
Rob Pike’s comment about this is very interesting too:
Through the 1970s and 1980s, there was a continuous invention in how graphics, computing, and software interacted. With the dominance of the PC and the VGA card, we now have a largely fixed architecture for graphics in personal computers. There is some playing around with the software model, but basically we have a powerful, privately managed external "card" that does the graphics, and we talk to it with one particular mechanism. During my work on Plan 9, it got harder over time to try new things because the list of ways to talk to the card was shrinking, and other than the blessed ones, slower and slower.
For example, a shared-memory frame buffer, which I interpret as the mechanism that started this conversation, is now a historical artifact. Back when, it was a thing to play with.
As observed by many others, there is far more grunt today in the graphics card than the CPU, which in Sutherland's timeline would mean it was time to push that power back to the CPU. But no.
Not a value judgement, just an observation. The wheel has stopped turning, mostly.
Unfortunately VGA as we know it is dead and now, to render the blinking cursor, they render the whole screen surface in a compositor.
What sort of "weird" do you think would be fun?
( https://www.youtube.com/watch?v=Dt3q7Z7RjIU 4min54sec)
Which begat https://dl.acm.org/doi/10.1145/1166253.1166301 from the same institution. ( https://www.youtube.com/watch?v=kUUtiOWTzz4 7min20sec)
Married with something like https://arcan-fe.com/about/
With some https://en.wikipedia.org/wiki/Zooming_user_interface sprinkled in,
not necessarily in the 'style' of https://eaglemode.sourceforge.net/ but the concept.
Rounded with something like https://en.wikipedia.org/wiki/OpenQwaq , or https://en.wikipedia.org/wiki/Open_Cobalt
OFC fully themable like GTK before they broke it, or something like https://github.com/KDE/qtcurve which is endlessly modifiable.
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  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 .
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
But I totally agree with you on the "do something weird" approach to learning and gaining inspiration. Some problems that are hard in some spaces are extremely easy to deal with in others.
I actually do use acme on 9front for a lot of coding tasks in conjunction with sshnet (imagine importing a remote system's network accessibility over ssh - like a lightweight VPN-almost sorta) and sshfs through that sshnet "tunnel".
This gives me a nice code, compile, test cycle that has some "editing" commands that let me jump straight to where failures occur with a single click.
And Acme knows nothing about what it's doing... it simply follows its own basic rules, and the file system underneath is arranged to enable my workflow.
And yea, Acme is different, but Sam is weird. In a good way though. I never really tried to get the hang of it, but Sam does live on in some ways (Vim Ex commands and such).
I'm also not surprised that a 9front user thinks it's a good idea to be weird. Just look at your webpage and this very bizarre thing that is for some reason linked one click away on the side menu: http://9front.org/movies/
As a big fan of keyboard-only use of vim and emacs, this made acme a complete non-starter for me.
Writing a plug-in is actually completely language agnostic. It’s just standard file IO.
Any time you middle click the name of a script, it executes that file by looking it up in a PATH equivalent (pretty sure it’s also project local as well, but I don’t remember).
This is really powerful for two reasons: everything’s an editable text field from your menu bar, your window bar, and the buttons on them; and chorded selections, basically you can send a selection to a command by selecting and then clicking on another piece of text to determine the command.
This allows you to create a UI tailored to whatever you’re doing as you’re doing it. If you watch someone program with Acme, they’re writing little snippets in their status bar to do common tasks, or for more involved things, they’re just creating a new buffer and typing or cut and pasting some relevant code they need to search different parts of (because searching is just one mouse click away). The best part is, you can just save and load that buffer for later. It’s just a plain text file.
It’s definitely a change up from the keyboard-driven focus we’ve come to see, but again, I think we gave up on the mouse way too quickly. If you’re really honest with yourself, I think you’ll find you aren’t constantly clipping around at 1,000 key presses per minute in Vim. You’re spurty, you sit and think, and then you type. Once I started thinking about hands on mouse time as thinking time, then it wasn’t nearly so unacceptable. I even came to prefer it (gasp).
 Sorry I couldn’t resist referencing the classic Vim/Vi write up.
It's the first thing many plan 9 users run after they experience their first grey Rio screen and figure out how to draw a window. It also demonstrates the power of the file system based interface and how a program can expose its internal functionality via files to external programs to build a symbiotic environment. But most will find it cumbersome or obtuse to use after a while. Another major gripe is that it cant do graphics in its windows which is kid of seen as a break in the design from being a graphics first OS.
Personally I always felt it's the equivalent of the Explorer shell for Plan 9. My gripe with it is it becomes obtuse to use after you start to open a lot of windows and everything is boxed into corners and centering the window is frustrating. So most plan 9 users who actually write code use Sam. Another trick is windows in Rio are just text buffers so people open windows to use as scratch pads and then copy/paste between them and Sam.
Then there's hold mode, the ultimate text editor. You hit escape while in a window and it turns blue indicating hold mode. While in hold mode rc or whatever is running will not receive anything you type into the window buffer via stdin as it's being held back in the buffer. So type as many lines of rc script or w/e, edit, then to run just hit escape and the text is processed. I do this all the time writing simple rc scripts. Then just echo 'blah...' >$home/bin/rc/bla and chmod +x bla when done.
It’s probably not fair to say that we’ve lost a capacity or appreciation for creativity and novel ideas. In sheer volume, there are probably more people doing XeroxPARC level crazy stuff now than then. It just feels like way more investments are made to copy the thing someone else is doing but tweak it slightly than on truly large moonshots.
Part of this is probably the homogenization cause by mass, instant communication, and not forcing you to wonder, how did they do that, and how would I do it differently. It’s a double edged sword though. Hell, I feel like part of the reason some of this stuff didn’t catch fire and spread was because of the limited ability to share and talk with people too.
I don’t know what the right answer is. I just want more cool shit.
I'm not sure about that. From the Computer History Museum's 50th anniversary event of the Alto two days ago, each Alto cost about 18k in early 1970s dollars (about 100k today). And they built hundreds of them. Not sure anyone has the budget to do the level of crazy work that would require the equivalent amount of future computer power today.
The point I was making is that doing the equivalent level of 'crazy' work (for it was crazy, the idea of giving everyone the equivalent of a personal pdp-11 in those days) requires equivalent levels of funding. It's just that most people can't imagine what could be computed on a $100k equivalent of computing today.
For all of us who grew up in the days of personal computing, it's hard to imagine that what they accomplished as being crazy.
In Oberon, you can select any piece of text and apply a command on it.
Commands are public procedures in dynamic modules, so Module.Command will load it if not already loaded, and then execute command.
There are a couple of ways to write commands, depending if the act on selected widgets, selected text, selected windows, or if they ask for additional input.
For trying out it emulated on the browser,
And how the latest iteration of it, Bluebottle (AOS) with Active Oberon, looks like
One of the great things about PowerShell and Windows, is that despite all the warts it has, it allows exactly a similar kind of workflow, with .NET, DLLs and COM replacing that Module.Command experience.
GNOME and KDE can offer similar workflows, alongside DBUS, and fish shell, however people seem more keen in keeping the UNIX experience of yore instead of going down that route.
It's a big world out there and there's so many cool techniques we know are helpful but aren't widespread and really should be, and so much more to be discovered still!
> Plan 9 from Bell Labs is a research system developed at Bell Labs starting in the late 1980s. Its original designers and authors were Ken Thompson, Rob Pike, Dave Presotto, and Phil Winterbottom. They were joined by many others as development continued throughout the 1990s to the present.
Rob Pike opens with:
> Looking around at some UTF-8 background, I see the same incorrect story being repeated over and over. The incorrect version is:
1. IBM designed UTF-8.
2. Plan 9 implemented it.
> That's not true. UTF-8 was designed, in front of my eyes, on a placemat in a New Jersey diner one night in September or so 1992.
> The name Plan 9 from Bell Labs is a reference to the Ed Wood 1957 cult science fiction Z-movie Plan 9 from Outer Space. The system continues to be used and developed by operating system researchers and hobbyists.
Apparently plan 9 is specifically the space people's plan to resurrect the recently dead humans on Earth by shocking their pituitary glands.
Plan 9 from User Space (aka plan9port) - https://news.ycombinator.com/item?id=3064180 - Oct 2011 (2 comments)
Plan 9 from User Space - https://news.ycombinator.com/item?id=2125731 - Jan 2011 (6 comments)
Plan 9 from User Space - https://news.ycombinator.com/item?id=1266168 - April 2010 (6 comments)
These days I use goland and vim, and I feel much more productive.. I still write crazy amounts of small tools and scripts to solve little problems though, and my .profile has like 200 alias's, so I guess some of it bled over..
I personally find the lack of highlighting and auto-delimiters is a PITA for HTML/LaTeX though.
𝕚𝕟𝕥 𝗺𝗮𝗶𝗻⦅𝑣𝑜𝑖𝑑⦆ ⦃ ⦄
Sadly, I have not used acme. Wouldn't this deficiency be simple to overcome with scripting? I guess that's one particular area where emacs, being essentially a specialized LISP interpreter, encourages you to think about these things by default.
The fact you can create your own "buttons" that do basically anything is pretty nice, but you REALLY want a 3 button pointing device to use it. It also doesn't care about the programming language you use to create such a button, but you will work with the filesystem metaphor provided by Acme itself to get things done.
I find the mouse interface is extremely fast, and when you couple it with the power of the plumber in Plan 9, it's a reasonably good way to navigate around a complex workflow.
It's also a reasonably small environment in terms of lines of code. The Go version (Edwood) is pretty good too! https://github.com/rjkroege/edwood
You only have 4 bindings, You have at least 50 keys in your keyboard with 3 modkeys, That's a lot of combinations to do anything you wish for. Sure, use the mouse more, but to expect to not use standard keybindngs or adding any? It has to be a joke.
You can't even press the down key to go to the line below!
Most of keybindings you might want to add are handled by Acme's "commands" - like Edit. If you repeat them any often, it's easy and straightforward to connect the keybinding to the command in code. Alternatively, to avoid going into C, write a shell script with ready-made command; Acme is well prepared to be managed through shell scripts. The shell scripts have full access to Acme's Windows (open files, directories, scratchpads etc), including ability to edit content, open new ones, interpret right-clicks in new ways, etc.