> A unique property of writing a code editor is that after a very short bootstrapping period, the thing you’re writing will also be the main tool you’re using to write it.
I love these types of projects that happened because someone needed it and wanted to, and I loved that they came to us with the project in hand so they didnt have to talk down 100 but-why's like "dude why do you need yet another hobby editor, just use vim/emacs/whatever, i program in $LANG too and use these 37 plugins and 4 keymappings and it all Just Works".
I contribute to a popular IDE that I'm sure a lot of you use, and I'm still going to put down my setup and put a week all-in into this just to, if anything, spiritually put something out there, something positive, to validate this person's work. I see value in projects like these, and though it's hard to put into words I hope someone more eloquent echoes this sentiment in a more tangible way. This is great stuff, I wish more people broke the norm and just did-the-thing.
> Randomly deleting unit tests may seem like insanity to some of you, and in certain contexts it probably is — but writing your own editor is a particular endeavour, and if you embark on it I encourage you to do whatever feels right to you, refactor as you please, and embrace the chaos. Happy hacking!
I wish more people dared to buck the trends. Good on you, Gus.
> i program in $LANG too and use these 37 plugins and 4 keymappings and it all Just Works
I've been wondering if there is some analgory between programming editors and armoured military vehicles.
The backend guys might need a full-on tank (Abrams/T90) - an IDE/hyper-custom vim. The front-end infantry might need a lighter weight but highly mobile IFV (Bradley/BMP) like VSCode/whatever.
It's possible the IFV/artillery SPG/etc vehicles can also be built on the body of a tank to "save money" and time. Modularity is important right? But it also creates frankensteins like the BMPT [1] which is an IFV built on top a widely available T-72 tank platform but costs 2-4x what a normal IFV/BMP costs [2] and lacks the benefits of either an IFV or main battle tank.
Ultimately it has little to do with the inherent generic capabilities of the base editor/platform. It's about designing the platform around a certain audience and skillset, then building a community around it's mission. Then iterating on that particular usecase.
I was a hardcore fan of Vim for the longest time but I've come around on VSCode as the essential default for frontend/Typescript development which I do. Sometimes extensions/plugins aren't enough. You need an editor built around an idea/community that fully embraces it. Much like programming languages.
What a fascinating combination of "analogy" and "allegory".
This aside, I agree with your point - the best articulation I can think of right now is the human equivalent of "do what I mean not what I say". Where sometimes the collective intent gets stuck in an ideological rut and can't become what everyone wants it to be for lack of expression.
Learning VIM keybindings definitely have been one of the biggest productivity investments I've done across tools. And I rarely use vim.
However, I love the vim community and how they port VIM bindings to almost any IDE(or most software that works with text and allows for some extensions).
Same way to deal with text across OS/Machines and software feels very liberating.
I have Intellij Ultimate. It's just really heavy when I'm moving around a js project. Not against it though, some colleagues use Intellij for everything and seem happy.
I'd expect software to be more "stretchable" than armoured military vehicle designs. Hopefully, both the tank and the IFV can be Vim or Emacs or VS Code, and both can be good without compromises.
Yep - for projects like this, unit tests serve to reduce the dev's mental load. Once a test gets in the way of making easier progress, it's no longer serving that purpose.
Generalized a bit, unit tests on all projects serve to make progress easier and regression harder. There are secondary benefits on evidence/documentation. When the ROI on them turns negative, just delete them. Overcoming the belief that you can't delete unit tests is the lowest cost way to start writing more and better tests.
It's so weird when you think about it. People don't delete unit tests because not having them is bad. So, they... don't write them? "No unit tests" is a state we can always get back to in a seconds. Don't be afraid to leave it.
I love these types of projects that happened because someone needed it and wanted to, and I loved that they came to us with the project in hand so they didnt have to talk down 100 but-why's like "dude why do you need yet another hobby editor, just use vim/emacs/whatever, i program in $LANG too and use these 37 plugins and 4 keymappings and it all Just Works".
I contribute to a popular IDE that I'm sure a lot of you use, and I'm still going to put down my setup and put a week all-in into this just to, if anything, spiritually put something out there, something positive, to validate this person's work. I see value in projects like these, and though it's hard to put into words I hope someone more eloquent echoes this sentiment in a more tangible way. This is great stuff, I wish more people broke the norm and just did-the-thing.
> Randomly deleting unit tests may seem like insanity to some of you, and in certain contexts it probably is — but writing your own editor is a particular endeavour, and if you embark on it I encourage you to do whatever feels right to you, refactor as you please, and embrace the chaos. Happy hacking!
I wish more people dared to buck the trends. Good on you, Gus.