Bram Moolenaar responds to Neovim

<i>Total refactoring is not a solution.</i><p>To Diego: Prove him wrong. I suspect that Bram has been maintaining the code base for so long, that he might need a bit more than a mere message to warm him up to the idea of a refactoring to the scale that you&#x27;re undertaking. Also, you might not be the first person to contact him with such a proposal. I wonder how long it took for others before they gave up. Build something tangible and contact him again later with proof of concept, something that would make this more than just a fleeting dream.<p>To people questioning Bram&#x27;s position: You need to look a bit further than your nose. The fact that you want to create plugins or extensions does not put you in the mainstream as a Vim user. It&#x27;s an extremely popular editor of almost religious proportion, with lots of existing plugins and extensions. So we know that people use it and making plugins is possible. With all of its annoyances it gets the majority of the job done for most users. One can&#x27;t just wake up one day and say that they&#x27;ll change things, not even Bram at this point.<p>The most desirable outcome in my opinion would be to have Neovim be a continuation of Vim (Vim 10.0?) rather than just another fork, and for that, having Bram on board would be a boon. His longevity as a maintainer is impressive.

To be fair to the authors of neovim, there were patches they wrote and submitted to vim, which added exciting new features I would like, which were rejected.<p>People who basically want him to never change (and that is fine) can be happy with mainline. There are others who would like to see some significant updates, particularly allowing better threading support.

Perhaps this was mentioned the other day, but Neovim did make me think of this old chestnut from Joel Spolsky:<p><a href="http://www.joelonsoftware.com/articles/fog0000000069.html" rel="nofollow">http:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;articles&#x2F;fog0000000069.html</a><p>I realize Neovim is being characterized as an &quot;aggressive refactor,&quot; but I&#x27;m sure that&#x27;s the way Netscape thought of it as well.<p>tl;dr Things you should never do: rewrite the code from scratch.

well of course. Vi was specifically written by Bill Joy to optimize for every character, see<p><a href="http://www.theregister.co.uk/2003/09/11/bill_joys_greatest_gift/" rel="nofollow">http:&#x2F;&#x2F;www.theregister.co.uk&#x2F;2003&#x2F;09&#x2F;11&#x2F;bill_joys_greatest_g...</a><p>And there is no reason we could ever improve on that 35 years later. we need those optimizations...<p>&quot;It took a long time. It was really hard to do because you&#x27;ve got to remember that I was trying to make it usable over a 300 baud modem. That&#x27;s also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. It was just barely fast enough. A 1200 baud modem was an upgrade. 1200 baud now is pretty slow.<p>9600 baud is faster than you can read. 1200 baud is way slower. So the editor was optimized so that you could edit and feel productive when it was painting slower than you could think. Now that computers are so much faster than you can think, nobody understands this anymore. &quot;

Why aren&#x27;t there other vim committers?<p>Bram&#x27;s conservatism makes perfect sense for someone who has to maintain this huge, consequential, intimidating codebase. Why hasn&#x27;t he gotten some help?

This reminds me to the origin of Inkscape, as a fork from Sodipodi. The (only) Sodipodi committer didn&#x27;t want too many patches, and he wanted to stay with C (no C++ code).<p>Some people forked Sodipodi, and created Inkscape. I can remember that one of their first tasks was to make the code compatible with a C++ compiler.<p>Nowadays, Inkscape is a very good tool, and I hope that Neovim has a great success too.

Vim is not a healthy project. Example: They support transparent encryption for documents, but refuse to address or document the shortcomings of their implementation. It&#x27;s of course a fully custom implementation of a half-homerolled protocol.<p>Main flaws: Apart from implementation issues, non-authenticated encryption susceptible to bitflipping.

It&#x27;s very easy to look at code base full of weird special cases and think &quot;this could be such much easier if I started from scratch&quot;, but in the end if often turns out that all this cruft is there for a reason. It&#x27;s essential complexity that you wrongly identified as artificial complexity. And the rewrite ends up being much more work than originally anticipated.<p>I don&#x27;t think there&#x27;s a way to learn that except by making the same mistake yourself, possibly more than once.

