Earlier quoted context omitted.
Helix has been trying to implement a plugins system for like 2 years that should tell you everything you need to know about its future prospects
A plugin system is much less of an issue when Helix has built-in functionality for most of what comes as plugins in Vim. That said integration with git or with code assistants/chat is something that is probably better done via plugins hence it is still on the roadmap. But in my experience of ~10 months of Helix vs +20 years of Vim, the former is a much more pleasant and hassle-free experience, mostly because of it of…
Leaving Neovim for Zed
221–230 of 331 posts
Re: Leaving Neovim for Zed
#222> I was already a keyboard maximalist from previous jobs where I learned speed = productivity I've never understood this. In over 30 years in the industry, I've not once held a job where my keyboard speed had a noticeable effect on my productivity. Even when I had to type one-handed for a month, my productivity was unchanged. The average developer averages 10 lines of finished code per day. And even with a raw 10x th…
> The average developer averages 10 lines of finished code per day This is a ridiculous statement. Citation needed.
- code is not the only output produced by a developer. Communication, design, documentation, testing and tests, diagnosing and debugging, etc.
- I can and do write hundreds of lines of working code in a given day (and I'm not an IC). But "finished" was meant to describe something that doesn't get touched again unless new work requires it. A lot of code today is written more iteratively, with mvps, experiments, baselining, refactoring, etc. An mvp is not (yet) finished.
- 10 lines may be a low estimate today, but 100 is probably fair. (yeah varies a lot with language, boilerplate, etc)
I hope the general agreement would be that the amount of characters of code written is definitely not the largest part of a developer's output, but reaching the point where a given line of code is "finished" involves a number of processes and lot of typing. And editors are an important part of many of those processes.
Re: Leaving Neovim for Zed
#223> I was already a keyboard maximalist from previous jobs where I learned speed = productivity I've never understood this. In over 30 years in the industry, I've not once held a job where my keyboard speed had a noticeable effect on my productivity. Even when I had to type one-handed for a month, my productivity was unchanged. The average developer averages 10 lines of finished code per day. And even with a raw 10x th…
> 90% of software development happens in the mind. Why? The only reason I can think of for this to be true is when there is high risk in writing wrong code. For example, long compile times leading to a large sunken cost, or a lack of testing processes. Unless you're doing R&D, only spending 10% of your "coding" time actually writing code seems very low, and you should try to optimize the processes that are lacking.
Re: Leaving Neovim for Zed
#224i would say this as a mid-level dev in a team spread across geographies, however: when using a workflow that should work for all, it is more important to have a tool that works for all rather than the "best" one.
unfortunately, neither (neo)vim nor zed seem to be in a place where an entire team could easily adopt to its workflow. the latter probably needs a while to marinate and become suitable for most.
Re: Leaving Neovim for Zed
#225Earlier quoted context omitted.
They already have Scheme based config files and I'd say it is simpler that Lua.
It can't really be simpler than Lua, come'on. Maybe if you already know Lisp, but for people who know C-like languages (Java, Javascript, C++) Lua should be much more "obvious".
Re: Leaving Neovim for Zed
#226Earlier quoted context omitted.
And, oddly, they chose to do their own Scheme implementation for it. Not that I'm against Scheme in particular, but a lot of other people justifiably seem to be. It doesn't have the speed or learn-it-in-10-minutes of Lua (nvim) or the historical excuse of Elisp/Vimscript (emacs/vim) or the ecosystem of Typescript (vscode). Strange choice.
They already have Scheme based config files and I'd say it is simpler that Lua.
Re: Leaving Neovim for Zed
#227> I was already a keyboard maximalist from previous jobs where I learned speed = productivity I've never understood this. In over 30 years in the industry, I've not once held a job where my keyboard speed had a noticeable effect on my productivity. Even when I had to type one-handed for a month, my productivity was unchanged. The average developer averages 10 lines of finished code per day. And even with a raw 10x th…
In my present work at DevOps, I could say it’s true IF we only look at code.
When I was doing computational intensive simulations, I would write clearly 100 or more lines of code everyday.
Re: Leaving Neovim for Zed
#228Earlier quoted context omitted.
They already have Scheme based config files and I'd say it is simpler that Lua.
What are you talking about? It uses TOML for config files and some S-expressions for queries, which is actually a consequence of using tree sitter. https://docs.helix-editor.com/configuration.html
Re: Leaving Neovim for Zed
#229[2] I must say here too that Nano is actually an underappreciated gem. It supports a lot more features than people generally imagine: syntax hilighting, line numbering, auto-indent, multi buffers, mouse support, keyboard macros, … it's actually a decent simple code editor!
[3] https://kate-editor.org/post/2022/2022-08-24-kate-new-featur...
Re: Leaving Neovim for Zed
#230Earlier quoted context omitted.
A plugin system is much less of an issue when Helix has built-in functionality for most of what comes as plugins in Vim. That said integration with git or with code assistants/chat is something that is probably better done via plugins hence it is still on the roadmap. But in my experience of ~10 months of Helix vs +20 years of Vim, the former is a much more pleasant and hassle-free experience, mostly because of it of…
I tried to use it for multicursor editing which I tried to enable in Vim via plugins and it sucked, but being a console editor didn't help much. So I'm still using vi/vim for console editing because it's installed everywhere.