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

131–140 of 151 posts

Re: Bram Moolenaar responds to Neovim

#131

Post by fmoralesc »

jballanc wrote: post #127

The old Unix ways are dying... Or, at least, I think that's the best way to summarize the essential miscommunication between these two camps. Vim is, in the spirit of Unix, a single purpose tool: it edits text. Why would it need threading? async? background jobs? You can't type in two places at once, right? NeoVim wants to be something like an IDE-lite. Text editing, yes, but with the ability to do background compila…

> You can't type in two places at once, right?

You might want to. See https://floobits.com/

Re: Bram Moolenaar responds to Neovim

#132

Post by fmoralesc »

psquid wrote: post #104
svalorzen wrote: post #68

Earlier quoted context omitted.

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…

> 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 For python at least, having 'preview' as part of your completeopt has it display the docstring of what you're completing. And :h completeopt suggests that's intended behaviour for all types of completion (where it makes sense), too.

Yes, but currently retrieving that info is done synchronously, so it might slow down things. Under neovim's model, this can be done more efficiently.

Re: Bram Moolenaar responds to Neovim

#133

Post by btipling »

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…

We actually continued to work on the fork until it was clear Bram wouldn't be responsive to any more changes. Once it became clear he wouldn't accept the patch we stopped wasting more time as we are trying to create a viable business. We weren't going to sink our startup for the sake of vim, as much as I love the editor. We spent a long time, it was a frustrating experience, so yes we tell the internet when it comes up. Any of the freezes we found we would have loved to patch back into vim had this gone differently, and it would have been a lot of work.

Re: Bram Moolenaar responds to Neovim

#134

Post by jamesrcole »

perlgeek wrote: post #6

It'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…

> ...code base full of weird special cases ... _often_ turns out that all this cruft is there for a reason. It's essential complexity... (my emphasis)

If it's often, then it's not always, which means that in some cases it could be done better. Is Vim one of those cases? I don't know, but you don't give any reason to suggest that it isn't.

Re: Bram Moolenaar responds to Neovim

#135

Post by dhimes »

Pacabel wrote: post #67
TazeTSchnitzel wrote: post #43

Earlier quoted context omitted.

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

I think you are coming dangerously close to muddy semantics. Let's say: a clone is a clone- git clone, hg clone, etc.

A rewrite may start with a clone, but the code is no longer a clone when you start the rewrite.

A refactor is a subset of a rewrite.

Now we can have meaningful discussions about them.

Re: Bram Moolenaar responds to Neovim

#136

Post by ansible »

jballanc wrote: post #127

The old Unix ways are dying... Or, at least, I think that's the best way to summarize the essential miscommunication between these two camps. Vim is, in the spirit of Unix, a single purpose tool: it edits text. Why would it need threading? async? background jobs? You can't type in two places at once, right? NeoVim wants to be something like an IDE-lite. Text editing, yes, but with the ability to do background compila…

In some ways, neovim keeps to the Unix spirit better than vim. People already use vim as an IDE, but it doesn't work well in many cases. And the alternate user interfaces are not as good as they could be.

If you've got a clean separation between the editing engine and the rest of the IDE suite of processes, that is the Unix way in my view.

Re: Bram Moolenaar responds to Neovim

#137

Post by egeozcan »

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.

A general statement such as "never rewrite" is as good as something like "never grow a beard" - while it may be a good advice for someone working in a traditional corporate environment, it certainly doesn't make sense, let's say, for a freelancer.

Re: Bram Moolenaar responds to Neovim

#138

Post by ksk »

z3phyr wrote: post #111

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

If you watch any of Carmack's recent keynotes you'll see hes advocating doing the opposite now. Whats changed is the multi million dollar risk profile associated with modern game releases, the huge increases in the sizes of the teams, the large scale complexity of modern AAA code-bases, etc. And also the fact that most games now are data-dominant rather than being sold entirely on some new game-engine feature(s).

Re: Bram Moolenaar responds to Neovim

#139

Post by oftenwrong »

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.

Commandos 2 is one of my favorite games! I wish there were more games with the same mix of stealth and strategy being made.

Re: Bram Moolenaar responds to Neovim

#140

Post by emidln »

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.

Teams I've been a part of are 3/4 (3 successes, 1 failure) on total rewrites over my career. The failure was entirely my fault as a developer not knowing my own limits (coding, design, security, devops, business reqs, managing up can't happen (at least for me) in the same 60 hours a week). It still almost succeeded on strength of the design and ability of my amazing coworkers to aggressively simplify and consolidate all the things.

Rewrites fall into two categories: essential to business and doomed to fail. If it's essential that the business execute on a rewrite, it will happen or the business will fail. If it's not essential, it very well might be the reason the business fails (siphoning away talent and squandering time when a refactor or benign maintenance would suffice). Precisely because massive rewrites are so risky, they are undertaken by the foolish (myself firmly in this camp). The heuristic under which they might succeed is bare necessity.

Post reply on HN