[mbrutsch]

I'm early 50s, and I've "learned and discarded" several decades of skills: 8/16-bit assemblers, the entire DEC range of computers, MUMPS and the VA ecosystem, the Perl craze of the early 2000s; I'm in an Oracle/Ruby shop now, and I suspect I'll be learning something new in a few years. Only way to keep up in this field, throw out the details, keep the concepts, gird the loins and hit the books. Well google, no one uses dead trees anymore. I have almost 100 lbs of "replaced by google" books sitting under my carport waiting to be recycled, becuse even schools don't want them.

[jazzdog]

I have been programming since the late 70s. I will say, some folks my age should be discarded, not because they're old, but because they've refused to keep up their skill sets. Many of my friends, whom I worked with in the 80s, are still scrounging around for whatever RPG AS/400 jobs are left. I shake my head. I'm having more fun than ever developing these days. Angular and Typescript of late. And it'll be some new framework in a year and a half. Other folks I talk to complain that they've been replaced by outsourced Indians. A little bit further probing reveals that "well they moved it to Java, and I'm a Cobal programmer, I don't want to learn Java". I shake my head some more. I'm not helping the cause here, I guess. Just some random observations.

[p4wnc6]

I'm a fairly young programmer, but I have almost the opposite perspective. Tools should be chosen because they offer pragmatic benefit for a particular purpose (usually for servicing a desired business outcome). But in the majority of jobs, tools are chosen for reasons of status and affiliation. Even two of the tools you mentioned, Angular and Typescript, are often derided by proponents of newer, trendier tools.

There's also an issue between the experience / what a person can accomplish for you vs. insistence on integration with a particular framework. If someone is a COBOL programmer and can demonstrably solve my problem more expediently with COBOL than by slowly plugging into my pre-existing Java system, then I should want them to work in COBOL and I should solve the problem of integrating disparate systems instead of effectively removing the comparative advantage that the COBOL expert brought to the table by forcing them to do things in my Java system for reasons of uniformity and standardization.

Obviously this is a simplification. For example, I enjoy programming in Haskell, but it's hard for employers to locate good Haskell programmers and so there is some extra hiring risk if you agree to bring Haskell into your family of tools. That's not trivial, but it is often deeply over stated. And the actual specifics of that kind of risk are rarely analyzed or considered -- as opposed to just rattling off a glib dismissal based solely on the mere fact that a risk, in principle, even exists at all, because dismissing for this reason is probably convenient to someone else's political power play to re-org around Java or something.

Many enterprise technology investment decisions are very bad decisions that are made by non-technical people for purposes of nepotism, status signalling, and creating bonus fuel for middle management and executives. The newer and sexier the technology, the better. Or, if new and sexy doesn't work, then buy a brand, like IBM, regardless of whether it actually fits your needs.

I find that most programmers are very happy to learn new things and are even motivated to do it and find it pleasant. But most programmers also cannot deal with being forced to learn clearly and unequivocally inferior tools that don't have redeeming engineering trade-off pragmatism to support their adoption -- which is the majority of modern frameworks, new languages, and libraries.

You can say "get with the times" but it's just the wrong diagnosis. "Getting with the times" generally means being underpaid and overworked in order to take poorly designed tools and use them to cram square pegs into round holes. Some people call it "gainful employment" and if it doesn't make you feel soul-crushingly miserable, that's great for you. But other people call it "talent wasting graveyard that will cause me to die early from a life of absurdly needless stress" and they seek other careers.

I wouldn't judge those COBOL programmers the way you are. They have a comparative advantage with COBOL and know its pragmatic use. If they recognize ways of solving a problem better without dealing with enterprise Java inanity, and their economic preferences imply that it's just not worth it for them to be overworked and underpaid if they are also forced to use an inferior tool, then they are being perfectly rational.

You are trying to characterize it as "adapt or die" but the reality is that many modern software shops are just graveyards, so it is "adapt and die" -- at least by refusing to adapt, you might find some more pleasing way to spend your time before you die.

(I'd argue the same goes for other trends too -- like the way start-up jobs are becoming cult-like lifestyle communes, and how basic human needs like privacy are required to be sublimated away in awful open-plan surveillance offices. "Adapting" to "tolerate" these things is a bad outcome -- and for many it's a far worse outcome than being unemployed or having a very hard time with job searching).

[bootload]

"I enjoy programming in Haskell, but it's hard for employers to locate good Haskell programmers and so there is some extra hiring risk if you agree to bring Haskell into your family of tools."

@p4wnc6 what are you using Haskell for?

[p4wnc6]

The only job experience I have with Haskell was in education technology, and part of that was focused on prototyping some things with Elm and PureScript for some boring business web tooling.

What I like working on in Haskell is numerical linear algebra / machine learning / data analytics toolkits.

But I also know Python pretty well (much more experience than with Haskell) and Python has the advantage of actually having a decent-paying job market, so I mostly stick to that. The few times I've interviewed for possibly decent-paying Haskell roles, they have been with large banks whose tech dysfunction was so large that it destroyed any credibility that may have been assumed due to the usage of Haskell.

One of the most eye opening things in my working experience has been that when someone says they use "functional programming" in a business setting, it generally means they don't follow any of the established practices or ideas that make functional programming worthwhile in the first place. So for jobs, seeking functional programming perhaps makes me overly skeptical.

I have heard of a few start-ups that really do functional programming, and one or two even using Haskell. But the pay and work environment are just too poor to consider it.

[bootload]

"The only job experience I have with Haskell was in education technology, and part of that was focused on prototyping some things with Elm and PureScript for some boring business web tooling."

Elm is written in Haskell, and you can only build the latest Elm with a late Haskell install. Found this out the hard way trying to install Elm on debian/Raspberrypi. [0]

I ask, because I'm curious to see what applications haskell are used for. I see Haskell being used, but limited to specific roles. [1] One thing I have noticed is Haskell to build you require a low level tool chain, like C. HS also is a moving target. Latest development should be via Stack yet a lot of documentation and code relies on Cabal. This is a pain installing some things.

All I want to use Haskell is for building a new language. I could use the "C tool chain" and I will do this if I can't grok Haskell. But to tell you the truth the learning hump and pain is worth the advantages of the advanced compiler, types and the clean code.

Builds and implementation is a hurdle I'm looking at.

[0] Unless you cross-compile or re-compile Haskell which is a PIA.

[1] https://en.wikipedia.org/wiki/Haskell_%28programming_languag...

[bootload]

elm-flasked (elm front-end, python-flask backend) popped up in the NoRedInk repo this week, take a look ~ https://github.com/NoRedInk/elm-flasked

[dboreham]

I loaded up my truck with the books a couple of years ago and took them to the dump (no recycling of bound paper here).

I still have my Vax though, and copies of Knuth, K&R, ...