I haven’t blogged for a while and I forgot how internet commenters can get bizarrely angry about statements like “I got tired of managing my vim config so I decided to stop using vim for now”, as if it’s some kind of attack on vim (or on them??)
It makes me really appreciate @grimalkina’s work on developer culture, like this https://osf.io/preprints/psyarxiv/2gej5_v2
I still have a lot to learn but her work has helped me start to understand where this stuff comes from
(I used vim for a long time and I love it!)
@b0rk thank you!!
I really need to write my "when thinking about our tools is thinking about ourselves" paper
@grimalkina @b0rk Yes! I want to read this.
25 years ago I wrote “Then something strange happens. They start to identify themselves with Perl, as if Perl were part of their body, or vice versa.”
@grimalkina @b0rk Oh, totally. And with some people - especially very new or junior devs - something as simple as teaching them a second programming language with different strengths immediately breaks the "tool = self" mindset without having to have the explicit conversation at all.
But then there's also the entire organizations that lean into the tool as identity thing as a substitute for having a deliberate culture, which just straight up scare me.
@grimalkina @b0rk I have been doing just that. I have been (accidentally) rebuilding my existing neural scaffolding (org mode and emacs) in a fully AI assisted platform, with real time rendering, a talking teddy bear and detective cases.
It also supports a modern, multi-agent workflow with subcontext splitting, "memory's editing", semantic search and probably lots more I've forgotten about.
I use it as a spatial to linear translator so I can stop burning so much mental energy on it.
I'm documenting the whole process here.
https://www.graemefawcett.ca/blog/strange-attractor
I think that very much qualifies for "thinking about our tools... Thinking about us". I would be honored if you would give it a glance.
I find this stuff fascinating and I'm deeply focused on reframing on building empathy into my designs
@b0rk @grimalkina I was astonished when I said in a talk that the C++ macro feature was bad and people got mad at me. I thought it was self-evident and that even big fans of C++ would agree with me that the macro system was one of the worst parts of the language.
Instead they just got angry.
@b0rk @grimalkina A while back I was helping my kid with her CS class homework and sent her a followup email observing:
“You lost a lot of time and energy dealing with issues like: Using vim; copying files back and forth with scp; losing the network connection; the college shared machine is slow and yucky.”
“It's important to remove as much friction as possible from your basic process. Otherwise it's like trying to cook with dull knives and rusty pots, except worse because it interrupts your train of thought. You can't do good work with bad tools.”
“When you start the next project, start it in VScode in the beginning. And maybe set aside an hour or two before you start in earnest, just to go through the VSCode tutorial and familiarize yourself with its basic features, without trying to do that at the same time you are actually thinking about your homework. This will pay off quickly.”
Then I published the letter on my blog and boy oh boy did I get a lot of hate from the vim fans.
But the simple fact was, she lost a lot of time and energy dealing with vim.
Looking forward to reading your article BTW. I have been thinking about these issues for a long time.
@grimalkina @ink @mjd @b0rk I have nothing against making it easier for new developers, but there's other reasons for using and recommending tools that are perhaps harder to use besides the reasons you mentioned.
It's hard to get out of Big Tech's walled garden once you're in it (and you can see where that has led us).
The recommended open-source tools offer a stable platform that'll be with you for decades and work in a lot of different environments.
That's worth something as well.
@grimalkina @mjd @b0rk I’ve been using vim since I was a kid. I have used it for a lot of projects over the years, professional and personal.
I don’t use vim for work anymore. I use the thing that will definitely work and is easy to get to a known good state. Vim is a great editor. But VS Code is the gold standard.
@pozorvlak @b4ux1t3 @grimalkina @mjd @b0rk I regularly use vim, notepad++, and VS Code each for different reasons or to solve different problems. Lately gvim has been "helpfully" autoindenting and inserting [expletive] tabs into my text and I have not spent the time to figure out why this is happening or (more importantly) how to disable it permanently.
I have zero plugins installed; every time I look into vim plugins I waste 2-3 days trying to make anything work and the time spent is never worth it.
I was forced to use vi back in 1986 because the alternative was ex. Emacs was not available for some reason, probably due to limited disk space (it didn't seem like it at the time but I feel I dodged a bullet there...)
I find VS Code is good for complex projects, vim is good for precise bulk editing, and npp for when I want to just want to write without doing much editing.
@mjd i did a podcast interview once where someone asked me why developers should learn vim and I said something like “I don’t know, maybe they shouldn’t! people should use what they like”
the attitude that people “should” use it is so baffling to me
@b0rk I learned vi first. (No vim yet then.) After a year or two I encountered emacs, decided it was obviously better, and put
alias vi=emacs
in my rc file to force myself to make the switch.
VS Code is much, much better for me than either one ever was.
@mjd @b0rk I was an emacs guy before switching to IDEs, and one of the main reasons was that I became really good at using the emacs merge tool for manual code merges, which tended to be much more frequent and heavyweight in the days before git. Emacs merge could do a lot of the automation that the source control system wouldn't.
Git tends to boil manual code merging down to the point that VSCode's simple treatment of merge markers is good enough to deal with it 99% of the time.
In my subjective experience, using vim has probably saved me at least net 1000 hours of time over my decade-plus of programming projects, and I'm not even a full-time developer. I probably didn't break even on time saved within a year though.
I think that this subjective experience (along with a dose of toxic kids-these-days pride) is what prompts the misguided "everyone should use it" line.
I'm mature enough to recognize that the same time savings won't necessarily materialize for all my students, and that in different ways, emacs might have saved me 1000+ hours too. I make sure there's a vim section of our course's recommended editors page but I don't push anyone away from vscode, which is the default. I don't believe everyone should use vim, even though in theory I think it could be a net time savings over the long term for a lot of people, because that theory is only sometimes borne out in reality.
@b0rk Ooh I'm literally trying this at the moment, I only started using helix about 2 days ago.
Thanks for sharing your experience!
@b0rk helix is cool! I really enjoy not needing to configure anything - compared to vim anyway. The multi selection thing is fun. Go, my cursor army!
I occasionally need to use vim to edit some config file on a remote server. I can get around in it ok enough to change a line of code and save the file, but have forgotten anything beyond that.
@b0rk Thanks for this! I've been trying to switch from a hybrid vim/vs-code setup to just using Helix and it's been equal parts fun and maddening.
There are tabs, sort of! In config:
[editor]
bufferline: 'multiple'
Then you can walk through your tabs using gp "go previous" and gn "go next".
@b0rk I played with par and Helix and unfortunately it couldn't deal with bullet and numbered lists (think Vim's :set fo+=n). As I write mostly in Markdown I finally settled on this Helix config:
[keys.normal]
"=" = ":pipe pandoc -f markdown -t markdown --wrap=auto --columns=72
So I can write regular text files, commit messages, etc and select all using % and then press = to have it nicely formatted. There are probably better ways, but this works for me.
@b0rk I had similar journey. I started using it in May 2022 (https://microblog.desipenguin.com/post/helix-editor/) and been using it ever since.
I am surprised you didn't even mention object-verb/verb-object difference from Vi/m
After 3+ years, Helix has taken over my muscle memory (After 20 years of Vi)
Now, when I go back to vi occasionally (Vi is built-in on all *nix machines, `hx` needs to be installed) I am stumped for a second. 😂
I came across Helix Editor on youtube when watching about neovim related video. It is vim like editor. That is, a modal editor. But it is different in one fundamental way, it terms of how commands work. In (Neo)vim, it is action followed by object. So delete word becomes dw But in Helix it is other way round. Object followed by Action. So it is word delete hence wd It takes a bit getting used to.
@thomastc I too find myself using VSCode (based) editors these days. But mainly for their GenAI/Agentic coding integration.
When I write my blog posts (markdown) I use `hx`
Also, when making minor/quick edits - `hx`
I also use Zed. Can you clarify `their stance on AI` ?
@ddwwcc personally I would not use Micro because I prefer a modal editor.
the way I think of Micro is "something that seems like it might be a cool replacement for nano, or a good way to have an occasional terminal text editor if you're not a full-time terminal-text-editor user, but I don't personally have a use for it"
I just conceptually find Micro to be very cool.
Hello @b0rk ,
Thank you for sharing your experience with Helix :) For two weeks now I'm using Helix regulary and I'm quite happy with it. Especially since I have syntax highlighting for my org files natively supported :D
Regarding your mention of missing tabs:
There is the option called "bufferline". When set to "multiple" Helix displays the buffer name as tabs above your current buffer if you have more than one file opened: