Weird take. I've been programming for 40 some years. I don't do it full time, trading time for $ anymore, but I still do it to write tools for my business pretty much every day. Cuz it's fun.
Iphone SE user here. Big screens is why I have an iPad in the house. Small form factor is why I have an iPhone SE in the pocket. My iPad gets _much_ more use than my iPhone. I'm not out and about much, even before the virus. I see phones sticking out of people's pockets and it makes no sense to me.
My perfect Apple ecosystem would be a standalone watch that makes phone calls, initiate text messages, and can pair to my car via CarPlay. Basically do all the things that my phone does right now w/o needing the iPhone.
My phone is simply the conduit that everything flows through - I have everything routed to Mac, iPad, etc. My phone is just on a table next to my keys so I don't forget to pick it up on the way out the door.
The Apple Watch has to have an iPhone paired to support calls which means you need to own and activate an iPhone with a carrier.
I tried to get this setup with a cellular Apple Watch and a cellular iPad but it ultimately meant I didn't have a cellular phone number that could enable the Watch to take calls.
I use both android and apple. Recently got a ipod touch to replace my iphone. I don't understand the need for huge phones. We've got a bunch of ipad pro 12.9" for general tablet tasks.
Now I common carry an android and ipod touch tethered. Best of both worlds. The samsung is small too.
I come from the .Net toolchain as well, no longer develop full-time, but write tools for my business as needed. I use Angular (6 or whatever). They talk to a .Net (core) server as little as possible. What I find is the iterative dev turnaround time, that cycle between find a bug - fix it - test it, is so much faster with angular than if server-side rendered. It's a joy. That same cycle on server side in .Net - change some .cs file and check that fix quickly - , slowly rather - a real pain. That alone drives the choice for me.
How about making it anything less than painful to use on an iPad. Like, maybe some of your developers can actually try to use it on an iPad? If this has been fixed, I retract. I've moved on long ago.
And maybe less obvious is the start-up that Netflix once was has a tougher go of it because Comcast wants their content streamed nicely and has to keep the Netflix customers from yelling too loud and have to squeeze someone's bandwidth to make profit goals which is perfectly legal as long as they are transparent about it.
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.
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).
"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."
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.
"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.
Is your point that 40+ aren't doing Math and Programming, so one should not aspire to be doing that at 40+? But why aren't 40+ doing Math and Programming? Because they've moved on to other challenges, or because they are being replaced? Aren't we back to the original point?
