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

51–60 of 151 posts

Re: Bram Moolenaar responds to Neovim

#51

Post by pit »

haberman wrote: post #42
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 is being sold as a VIM refactor, but apparently with no new functionality Where did you get that idea? When I read the project page ( https://github.com/neovim/neovim ), two of the explicit goals are: "Enable the implementation of new/modern user interfaces without any modifications to the core source. "Improve the extensibility power with a new plugin architecture based on coprocesses. Plugins will be writt…

The original mailing list post says:

"There's a new project that is called Neovim that seeks to refactor and modernize the codebase."

Re: Bram Moolenaar responds to Neovim

#53

Post by pit »

haberman wrote: post #42
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 is being sold as a VIM refactor, but apparently with no new functionality Where did you get that idea? When I read the project page ( https://github.com/neovim/neovim ), two of the explicit goals are: "Enable the implementation of new/modern user interfaces without any modifications to the core source. "Improve the extensibility power with a new plugin architecture based on coprocesses. Plugins will be writt…

The original mailing list message says:

"There's a new project that is called Neovim that seeks to refactor and modernize the codebase"

Re: Bram Moolenaar responds to Neovim

#54

Post by btipling »

shmageggy wrote: post #16
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.

What were the features they submitted? Stuff that's mentioned on the github page or something else?

At Floobits we tried to submit set_timeout/async stuff, and couldn't get anywhere with Bram. Months of work wasted.

https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM%...

Re: Bram Moolenaar responds to Neovim

#55

Post by mekarpeles »

raverbashing wrote: post #36
haberman wrote: post #32

Earlier quoted context omitted.

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

To a degree, I think these distinctions both support and are a logical consequence of haberman's argument (please correct me if I'm wrong). As computing systems evolves, we learn more about how to address their constraints and how these constraints impact how users choose/desire to interface with their programs. Vim is publicly ~22 years old. During it's maturation, many computing milestones have been met which overcome many of the original assumptions or challenges which prevented us from using some of the interfaces we prefer today. Async (re: MarcWebber) being one such example.

I believe tmux / screen is a beautiful example, given Screen has a lot of black magic and has a very challenging codebase to work with. A lot of the philosophy built into tmux are cumulative learnings deduced from what was done correctly or incorrectly within screen. This materializes as features missing (or implemented with different intent) from tmux that exist in screen -- the philosophy behind sessions is one such big underlying principle change.

I like to think of this as similar to using a genetic algorithm to evolve an overly complex/convoluted solution over a period of time (based on some assumptions which may no longer even be applicable), and then explicitly defining/reconstructing a comparable solution using more deterministic and intentional approaches. The focus of these two development cycles are fundamentally different and perhaps neither wrong (the former attempts to discover novel ways of addressing a problem whose solution is unknown, the latter prunes this known search space).

Re: Bram Moolenaar responds to Neovim

#56

Post by 4ad »

mjn wrote: post #33
chimeracoder wrote: post #21

He'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 increment…

I agree Plan 9 is not a good example in this story. Plan 9 didn't failed because of the problems associated with a re-write as described in Joel's post, but because of political and social issues.

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

I'm not sure what you mean by inertia. v8-v10 were not widely released to avoid another BSD incident.

v8-v10 were 4.3BSD derivatives, so I'm not sure I'd call them incremental evolutions on the original upstream. They removed and/or reworked all the new BSD stuff though, and the basic userland was very custom. Some of it survives (in some form) in Plan 9.

Re: Bram Moolenaar responds to Neovim

#57

Post by andrewflnr »

chimeracoder wrote: post #35
pcwalton wrote: post #27

Earlier quoted context omitted.

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

Re: Bram Moolenaar responds to Neovim

#58

Post by [deleted] »

middleclick wrote: post #38
Jare wrote: post #28

Earlier quoted context omitted.

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.

[deleted]

Re: Bram Moolenaar responds to Neovim

#59

Post by alecthomas »

Jare wrote: post #28
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.

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.

Man, I loved Commandos 1 back in the day. I recently got a bit nostalgic and bought the whole series on Steam, and they are still great games! But MAN are the controls opaque. Thinking back, I think the game came with a little cardboard sheet with all the controls on it, which would have been easier to deal with.

Fantastic game though, thanks :)

Re: Bram Moolenaar responds to Neovim

#60

Post by tokenrove »

ggreer wrote: post #50
nhaehnle wrote: post #39

Earlier quoted context omitted.

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

Have you looked at the Vim source? There are a few things in platform-specific headers, but most ifdefs are scattered in actual code. There are even ifdefs in the middle of control flow statements. For example, in RealWaitForChar(): https://github.com/b4winckler/macvim/blob/master/src/os_unix... That function is over 400 lines and has over 50 ifdefs. What does it do? It waits for any key to be pressed. Unfortunately,…

If that example (eval.c) is supposed to be bad, I don't think there's a strong case here. It looks like lots of older Unix/BSD code, and most of the ifdefs are feature-related, rather than platform hacks; some of the functions are a bit long, but that's typical in older C code.

I've never read the vim code before and I was surprised how cleanly written and well-commented it is, given my expectations set by this thread.

Post reply on HN