Hacker News Reader

Comment by johncoltrane | Hacker News Reader

That's not what he said. He said that Neovim's goals could be achieved without cutting out features and removing supports for exotic OSes.

View on HN

>He said that Neovim's goals could be achieved without cutting out features and removing supports for exotic OSes.

That's the same as what parent said.

Neovim's #1 goal (from the webpage) is: "Neovim is a project that seeks to aggressively refactor Vim in order to simplify maintenance and encourage contributions". And other goals including adding new features for the future.

You might not 100% HAVE to drop "supports for exotic OSes" for that, but is extremely logical, and very much helpful in that direction.

Anything that reduces code size makes it easier for maintanance. You don't want to have to check how things play for those IFDEFS for Amiga OS when you write code for 2014.

Dropping support for exotic OSes frees you from having to test on that OSes.

Given that the statement is very short, I'd expect that cutting out features is the point Brad puts more weight on.

For example, Neovim has plans to remove ex:

https://github.com/neovim/neovim/issues/1089

Exotic is also a matter of definition, there are still applications in use on those oses, and supporting them is a service to those that have to work in them. Not everyone is building apps for Heroku deployment nowadays.

While true, many of those OSes are not updated anymore. So good old Vim (4, 5, 6, 7) will serve them just fine. More than that, several of them (Amiga, BeOS, etc.) run on underpowered machines so the latest and greatest Vim updates won't run on them anyway. We could say that they're well served by Vim 5, for example.

In your concrete example of a feature being removed, Neovim is actually removing a misfeature: the interactive ex mode, not the command line ex mode. The feature they're removing is akin to: http://xkcd.com/1172/.

I use ex maybe once a year, when $TERM is screwed up or latency is terrible, but to me removing it is a red flag that says the NeoVim folks don't really grok vi.

This was my initial take, but all that's really being removed is the ability to switch between ex mode and visual mode - to which my objection is substantially weaker (to the point that code clarity and separation of concerns are probably more important).

I'm not aware of any vim developer that uses the ex mode, to be honest. Simplicity is a feature, and when something like ex mode is bloating the code, the best option is to remove it. There are other better ways to script neovim.

This has been discussed before and several people said they use ex for scripting (with pipes). However, NeoVim is not removing that, only the UI for ex mode.

Hi! I am a developer who uses ex mode from time to time. Now you're aware of one.

I objected when I thought they were removing all support for ex; as it turns out, they're only removing support for switching between visual mode and ex mode - making them two separate front-ends. That's not a problem.

I guess Bram's point of view is that you could refactor the codebase without removing support, i.e. instead of a 400 line function with ten ifdefs, a 20 line one for the "sane" platforms and extra per-platform shims overriding it.

I am with the neovim guys on this, but you can refactor without removing features (in fact, the original meaning of "refactoring" was in fact "code improvements with no functionality changes")

A refactoring that removes features is not a refactoring; it's a massacre.

And yes, removing features and support for some OSes is not a prerequisite for reaching neovim's goals. It will make it easier for them, that's for sure, but that is absolutely not a given, at all.

In practice, is it a feature to be available on a given legacy platform? For most users, no relevant feature is lost when legacy support is removed.

>A refactoring that removes features is not a refactoring; it's a massacre.

Features that aren't used (or used in very rare cases) can, and in many cases should, be ruthlessly cut out in a refactoring.

By definition we care for the features that we care about. If noone (as in: very small value of "some people") cares about Amiga OS support, it should be removed to have a cleaner codebase.

Else in 2050 they'll be wondering what this Oric Atmos is, and why it needs 400 IFDEFS in vim code.

>And yes, removing features and support for some OSes is not a prerequisite for reaching neovim's goals. It will make it easier for them, that's for sure, but that is absolutely not a given, at all.

More mevelopers should get familiar with the notion of "opportunity cost".

Removing features that aren't used should often be done, but I'm hesitant to call it "refactoring". Most definitions say that a refactor doesn't change external behavior. Removing features has additional ramifications - good and bad - and probably deserves to be called out more explicitly.

Refactoring in its pure form yes, but people use refactoring to mean any large scale restructuring of a program not just following refactoring patterns that produce the same result as before.

In practice large scale refactoring and change in behavior (dropping some features, fixing some stuff) are pretty much tied together.

I don't object to using "refactoring and ..." for such. I've weak objection, in terms of clarity and what we should be clear about, to using "refactoring" alone for it. I agree that it's not terribly uncommon.

In my opinion starting out from the mess that vim's code base has become over the years, can't result in something good.

That is why I started from scratch:

https://github.com/martanne/vis

The best part of the repository is the README explanation about how it works.

Reply on news.ycombinator.com