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

111–120 of 151 posts

Re: Bram Moolenaar responds to Neovim

#111

Post by z3phyr »

Abrash wrote in his graphics programming black book, and I quote, Carmack's law ->

"I’ll take this opportunity to coin Carmack’s Law, as follows: Fight code entropy. If you have a new fundamental assumption, throw away your old code and rewrite it from scratch. Incremental patching and modifying seems easier at first, and is the normal course of things in software development, but ends up being much harder and producing bulkier, markedly inferior code in the long run, as we’ll see when we discuss the net code for QuakeWorld. It may seem safer to modify working code, but the nastiest bugs arise from unexpected side effects and incorrect assumptions, which almost always arise in patched-over code, not in code designed from the ground up. Do the hard work up front to make your code simple, elegant, great—and just plain right—and it’ll pay off many times over in the long run."

Re: Bram Moolenaar responds to Neovim

#112

Post by ChuckMcM »

Every 10 years or so I think some energetic programmers should set about writing God's Own Text Editor. There have been a lot of really useful technologies that have come from those efforts, whether it was EMACs, Gosling EMACs, vi, vim, pfe, visual slick edit, sublime text, or even wordpad. An editor is a fairly complete system, well within the capabilities of a single motivated individual, and like cocktail gowns entirely fashion/taste driven.

Re: Bram Moolenaar responds to Neovim

#113

Post by teacup50 »

kzrdude wrote: post #87
perlgeek wrote: post #13

Earlier quoted context omitted.

> The code if fill of typedefs for AMIGA and OS/2. Useful to a small number of people certainly, but making progression harder too. Sounds like the code of pretty much every non-trivial C program that is meant to run of many platforms, not just the five or ten most popular ones. I'm not saying that this is a good thing, just that I don't know any good alternatives that don't sacrifice compatibility with lots of platf…

It should say ifdefs, not typedefs. Inline ifdef directives everywhere is a real nightmare. The very first commit in neovim includes this log: - Process files through unifdef to remove tons of FEAT_* macros

Which is exactly the sort of pointless "refactoring" that someone does instead of actual refactoring.

It also makes merging back to vim difficult to impossible.

Expect to see 'neovim' development dissipate rapidly.

Re: Bram Moolenaar responds to Neovim

#114

Post by ggreer »

teacup50 wrote: post #88
btipling wrote: post #54

Earlier quoted context omitted.

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

Your patches were broken. People spent plenty of time trying to help you fix them. Your response is to tell the Internet that Vim is wrong for not accepting broken patches?

All of the crashes we encountered can be reproduced with stock Vim, using a combination of updatetime and CursorHold/CursorHoldi autocommands. These are bugs in Vim, but they're rarely hit because few plugins (ab)use Vim in this way.

Re: Bram Moolenaar responds to Neovim

#116

Post by gradstudent »

mekoka wrote: post #98

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 attract users and thus developers NeoVim will be left forever playing catchup with Bram's original creation -- constantly rewriting new features to remain relevant and forever fixing both old vim bugs and new NeoVim-specific bugs.

Re: Bram Moolenaar responds to Neovim

#117

Post by Jasber »

ampersandy wrote: post #109
Jasber wrote: post #106

Earlier quoted context omitted.

Did you read the same thread I did? Floobits addressed all the issues. It came down to a fundamental design decision—and after months of hard work, they got a non-answer.

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…

I agree segfaults are a problem if caused by the patch, but it looks like those may have been bugs in VIM itself.

I think the bigger problem was just that nobody could agree on the cancel/freezing timer issue.

To me that's a design decision a maintainer has to make, not someone submitting a patch.

Re: Bram Moolenaar responds to Neovim

#118

Post by fsloth »

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.

Joel has lots of right things to say, but I'm afraid that one - "Never rewrite from scratch" - is far too sternly interpreted to the point where it is actually more harmful than beneficial.

Of course you can rewrite from scratch. You just should not expect to reach the same feature coverage instantly, and should approach the work methodically. Most of all, you should have a good reason. "This code is spaghetti" is usually not one. "I want to implement feature X and the current codebase does not really support is" could be a good reason.

Also, a rewrite is pointless from the point of view of code quality unless you are familiar with similar codebases operating in a similar domain.

Main advantages or rewrite are, that when you are a domain expert and implementing and designing core routines, you get constant flashes of intuition "Aha, I should add this interface here because that will enable me to implement Foo and Bar using this instead of writing a FooSubsystem and BarSubsystem" and so on.

If you have no experience from the domain, you get those insights only after you've written the code and are actually new proud owner of new heap of semi-maintainable code.

Re: Bram Moolenaar responds to Neovim

#119

Post by ordinary »

kamaal wrote: post #110
hglaser wrote: post #8

Why aren't there other vim committers? Bram's conservatism makes perfect sense for someone who has to maintain this huge, consequential, intimidating codebase. Why hasn't he gotten some help?

Big old code bases, have a lot of what I call as 'tribal knowledge' associated with them. People go out, and do experiments only to burn their hands. Over years, the old maintainers generally accumulate a lot of ideas and 'tribal knowledge' to know why 'pie in the sky' ideas won't work. Nevertheless, people still try. A lot of them fail, a few succeed. The vim code base is around 300K lines of C code. I'm sure its no…

The vim code base is around 300K lines of C code.

I found this hard to believe, so I ran it through cloc:

  ----------------------------------------------------
  Language      files      blank    comment       code
  ----------------------------------------------------
  C               113      33366      61819     285817
  vim script     1186      22871      32599     145700
  C/C++ Header     63       3175       4626      19735
Slightly more than 300k, but still mightily impressive.

Re: Bram Moolenaar responds to Neovim

#120

Post by weavie »

gradstudent wrote: post #116
mekoka wrote: post #98

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…

That will depend on which way the extension developers go after that. If they all flock to neoVim then it will soon be the case that you have to use neoVim in order to use the best extensions.
Post reply on HN