[TheRealPomax]

the real world does not particularly line up with that statement. For a fast moving contract based world, sure, but there's also the other part of the programming landscape where codebases need to be maintained forever for institutions and large companies whose idea of stable is even stricter than OpenBSD.

I know plenty of people who work on both, and the second category gets paid very good money indeed to be the sole maintainers of complex codebases, with zero need or intention to learn new approaches because it won't let them do their job any better. Does that make them less likely to get a new job? sure, unless their new job still uses the language they use right now, which when you have 20 years of experience tends to not happen - other big companies and institutions will hire you on the spot. But a more important question is: will they even get to a point where they will need to look for a new job before retiring? Chances of that are roughly zero.

[Falkon1313]

Even in those jobs, there are always tangential tasks, one-offs, and side projects that could potentially be done much more easily/efficiently using different tools than the primary codebase. Even when using the same tools, different ways of thinking (patterns, paradigms) can make a huge difference.

The tools used to build GUI CRUD apps may be very well suited to that, but sooner or later all that data collected by the CRUD GUI will need to be processed, analyzed, and/or migrated. Although that might be doable with your CRUD GUI building knowledge, other tools or approaches, more well-suited to data processing, could make that task far easier, better, faster, and more reliable.

A legacy system from pre-networked days may be optimized well within the environment that it was created for, but when the day comes to make it connectable with an API, different skills may be useful. If you refuse to learn them, then either you have to hire someone else or you are likely to end up with a mess.

[pjmlp]

Then the company decides to outsource the IT doing the maintenance of that complex codebase to an Indian off-shoring company and fire 80% of the team, leaving just the ones needed to work as technical leads for the off-shoring team.

Now those guys are stuck with outdated skills that no one wants to hire.

[ebbv]

I'm not sure how your response applies to my comment? I said that your particular job may not provide an opportunity for FP but you should still learn it for the sake of professional development.

Even if you never need a job that uses FP, you should understand it so that you understand why you don't need it in your job.

Even if you never leave your job, having those skills will help you push for a raise and move you ahead in your field.

And chances are even if your job doesn't need it now, unless you're already near retirement, eventually there will be a case where maybe it is applicable.

[TheRealPomax]

And my response is still "why should they"?

Mind you, that's in part because of the ambiguity of the term "should": are you using the "should, as in nice to do but not required" or "should, as in required, and not doing it is wrong", because I'm on board with the first, but that is not how the original comment reads. That reads more like everyone should be familiar with multiple paradigms and not following that rule is bad. Which the real world heavily disputes.

[ebbv]

I think it's pretty clear from my comment that I'm saying should in the same sense as you should not smell like a dumpster on a hot day and you should be nice to work with.

Technically it's not required, but if you don't then you're lazy and probably not a great employee.

[mannykannot]

If this discussion is about the use of the word "should", then it has been a waste of time.

[johncolanduoni]

I feel that case just begs the answer. You're describing a job which is defined as "don't change anything unless absolutely necessary", so it won't directly help your work to learn how to change things. This doesn't seem like a deep result about the uselessness of learning new programming paradigms.