Much of the world's financial systems run on it, replacing it is infeasible, but the expert's in this area are aging out (and many have retired more than once). But the tech still needs maintaining, and is difficult to work with.
Fewer and fewer grad students seem interested in learning it, and the expectation that you'll stay and work on this stack for 20+ years is something that drives others away.
Probably because it's not really fun languages to work in compared to newer things. I'd rather get paid a bit less and work with C# for example than get paid a lot more and being miserable. :)
And since it is a language that will probably die off sooner or later, it is not really a good investment since it will limit your job prospects if the bank you work for would ever change their financial system.
I work on z/OS utilities, mostly assembler. It can be fun, you have to be resourceful. z/OS is actually quite pleasant environment compared to many newer platforms (such as Windows), because you get a very high visibility into what's going on in the system.
I guess it depends on type of person. If you love to understand things across the stack (what's going on under), you might like it. If you would rather focus on an application (or framework) layer only, you probably won't.
But yeah, totally depends on the type of person and while I could potentially see myself doing these things I much rather develop in newer languages that makes my life easier. It isn't like it's bad pay for modern languages anyway.
The compensation would have to be a lot in order for me to even consider it :)
Nothing is infeasible to replace, it might be costly, but not infeasible
And of course IBM is happy to get paid millions to keep backward compatibility on the systems they sell
Nobody wants to invest their time learning a dying platform that is good for nothing but a dead end job at a bank and won't teach anything usable in any form of modern system (hope you like wearing a tie for your job as well)
(Fortran is still used, z/OS might be dying down as well but it runs some modern software)
Hahaha, nope. It's easier and cheaper to train a copule of COBOL programmers than replace the systems that run COBOL.
At a previous company I worked for, it was estimated that the cost to replace just a single COBOL based system was upwards of $50 million.
Not only that, banks are notoriously risk averse, especially with their software. They are very reluctant to change things that already work.
If the cost of training peons to make it last and run is less than the cost of rebuilding it, be it from scratch or piece by piece, it will matter longer (that's the point of view of insurances, banks and big corps today, and what's still happening in the IT industry).
> Nothing is infeasible to replace, it might be costly, but not infeasible
Too costly. Which does make it infeasible.
Five minutes of downtime can result in multi-million dollar profit losses. (At least that's the quote I was given by the CTO when he was explaining the scope of my role when I was consulting at a major Australian bank).
When you have literally millions of transactions a second you need to handle, building a new system to handle the same:
* Regulations * Specifications (Some thousands of pages) * Edge cases * Load
Turns into a multi-year, multi-million dollar operation that will likely be outclassed by the old system by the time it is ready.
No manager in their right mind would approve such a project, no matter how forward-thinking it may be.
Not impossible, but entirely infeasible.
My first job was writing COBOL on an IBM 390. I hated it at the time, but I realise now how many important lessons I learned from it. It wasn't trendy, but it was worth doing and I'm glad I had the opportunity.
However, for the most part those systems have been running for decades and aren't modified that much any more. While probably not completely bug-free they tend to have a low error rate, in terms of functional requirements at least. They also mostly deal with low-level mathematical and accounting functions that don't change frequently.
For better or worse a lot of COBOL code also gets replaced when new compliance measures like Basel II and III are implemented. Additionally, there are even transpiler-like tools that convert COBOL to Java code. The resulting code of course is horrible but at least it then is available in a language with a long-term maintenance outlook.
In addition to a very conservative work environment all of this contributes to COBOL not having the prospects it might seem to have at face value.
That's really not my experience.
I was brought in to maintain, and manage a series of changes to a major bank in Australia, where I trained a full-time replacement before leaving.
We replaced COBOL code... With more COBOL.
> Additionally, there are even transpiler-like tools that convert COBOL to Java code. The resulting code of course is horrible but at least it then is available in a language with a long-term maintenance outlook.
Not just horrible to look at. Slow. Performance that is hundreds to thousands of times slower than the pre-existing code. That's just not acceptable.
---
Now, we were writing "new" stuff in a different language - C++, because IBM has a wonderful linker framework between Fortran and C++ on their mainframes. But the COBOL is staying put, because nothing can really replace it without unacceptable downtime or performance regressions.
Ember never made it to that point and almost certainly never will. People are still free to use it of course, but it’s going to be a poor technology choice in light of the above factors.
I personally feel productive with Ember, but the custom object models and getters and setters for everything are a bit of a turn off, especially after working on an Angular project recently with typescript support. Mobx, for instance, seems to be able to accomplish similar things as Ember but without the custom object model and getters/setters.
[1] For those wondering, Glimmer is Ember's next iteration of view layer and rendering engine, pulled out into a separate library. It's built from the ground up (and so isn't subject to backwards compatibility with Ember just yet), uses typescript, is component based, and it compiles down to op-codes that are used to update the DOM instead of DOM-diffing. http://glimmerjs.com/
There are a few reasons for this. First, Angular’s programming model lends itself to typical enterprise software requirements. Secondly, Angular, and TypeScript in particular, is similar to what enterprise programmers are typically used to (namely Java and C#). There also is Ionic, which is largely based on Angular.
Finally, Angular and React is one of those odd cases of regional variation in technology distribution. React appears to be more popular in the US, particularly with Silicon Valley companies, than in Europe.
Job postings on job boards, or talking with real people from real companies asking for and ready to pay for the skill? The perception of what is needed could be skewed by someone investing more in postings, recruitment spam is notorious as well.
Basically they didn't jump on the React bandwagon because of the licensing thing, but are ready to jump on Angular's because it ticks all their boxes
https://insights.stackoverflow.com/survey/2017#technology-la...
Every non-tech company, and even some tech companies seem to be moving whatever they can into Office 365 and Azure. Some are just moving Exchange, others are moving Sharepoint, and some are just using Azure as an alternative to running a VM farm on-prem (bit boring really). But MS is marketing this HARD here and everyone seems to be buying the message.
Plenty of lower-tier 'Infrastructure Admin' type roles going all over the place, most MSP's are looking for architecture and engineering types as well in fairly high numbers (I count about 20-30 such roles on Linkedin). A lot of Dev roles also seem to be angling towards "Experience with Data Lake/App Service/Some other Azure-ey thing is preferred".
However, demand for lower-paying jobs using open-source CMS's like Umbraco seems to be rising, whereas the rates for contractors are rising for the enterprise level choices like Sitecore.
I mention contractor rates because in Bristol companies are struggling to keep experience in full-time development. For Umbraco, we're seeing the space grow with more full-time people, whereas if you're a developer that can work with Sitecore you can earn a LOT more by moving into contracting. Developers are going from £40-50k roles into £550-600 a day roles as contractors, earning over double what they were before. It's also lucrative for recruiters, as they get a percentage of a bigger overall salary.
Sure, it's fairly niche, and it's as unglamorous as it gets, but the work is there if you know this proprietary CMS as it is widely used by a number of large businesses based on its marketing platforms.
Some lonely ads are also asking for Ruby or Python.
It's easy to forget on HN that 90% of tech jobs are in 'dull' bread and butter languages used in enterprises, and nothing to do with the latest trends.
I think the stack overflow jobs stats linked elsewhere in this thread says it all... Java, JavaScript, Python are the most in demand languages right now. Tensorflow doesn't even show up on their list of popular tools.
Really efficient some say :)
Real IDE usage (vim/emacs).
Just because something is on an underlying layer doesn't mean it's more important or more in demand.