Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bram Moolenaar responds to Neovim

groups.google.com

Post reply on HN
Print view View original

61–70 of 151 posts

Re: Bram Moolenaar responds to Neovim

#61

Post by andrewflnr »

CJefferson wrote: post #7

To 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.

> To be fair to the authors of neovim...

Sounds to me like you need to go farther. "We should improve what we have" totally fails as a criticism when written by the same guy who won't let the product in question be improved.

If there's good reasons not to admit patches, fine, let's hear them, but don't give me this glib "we should improve what we have" crap. I can hardly believe that's basically his only answer.

Re: Bram Moolenaar responds to Neovim

#62

Post by Cederfjard »

sramsay wrote: post #2

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.

I'm somewhat confused by your comment, since the GitHub page explicitly says that NeoVim "is not a project to rewrite Vim from scratch". Where's the discrepancy here? Perhaps I'm just too tired right now.

Re: Bram Moolenaar responds to Neovim

#63

Post by InclinedPlane »

sramsay wrote: post #2

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.

Spolsky is wrong.

Rewriting is a significant risk, and rewrites often fail because people don't appreciate that fact. But there are ways to rewrite successfully, and often doing so is the correct course of action.

A big problem with rewrites is that it puts a strain on development resources, and it's not possible to maintain both old and new code at the same time. Another big problem is prematurely committing to the rewrite, before it has proven itself. When the inevitable happens and schedules slip, defects arise, and features need to be cut this can prove disastrous for a rewrite that you've foolishly committed to in advance. Also, people often ignore the value of years of productive use which provides testing and validation of immense value.

If you have the resources often the best choice is to spin off a new project for a rewrite and have them compete in the open. With luck the rewrite could become mature enough to overtake the original (as has happened with many projects). Alternately, work in phases doing refactoring in steps, perhaps with new features behind feature flags.

Many people think that rewriting code is easier than green field development, in reality it's often more difficult. It takes a great deal of skill, and often luck, to manage a good rewrite.

Re: Bram Moolenaar responds to Neovim

#64

Post by benched »

sramsay wrote: post #2

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.

There is probably no Spolskyism that I disagree with more. And yet, I don't really disagree with what he said in context. The context is within a business where the opportunity cost could make it not worth it. If the only concern is making the software better, my experience is that rewriting does wonders for old code.

Re: Bram Moolenaar responds to Neovim

#65

Post by anon4 »

sramsay wrote: post #2

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.

What you're missing is that Netscape rewrote their own product from scratch. Neovim is a fork bringing very invasive changes (not rewriting from scratch) to a project by a different developer for the purpose of extending the original project in ways the current maintainer doesn't want to.

So it's more like taking the old netscape code and making gecko.

Re: Bram Moolenaar responds to Neovim

#67

Post by Pacabel »

TazeTSchnitzel wrote: post #43
mjn wrote: post #37

Earlier quoted context omitted.

> 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.

Clones and rewrites aren't really comparable, though.

They're pretty comparable. A "clone" can almost always be considered a subset of a "rewrite". Both involve a new software system that is directly inspired by an existing one.

The main difference is that a clone is often written by developers who had no involvement with the development of the original system. But that's not always true, especially for any old or sizable software system, where the original developers may no longer be involved.

Re: Bram Moolenaar responds to Neovim

#68

Post by svalorzen »

aeonsky wrote: post #45
tinco wrote: post #9

Well 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 a…

I still have yet to see these concrete user benefits.

The benefit is indirect rather than direct, as in the user benefits from the increased availability of plugins/guis since they would be easier to create. Also vim lacks lots of very simple but essential features of modern code editors simply because it lacks the graphical capabilities to do so (an example would be displaying the documentation of some method you are autocompleting, something which I have never seen in vim and which I actually believe is impossible).

Re: Bram Moolenaar responds to Neovim

#69

Post by Pacabel »

InclinedPlane wrote: post #63
sramsay wrote: post #2

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.

Spolsky is wrong. Rewriting is a significant risk, and rewrites often fail because people don't appreciate that fact. But there are ways to rewrite successfully, and often doing so is the correct course of action. A big problem with rewrites is that it puts a strain on development resources, and it's not possible to maintain both old and new code at the same time. Another big problem is prematurely committing to the…

A significant problem is that there are a lot of developers today who revere Spolsky as some sort of a god, and absolutely refuse to question or reconsider anything that he has written.

This trend is particularly bad with those who've gotten involved with software development since 2005 or so.

I chalk it up to a lack of experience with massive, multi-decade software projects. If all a developer has worked with are small, recently-written Ruby on Rails apps, for example, then I don't think they can appreciate situations where rewrites of some degree are the only viable option.

Hopefully this attitude regarding Spolsky's writing will change with time, as these people encounter the real-world situations where significant or total rewrites are basically the only possible option.

Re: Bram Moolenaar responds to Neovim

#70

Post by Pacabel »

andrewflnr wrote: post #57
chimeracoder wrote: post #35

Earlier quoted context omitted.

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 sub…

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.

Post reply on HN