I have watched a number of demos of Acme and I have two general takeaways. The idea of adding “buttons” (so to speak) to the toolbar by just writing text seems incredibly cool, and I doubt I would ever enjoy actually using Acme.
Like a lot of people, I went through an EMacs/Vim phase. Then went SublimeText, and now I live happily in VSCode. I feel very uncool to say it, but I just work really quickly with VSCode and I think it’s more because of a thousand micro-optimized UX choices by Microsoft rather than a particularly elegant core design, which is how I’d characterize Acme based on those demo videos. This is sadly how I feel about a lot of software these days.
I used acme as my main text editor for a few years and a lot of what you say resonates with me. The biggest problem I had with amce wasn't the editor itself but the lack of easy to use integrations.
Acme integrates well with external programs. This is really nice, but I don't want to spend the time writing all of my own integrations. Maybe I can justify that effort if I work in one codebase for a long time, but I've bounced around and haven't thought the investment would be worthwhile.
Compare with vscode: actively developed and you just click some buttons to get all the integrations. Just so much less friction.
If acme had an active community around it the situation may be different. But that's just not the case.
This is an important point: not only the Acme community doesn't want to implement features, they also don't want to share the way things can be automated. This article is a good example: the author spends 90% of the time explaining why things shouldn't be done, instead of explaining how exactly he does it. This is not a great way to create a community.
I'm against VSCode because it's a Microsoft product. I've been working on kernels for several decades and I remember when they tried to kill Linux and ran an entire ad campaign around it. Their entire embrace, extend, extinguish is still alive, and they're only embracing OSS because they lost their end user device battle (because their OS is trash) and had to pivot to cloud where people were already embracing OSS. WSL, running my editor in the cloud and paying for a subscription, having Microsoft control your editor, it's all clearly a dystopia for developers that leads to lock in, paying for things that should be free, and an invasion of privacy that should be avoided at all cost.
There are so many editors to choose from. I get that not everyone wants invest in Vim/Emacs, even though you should and it will pay off, and the vast majority of the programmers that are doing great things are using Vim/Emacs (seriously, I have a list of big names and except for some rare exceptions like James Gosling who apparently uses Netbeans, EVERYONE noteworthy uses Vim/Emacs), and it's OSS, and in Vim's case it's also helping a charity. But if you are the person who just can't get there with Vim/Emacs, at least don't give yourself over to Microsoft. Use Sublime, Nova, BB, etc. They're all great editors by small companies making cool stuff and they'll get way more out of your support than Microsoft.
It would be cool to have a wiki page of who uses what.
Torvalds uses MicroEmacs, but I don't know what Poettering, Taymans, Realthunder, Bellard(I assume he knows a CLI editor though) are up to. No clue what the devs of Obsidian use. Lots of LibreOffice devs seem to use VS Code.
And of course, in the JS ecosystem IDEs seem pretty common.
Van Rossum uses Vim it seems. But mostly all the devs I respect most don't seem to talk a lot about editor choice. I guess most of them are probably on a CLI editor but ALL? There's gotta be a few that are on IDEs, right?
What do the Red Hat people use?
Also Sublime/Nova/BB seem to be for Mac and not free.
VSCode being free as in beer is a pretty big draw. There isn't all that many alternatives to VS Code that have that level of features unless you want to do some real setup work, and have another customized suite in your life to maintain.
> I'm against VSCode because it's a Microsoft product.
Note that there is also VSCodium [1], an OSS fork of VSCode with the M$ telemetry removed. I'm a heavy vim user but for cross-platform development with .NET SDK or Node.js VSCodium has pretty good support with the huge number of available extensions. If I want to tweak the editor's behavior, it's not harder, or even easier, than with vim. I find writing an extension for VSCodium in JS more approachable than doing the equivalent with vimscript.
I get the anti-corporate opinion. I don’t think it totally fits here because VSCode is FOSS, and it offers them a very limited moat; if they tried to push something weird then you can bet on a fork or the myriad of alternatives in the saturated editor market. I work against aggregated market power for my day job, but this isn’t a case that needs fighting IMO.
As for the appeal to true hackerdom, I guess I’ll just hope I’m in the minority of great-thing-doers.
>VSCode is FOSS
not really, the Microsoft extension store/repository is the only practical way to install extensions, and the totally open-source fork (VSCodium) is literally unable to install a lot of fairly key extensions because MS is apparently alright with open-sourcing the editor but not the tools they build for it.
regardless, I do not want to have to disable telemetry in my text editor -- the idea that it exists in the first place is frankly baffling.
I want to make a big stand about Microsoft and free software and tracking and whatnot, but I can't here. I break those rules at work all the time during time crunches.
It's kinda petty, but the bits of screen real estate it steals around the sides of the screen are too distracting for me after having gone full vim for a while. You can hide most of it, but the activity bar keeps showing back up after doing something like opening the git/file explorer/etc panes.
The IntelliJ line is a bit better, you can hide everything pretty easy, but I don't always have a corporate license for those, so I tend to avoid depending on them.
It's crazt to see how heavily the FOSS community focuses on first principles thinking.
Microsoft really understood, and still does, understand the value of the other kind of design, based on common task patterns and human factors rather than naturally flowing from some core philosophy.
Elegant software always requires you to learn to adapt not only the task but your thinking to the tools, and you're pretty much on your own to design a workflow, Microsoft style design tries to give you an obvious way to do the common stuff, even if it's inelegant and hackish and has no basis in any logic, it's reliable and widely known and easy.
I think there's a selection effect there too - or equivalently, maybe the causation goes the other direction.
If you tend to think in terms of first principles, you're more likely to have boarded the FOSS bandwagon in the first place. If you think in terms of tasks and practicality, you're more likely to have chosen to work for Microsoft. Each ecosystem reflects the principles of those who join them.
Oh wow. I really don’t relate to the “mouse + keyboard together is annoying, therefore I choose more mouse” reaction.
Since we have to type to code anyway, my pick is keyboard only, and since I don’t want RSI, I switched from emacs to vim 20 years ago or so, and I’ve been mostly happy ever since.
I do really love the idea of super simple bindings out to shell scripts in acme, that’s not … super simple in vim, but other than that this post filled me with a mix of consternation and revulsion; I guess like he mentions upfront, acme isn’t for everyone :)
Is it just me or does the way the lack of features is used as a feature here seem like the 'your holding it wrong excuse'. Just from this essay and never having used Acme, I wonder what advantage the has over other minimalist text editors. I mean if lack of features is the feature why not just use ed.
There's something to that criticism, but plan9 was also built for improved modularity and compositionality when compared to earlier Unix. Some features that are not included in Acme may be achieved simply by leveraging outside code.
Acme was (is?) built by the same people who built Go, and a lot of the same complaints about this way of thinking are heard about Go.
Simplicity as a design goal means that there are trade-offs. YAGNI is one of those trade-offs: "yes we could probably add that feature, but it would make things complicated and we don't think the additional complexity is worth it for this feature".
I'm a huge fan of this approach. Mostly because in a majority of cases, YAGNI was true: by thinking more about the problem I needed less language features (as the article says).
I'm curious about ACME. I'm annoyed with VSCode (getting too slow), and IntelliJ/Goland feels too Java-y. Vim is fantastic but corrupts my muscle memory, and I can't get past the tutorial for Emacs.
IMVHO too many fails to comprehend what "editor" means. Now it means just "something to edit text", in the past means "human-computer interface".
ACME is modern respect of Tioga (Xerox) or Emacs, but it's still a classic editor, or the human-computer interface. Plan 9 while address many unix shortcoming it's still the successors of unix so it's still shell-centered and ACME was/is it's tentative to came back to classic OSes, so editors, models, while retaining unix "cheapness" and "raw simplicity".
I think at Bell Labs someone have thought that "perhaps we still find a way to a non crappy and archaic OS, while satisfy big business needs against the users" so something that was a desktop but still networked in a way that push toward modern data centers/cloud model. That's because re-reading IT history since original Xerox desktops almost all the industry seems to have do it's best do deprive end users of control on their own systems to shift it toward some vendors. All we have today was essentially designed back then, and changed to be proprietary and centralized from emails (now essentially webmails and proprietary chat platforms) to modern "recommendations engines" vs classic user-local scoring tools.
Editors was the biggest and more evident change: from desktop UIs to mere text-writing tools. After a certain amount of time big and narcissist IDEs arrive, explode and then people tired by their bloat want again "classic editors" without even really knowing them, so arrive the era of Sublime, VS Code etc, notebook UIs (like Jupyter) etc perhaps in another decade or two we will unveil the new shiny and powerful editor, witch happen to be a copycat of old Tioga and co...
> When one talks about software, it’s common to start by listing out a program’s features. When it comes to acme, however, it’s perhaps more appropriate to start by talking about what features it does not include.
I think this assumes you do have an idea of the program you're building already, which means you already have idea of it's shape and featureset. I agree with the premise but I think you can't realistically start at "What don't we do". You still need to know what roughly you're building so you know what to take away.
I wrote my PhD thesis using acme. Both text (markdown+latex) and code. It was a really nice experience because you really feel like the environment is yours. If I needed to automate anything all I had to do was to write a script in any language - because the virtual file system interface is accessible to all and does not discriminate.
Most often a simple shell script would suffice.
In most other editors writing a plug-in is a more cumbersome endeavour.
I don’t buy the thing about syntax highlighting. Even if I did think turning it off made me write better code — I do not — I still have to work with code that I have no control over.
I agree about tabs and proportional fonts, but I think those are lost causes.
Maybe we should. We already have Grammarly for linting of prose. Throw in syntax highlighting, auto-complete. If you want to get really creative find a way to identify the relevant proper noun when you hover the mouse over a pronoun.
I don't really "buy" the reasoning[1] behind "no syntax highlighting" either, BUT I turned off syntax highlighting (in vim/neovim in my case) about 5 years ago (that was ~15 years into programming full time) and haven't looked back. I just don't miss it at all. At first I wanted to see what it was like to not have syntax highlighting because I realized I had never questioned the need for it. I found out I really liked not having it! I can't put my finger on why exactly, and this is the first time I think I've ever written a single word on the subject (ie, I'm not trying to convince anyone else to try it).
But I also use "light mode" (white background, black text) in my terminal, editor, etc, so... take all this however you will :)
(In reference to the topic at hand, I've tried seriously using acme, and although its "elegance" is attractive, I wasn't able to make it stick. I'll still open it or sam up every once in a while, and vis (https://git.sr.ht/~martanne/vis) is an editor I always have in the back of my mind to try to use more.)
[1]: The reasons against syntax highlighting in the article seem to be 1. it hides ugly code, 2. it's possible to waste a lot of time on configuring your colorscheme, 3. (not in the article, but) the old "do you syntax highlight prose? I didn't think so". I don't find 1 or 3 to be convincing, and wasting time on a colorscheme... whether it's a "waste" or not depends on your own preferences and circumstances.
The way ACME UI works, it is how the whole Oberon OS works, selecting text elements with mouse chords and executing commands if they happen to match Module.Command pattern.
The less is more philosophy isn't new, in fact, it's rooted in some of the world's oldest philosophies, religions, art, etc. It's not something that engineers grasp easily. Engineers see the world in terms of features, and features that increase convenience as a net good. But convenience is often bartered against critical thinking, and that's why conveniences in editing code like syntax highlighting, autocomplete, may not be the clear wins they are assumed to be.
I use acme as a personal wiki where I can store useful playbooks (executables from there). From sqls to kubectl commands. Just a big wiki with the unix at the mouse.
ACME is a really cool editor and it's approach to the Unix philosophy is something I wish would have caught on in other TUIs/GUIs.
That said, the real takeaway from ACME is you don't need an IDE to be a noteworthy programmer. In fact my list of noteworthy programmers (currently has a little over 100 devs on it), which includes Linux kernel devs, GNU devs, Bell Lab devs, programming language author devs, compiler devs, other people who wrote famous software, etc. contains 99% Vim/Emacs users. And no, it's not just people from an older generation, the list contains plenty of up and comers and even teenagers and college students who are already doing great things.
Clearly more features, smarter IDEs, etc. isn't the deciding factor in doing great things. I think what ACME really teaches us is that by taking a less is more approach, we can train ourselves to understand code at a deeper level by paying more attention and taking our time, and giving us the creative freedom to compose code in any way we choose.
On my list of noteworthy programmers is John Carmack, who has praised Microsoft's Visual Studio and other tooling for offering the best development experience, especially for game dev. No amount of faffing about with Emacs, compilers, and command line tools will give you the equivalent of DirectX GPU debugging.
Also on my list is Dan Ingalls, who implemented much of what could be considered the primordial IDE -- Xerox PARC's Smalltalk system.
You're right in that IDEs are not what enable great code. But they do make writing great code (or terrible code) faster and easier.
I've been using Acme exclusivly for almost 6 years now. I consider it
to be the only true GUI text editor that has been developed, and the
only non-trivial development in editor-technology since vim and emacs.
Like emacs it is more then just an editor, it is a full programming
environment. If it was extended to support more then just text it could
be a full desktop environment.
I see posts complaining about having to write your own
integrations....well thats exactly the point of Acme. Its a programmers
editor. Your write tools to make your programs, to create better tools
to create better programs, to ....
Acme creates an environment, like the unix shell, for all those programs
to be integrated. Acme is the modern shell!
It's sad that nothing better has been created since (~30 years)
Like a lot of people, I went through an EMacs/Vim phase. Then went SublimeText, and now I live happily in VSCode. I feel very uncool to say it, but I just work really quickly with VSCode and I think it’s more because of a thousand micro-optimized UX choices by Microsoft rather than a particularly elegant core design, which is how I’d characterize Acme based on those demo videos. This is sadly how I feel about a lot of software these days.
I’d be happy to be wrong.