My $20 is totally worth the &quot;risk&quot;. Here&#x27;s some dude from Brazil, that has at least some demonstrable skill, willing to take a month and have a go at improving a tool I use every day. For the price of four coffees.<p>As for Bram, he can, and most likely will continue his good work on vim. I am kind of disappointed that he is not more supported of this effort though.

That seems like a fair response. I tend to agree that sweeping refactorings tend to take a lot of time and it&#x27;s better to break off small bite size pieces. That being said I really like some of the proposed improvements into vim. I wonder if a similar approach could be taken as when vi was improved to create vim, or perhaps that&#x27;s what added all the complexity Neovim is trying to solve.

<i>As vi was a popular editor amongst programmers and system administrators, there initially was doubt whether Bram&#x27;s &#x27;improved&#x27; version could achieve the quality and fan following of the original. But since its first release for Unix systems in 1992, Vim has effectively eclipsed the original Vi, having won several awards[3] and has been referred to as one of the most popular text editors.</i><p>- Excerpt from <a href="http://en.wikipedia.org/wiki/Bram_Moolenaar" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Bram_Moolenaar</a>

The old Unix ways are dying...<p>Or, at least, I think that&#x27;s the best way to summarize the essential miscommunication between these two camps. Vim is, in the spirit of Unix, a single purpose tool: it edits text. Why would it need threading? async? background jobs? You can&#x27;t type in two places at once, right?<p>NeoVim wants to be something like an IDE-lite. Text editing, yes, but with the ability to do background compilation&#x2F;syntax checking, a bit of debugging here, some REPL-ish things there. For that you need a better async story, better process control, etc.<p>So, in the end, I don&#x27;t actually see a problem here. Vim will cater to one audience, NeoVim to another. For my money (or donation to Uganda), I&#x27;m happy using tmux splits, sending text between vim windows and REPL windows, and keeping Vim primarily as a text editor with syntax highlighting. I would appreciate if <i>some</i> events could be backgrounded (e.g. syntax check on file save), but I don&#x27;t think this needs a complete refactor.

I get the idea that Bram thinks it&#x27;s going to be more of a rewrite than <i>I</i> think it&#x27;s going to be. As in, I assumed that neovim would not be a complete rewrite or something, but more targeted refactorings.<p>Of course, Bram knows the codebase and I don&#x27;t, and I may well have misunderstood the neovim plan, so I&#x27;m not sure which of us understands.

Abrash wrote in his graphics programming black book, and I quote, Carmack&#x27;s law -&gt;<p>&quot;I’ll take this opportunity to coin Carmack’s Law, as follows: Fight code entropy. If you have a new fundamental assumption, throw away your old code and rewrite it from scratch. Incremental patching and modifying seems easier at first, and is the normal course of things in software development, but ends up being much harder and producing bulkier, markedly inferior code in the long run, as we’ll see when we discuss the net code for QuakeWorld. It may seem safer to modify working code, but the nastiest bugs arise from unexpected side effects and incorrect assumptions, which almost always arise in patched-over code, not in code designed from the ground up. Do the hard work up front to make your code simple, elegant, great—and just plain right—and it’ll pay off many times over in the long run.&quot;

Every 10 years or so I think some energetic programmers should set about writing God&#x27;s Own Text Editor. There have been a lot of really useful technologies that have come from those efforts, whether it was EMACs, Gosling EMACs, vi, vim, pfe, visual slick edit, sublime text, or even wordpad. An editor is a fairly complete system, well within the capabilities of a single motivated individual, and like cocktail gowns entirely fashion&#x2F;taste driven.

&gt; It&#x27;s going to be an awful lot of work, with the result that not all systems will be supported, new bugs introduced and what&#x27;s the gain for the end user exactly?<p>That may be a problem for vim but not for neovim. Neovim doesn&#x27;t have a legacy user base, they can focus on the currently used systems.

