We should call it what it really is: oligapolization of intellectual work. The capital barrier to enter this market is too high and there can be no credible open source option to prevent a handful of companies from controlling a monster share of intellectual work in the short and medium term. Yet our profession just keeps rushing head first into this one-way door.

Cannot tell if this is a joke.

This year, I've switched to herbstluftwm, a tiling window manager that's really nice and works in a way that agrees with me.

Yes.

[1] https://www.humprog.org/~stephen//research/papers/kell17some...

- Having nearly 20 years of experience using Emacs, it's just a totally natural fit for me.

- I program primarily in Rust. I use the built-in LSP client, eglot, to communicate with rust-analyzer and have IDE features such as jump-to-def, find-refs, find-impls, auto-import, auto-format, semantic rename, etc. It works just as well as VSCode/Codium (which I tried for about a week to make sure I wasn't missing out; I wasn't.) I also do the odd shell script, Python script, YAML config, Dockerfile, etc. for which Emacs is also well-suited.

- As far as I know, I'm the only person in the company using Emacs. There's a few vim/neovim users, but the vast majority of people are using VSCode. Having paired with many, I don't think that I'm slower for using Emacs; in fact, I think that I am in many cases faster because I am so familiar with the text operations that I don't even think about them, I just do them.

- Overall, I don't see any reason for me to switch away from Emacs at the moment, especially since LSP really blurred the distinction between "text editor" and "IDE".

- I typically don't recommend that programmers try Emacs if they're not already familiar with it. Partly because I don't want them to ask me questions, but mostly because their natural tendency is to try and reproduce their VSCode/JetBrains/Visual Studio workflow. This usually causes frustration, because the way to use Emacs effectively is different from the way to use a product like VSCode that aims to have a good out-of-the-box experience.

Did you understand this comment to be positive or negative?

Of course, the extra hooks we put in to allow re-use and extensibility usually results in code that is slower and more complex than the simple thing. Worse, very often, when a customer needs a new feature, the current extension hooks did not predict this use case and are useless, and so the code has to be modified anyway, but now it's made 10x more difficult because of the extra complexity and because we feel that we have to respect the original design and not rip out all the complexity.

I like Knuth's quote [1] on this subject:

> I also must confess to a strong bias against the fashion for reusable code. To me, “re-editable code” is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.

[1] https://blog.jj5.net/blog/2021/05/21/knuth-on-reusable-code/