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!
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)
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.
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.
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.
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.
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
(Sarcasm aside, ^this)
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.
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.
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.
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.
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.
> 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.
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.