Live data from Hacker News

Bram Moolenaar responds to Neovim

groups.google.com

121–130 of 151 posts

Re: Bram Moolenaar responds to Neovim

#121
post #98

Total refactoring is not a solution. 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'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 tangi…

Good points but I'm not convinced there exists a compelling reason to fork vim. From a user perspective there are no points of differentiation between NeoVim and vim. As an outsider looking in, it appears to me that NeoVim exists only to scratch the itch of some developers writing vim extensions. Is that reason enough to exist? Maybe. But what's the long-term aim here? Without a strong point of differentiation to att…

I'm not qualified to say technically whether I think it's justified or not, but I'd say the reason you're looking for will be the first new graphical version of vim for OS X that is much better than MacVim.

Re: Bram Moolenaar responds to Neovim

#122
post #2

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

I tend to agree with Joel's thesis here, but the example is bad: Netscape was doomed either way, the rewrite was an act of desperation, and I'd say it succeeded because it led to Firefox which slowly clawed back those first few points of marketshare from Microsoft—enough to finally get them to resume browser development. Even assuming they could have pulled a rabbit out of their hat with the Netscape 4 codebase (which was unlikely considering the history of that codebase, and it's legacy compared to the talent and experience that was being pumped into the greenfield Internet Explorer (yes, ironic I know)), IE was still going to eat their lunch. Netscape was between a rock and a hard place. But hey, at least their code lives on today right?

Re: Bram Moolenaar responds to Neovim

#123
maybe if Bram even commented on the two patches that Thiago had posted, things could have been different.

All Thiago got was: being ignored, one of the worst ways of disdain. Not just even a 'thanks but not interested'.

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).

Re: Bram Moolenaar responds to Neovim

#125
Refactoring is hard. I'm learning this with delving into the LibreOffice codebase. It's got a lot of issues - about 25 years of accreted code and design decisions that need unpicking, tangled code that needs refactoring, etc.

However, it's sure easier to refactor than start from scratch! At least LO has a working product. Best of luck to the Neovim guys :-)

Re: Bram Moolenaar responds to Neovim

#126
post #110
post #8

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

Big old code bases, have a lot of what I call as 'tribal knowledge' associated with them. People go out, and do experiments only to burn their hands. Over years, the old maintainers generally accumulate a lot of ideas and 'tribal knowledge' to know why 'pie in the sky' ideas won't work. Nevertheless, people still try. A lot of them fail, a few succeed. The vim code base is around 300K lines of C code. I'm sure its no…

I can't speak for vim, but the following smacks of code that needs a refactor:

300K lines of code which does the actual work is simply too much code. And one should exercise great caution while dealing with it. Regression is just one thing, I'm sure there are a lot of places in the code which can silently break things you can't detect only to pop up in some strange case in the wild.

Re: Bram Moolenaar responds to Neovim

#127
The old Unix ways are dying...

Or, at least, I think that'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't type in two places at once, right?

NeoVim wants to be something like an IDE-lite. Text editing, yes, but with the ability to do background compilation/syntax checking, a bit of debugging here, some REPL-ish things there. For that you need a better async story, better process control, etc.

So, in the end, I don't actually see a problem here. Vim will cater to one audience, NeoVim to another. For my money (or donation to Uganda), I'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 some events could be backgrounded (e.g. syntax check on file save), but I don't think this needs a complete refactor.

Re: Bram Moolenaar responds to Neovim

#128
post #2

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

With that thinking we never get Linux (NeoMinix), tmux (NeoScreen), Clang (NeoGCC), WebKit (NeoGecko), Subversion (NeoCVS), or Vim itself (NeoVi/Elvis/Stevie/etc).

None of those are from-scratch rewrites of existing software. They're mostly (not all) clones of existing software, with some (e.g. Linux) being more "inspired by", and some (e.g. Clang) being "We can do this better".

Re: Bram Moolenaar responds to Neovim

#130
post #110
post #8

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

Big old code bases, have a lot of what I call as 'tribal knowledge' associated with them. People go out, and do experiments only to burn their hands. Over years, the old maintainers generally accumulate a lot of ideas and 'tribal knowledge' to know why 'pie in the sky' ideas won't work. Nevertheless, people still try. A lot of them fail, a few succeed. The vim code base is around 300K lines of C code. I'm sure its no…

The coding style is archaic in every way possible. Most things seem to be coded "in-line" instead of being compartmentalized. This coding style shouldn't be used past a few thousand lines of code, no wonder it is hard to improve upon it.

In a way, it's like a direct application of the style in /The C Programming Language/.

Post reply on HN