141–150 of 151 posts
Was Vim a complete rewrite of Vi?
Lots of things were a complete rewrite of vi. Vi was a complete rewrite of ex. ex was a rewrite of em, which was in turn a rewrite of ed, which was a rewrite of qed. Trying to rewrite vim is the wrong approach. Trying to replace it in a backward-compatible way, the way vim did to vi might received a lot better.
Earlier quoted context omitted.
Go is certainly not a rewrite of C. It looks like most/all of the go compiler have been/are being rewritten from C to Go, described at https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdw... . That looks to be machine-assisted, so I'm not sure how good an example it makes.
This "Go is a rewrite of C" misinformation that's been floating around lately is getting almost as bad as the "JavaScript is Scheme-like" nonsense that has gotten uncomfortably common. Although incorrect and annoying, they are at least becoming a way to identify people who likely don't know what they're talking about.
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…
This is shallow and short-sided opinion. If neovim achieves goal of "easier to maintain codebase" then it will have much faster feature development, bug fixing, and extension development. All extremely user facing and exciting.
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.
> but I'm sure that's the way Netscape thought of it as well Don't really think so. At least as far Netscape 6 went, they came up with an entirely different framework and moved over to Java (as far as I remember). I have rarely seen that sort of thing characterized as a refactor (even on their mailing lists).
Some of us have been using Gecko as their renderer for almost sixteen years now. Seems KHTML(w), the base of both Webkit and Blink[5], is the same age. Seems we've gotten a good run out of the existing codebases. In fact, this means that Gecko (and khtml) have been in use twice as long as NCSA Mosaic, which the first Netscape was based on[6]. Imagine how Spolsky must feel about the Servo rewrite.
1. http://www.seamonkey-project.org/
2. https://en.wikipedia.orgwiki/Mozilla_Application_Suite#Marke...
3. https://en.wikipedia.org/wiki/Netscape_6
4. https://en.wikipedia.org/wiki/Netscape_7
Earlier quoted context omitted.
Bram's last post was 10/21/13, and a month later Bjorn confirmed in his fork that he could reliably freeze VIM and had segfaults that he had yet to fix. The final word seemed to be: "There are enough vim users out there (myself among them) to warrant supporting a fork for as long as we're around. We'll try to keep it up to date with the latest changes." I don't think anyone should expect Bram to chase them down for u…
We actually continued to work on the fork until it was clear Bram wouldn't be responsive to any more changes. Once it became clear he wouldn't accept the patch we stopped wasting more time as we are trying to create a viable business. We weren't going to sink our startup for the sake of vim, as much as I love the editor. We spent a long time, it was a frustrating experience, so yes we tell the internet when it comes…
Each iteration of the patch was provided with a whine about whether it was ready for inclusion yet ... when the reality is, that as the patch author, it's your job to make sure there aren't more bugs and the patch is ready for inclusion.
Every time someone found another issue was a red flag to any sane maintainer that your patch wasn't ready for inclusion. Every time you whined about having to iterate, you made it clear that you couldn't be trusted to have written something stable and maintainable.
If you can't deal with working on mature software, stick to startup code.
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.
So, the engine that Spolsky was saying was a mistake has now been in use for twice as long as the engine it was replacing.
Earlier quoted context omitted.
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…
"From a user perspective there are no points of differentiation between NeoVim and vim." This is shallow and short-sided opinion. If neovim achieves goal of "easier to maintain codebase" then it will have much faster feature development, bug fixing, and extension development. All extremely user facing and exciting.
I think this is a bit naive. There's no plan of any kind laid out for NeoVim, not even a goal against which progress can be concretely measured. New and compelling features must be well thought-out, well designed and well executed; they don't just fall out of the sky as a consequence of "easier to maintain code".
Earlier quoted context omitted.
We actually continued to work on the fork until it was clear Bram wouldn't be responsive to any more changes. Once it became clear he wouldn't accept the patch we stopped wasting more time as we are trying to create a viable business. We weren't going to sink our startup for the sake of vim, as much as I love the editor. We spent a long time, it was a frustrating experience, so yes we tell the internet when it comes…
My only takeaway from the thread was that you approached the process of patch review begrudgingly, and seemed to assume that everyone should understand/appreciate your node-derived vocabulary and design. Each iteration of the patch was provided with a whine about whether it was ready for inclusion yet ... when the reality is, that as the patch author, it's your job to make sure there aren't more bugs and the patch is…
Earlier quoted context omitted.
This isn't a "rewrite the code from scratch", but instead is an incremental but aggressive refactoring. There's at least one wildly successful example of this successfully being done for GCC, which is a project even bigger and more complex than Vim. Around GCC 2.8, it was forked into EGCS where major changes were made. This fork was so successful that it then became the official branch of GCC, and modern versions of…
As I recall, EGCS happened because GCC development had stagnated, if not stalled entirely.