Open Source Insider Vim text editor turned 25 late last year – the first public iteration was launched on November 2, 1991, a couple of weeks after Linus Torvalds announced Linux. To celebrate Vim's anniversary, creator Bram Moolenaar recently dropped version 8.0.

Ordinarily the update of a text editor wouldn't be worth mentioning, but this is the first major Vim release in ten years. In today's world, where web browsers drop major point updates (what they consider major, anyway) several times a year, Vim's lack of major updates is not just refreshing, but speaks of an entirely different approach to developing software.

Even leaving aside the absurd version system of today's web browsers, eight releases in 25 years would be considered slow by today's software development standards. Interestingly, though, Vim's biggest rival, GNU Emacs, has a roughly similar development pace. GNU Emacs began life in the 1970s and is currently at version 25, which means it averages two releases to Vim's one, but still definitely on the slow side.

Yet Vim and Emacs taken together may well be the most used software in the software developer's toolkit.

As a long-time Vim user (since 2005 or so), Vim's lack of updates may well be my favourite feature. Vim is Vim. It does what I need it to do and it doesn't try to completely reinvent itself every six months. In fact, I had been using version eight for several weeks without even realising it, which at this point is pretty close to my definition of great software – if it ain't broke, don't fix it.

Contrast this with your favourite web browser, which pushes out updates every six weeks. I don't even need to know what your favourite browser is to make this generalisation because they all do it. Now some of this frantic update pace can be attributed to the fact that the browser is a newer idea, there are more bugs to work out. That sounds good. Until you think about what Vim, and even more so Emacs, is capable of, which includes, in Emacs' case, being able to render HTML using WebKit.

So much of software development these days feels like reinventing the wheel for the sake of it. I recently took on a new client with a codebase written in Symfony 1.0, which is old enough that I had to use Archive.org just to find an overview of it. And I'll admit my first instinct was to rewrite the code in something more modern. But then I stopped myself and stepped back and looked at the actual code. Is there anything wrong with it? Well, in a couple of places yes, but by and large, no. It works. It does what the client wants to do well enough that they want me to port it to another part of their business. It ain't broke, why am I trying to fix it? I put down the shiny new stuff and got back to work.

The desire for the latest and greatest is a mental trap we all fall into to some degree. New ideas come along and in many cases they're good ideas, better than what was there before. To stick with Vim as an example, version eight does have a bunch of cool new stuff, like support for asynchronous I/O, channels, JSON, jobs, timers and GTK+ 3 among other things. None of that is immediately, obviously useful on its own, but all of which opens the door for some new and potentially very powerful Vim extensions.

There's nothing wrong with helpful new features, but too often those helpful new features come with a price. They require relearning how to do things that you did reliably the day before. And even the most helpful features cease to be helpful if they require me to completely change my existing workflow. Vim 8 was a totally transparent update. It didn't require me to learn some new way of working, it didn't completely break extensions I rely on just so it could round off some corners in the UI (OK, Vim doesn't really have a UI, but if it did I feel pretty confident that it wouldn't waste time rounding corners on tabs, cough, Firefox).

A common defence of the rapid release cycles common in today's software, graphical and otherwise, is that things must progress. To not progress is to deny ourselves the birthright of, uh, progress?

Stagnation is the equivalent of death apparently, which is as much a cultural value as one of the software produced by that culture, but either way it might be worth remembering that there is something else that pursues growth at all costs, dividing over and over again in a ceaseless headlong rush – cancer cells.

The more time I spend meditating on this analogy the more accurate it feels. To be clear, I am not talking about security updates. Security updates improve software and are a good thing. What I'm talking about are the needless UI rewrites that don't actually do anything for users (web browsers seem to be the most egregious example of this), the development frameworks that reinvent themselves with every point update, or the latest trend: abstractions that promise to simplify everything but end up increasing the complexity of everything.

To pick what I think is the most absurd example of this trend, look at CSS, an incredibly simple syntax for styling web pages. But, no, it turns out that CSS is too complex, so we get Sass. But then Sass doesn't quite do what we want so we get Compass and now what used to be something so simple few would call it programming requires two interdependent frameworks, Ruby and half a dozen Gems to output CSS we could have just written in Vim.

Then there's the insanity of deployment. Deployment tool chains are the most aggressive cancer around right now. All to save you from being a complete Philistine who just pushes and pulls to a git repo, or, Festivus help you, uploads files over scp.

Alas, I don't expect things to change from their current course. If anything the future looks to be full of more abstractions, more pointless UI rewrites, more frameworks that break backwards compatibility, and more cancer-like growth. Which is why Vim is so important.

At least our text editors will still be there, stalwart unchanging places to reliably weather the storm. Thanks, Vim, I quite literally could not do what I do without you. Happy 25th birthday and here's to another ten years before Vim 9 rolls around. ®