You can determine who something is for by looking at who is paying for it. This one is provided to us for free and without any obvious source of third-party revenue (e.g. advertising), so, like HN comments, it is no doubt for the author.
No, nobody _says_ this. An enormous number of people make statements that imply they believe this.
Honestly, that’s one of the common criticisms I see of HN: That it’s full of people who believe they’re doing something new when they’re just recreating something old, but because theirs is new it’s better, usually because of why it’s new. (Blank but in Rust, Blank but in Go, blank but in JavaScript…)
In my own experience, this was demonstrated most starkly by how suddenly Subversion became “terrible” when everyone decided to switch to git, while many of the same people considered it great when they were switching to Subversion from CVS. And the same for the SCCS+clones to CVS transition.
Back in 2016 I briefly worked at a old, large corporation that was still using CVS.
During that time management decided that company policy was now to be hip with the younger generation. One very senior manager actually used the expression "we must strive to be the Uber of [our industry]"
This also led to a mandate that we should switch to Git because it was new and shiny.
You can just imagine the how steep the learning curve was for all the old hands, especially as some of them joined the company in the previous century as COBOL programmers.
We were also pulled in to team building sessions where we were encouraged to "think outside of the box" and be "innovative". During one of those sessions I suggested that "you know, we should just use SVN instead" and was promptly shot down.
You're not the only person. I know a handful of devs who heartily agree with you, and most devs I know don't really love or hate it. It's just the tool they have to use.
I don't hate git, but I do like subversion more. That said, I completely understand why someone would hate git.
Sometimes the best of the last generation is better than the new of the next. While I don't know how strongly this author makes that case, it's true in a general sense.
Personally, I've set 10 years for myself as a reasonable timespan, and I round up or down the version number to where it makes sense in terms of larger changes that have happened throughout the version history of the respective piece of software.
There's a thought that Nassim Nicholas Taleb mentions in one of his books that I've frequently used as a mental model ever since coming across it: For a book that has continuously been read for the last 100 years, you can expect it will continue to be read for the next 100 years. For a book that has only come out last year and been continuously read since then, you should have an expectation that one year from now, people will stop reading it.
10 years is a number I've arrived at by experimentation, thinking about version histories of various bits of software I build upon. For example, for Python this takes me back to version 3.4, before type decorators and many other things hit the scene that I disapprove of anyway. So now, I test all my code with both version 3.4 and the newest version (3.11). I won't use language features from 3.11 that weren't already there in 3.4, and I won't use code in 3.4 that breaks or throws deprecation warnings in 3.11. I also apply this test to dependencies, seeing what happens if I try to get the newest version of some Python library running on version 3.4 of the interpreter.
This means, my code is engineered in such a way that it could have been in continuous operation for the last 10 years, while running continuous updates on what's underneath it. And this gives me a reasonable expectation that my code will require only minimal code changes over the next 10 years to keep up with whatever might arise.
With the python interpreter itself, it's remarkably easy to do that, and I feel it doesn't limit me in my own coding in any meaningful way. With other bits of software, including many python libraries that one might depend on, it would be absolutely unworkable. In such a case, I take that as a clear signal not to use the software/dependency at all.
This is a lot of work, but also a good forcing function that prevents me from becoming a dependency hog myself. It's also useful research, because I get to develop an understanding of what time does to a piece of software, i.e. what causes breakage through time versus what causes stability through time, because I see the breakage in other bits of software through the time axis that I simulate into the past. And this way, I can avoid those mistakes when designing my own software.
There's a certain comfort in using a language that's "done" and is not going to change from beneath your feet. It's also one of the reasons why I strangely like python2. Compared to python3 which has a new release every year (and requires you to update all libraries that now are only compatible with the new version, causing a lot of churn for no reason), python2 still continues chugging along, and you know that people still targeting it value stability over breaking change.
Changing a number doesn't equal a generation. Just because 15 javascript frameworks have reimplemented the same idea, it doesn't mean a generation actually changed.
And even if the new _is_ better, it's called the bleeding edge for a reason. I find I bleed all over it - stress, bugs, and time.
If it's not worth spending one of your innovation tokens[0] on this new fangled technology, then use the old version that doesn't require the bleeding.
As an example, I've worked in telecom - I can absolutely tell you that in 2003-5, while VoIP was available, you were 100% better off buying a legacy TDM PBX rather than buying a bleeding edge (immature) VoIP one.
Also related is my policy of "never rely on anything until it reaches at least version 3". (Figuratively speaking, as version numbers don't really mean what they used to)
Completely agree. I could care less if it's not about Next. The fact that nobody caught this when proof reading says it all. Probably written by a Jr dev or non-techy writer.
...or it could have been written by someone with a disability. Man you all can be so intolerant. Does it change the facts in the article? No? then whatever, get over it.
There is one issue not mentioned in the article: authors of "old" tech quite often abandon it while developing a fancy new version, so the choice is not the imaginary one between old and new, the choice is real between abandoned and not-yet-ready.
Abandonment would not be a problem in a stable environment (see, Clojure libraries last touched in 2014 don't need any maintenance, and old Go libraries usually need just a bit of touch-up), but in a chaotic environment of most other languages abandoned library bitrots immediately.
> The point is, the things we use to build applications are in a constant state of evolution and change.
Evolution and change are great!
The article misses a deeper issue though.
There is tech that evolves with breakage (PHP, large parts of the JS ecosystem etc.) and tech that evolves with compatible change (Go, Java, Clojure etc.)
There shouldn’t be anything wrong with starting on v(N-1). But there is something fundamentally wrong if vN breaks you.
Programmers get anxious about that for very good reasons. We already have enough work to do! Breaking changes looming over our heads is not something we like having to worry about.
I don’t know whether Next13 will or will not break Next12 code. But that’s besides the general point.
This. So much this. It's fine to not use the latest version, but use a supported version. If the version is EOL, don't use it. Even if you have backports. Otherwise you will inevitably run into issues where the system is insecure by-design. I can't ssh into half the servers because I have to first enable insecure algorithms, the PHP version is almost old enough to drink, and the Debian mirrors don't even serve this version anymore.
Sure, the system is stable. Until somebody finds it, then it can be a threat to the entire network.
I moved to Windows 10 for my MMO client, and I brought the cl.exe compiler with me and now I need to call "set __COMPAT_LAYER=WIN7RTM" before I run the game othervise file operations randomly fail.
It messes with my head, and is fundamentally discouranging.
Also I cannot distribute that compiler for legal reasons, so I need to add another compiler to my project delaying it many months.
Linux has other problems, like 32-bit vs. 64-bit.
It seems to me we're in a vortex of complexity that we will never escape, fundamentally fueled by peak lithography.
I'd recommend trying again; none of the article's message is specific to or contingent on Next, and it'd be a shame to dismiss it over something so superficial.
Eh, I disagree. It's a tech article and the writer clearly isn't familiar enough with the topic to catch this issue. It shows they are not actually really close to the tech or if they are, they don't proofread their articles.
The main theme of the article was: should I start with stable old tech or go to unstable new tech right away?
First the author links to an article called "the Fallacies of Enterprise Computing" that I honestly didn't read but it's about debunking a fallacy "New technology is always better than old technology". Then he uses the case of python3 vs python2 for making the case that a lot of people worked successfully with python2 while python3 was unproven and finishes with a non-sequitur question: so why should stable old tech be recommended and used [in face of unstable new technology]?
He argues in favour of old tech because, 1. new tech will be buggy, 2. you can't wait for the new version to be stable, 3. you will have to rewrite your project anyway to a new version some day, 4. technical debt is inevitable and not that bad.
His conclusion is to develop with an old stable version and upgrade to a new version when the new version gets stable.
Except for the first point, the one about the bugs, I'm not even sure that points 2, 3 and 4 even help his case. In fact I could easily use them to argue in favour of starting a project right away with unstable new tech.
I might be a dumb guy and I might not have understood entirely the point of the author, but I don't like this kind of article. For me it all looks an incoherent assemblage of phrase of effects crafted with the intent of being provocative rather than having some real content. Props to the author for putting the effort of writing an article, but that's all of positive that I can say about it, the rest sounds only like platitudes.
Was very interested in the article, but after 2 Nest 12 references I started questioning their credibility, and after a bunch more of the same error, I realized the author has probably never used Next. Some people here are saying it shouldn't matter. Of course it should. The author picked a tech for the analogy, most likely one they know the most about. And yet they call it Nest... which means they most likely aren't actually close to the development workflow whatsoever.
This is closely related to the effect you see inside orgs where nobody wants to touch the old thing because the replacement is coming but, critically, hasn't arrived yet and nobody can give you a date. That old service with all the bugs that nobody wants to add a feature to because the New Shiny Thing (which doesn't exist yet) will Make The Problem Go Away.
No. The current thing is the only thing, until it actually isn't. It is a going concern until it gets switched off. Yes, this means it needs maintenance, security patching, support, and, yes, new features.
The number of times I've seen teams fall into the trap of making their current situation worse by betting on an as-yet undelivered platonic future and intentionally ignoring their current estate because it's "not worth the effort for something that's going to be replaced" just makes me weep.
46 comments
[ 3.3 ms ] story [ 93.1 ms ] thread> New technology is always better than old technology
No one believes this.
You can determine who something is for by looking at who is paying for it. This one is provided to us for free and without any obvious source of third-party revenue (e.g. advertising), so, like HN comments, it is no doubt for the author.
Honestly, that’s one of the common criticisms I see of HN: That it’s full of people who believe they’re doing something new when they’re just recreating something old, but because theirs is new it’s better, usually because of why it’s new. (Blank but in Rust, Blank but in Go, blank but in JavaScript…)
In my own experience, this was demonstrated most starkly by how suddenly Subversion became “terrible” when everyone decided to switch to git, while many of the same people considered it great when they were switching to Subversion from CVS. And the same for the SCCS+clones to CVS transition.
Back in 2016 I briefly worked at a old, large corporation that was still using CVS.
During that time management decided that company policy was now to be hip with the younger generation. One very senior manager actually used the expression "we must strive to be the Uber of [our industry]"
This also led to a mandate that we should switch to Git because it was new and shiny.
You can just imagine the how steep the learning curve was for all the old hands, especially as some of them joined the company in the previous century as COBOL programmers.
We were also pulled in to team building sessions where we were encouraged to "think outside of the box" and be "innovative". During one of those sessions I suggested that "you know, we should just use SVN instead" and was promptly shot down.
I don't hate git, but I do like subversion more. That said, I completely understand why someone would hate git.
Oh, boy. That's a very bright signal to run, don't walk, away from that company.
Sometimes the best of the last generation is better than the new of the next. While I don't know how strongly this author makes that case, it's true in a general sense.
How far back do you lag to feel safe?
There's a thought that Nassim Nicholas Taleb mentions in one of his books that I've frequently used as a mental model ever since coming across it: For a book that has continuously been read for the last 100 years, you can expect it will continue to be read for the next 100 years. For a book that has only come out last year and been continuously read since then, you should have an expectation that one year from now, people will stop reading it.
10 years is a number I've arrived at by experimentation, thinking about version histories of various bits of software I build upon. For example, for Python this takes me back to version 3.4, before type decorators and many other things hit the scene that I disapprove of anyway. So now, I test all my code with both version 3.4 and the newest version (3.11). I won't use language features from 3.11 that weren't already there in 3.4, and I won't use code in 3.4 that breaks or throws deprecation warnings in 3.11. I also apply this test to dependencies, seeing what happens if I try to get the newest version of some Python library running on version 3.4 of the interpreter.
This means, my code is engineered in such a way that it could have been in continuous operation for the last 10 years, while running continuous updates on what's underneath it. And this gives me a reasonable expectation that my code will require only minimal code changes over the next 10 years to keep up with whatever might arise.
With the python interpreter itself, it's remarkably easy to do that, and I feel it doesn't limit me in my own coding in any meaningful way. With other bits of software, including many python libraries that one might depend on, it would be absolutely unworkable. In such a case, I take that as a clear signal not to use the software/dependency at all.
This is a lot of work, but also a good forcing function that prevents me from becoming a dependency hog myself. It's also useful research, because I get to develop an understanding of what time does to a piece of software, i.e. what causes breakage through time versus what causes stability through time, because I see the breakage in other bits of software through the time axis that I simulate into the past. And this way, I can avoid those mistakes when designing my own software.
If it's not worth spending one of your innovation tokens[0] on this new fangled technology, then use the old version that doesn't require the bleeding.
[0] https://mcfunley.com/choose-boring-technology
Also related is my policy of "never rely on anything until it reaches at least version 3". (Figuratively speaking, as version numbers don't really mean what they used to)
Abandonment would not be a problem in a stable environment (see, Clojure libraries last touched in 2014 don't need any maintenance, and old Go libraries usually need just a bit of touch-up), but in a chaotic environment of most other languages abandoned library bitrots immediately.
Evolution and change are great!
The article misses a deeper issue though.
There is tech that evolves with breakage (PHP, large parts of the JS ecosystem etc.) and tech that evolves with compatible change (Go, Java, Clojure etc.)
There shouldn’t be anything wrong with starting on v(N-1). But there is something fundamentally wrong if vN breaks you.
Programmers get anxious about that for very good reasons. We already have enough work to do! Breaking changes looming over our heads is not something we like having to worry about.
I don’t know whether Next13 will or will not break Next12 code. But that’s besides the general point.
Don’t embrace “old” tech! Embrace _stable_ tech.
Sure, the system is stable. Until somebody finds it, then it can be a threat to the entire network.
This is why I used Debian Linux.
It messes with my head, and is fundamentally discouranging.
Also I cannot distribute that compiler for legal reasons, so I need to add another compiler to my project delaying it many months.
Linux has other problems, like 32-bit vs. 64-bit.
It seems to me we're in a vortex of complexity that we will never escape, fundamentally fueled by peak lithography.
Seriously considering going back to the C64.
First the author links to an article called "the Fallacies of Enterprise Computing" that I honestly didn't read but it's about debunking a fallacy "New technology is always better than old technology". Then he uses the case of python3 vs python2 for making the case that a lot of people worked successfully with python2 while python3 was unproven and finishes with a non-sequitur question: so why should stable old tech be recommended and used [in face of unstable new technology]?
He argues in favour of old tech because, 1. new tech will be buggy, 2. you can't wait for the new version to be stable, 3. you will have to rewrite your project anyway to a new version some day, 4. technical debt is inevitable and not that bad.
His conclusion is to develop with an old stable version and upgrade to a new version when the new version gets stable.
Except for the first point, the one about the bugs, I'm not even sure that points 2, 3 and 4 even help his case. In fact I could easily use them to argue in favour of starting a project right away with unstable new tech.
I might be a dumb guy and I might not have understood entirely the point of the author, but I don't like this kind of article. For me it all looks an incoherent assemblage of phrase of effects crafted with the intent of being provocative rather than having some real content. Props to the author for putting the effort of writing an article, but that's all of positive that I can say about it, the rest sounds only like platitudes.
not only is it cheaper to use a version that's a few years old, you know the pitfalls, documentation is easily found etc.
No. The current thing is the only thing, until it actually isn't. It is a going concern until it gets switched off. Yes, this means it needs maintenance, security patching, support, and, yes, new features.
The number of times I've seen teams fall into the trap of making their current situation worse by betting on an as-yet undelivered platonic future and intentionally ignoring their current estate because it's "not worth the effort for something that's going to be replaced" just makes me weep.