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.
Bram Moolenaar responds to Neovim
11–20 of 151 posts
Re: Bram Moolenaar responds to Neovim
#12well 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).
I think neovim could be a great project and a major change for vim, but it could just as easily never reach a viable state. I won't suggest they give up, but I'm also not putting a lot of hope into it. Bram's vim is amazing, and even vi is stellar. I don't really see a downside whether they succeed or fail.
Re: Bram Moolenaar responds to Neovim
#13It'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.
Sounds like the code of pretty much every non-trivial C program that is meant to run of many platforms, not just the five or ten most popular ones.
I'm not saying that this is a good thing, just that I don't know any good alternatives that don't sacrifice compatibility with lots of platforms.
Re: Bram Moolenaar responds to Neovim
#14Perhaps 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.
37Signals rewrote Basecamp from scratch and as far as I know it's been very successful.
Re: Bram Moolenaar responds to Neovim
#15It'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…
It will drop support for lots of legacy systems. That will allow simplification of the code - at the cost of those on amigas.
I love vim. I use it for all my development. I've only been using it for a couple of years though and I can see the warts that are being addressed. They were fairly evident upon joining the ecosystem and I don't think "it's too hard to change" is a viable long term strategy.
I would absolutely love neovim to succeed - and I think that something like it is essential if vim is to have any place in the future.
Re: Bram Moolenaar responds to Neovim
#16To 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
#17Perhaps 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
#18Perhaps 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
#19It'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.