More people should definitely try out sam and 9term as examples of how much code/features you don't really need and can still get real work done.
Personally, I wish sam had even less complexity and features than it currently does and thus be more understandable and hackable. Also, never going back to a normal terminal again, "dumb" terminals are awesome.
And actually, this experience has lead to a philosophy of software where I think the "dumb"er a piece of software the better and more reliable/performant it is likely to be. So I'm also hugely skeptical of the current Deep AI efforts leading to anywhere good.
Just jumping off your last sentence: "Simplicity" and "Transparency" are orthogonal.
In the case of deep learning, all current state-of-the-art models can be expressed as nothing more than matrix multiplication, addition, and clipping. That's all you need. It's so simple: multiply, add, clip. Multiply, add, clip.
But the model isn't transparent. It's clear what each step is doing (multiply! add! clip!), but it's not clear to the human why that's necessary.
I've never tried sam, but I used to do all my unix coding in nano, because it was simple enough that I never had to think about how to use it. I prefer simpler tools, generally, since I don't want to think about the tool; I want to think about the work I'm doing with the tool. People do amazing things with emacs, and to a lesser degree also with vi, but I simply don't want to spend the time it would take to learn such a complicated interface when I clearly don't need such a powerful tool to get my job done.
I eventually wrote my own editor, which is effectively just a text-mode window manager wrapped around a simplified nano clone which uses the control key bindings I'm familiar with from non-terminal environments. I'd be reluctant to recommend it to anyone else, since it's such a specific implementation of my own personal taste, and it has a handful of minor problems I've never bothered to fix that might cause someone else significant irritation; but it suits me. It's a very comfortable feeling to know all that can be known about the tool; I never have to waste a moment trying to remember how any of it works, and can direct my full attention through the tool to the work I'm actually trying to do.
A great trivia bit about Sam is that it's the first full screen editor Ken Thompson switched too, and he still uses it today[1]. Ken Thomspon wrote ed (in addition to being the primary original author of Unix).
I agree there are a lot of interesting ideas in 9term/sam/acme and Oberon (which was the initial inspiration for the project). In the future I would like to experiment with integrating a few more, but unfortunately time is a limiting factor.
9term/Unix is still not as lean as something you'd get with a more integrated environment like Oberon or Lisp. Just think of the many ways of parsing arguments and input. Ad-hoc languages wherever you look.
Exactly. When you want to exchange data, it's much preferable to have typed/tagged representations. If not that, then one should strive to at least avoid regex "parsing" everything. The exception is that plumbing is okay because it integrates output from all kinds of programs that already exist, but if you have control, it's a lot better to have short prefixes like, say, bug:BUG123, git:COMMITID, pkg:DISTROPACKAGE, etc. But these short prefixes miss namespacing. Anyway, this is only true for acme and friends and in Oberon elements are rich and not plain text.
Yeah, every programmer at one point has to make her own argument parsing library. Nope, there is no one syntax that fits all use cases.
While there are thousands of ways programs can parse arguments (and that's great!) there is only one argument passing mechanism in Unix (plus environment variables for implicit static things and file descriptors for streams).
Unix doesn't care how you parse your arguments, and that's why it is lean, and why it has been successful as a development platform.
Donald Knuth: "I define UNIX as 30 definitions of regular expressions living under one roof."
Yeah. I've been using Acme for awhile now. While Acme itself is nice, what I really like is the B/E editor embedded in it. It's just a very simple editor that can be extended with _external_ programs.
Finally, I've come to appreciate using a mouse with my editor. Until I completely got rid of using most keyboard shortcuts (other than the most basic ones), I didn't realize how much cognitive taxes I was paying to retain and context-switch among different families of keyboard shortcuts. Mousing is so much more uniform.
They are the utility scripts to start an editor window in Acme. B is async whereas E is sync (so that it can be used for the EDITOR env variable for software like git).
Not sure what they stand for for sure. E is probably editor. B might be buffer?
Personally, I wish sam had even less complexity and features than it currently does and thus be more understandable and hackable. Also, never going back to a normal terminal again, "dumb" terminals are awesome.
And actually, this experience has lead to a philosophy of software where I think the "dumb"er a piece of software the better and more reliable/performant it is likely to be. So I'm also hugely skeptical of the current Deep AI efforts leading to anywhere good.