Enjoyable list but I’m not sure the AlphaGo documentary counts as pop culture :).
It’s interesting how people talk about vi vs emacs, can’t remember ever meeting anyone who chose vi over vim, let alone enough people to make th at the debate.
> can’t remember ever meeting anyone who chose vi over vim
Pleased to meet you.
Most of my console dev time is spent in *BSD, where nvi is where I land. I find the the default creature-features of vim annoying, so I end up having to configure it to be a bit more quiet, and I don't know anything so compelling about it (a vi clone (to an extreme, acknowledged)) that nvi isn't a good enough place to be. I have vim installed, but it's not my go-to.
For me, it'd be primarily having more than one undo. Not being able to undo the second-to-last change is pretty bad. In fact, vim's undo being set up as a tree that can be walked with g- and g+ is excellent. It's impossible to lose a state of the buffer, even if you undo and make changes. It's a lot more practical to navigate than Emacs' undo, too.
EDIT: I just realized that nvi can undo more than one change by having u toggle the direction and . continue in that direction. I don't think ex-vi could. busybox vi seems like it can undo multiple with u but it seems to have no redo.
> For me, it'd be primarily having more than one undo
Do you mean infinite undo? nvi has that. I'm not sure what you mean "set up as a tree" wrt undo, but i'll look into it. I think of nvi's undo as linear - I can 'u' to "undo" and implicitly set my "undo direction" "backward in time" (as one would expect). If I want to "undo, even more", '.' (dot, period) to "do that last command again" is what I'll do. If I want to "undo an undo", 'u'. That has the effect of moving the "undo direction" back towards the state of the buffer we had at the beginning of our discussion here.
The only times I encounter vi (and so not sure what version, but likely barebones Linux), it doesn't indicate whether you are in insert or normal mode. So I immediately install vim (once possible).
Is that something you just get used to, or was I using some weird vi?
I always assume I am in normal mode unless I am actively typing. If I stop to think I ESC. Then, when I gave thought, I know what I need to do next.
So for me there isn't really any time of looking at the screen and not knowing. And if there ever was some ambiguity I would reflexively hit ESC to get to a known state.
So, not sure it would bother me. But my editor does give me an indication of whether I am in normal, insert, visual, visual block, or Emacs mode.
> can’t remember ever meeting anyone who chose vi over vim, let alone enough people to make th at the debate.
Because vim generally offers everything vi has.
vi does have one advantage though. It's a lot lighter. vim is like 5.4MiB in size with 82 shared library dependencies, while vi[1] is like 260KiB with 2 library dependencies (libc and ncurses).
Right. Sometimes all you need is to edit a couple lines in a config file and get out, in which case hjkl, i/a, and Esc (and then :wq) are all the editor really has to implement. (And a few more movement tools like w/b and so on). Plugins? Colorschemes? You don't need 'em to edit a couple lines in a config file. (I'll grant that syntax highlighting that makes the comments a different color from the actual lines can be helpful, but if it comes at the cost of a much larger binary it's not always worth the cost on those resource-constrained systems).
> can’t remember ever meeting anyone who chose vi over vim
As a sysadmin, I prefer a basic "vi" as in most cases I want quick open/edit/close and don't need fancy colours and such. (I.e., vim.tiny on Deb/Ub rather than vim.basic.)
I agree with the main point but this misses something crucial:
> why wouldn’t you use it to deliver more value to your customers, faster? That should show up as MAU, conversion, revenue
Most roadmaps are full of garbage and would be better off being deleted. You get very few truly useful new features in a year.
To paraphrase ESR: the value to your customers is in them being able to know that can rely on your product still operating next year, not in those 20 new features.
Or to think about it another way, maybe block will be better off with fewer developers, but only if they produce sufficiently FEWER features so that they’re forced to prioritize.
I thought we were very close until recently but I’ve just seen a long string of very promising openings from myself and others turn into “yeh dunno, it doesn’t work, I gave up”.
The effort to start is way down and drives new demand for software (at least in my own portfolio of side projects) but the effort to keep going is still above this threshold.
It was obvious hyperbole. I can believe that there are many companies where the boss heard about MCP and put it on a roadmap before anthropic decided that it wasn’t a good idea… and now the team is implementing this in the name of “we need to do some AI”
MCP allows you to easily separate API requests from their access tokens, so that the LLM only has access to the requests part. Giving an LLM CLI access removes all boundaries, anything goes.
EDIT: to add an example: I have a personal claw agent that I only use CLI, I don't care. But I'm also building an agent inside a company product, and there we use MCP all the way.
The point is that you still need to expose a shell or a wrapper around exec to launch those commands. That is t appropriate when I want to lock the model down to working entirely from a sandboxed environment and expose some basic tools which are not “entire posix user space”.
MCP servers are not dead, they’re just overused in contexts they don’t really make sense in.
Another examole which is trivial with MCP but hard with cli binaries: blocking certain commands, such as write operations from the agent. With MCP your client can easily have a blocklist for commands, but with cli you would need to code custom logic for each cli separately.
Access control is the operating system's job, and modern OSes already provide plenty of great tools for doing that.
Just use the existing sandboxing infrastructure like bubblewrap, seccomp, etc. I have way more faith in that than in something than some regex-based blocklist.
With MCP your client can easily have a blocklist for commands, but with cli you would need to code custom logic for each cli separately.
Nah. Just don't let your model do anything potentially destructive until three or four other models have vetted the proposed action.
Filtering individual commands can never provide more than the shallowest semblance of security. If a smart model is hellbent on deleting your production database, it will write its own Python program to do it if the usual commands are blocked.
That sounds intuitively right but breaks down when you ask “inefficient at what?”. Are you efficient with CPU cycles or efficient with human working memory?
Edit: I lost the context that this is about building devtools where you can’t just throw more hardware at the problem. But perhaps my answer still explains the reality: anthropic builds Claude with Claude so Claude needs to be easy to build with Claude.
Easier to read for humans is easy to read for LLMs. A more expressive language will bring about fewer misunderstandings when you apply stochastic tools like LLMs.
Just be sure you don’t choose something heavier/slower that is not more expressive.
The post talks about LLM+human contributions being recognized in some different category from human-only. But is it possible to spot the difference between the two?
reply