Hacker News Reader

Comment by fournm | Hacker News Reader

I agree with almost everything--except for backwards compatibility when it comes to throwing stuff out. There is definite value in it, especially when we're talking about something as old and widely used as vim!

The thing about compatibility is that it doesn't matter how great your new and shiny is if it can't talk to old things at all. Imagine the best new text editor in the world, but it's completely incompatible with every file format that's ever been written previously, even .txt! No one would use it, because the cost of switching is too high.

In some cases, it's definitely worthwhile to have some development pain to keep that around. Stuff like keeping vimscript (and therefore the entire ecosystem around vim) functioning means that neovim could be a drop-in for some people, and HAS to be preserved at least partially. Stuff like keeping ancient Amiga support or integration with Sun workshop? Definitely not worth it anymore.

View on HN

    I agree with almost everything--except for backwards compatibility when it comes to throwing stuff out. There is definite value in it, especially when we're talking about something as old and widely used as vim!

This is the part where people are surprised, but I am an extremist. I definitely think backwards compatibility should be among the lowest priorities when making decisions on improving software, especially and perhaps just, in Open Source.

Just think about it. What happens when we decide a certain core feature of Vim is archaeic, and could be implemented in a more modern, more flexible, more loosely coupled way.

First, every vim plugin would break. But if you look at how many Vim plugins are actually used, I would be surprised if the top 100 Vim plugins covered less than 99.99% of all Vim users. That means we only have to upgrade 100 Vim plugins, and probably just a couple of lines if they're written well.

How much technical debt have we accrued now, that in reality could be paid off just by biting the bullet and going through a hundred pieces of software and changing a couple of lines?

This is open source, we could just do it. (tm)

The problem is you broke compatibility now. Will you do it again next year, and fix 100 plugins once more?

I am also not a big fun of extreme forms of compatibility, but plenty of projects try to break it only to have people which stick around with old versions for years.

Big projects like Python only break compatibility once every few years, and a lot of thought goes into it. I think it's a lack of respect to the authors of Python and perhaps a lack of authority of Guido that packages are not being upgraded to Python 3.

I wonder what would happen, if just a few companies that actively use Python, like Google, would hire a few devs that for a year would only fork and fix Python 2 projects. Wouldn't it just solve the problem? I bet they'd be done within a couple of months too, and they wouldn't even have to be super senior types.

Almost all major Python packages have now been upgraded to Python 3. For example, only 3 or 4 of the Top 50 have not been upgraded, and all but 1 of those are in the process of updating.

It's now mostly just the thousands of smaller packages that still are on Python 2 only.

But Python couldn't get away with that more than once every 10 years.

Maybe I would have upgraded to python 3 by now if I saw any compelling reason to do so (like, say, getting rid of the GIL).

As a user of software - fuck you, and may you never touch anything I use. It's juvenile oo-look-shiny nonsense like this that makes us people who just want to get shit done waste yet another afternoon on patching working stuff after a (forced) update because some wet behind the ears dude decided that everybody before him was a utter moron.

There is a reason people pay for software that just works, and will work for the next few years. It's because they're fed up with being the guinea pigs for architecture astronauts and code purity fetishists.

Also, "that means we only have to upgrade..."

Who is "we" here? You? Of course not, you're too busy chasing the next fad, while the rest of us have to repare shit just to make it do again what it aready did before.

Haha, thanks roel. I'm so glad to be relieved of the duty to try to improve things you use...

And let me extend my apologies in name of all the authors of software whose extra features and nice bug-freeness you enjoyed at the terrible cost of going through the gruelling process of having to upgrade your software.

Perhaps all us developers of modern software could get together raise funds so you could get a refurbished pink iMac G3. Before all those pesky Apple people started their code purity fetishist backwards compatibility breaking migration to a BSD+Mach based OSX.

That's pretty funny. OSX has far more backwards-compatibility with old software than OS <= 9. Heck, it even comes with vim and an xterm-compatible terminal preinstalled.

Haha, that's funny indeed. I hadn't looked at it that way :)

