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?
My college still teaches COBOL, requiring two semesters of it. But I'm not sure if this is because they illegitimately believe it's still useful or just because of old habit (and to keep the guy teaching it employed).
SJW's don't eliminate discrimination. They just expropriate it for themselves.
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.
The TFA author has an interesting perspective.
I dove into TFA because the description lists *Scala* with languages like COBOL as both being "unpopular"...not sure if Scala is "unpopular" in the way COBOL is that...
While reading TFA, I discovered his link to his other article of *5 Programming Languages to Learn*
in it, he lists HTML5/CSS3/PHP as *2* of the 5! haha! i hope this doesn't cause another round of "HTML5 isnt a language" arguments...Erlang gets a shout out
good articles...i'd stay away from anything M$ proprietary so that #F language or w/e I don't agree with...but i like his analysis in both articles and learned alot...
Thank you Dave Raggett
MATLAB/R/SAS are still used a lot in life sciences and probably other businesses. I don't use them directly but have users who do.
In the olden days I got a lot of programming and database experience iwth MUMPS (or M as it's sometimes called). Think hierarchical rather than relational databases which makes things like patient data a lot easier to sort through.
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.
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.
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.
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'm a software engineer who works mainly in C++. There are tons of jobs available to me, and they generally pay a metric fuckload of money. How much more could these jobs for unpopular languages pay? Having the choice of many employers is a big benefit of being strong in C++, and that allows me to choose a company that will treat me well both in terms of compensation and work/life balance. There would have to be an extremely very large premium for me to focus on an unpopular language and limit my choice of employers.
The actual cards would be those 80 column things that the ancient languages were stored (and inpuy) on.
"...access to a mainframe system"....
Well, there is more than one kind of mainframe, and they aren't much alike. But let's assume you really mean IBM zSeries. You have several options:
1) Take a course. Many schools have IBM sponsored classes with access provided.
2) Find a copy of the "Hercules" emulate http://www.hercules-390.org/
3) Sign up for ANY university class to become a "student" and apply to IBM http://www-03.ibm.com/systems/...
Also note the growing popularity of Linux on zSeries systems, so your Linux skills can be directly applied.
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.
I would probably avoid looking into Clojure or Scala to make money based on popularity. Problem is that these languages are 'cool' which means that there is considerable amount of good programmers playing with them in free time and willing to take a job where they could code in that. Let's say that there are
- 2 million java programmers
- 2.1 million java jobs
Doesn't look good? But if you compare it to (completely random numbers)
- 50k Clojure programmers
- 1k Clojure jobs
Then the fact that there is 40 times less Clojure that java programmers is not going to help you much.
If you are trying to game the popularity, you need to find languages platform which are in some demand, skillset is rare and they are horrible to work with. With that, you may get into job which you will hate, but you will be paid a good money and have job security.
Look what is happening with game development. So many people want to work there that you work very long hours and pay is very low. I knew some people who were willing to get pay cut to switch from Java to Scala. They weren't learning Scala to earn more, but to have fun again.
From my experience, domain you work in has a lot bigger factor in salary than platform. Investment banking people will earn same money, regardless if they code C#, java, C++ or python, but might get considerably different packages based on domain knowledge and actual skill. Game developers will be paid badly regardless if they do Flash, Android (talking about salaries, not indie games) or C++.
Switching language in same industry can give you maybe 20-30% salary increase? Switching industries can double or triple it.
Examples:
C# developer with 5 years experience in banking
http://jobview.monster.co.uk/C...
600-700 GBP per day (which gives 130-150k yearly)
plus plenty of other 500-600 GBP per day jobs.
Web C# jobs outside banking (same city)
30-50k GBP yearly
and no offer for daily contracts.
Learning Scala just to move from 30k to 35k job is not worth it. If you want money, go for proper industry. Learn languages/platforms if you want to have fun in work - but then base it on what you want, not what is best paid.
Heh- a large chunk of our timesheet system where I work as well as departmental budgets is all done within a custom portal written in.... ColdFusion. We're slowly moving away from bits of it (The helpdesk ticketing/inventory control parts are gone now) but I can't see it dying completely within the next decade.
"Seven Deadly Sins? I thought it was a to-do list!"
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.
Most R code does things like model fitting, parameter estimation, data visualisation, data analysis etc.. The code mostly is just a way to capture and operationalise an idea in statistics or data processing. If you can recognise, grasp, and follow through that idea then the code usually starts to make sense pretty quickly.
On the other hand, if you can't, then you'll be hard put to understand the code on its own terms and you really shouldn't try to modify it because you won't know what to look out for.
As I see it, the openings in "R" are for people who are "numerate", know about statistics, data analysis, a little database knowledge and who also happen to know R.
People like that are also likely to be able to work effectively with SAS, SPSS, SQL, Matlab and other high-level programming languages.
It's better to devote your time to improving your logic, design and architecture skills. If your career is tied to the continued usefulness of a given language, you're almost guaranteed to eventually find yourself unemployed or forever locked into a maintenance job that doesn't allow you to create anything new or interesting. Hardly what I'd call a "great job", which you seem to believe you must paint yourself into a corner to obtain.
Stop focusing on being a coder and start focusing on being a software developer. Learn about algorithm analysis and optimization. Learn about design patterns. Learn about software architecture. Apply those to whatever language the "great job" employer wants you to use.
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.
And still required for some DOD development. I like Ada, if you can get it to compile it may still have a crap ton of bugs but it rarely if ever crashes...
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.
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.
Allocating capital profitably is extremely beneficial to humanity.
High frequency trading is not about allocating capital, it's about bleeding the people who are seeking to reallocate it.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
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
And they still do. They just want to pretend new recruits are up to speed right away. That looks better on the balance sheet, I guess.
It's all about the appearance of efficiency, rather than actual efficiency. You get the former by measuring and micro-managing everything, and the latter by ensuring your employees want you to succeed and then cooperating with them. Yet companies insist on re-enacting Soviet Union in their own structures and practices, with predictable results. So I gues it's true that enemies will always end up resembling each other...
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Here is a list of truly unpopular (almost hated) languages that I know folks make over us$150,000 using:
- Delphi / pascal (automotive, process control, chemical )
- Forth (embedded)
- Basic (a large array of strange niches from chemical processing , manufacturing assembly lines, scientific etc )
- visual basic 6 ( chemical and scientific )
- Lisp (autocad scripting , embeded and graphics processing/simulation creation )
- Q&A database aka Sesame database (seriously I have no idea who uses this but I keep coming across jobs for this)
none of the languages are seen on open forums like monster or dice but rather are direct hire, strange recruiter spam and consultant gigs from the niche language mailing lists.