4 ms·

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 tal

by fournm 13y ago

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.

tinco 13y ago
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)
- riffraff 13y ago
  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.
  - tinco 13y ago
    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.
    - jnbiche 13y ago
      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.
    - GFK_of_xmaspast 13y ago
      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).
- roel_v 13y ago
  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.
  - tinco 13y ago
    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.
    - deleted 13y ago
      [deleted]
    - bashinator 13y ago
      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.
      - tinco 13y ago
        Haha, that's funny indeed. I hadn't looked at it that way :)
    - devcjohnson 13y ago
- goldfeld 13y ago
  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.)
  - tinco 13y ago
    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.
    - philwelch 13y ago
      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?
- chongli 13y ago
  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 http://en.wikipedia.org/wiki/Long_tail [1] http://www.vim.org/scripts/script.php?script_id=483 http://www.vim.org/scripts/script.php?script_id=483 [2] http://www.vim.org/scripts/script.php?script_id=905 http://www.vim.org/scripts/script.php?script_id=905
  - devcjohnson 13y ago
    Please do not invoke factual information that contradicts the myopic view of the world as I see it. K thanx bye. (Sarcasm aside, ^this)
- Too 13y ago
  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.
  - Perseids 13y ago
    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-constructor-calls-vs-function-declaration 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.

by fournm 13y ago

tinco 13y ago

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)

riffraff 13y ago
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.
- tinco 13y ago
  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.
  - jnbiche 13y ago
    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.
  - GFK_of_xmaspast 13y ago
    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).
roel_v 13y ago
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.
- tinco 13y ago
  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.
  - deleted 13y ago
    [deleted]
  - bashinator 13y ago
    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.
    - tinco 13y ago
      Haha, that's funny indeed. I hadn't looked at it that way :)
  - devcjohnson 13y ago
goldfeld 13y ago
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.)
- tinco 13y ago
  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.
  - philwelch 13y ago
    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?
chongli 13y ago
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 http://en.wikipedia.org/wiki/Long_tail [1] http://www.vim.org/scripts/script.php?script_id=483 http://www.vim.org/scripts/script.php?script_id=483 [2] http://www.vim.org/scripts/script.php?script_id=905 http://www.vim.org/scripts/script.php?script_id=905
- devcjohnson 13y ago
  Please do not invoke factual information that contradicts the myopic view of the world as I see it. K thanx bye. (Sarcasm aside, ^this)
Too 13y ago
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.
- Perseids 13y ago
  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-constructor-calls-vs-function-declaration 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.