Slashdot Mirror
Unpopular Programming Languages That Are Still Lucrative
Nerval's Lobster writes In theory, learning less-popular programming languages could end up paying off big—provided the programmers who pursue them play their proverbial cards right. And as with any good card game, there's a considerable element of chance involved: In order to land a great job, you need to become an expert in a language, which involves a considerable amount of work with no guarantee of a payoff. With that in mind, do you think it's worth learning R, Scala, Haskell, Clojure, or even COBOL (the lattermost is still in use among companies with decades-old infrastructure, and they reportedly have trouble filling jobs that rely on it)? Or is it better to devote your precious hours and memory to popular, much-used languages that have a lot of use out there?
Key words "in theory".
The type of businesses who need an actual expert in COBOL and not just a programmer who can pick up what they need to know need just that: an expert. You can't really become an expert without actual experience. When a company wants a COBOL expert, they want someone with 20 years experience to sort out the problems the programmers with a c++ or java background can't figure out.
I've been hearing since I was in school that the "smart" thing to do is learn COBOL and go make a billion dollars maintaining someones mainframe, but I've never heard of anyone actually doing it. Not saying it doesn't happen, just not in my chunk of visible world.
On the other hand, a friend of mine started working with Foxpro back when it was popular, and unlike everyone else, stuck with it. She makes egregious amounts of money maintaining the small number of things still using it. In her words: "keep laughing, it paid for my house".
TLDR: if you were lucky enough to have started in some old tool/language that's still used and have kept your skills up to date, there is big money. Good luck jumping into it now though.
When I asked why they still taught the CS students COBOL 20+ years ago the explanation was 'it's a weed out, you have to really love computers to put up with COBOL'.
They didn't make EEs/CompEs take it. Thank dog. I had taken a semester at a Jr College at 15, thinking it might get me respect and a job from the big iron idiots of the day.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
For what it's worth:
I work in the power industry. We are upgrading to the very latest version of the application we need to operate our power plants.
It is COBOL throughout.
The vendor is taking away access to the source code soon, as the version that replaces this one will be Java. By Java, they mean all the COBOL code wrapped in Java.
So, a major application for use in the power industry will be COBOL until at least 2030.
Our COBOL devs make nearly six figures. And after our salary review is done, will get some serious raises.
They're all in their late 40s-50s. We have no COBOL people in the pipeline.
My mom says I'm cool.
You should think of what the choice of language says about a company. Any company that built its business on Clojure, Scala, or Haskell has a management problem in my opinion: while those languages may be more productive than, say, plain Java, hiring and tool support has always much more difficult. COBOL is indicative of lots of legacy code and a company that has been in business for a long time. That has some advantages, but also means a work environment that's likely very different from others in the industry. R is something used by statisticians and scientists; if you get hired solely as a programmer (rather than a scientist/analyst) to do R programming, your job is likely to clean up other people's messy R code. Can you make money with any of those languages? Sure, but the job may not be quite what you expect or what you are used to.
Right, but would they hire someone who didn't know what a COBOL was 4 years ago?
It seems to me that the people looking for COBOL programmers are looking for experience. This image of taking a COBOL class or two then going out to make a fortune has been fed to me since I was in school, but I've yet to see it actually happen. I do hear plenty of stories of people who stayed with COBOL and are now doing very well, but no success stories of people jumping into it at this late point in the game.
It's not so much that it was a mistake, as it was actual reality of the situation the company found themselves in.
We're talking about systems with 40-50 years of data, for highly complex machines with incredibly long service lives that generate billions in revenue, which are tightly integrated into everything in the company, and which would likely cost 10's of millions of dollars (if not 100's) and several years to replace -- with the risk that you'd spend the money and still not end up with a viable replacement.
The reality is, in long-established businesses in highly regulated industries with systems which are literally decades old and not easily replaced ... many many organizations find that it would be impossible to replace/retire these systems, and that it's cheaper to keep paying the people who have familiarity with these systems. And if they die, you find someone else with a lot of years on a similar system.
Saying "oh, just replace it with something new" is something which I hear from naive, inexperienced people who have never encountered these kinds of systems. Sure, it sounds great, but it doesn't match up with actual reality.
I've encountered several of these systems, and been on projects to try to replace a couple -- and almost universally when you try to do it, you realize that the scope of the problem, and the way in which it will break everything else you have, corporations decide it's not possible or cost effective.
Say what you will about the old school mainframe applications, but they did exactly what they were supposed to, for very long periods of time, with thousands of pieces of institutional and business process embedded in them ... and they do it without crashing, breaking, or otherwise being unavailable. EVER!
Systems which have been running robustly since decades before Microsoft was even founded are about as non-trivial to replace as you can possibly imagine.
Precisely because they are so big, so important, so complex, and so tightly integrated into every one of your business processes.
So, you'll excuse me if I question if you've actually encountered any of these systems, or been part of trying to replace one.
Because anybody who has usually looks at the project and says "no way am I getting dragged into that".
Lost at C:>. Found at C.
Exactly.
I started writing a replacement for our company's 20+ year-old file-based data system 7 years ago. I didn't tell anyone about it until a few years later when I had a prototype ready and started producing better and faster reports for management than the old system. But they still wouldn't okay me to go ahead and start designing a full replacement for our old system. Then the old system coughed up some blood for a couple weeks and nearly caused us a to lose a couple million in sales.
After everyone stopped running aroud with their hair on fire they asked me what it would take to get my new system up and running as a replacement. I did it and now I am the one who controls all company data. At least a half-dozen people now work supporting the system and writing new code for it, but no one else has 7 years experience thinking about and designing this system, so a lot of the details escape them. HA! Try to get rid of me now.
Proactive programming will get you far.
At that point, having a decade of experience on the exact same thing won't really help you
... unless you specialized in something that's still used, and the company you're at still uses it or some other company out there needs it.
I mean, if the "thing" you did for those 15 years was streamlining TCP traffic in assembly, then you could go make $500,000/year as a quant dev on wallstreet. If it was abstract computer generated graphics in turboPascal... then not so much.
So yeah, it depends on where you are market-wise. Sometimes specializing is a good idea. Sometimes it pays to be a generalist.
Personally? I went with embedded C and every now and then dip into general business applications just so I'm not super-specialized. But so far, low-level C has been a stable bedrock for a career. And I don't think I'm being too optimistic when I say it's probably going to stay that way.
I've worked at a three places that did MicroFocus COBOL on Linux, huge in insurance world
if you just want to play, 'sudo apt-get open-cobol' on your debian or ubuntu or mint box http://sourceforge.net/project...
Three words:
High frequency trading
Most of the code driving that is written in Haskell, which is just criminal, since it's some very bright people writing that code, and they're not contributing in any meaningful way to humanity, just fiddling bits to determine who has how much of what money at the end of each trade.
http://adtmag.com/articles/201...
Sphinx of black quartz, judge my vow.
I wish there were an open-source version of FoxPro. There is the Harbour project for xBase, but it's not interpretive, and lacked many of the interactive features the last time I checked.
FoxPro and xBase are great for hobby CRUD-centric or smaller data-centric projects: Lots of functionality with very little code because the imperative code could be tightly bound to the database rather than requiring application-code-to/from-SQL translation layers like the current stuff. One learned to "think in tables", and thus become a Tablizer. It's sort of like APL re-shaped by practical concerns.
There's something magical about it in that it can dance nimbly between high table abstraction and nitty-gritty imperative fiddling code. Some try to compare it to LINQ, but LINQ feels like an add-on to the regular clunky way, and not part of a bigger united experience.
The xBase approach may not work well for "big team" programming, but for certain projects it could scream.
Ah, the good 'ol days. You Ruby-ites get off my lawn!
Table-ized A.I.