> The changes in programming are pretty superficial.
In mainstream programming. You don't need to time-travel to experience huge cultural and technological shifts - you can go from Prolog to Forth to Racket to Smalltalk to OCaml to Haskell and experience more of a change than a C++ programmer from 1985 would if transported to 2013.
Inside one paradigm the changes are necessarily iterative and slow. Differences across the paradigms are huge. At a given time only one or two paradigms are mainstream, and they change rarely. The same goes for hardware architectures. This makes it look like programming is stagnant, and for the most part it is. However, when the change comes - like from unstructured to structured programming or from 16 to 32 bits architectures - people who lived happily inside the main paradigm have a hard time adjusting.
I don't know when the next major shift in paradigms will come, but it will, and then the belief that the only changes in programming are superficial will prove dangerous.
What I'm saying is that there were moments in a short history of programming when it was "hard for someone who programmed 5 years ago get a job today", and not because of economical reasons.
I personally remember one and it was around the transition from 16 to 32 bit architecture (for me it was in context of WinAPI vs. MSDOS programming). That seemed like everything has changed completely and people had to put a big effort to stay relevant. The same happened - from what I hear - when OO became mainstream. The same when we largely abandoned asm for higher level languages. Basically, I'm saying that there are such 5 years periods in which the above statement holds true.
Such turning points have, I think, one thing in common - new technologies, methodologies and paradigms are not created overnight, in each case the "new" was around for quite a few years before it "suddenly" replaced the "old". It was just outside of day to day work of most programmers. That's why I think it's important to be on a constant lookout for new things in programming - or even old, but different things. One day, in a matter of months, they may become dominant and make your skills largely obsolete which will make you maintain some legacy stuff for the rest of your career. It's a hyperbole of course.
Anyway, while today and 5 years back are not that different, maybe today and five years in the future will be. And then you'll have a problem getting a job until you catch on. I'm not saying how probable it is, but it happened and may happen again. Or didn't it? What is your perception of this issue?
In mainstream programming. You don't need to time-travel to experience huge cultural and technological shifts - you can go from Prolog to Forth to Racket to Smalltalk to OCaml to Haskell and experience more of a change than a C++ programmer from 1985 would if transported to 2013.
Inside one paradigm the changes are necessarily iterative and slow. Differences across the paradigms are huge. At a given time only one or two paradigms are mainstream, and they change rarely. The same goes for hardware architectures. This makes it look like programming is stagnant, and for the most part it is. However, when the change comes - like from unstructured to structured programming or from 16 to 32 bits architectures - people who lived happily inside the main paradigm have a hard time adjusting.
I don't know when the next major shift in paradigms will come, but it will, and then the belief that the only changes in programming are superficial will prove dangerous.