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?
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 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.
It's not COBOL that gets the jobs. It's CICS. The COBOL 'database layer'.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
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.
Well, that, and also the general perception that C++ programmers are generally way smarter than any other programmers out there. I've noticed that algorithmic skills are generally higher in C++ programmers---they generally know how linked lists work, how to implement array based queues, how sorting actually works, where the bottlenecks are, etc., stupid little things that most average C# or Python developers wouldn't be able to think through.
So yes, even if you're not hiring a developer to do C++, having a C++ developer generally increases the programming skill level on your project. In other words, hire smart folks, and you'll do well.
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.
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.
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.
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"
Anyone who is proficient in programming shouldn't have a problem picking up a book (or website) and learning a new langauge, API, etc. in a weekend or two.
This is true as long as you're hacking something together. If you're expected to work with other developers and create something maintainable, you've got to learn a million little standards, conventions, quirks, tricks, and optional 3rd-party libraries.
Picking up the basics is easy, but in my experience it takes a couple of years before one can truly be comfortable with a new language.
Last post!
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