I agree with Joel Spolsky on this subject [1]. From what I've seen when people write something monolithic from scratch they just end up making similar mistakes and introduce new problems that weren't there to begin with. Vim's codebase isn't terrible, it's been going strong for 23 years, but it's accrued a lot of technical debt that makes doing somethings difficult. It's also controlled by a single person, and don't get me wrong this isn't necessarily a bad thing, but it makes getting in the necessary changes to achieve the goals of neovim nearly impossible.
Probably yes. I wondered this myself when I heard about this reengineering project which I agree needs to be done after delving into the vim source before.
However the time to market before it was even slightly usable would be rather large I imagine. I wrote a very basic clone of "ed" in Z80 assembly back in the 90s and it took me nearly 6 months before I trusted it with a file that wasn't disposable.
Perhaps there should be two projects starting at each end of the problem and see which one wins.
Why? Vim is a well tested codebase. It has many features. Starting over would produce better code, but in what timeframe? I think the neovim contributors made the right decision to refactor.
I think the fact that you can continually have a viable program while doing the sort of refactoring they are doing makes it a lot more easy for lots of people to work on the project. Starting from scratch would mean a large portion of time where only people with a very clear design vision could write components.
I think there was already some idea of how to make the changes they wanted to make, so it made sense to fork since the maintainer wouldn't integrate the changes.
That's not possible. Read the original text on Bountysource [1], the whole idea behind the project was to make a clean break from Vim and implement changes that were ignored when were brought up on the Vim mailing list.
[+] [-] weaksauce|11 years ago|reply
1. The speed in the refactoring.
2. The (apparent) ability to come to a consensus quickly.
3. The quality and depth of the communication of the progress and ideas.
I wish them all the success.
[+] [-] chappi42|11 years ago|reply
[+] [-] noname123|11 years ago|reply
[+] [-] adamors|11 years ago|reply
[1] https://github.com/Shougo/neocomplete.vim
[+] [-] ffreire|11 years ago|reply
[+] [-] jbeja|11 years ago|reply
[+] [-] atrilumen|11 years ago|reply
[+] [-] jaredmcateer|11 years ago|reply
http://www.joelonsoftware.com/articles/fog0000000069.html
[+] [-] pling|11 years ago|reply
However the time to market before it was even slightly usable would be rather large I imagine. I wrote a very basic clone of "ed" in Z80 assembly back in the 90s and it took me nearly 6 months before I trusted it with a file that wasn't disposable.
Perhaps there should be two projects starting at each end of the problem and see which one wins.
[+] [-] semisight|11 years ago|reply
[+] [-] ludamad|11 years ago|reply
[+] [-] davis|11 years ago|reply
[+] [-] glesica|11 years ago|reply
[+] [-] cgag|11 years ago|reply
[+] [-] buster|11 years ago|reply
[+] [-] tokai|11 years ago|reply
[+] [-] adamors|11 years ago|reply
[1] https://www.bountysource.com/teams/neovim/fundraiser
[+] [-] Touche|11 years ago|reply