Agreed the OP was harsh in response but the point made regardless. Your caviler attitude in this thread, and overall post, makes me question your maturity as an industrial grade programmer but that moves towards ad hominem instead of healthy debate...this is not a sleight and will agree I lost the debate before it started.

Do keep in mind that modern software as you state are great tools for completed tools but very little options for those that create the tools themselves, IDE's for example but not limited to that concept. This leads to my point:

To paraphrase the OP, maybe some things should not be fucked with for "code purity" in the name of functional purity. If you vehemently disagree, make a better product. Critical mass will replace the failed ideology that ultimately leads to a better technology. All the flame wars in the world won't change this fact and ultimate outcome.

Thanks for not digressing :) To address your concern, yes I am not very mature as an industrial grade programmer. I have plenty of professional experience, but there's also plenty of experience still to be had.

I do understand my comments are inflammatory, and did not expect at all they'd be upvoted more than downvoted, but that seems to be the case.

Your standpoint is the one many in this thread have and I understand the least. This idea that "code purity" and functional purity are different.

The only reason that LaTex can not be improved is that its code is unaccessible. This means its functionality lies rigidly restricted in the 80s. In my opinion, there's nothing functionally pure about 70s/80s software. Back then, functionality followed from hardware restrictions.

I think you miss a major thing here: if you put vim with just it's top 100 plugins up against Sublime Text, I think it will easily lose. Why would I even use that? It's because of the long tail of thousands of plugins (your 1% usage) that I choose vim/emacs (more specifically, each power user chooses it because of the set of many of those top 100 hundred plugins + a handful of weird, obscure plugins that fit their needs perfectly.)

Maybe I'm wrong. I don't think I have any non-top100 vim plugins installed. I could be underestimating the problem by a large margin.

I sort of think that if just the top 100 plugins would be compatible, the authors of the non-top100 plugins would be motivated to migrate, as a sort of herd mentality thing.

This is the same kind of short-sighted programmer selfishness that leads to idiotic ideas like "let's abolish time zones and just everyone use UTC". Do you realize how many man-years of other people's time and effort you're proposing to spend adding zero value to that software?

First, every vim plugin would break. But if you look at how many Vim plugins are actually used, I would be surprised if the top 100 Vim plugins covered less than 99.99% of all Vim users. That means we only have to upgrade 100 Vim plugins, and probably just a couple of lines if they're written well.

Please don't invent fake statistics in order to support your argument. Vim's plugin ecosystem has a long tail distribution[0]. After just a cursory glance at vim.org's script repository you'll notice that even the 141st ranked plugin[1] has over 10,000 downloads. To find the first plugin with less than 1,000 downloads, you'll have to drop all the way down to sql.vim[2] which happens to be ranked 1501!

Personally, I happen to use (daily) multiple plugins which are ranked outside the top 1000.

[0] http://en.wikipedia.org/wiki/Long_tail

[1] http://www.vim.org/scripts/script.php?script_id=483

[2] http://www.vim.org/scripts/script.php?script_id=905

Please do not invoke factual information that contradicts the myopic view of the world as I see it. K thanx bye.

(Sarcasm aside, ^this)

Large scale proof why this is a bad idea: Python 2.x vs Python 3

Those of you who don't know about this mess, it shouldn't be hard to find some rants by googling. Basically Python 3 broke backwards compatibility with python 2 without providing any compatibility layer at all, they just expected every third party library to switch "sooner or later". It's now 10 years down the road and nothing has really happened. Everybody who gets shit done is still using 2.x because they need the old libraries.

Actually I see Python as a good example why you want to change. Python 3 has much cleaner concepts than Python 2: Strings are not byte arrays, use efficient generators by default, etc. On the other extreme take a look at C++: Lot's of ugly as hell syntax and pitfalls because of decades of backwards compatibility. See https://stackoverflow.com/questions/6939986/c-nested-constru... for an example of both.

> Everybody who gets shit done is still using 2.x because they need the old libraries.

And, btw., I hold each and everyone of these responsible as part of the chicken-and-egg problem.

Reply on news.ycombinator.com