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

71–80 of 151 posts

Re: Bram Moolenaar responds to Neovim

#71

Post by Someone »

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 makes you think this is a rewrite? If this is a rewrite from scratch, they are insanely fast coders, considering that they have a full-blown editor in less than a month (first commit is from January, 31)

That first commit also shows it is not a rewrite, though, since it has a comment starting with "Import vim from changeset v5628:c9cad40b4181"

Re: Bram Moolenaar responds to Neovim

#72

Post by kzrdude »

Vim is not a healthy project. Example: They support transparent encryption for documents, but refuse to address or document the shortcomings of their implementation. It's of course a fully custom implementation of a half-homerolled protocol.

Main flaws: Apart from implementation issues, non-authenticated encryption susceptible to bitflipping.

Re: Bram Moolenaar responds to Neovim

#73

Post by ageofwant »

My $20 is totally worth the "risk". Here's some dude from Brazil, that has at least some demonstrable skill, willing to take a month and have a go at improving a tool I use every day. For the price of four coffees.

As for Bram, he can, and most likely will continue his good work on vim. I am kind of disappointed that he is not more supported of this effort though.

Re: Bram Moolenaar responds to Neovim

#74

Post by InclinedPlane »

Pacabel wrote: post #69
InclinedPlane wrote: post #63

Earlier quoted context omitted.

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

An even bigger problem, in my opinion, is the idea (usually only implicit) that any advice can apply to the entire panoply of software development. As though writing Flappy Bird and writing control software for the Falcon 9 weren't as different as banging together some shelving using plywood from home depot and machining custom components from exotic alloys using a lathe. An important part of maturing as a developer is learning to understand that different situations call for different techniques and being able to know what things are truly important with a given project and which aren't.

Re: Bram Moolenaar responds to Neovim

#75

Post by ageofwant »

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.

You can not see the concrete user benefits of a modernised, cleaned up code base ? Maybe you need to look harder.

Re: Bram Moolenaar responds to Neovim

#76

Post by ayosec »

This reminds me to the origin of Inkscape, as a fork from Sodipodi. The (only) Sodipodi committer didn't want too many patches, and he wanted to stay with C (no C++ code).

Some people forked Sodipodi, and created Inkscape. I can remember that one of their first tasks was to make the code compatible with a C++ compiler.

Nowadays, Inkscape is a very good tool, and I hope that Neovim has a great success too.

Re: Bram Moolenaar responds to Neovim

#77

Post by guyzmo »

mden wrote: post #46
raverbashing wrote: post #36

Earlier quoted context omitted.

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

Neovim isn't a simple refactor though. It adds the ability to do many things which aren't currently possible or are extremely difficult to do with the current vim. Sometimes there is no easy way out and you have to put in the work to fix previous limitations.

well, if you want a re-think/re-factor of vim, you should definitely have a look at kak (https://github.com/mawww/kakoune).

It's basically trying to improve over vim, still using command/insertion modes, inverting the commands (by using movement/action instead of action/movement)… It's pretty configurable and the codebase is new.

definitely worth a try!

Re: Bram Moolenaar responds to Neovim

#79

Post by jey »

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.

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 GCC are direct descendants of EGCS.

Re: Bram Moolenaar responds to Neovim

#80

Post by kbrosnan »

haberman wrote: post #32
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.

With that thinking we never get Linux (NeoMinix), tmux (NeoScreen), Clang (NeoGCC), WebKit (NeoGecko), Subversion (NeoCVS), or Vim itself (NeoVi/Elvis/Stevie/etc).

WebKit does not work for your analogy. WebKit and Gecko are two completely separate HTML parsing engines. Maybe you ment neo-kHTML.
Post reply on HN