The project has already surpassed its requested value in the first 48hs. The enthusiasm reminds me of git-annex.<p>I really love this business model, the developer works on something he is passionate about, we can support the project and influence its future, all while strengthening the community around it.

He&#x27;s right. With every project, there&#x27;s a tradeoff between achieving the goals of the project and maintaining compatibility with existing systems.<p>As a Go programmer, I feel a bit sad&#x2F;ashamed to be saying this, but look at Plan 9 - it failed to usurp Unix (and its descendants) as the dominant OS, because the latter was &quot;good enough&quot;, and was already more widely supported and used.<p>Plan 9 vs. Unix is a very different comparison than Vim vs. Neovim, and there are a lot of other factors at play, but the same principle actually holds. Improving or extending an existing system in a compatible way is a lot easier than trying to establish mindshare with a completely new tool.<p>The tradeoff is that extending existing systems leads to cruft and bloat. So <i>if</i> you can establish mindshare with a new tool, you have an opportunity to make a much more elegant one. But that&#x27;s a big &quot;if&quot;.<p><i>EDIT</i>: I think a better analogy may be an attempt to refactor the Linux kernel into a microkernel. I&#x27;d certainly love it if this magically happened - microkernels are much easier to work with, and much more elegant. But it&#x27;d be hard to make the case that that&#x27;d be a worthwhile endeavor at this point, given the costs of doing so.

I won&#x27;t move off of Vim personally. I don&#x27;t push it really as I use a pretty stock setup. However, good luck to the neovim devs, it will be cool to watch.

Sorry to point out to the ironic here. But his signature includes the link to a &quot;new programming language&quot;. And it reads much like &quot;Neo-C&quot;.

Refactoring is <i>hard</i>. I&#x27;m learning this with delving into the LibreOffice codebase. It&#x27;s got a lot of issues - about 25 years of accreted code and design decisions that need unpicking, tangled code that needs refactoring, etc.<p>However, it&#x27;s sure easier to refactor than start from scratch! At least LO has a working product. Best of luck to the Neovim guys :-)

What would you call going from vi to vim? Regardless, anything that fixes the mess that is vimscript gets a thumbs up from me.

Am I the only one thinking why C?

maybe if Bram even commented on the two patches that Thiago had posted, things could have been different.<p>All Thiago got was: being ignored, one of the worst ways of disdain. Not just even a &#x27;thanks but not interested&#x27;.<p>Other two guys who tried to provide patches to be merged on the same area also suffered from being mostly ignored (he replied to them but just once I think).

Streamlining and simplifying a code base by introducing JSON-RPC for internal API? Success is practically guaranteed!

I haven&#x27;t looked at vim code in ages but if it is really 300K lines of code, I wouldn&#x27;t refactor it in any major way. If I absolutely wanted to scratch that particular itch, I&#x27;d rewrite it from scratch. In another language (not C or C++). And structure it differently.

Was Vim a complete rewrite of Vi?

Refactoring is not a big deal. In fact I don&#x27;t even want total compatible with vim.

Total refactoring without regression is rare. Especially in the wild.

Clang v. GCC all over again?

1. make kickstarter campaign to &quot;revolutionize&quot; open source project vim.<p>2. :%s&#x2F;vim&#x2F;neovim&#x2F;g<p>3. profit!?!?!?!?!?

Well that does it I&#x27;d say. With such a negative attitude, who wants him on the team anyway? What the advantages are? They&#x27;re clearly laid out in the project.<p>Seriously, screw that guy.<p>edit: Yes I know who &#x27;that guy&#x27; is and it&#x27;s great he&#x27;s been working on Vim for all these years, but he certainly has his head up his ass if he thinks Vim users would not benefit from some big refactorings, a more accessible code base and some dropped platforms. If all those Amiga programmers love Vim so much, why would they be disappointed with an eternal Vim7.4?<p>It&#x27;s not too late for Vim to lose the editor wars.