Bram Moolenaar responds to Neovim
groups.google.com
Bram Moolenaar responds to Neovim
1–10 of 151 posts
Re: Bram Moolenaar responds to Neovim
#2Perhaps 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.
Re: Bram Moolenaar responds to Neovim
#3well of course. Vi was specifically written by Bill Joy to optimize for every character, see
http://www.theregister.co.uk/2003/09/11/bill_joys_greatest_g...
And there is no reason we could ever improve on that 35 years later. we need those optimizations...
"It took a long time. It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem. That'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.
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. "
Re: Bram Moolenaar responds to Neovim
#4That seems like a fair response. I tend to agree that sweeping refactorings tend to take a lot of time and it'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's what added all the complexity Neovim is trying to solve.
Re: Bram Moolenaar responds to Neovim
#5well of course. Vi was specifically written by Bill Joy to optimize for every character, see http://www.theregister.co.uk/2003/09/11/bill_joys_greatest_g... And there is no reason we could ever improve on that 35 years later. we need those optimizations... "It took a long time. It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem. That's also the reason you…
Whenever I use vim through a lagging SSH connection, I'm very happy that it's still usable (at least more so than other editors).
Re: Bram Moolenaar responds to Neovim
#6It's very easy to look at code base full of weird special cases and think "this could be such much easier if I started from scratch", but in the end if often turns out that all this cruft is there for a reason. It's essential complexity that you wrongly identified as artificial complexity. And the rewrite ends up being much more work than originally anticipated.
I don't think there's a way to learn that except by making the same mistake yourself, possibly more than once.
Re: Bram Moolenaar responds to Neovim
#7To 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.
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.
Re: Bram Moolenaar responds to Neovim
#8Why 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?
Re: Bram Moolenaar responds to Neovim
#9Well that does it I'd say. With such a negative attitude, who wants him on the team anyway? What the advantages are? They're clearly laid out in the project.
Seriously, screw that guy.
edit: Yes I know who 'that guy' is and it's great he'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?
It's not too late for Vim to lose the editor wars.
Re: Bram Moolenaar responds to Neovim
#10It's very easy to look at code base full of weird special cases and think "this could be such much easier if I started from scratch", but in the end if often turns out that all this cruft is there for a reason. It's essential complexity that you wrongly identified as artificial complexity. And the rewrite ends up being much more work than originally anticipated. I don't think there's a way to learn that except by mak…
That is an overly simplistic viewpoint. Vim is written in an inedibly old style of C which is not taught anymore, or used by most people. The code if fill of typedefs for AMIGA and OS/2. Useful to a small number of people certainly, but making progression harder too.
This is not a total rewrite, it is a massive overdue refactoring.