Sorry to point out to the ironic here. But his signature includes the link to a "new programming language". And it reads much like "Neo-C".
Bram Moolenaar responds to Neovim
31–40 of 151 posts
Re: Bram Moolenaar responds to Neovim
#32Perhaps 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).
Re: Bram Moolenaar responds to Neovim
#33He's right. With every project, there's a tradeoff between achieving the goals of the project and maintaining compatibility with existing systems. As a Go programmer, I feel a bit sad/ashamed to be saying this, but look at Plan 9 - it failed to usurp Unix (and its descendants) as the dominant OS, because the latter was "good enough", and was already more widely supported and used. Plan 9 vs. Unix is a very different…
I think the other factors in play are the dominant ones in the Unix/Plan9 issue, though. The original "upstream" of Unix was Research Unix, the stuff the Bell Labs researchers were working on. V1 came out in 1971. But V7, released in 1979, basically got forked into a bunch of commercial Unixes (and indirectly, some free ones via the BSDs). Research Unix V8, V9, and V10 got virtually no uptake, despite being incremental evolutions of the original upstream, due to a mixture of inertia and licensing restrictions from AT&T. Instead, different incremental evolutions of V7, developed by other developers outside Bell Labs, became the dominant strains of Unix.
Plan9 was a pretty significant departure from Research Unix V7, but not as significant a change compared to V10... which didn't matter because nobody outside Bell Labs was using V8/9/10 anyway, since everyone was working on various forks of V7 (BSD, SunOS/Solaris, Xenix, etc.).
Re: Bram Moolenaar responds to Neovim
#34To 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.
What were the features they submitted? Stuff that's mentioned on the github page or something else?
Multithreading and job control
Re: Bram Moolenaar responds to Neovim
#35He's right. With every project, there's a tradeoff between achieving the goals of the project and maintaining compatibility with existing systems. As a Go programmer, I feel a bit sad/ashamed to be saying this, but look at Plan 9 - it failed to usurp Unix (and its descendants) as the dominant OS, because the latter was "good enough", and was already more widely supported and used. Plan 9 vs. Unix is a very different…
But isn't Go itself an example of success with a complete rewrite?
Good point.
If you view Go as a "rewrite" of C, then perhaps, but I wouldn't. It's a new language altogether. C can be embedded in Go easily, and even if it couldn't, there's no reason that one has to "win out" over the other. There's less direct competition between two languages than there is with a family of OSes. And Go was never intended to replace C completely - it just provides a better alternative for some subset of what C/C++/Java are used for. On the other hand, any given system is going to run only one OS[0].
In any case, as I mentioned, it's a tradeoff. There's no absolute answer, though I think he's right here in that the benefits don't outweigh the costs for this example.
Put another way, much as I might like to run a microkernel, I'd have a hard time concluding that it'd be the right move for the Linux project to spend time refactoring the entire codebase into a microkernel!
On the other hand, to see an example of a rewrite that was successful, look at Reddit, which rewrote the entire codebase in its early days. GCC could also be considered an example, depending on how you look at it.
[0] You can run more than one via virtualization, sure, but a number the benefits of Plan 9 come from having an entire set of computers running the same OS.
Re: Bram Moolenaar responds to Neovim
#36Perhaps 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).
Huummmmm no
Neovim is being sold as a VIM refactor, but apparently with no new functionality
Very different from Linux (had an aim of being a playground for new features), tmux is different from screen as Clang is different from GCC, Subversion is a totally different beast from CVS
Re: Bram Moolenaar responds to Neovim
#37Perhaps 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.
> tl;dr Things you should never do: rewrite the code from scratch.
Considering vim itself is a from-scratch 'vi' clone, that's interesting advice. :)
But in any case, I see this as more of a fork than a rewrite. It's more akin to the XEmacs/GNU Emacs situation, where someone submits significant patches upstream which aren't accepted, and then forks their own version to continue that line of development.
Re: Bram Moolenaar responds to Neovim
#38Perhaps 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.
When we started work on Commandos 2, we threw away everything from Commandos 1, and started from scratch. 15 years down the road, all the coders still agree that was the best decision ever.
Were you on the Commandos team? Mad respect to you. Probably my most favourite game of all times. Thanks for working on it.
Re: Bram Moolenaar responds to Neovim
#39It'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.
The code if fill of typedefs for AMIGA and OS/2.
There's nothing wrong with that as long as those typedefs are properly isolated in some platform-specific header files.
It's natural to have an initial feeling of being overwhelmed by that kind of stuff. However, it often turns out that there's nothing to gain from removing that stuff.
The only real cost is when people expect a platform to work, but nobody from that platform is willing to put in the testing effort.
Re: Bram Moolenaar responds to Neovim
#40Perhaps 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.
> Things you should never do: rewrite the code from scratch. I can clearly see the benefit of this old wisdom under context of limited resource and limited time, esp. in a commercial company. However, as an experimental, personal(?), non-profit, free/open-source project, I do think neovim has value in its own right: 1. It won't affect any existing plan of vim, and won't change any existing code in vim. We can still h…
I came to say this exactly.
In a commercial project where time and money are limiting factors, you are almost insane to rewrite from scratch.
In an OSS context, money is not always the biggest mover, and doing this might actually succeed, or at least not fail because the company fails. It certainly may be that the people lose interest before it gets anywhere, but who cares! The only reason that I could see is that someone wants to fold all their code changes back into vim's original codebase, and they both seem to have different end goals, so eventually they will drift away from each other.
Code evolution.