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.
Many jobs are lucrative, but so what? Try to do work you enjoy. If you go off trying to learn something just because it's lucrative you'll probably end up in a job where you're maintaining some obsolete system that's held together with duct tape. Not fun. Probably not worth the money for the amount of anguish it'll cost you.
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'
The story implies that COBOL is an ancient outdated language. But this is not true. COBOL serves a specific niche and does so quite well, and indeed like C and FORTRAN has been enhanced through the ages. Sure, you can't really code a bleeding edge website with COBOL (and FORTRAN), but that's not what they are for.
If you want news from today, you have to come back tomorrow.
Haskell code never has any bugs. But that's just because it's never used in production.
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.
As always with these sorts of questions, the answer is "it depends". If you are employed and working with Java or C++ or something else, then by all means be the expert in these languages. Once you get to the expert stage - might take a year or two or three - by all means expand and be a generalist in many languages, but continue being an expert in your favorite language. I can tell you that those COBOL/RPG programmers in this great land are within ten to fifteen years from retirement, and there is a-whole-lotta code out there that still needs love. Since Y2K, I don't know anyone under the age of 40ish who is writing COBOL/RPG, so there is an opportunity there, if you are so inclined. If you are unemployed, then do one or two projects in your favorite language and one or two projects in a language that is used on your prospect list. For example, you want to work for Twitter? Learn Scala. Regardless, as the old adage goes, if you got time to lean, you got time to clean, or in this case, code. Good luck, and good question.
R is on the upswing so I wouldn't call it "still used" really :)
That said, you can make money knowing R. I am doing it, but you really need some database experience and possibly some python, c++ and the like.
SAS won't die in a _long_ time either, in the banks I've been too except for this last one have been using SAS almost exclusively.
The problem with SAS/R code is that neither is usually written by a programmer but a statistician that want something to work there and then.
It can be a nightmare if you inherit too much legacy code.
Also, you actually need to know statistics to be effective :)
Why limit yourself? Learn both a popular language and a less-popular one. I had the fortune of picking up both Java and COBOL in a previous job, which helped me land my next job, which involved (guess what?) both Java and COBOL (and Perl, and SQL, and XML, and C#, and PHP, and....). Never have I encountered a job where you only need to know one language. All those big banks and manufacturing companies running COBOL? They probably need to make those systems talk to something written in a more modern language like Java, or C#, or PHP, or even Ruby or Python. They are probably even trying to move some of their old legacy systems off on to newer systems, so having an engineer who knows both the legacy technology as well as newer technologies is just what they need. Knowing more than one language and more than one technology also means you don't get stuck when the company re-orgs or you finally decommission the old system or they hit a rough patch and downsize.
What makes a valuable employee isn't someone who is an expert in one thing. A valuable employee is flexible, can teach themselves new things without having to take a class or being asked. A good programmer is good at programing regardless of language. The more you learn, the more valuable you are, and the more options you have finding a job. Once you have experience solving problems with software, picking up a new language isn't really that hard. Yes, you could specialize in something like mainframe COBOL and there will be niche jobs for you in the financial industry for a long time to come, and you might be able to command a hefty salary as well, but do you really want to write COBOL for the foreseeable future?
Perl was used because it was a powerful scripting language despite a god awful syntax that took the worst parts of unix shell and awk and made them even more painfully contorted. When an equally (some would say more) powerful scripting language called Python came along with a sane syntax, a shallower learning curve and a properly interactive interpreter its no surprise huge numbers of people jumped ship.
I for one won't miss Perl - it had its day but its day is pretty much done apart from legacy code and the few dyed in the wool web sites still using CGI.
I learned the one, what's it called? it has the little turtle that moves around in straight lines? Is that one still in use?
Ah, you're thinking of LOGO. It isn't widely used anymore, except as a niche language for cruise missile guidance systems.
I don't care if it's 90,000 hectares. That lake was not my doing.
The actual cards would be those 80 column things that the ancient languages were stored (and inpuy) on.
It's interesting how many programmers make decisions while ignoring the wisdom of the high school girl. When in doubt, you pick something that is popular. When you are really good at it, you pick something that is going to become popular, and by choosing it, you make it more popular.
Seriously though, it really depends on where you are, market wise, and where you want to be. There are a lot jobs around here for Java programmers that understand Spring and Hibernate. However, the people hiring for those jobs are looking for competence, and little else. You won't be able to ask for a great salary in those conditions, because while good performers aren't that easy to find, the hiring pool is also pretty large.
Instead, imagine that you have 15 years of experience, and you want to remain technical. At that point, having a decade of experience on the exact same thing won't really help you. Your selling point has to be that you've seen everything, and that you are up to date with the latest and greatest. So you don't look for yet another generic job with popular tools: You have to learn shiny new things, and sell that your know-how with many tools means you'll make a lot less architectural mistakes than a youngster. At the same time, this gives you a chance of getting into a technology early, when finding experienced people is harder. You ride the top of the wave, get paid well, and can keep in the tech switching train.
Soyou need both serious knowledge of a couple of popular languages, and then to try to spend your time working on the less popular ones, that are still growing, because that's where real opportunity is.
I work for a financial institution that rhymes with race, and im paid handsomly for nothing short of necromancy and time travel. my cobol applications interface with 50 year old cobol applications, which in turn interface with java, which runs in a godless vortex of jboss and tomcat. the accounts division I write for is beginning to suspect im some kind of evil witch that lives on the 5th floor and creates their reports over a fuming cauldron. I have in the past transferred money in my checking account using the original cobol-85 nested subprograms written to handle some of the first ATM's ever invented. Security has, on two separate occasions, mistaken me for a hobo trying to steal a laptop.
Good people go to bed earlier.
Often languages are chosen because of who they have on hand rather then what is ideal, so if you have a bunch of COBOL programmers from another project you use COBOL, if you have a bunch of Java programmers you use Java. Sense is usually irrelevant.
COBOL is great and prolific programming language. COBOL programms will be running long after we are dead. I almost wish I saw more COBOL on Linux. Designed by Grace Hopper she made it so average people with limited CS knowledge could get work done. It's about a sexy as Mom's minivan but it brings the groceries home.
I'm a systems architect with a company that does IT services for the airline industry. Airlines are the third oldest users of computers, next to banks and the military. There has been an amazing amount of legacy technology that has been built around for the last 60+ years. Systems that are running modern languages and OSes today need to interface with systems via IATA protocols that were invented decades ago. Even though those legacy systems may run on new mainframes, they're still speaking the exact same language they were when they were rolled out. All that whizzy new stuff passengers see (cell phone boarding passes, full function booking websites, etc.) is riding on top of an ancient core that fewer and fewer people know everything about.
Anyway, my point is this -- we do have some people on staff who know about all these systems, and have built or worked on parts of them. They're paid very well, but I guarantee they would have a very difficult time finding work if they were suddenly not needed. The main reason for this is that they're solely dedicated to supporting these older systems. People sometimes allow themselves to be pigenholed into a single task or set of tasks. In my side of the house (systems engineering,) admin tasks are becoming like this through things like ITIL. ITIL is solely designed to remove any sort of judgement from an administration job so that you can plug an interchangeable human into any process, give them a runbook and tell them to execute only these steps when prompted. It's a huge problem, because the next generation of admins is having difficulty graduating to systems engineer and systems architect roles, simply because they don't have a big-picture view of everything.
I've been with the same company for quite a while, but have taken this approach to managing my career -- never do the exact same thing for more than a few years. I get to work in the same field and do _similar_ projects, but I also don't stagnate into a single role. This is very difficult to do because it requires you to be very flexible and constantly learning new things. You need to push your way into new projects because managers will want to hang on to the skills you've developed. Because of this, you need to be willing to document your work and train a replacement when the time comes. Also, you need to actually have some depth in the technology you're working with. There must be 20 or 30 new web frameworks that come out every year, on top of everything else that exists out there. You could try to learn everything but you'd never get good enough at any of it to be useful. At the same time, specializing in ancient languages and systems may be lucrative but you need to be prepared to jump as soon as your skills aren't needed anymore.
If you do it right, you can make a lot of money by being able to jump into a position that no one else knows anything about. But if you can't jump right back out, you will end up doing the same thing forever.
I think R is similar. R is not as well known as many other languages, but it serves a very important purpose and is getting more and more popular every day. I know some people who as adults are "learning to code" for the first time right now for their jobs. Why? We are starting to get into territory where every business person worth their salt needs to have some familiarity with data science.
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...
That is what I love about COBOL - that the people who do it are doing it as a job, rather than a hobby where they get to play with new toys.
If you want to see what the future of programming looks like, as a professional industry, COBOL shops are the leader. I bet none of your guys has thrown a tantrum because he was asked to put some comments in his code, or had week-long arguments about implementing unit tests for every component.
I have yet to see a young person say, "I'm going to learn COBOL so I can spend my career nursing 40-year old code." You want to be building new things instead, and for that you choose the best tools for the job right this moment. Those are also usually the skills that will make you most marketable to companies that are building new things.
Conversely it's rare to see an IT person keep up with the latest technologies throughout their careers. At a certain point in life you get other things that need attention, such as raising kids, taking care of parents, mowing the lawn, or whatever. And you start to get more risk averse because people depend on you. Although you are very good at your job, truthfully your confidence starts to wane a bit when you see all the really good young people coming up, who can absorb the new skills with relative ease.
The result is what economists refer to as comparative advantage: The younger people who are more adaptable focus on the latest and greatest technologies, and the older people focus on problems that benefit from their experience and judgment.
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.
Reminds me of a good joke:
In 2010, a COBOL programmer developed a rare fatal disease for which there was no known cure. The programmer was cryogenically frozen, to be revived when a cure had been found.
In the year 9999, the programmer is revived. When he wakes up, he asks the doctors what year it is, and when they tell him, he asks if they finally found a cure for his disease. They answered, "We're sorry, but no, we still haven't found a cure. But it's almost the year 10,000, you see, and you know COBOL..."
The entire premise of the article is bull. Are companies ever going to get off this fixation on specific programming languages? There used to be such a thing as training. Companies once did that.
Now it sounds like everyone has accepted that you should train on your own time. Worse, you have to do speculative training. Learn the specifics of some platform, and you might get a job doing it.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
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.
The entire premise of the article is bull. Are companies ever going to get off this fixation on specific programming languages?
No. Companies (at least the executives running them) look at their code base differently than technologists. They see the cost of maintenance as X$, and if it's written in ten languages, the cost of hiring ten people to do maintenance is 10X. If you say "one person can know ten languages" they assume such people are expensive and very hard to find.
They want a simple way to manage the cost of maintenance. Cutting the number of languages in use accomplishes that goal, in their minds. Therefore, this practice will continue at companies that don't have unlimited IT budgets.
John
Ah, you're thinking of LOGO. It isn't widely used anymore, except as a niche language for cruise missile guidance systems.
[Image of panicking missile controllers attempting to abort an erroneous launch by frantically typing PEN UP repeatedly.]
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'