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?
Haskell not popular? Wow. That's a load of crap.
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.
I'm still getting paid for some Perl 5 work. Learned some when it was still hot, built something with passing value, and now I'm pulling a small but significant monthly fee for supporting it.
It's still what I do best, thanks to all this regular practice. Coding is otherwise more of a hobby than a job for me. Can't say that I see a lot of demand for Perl code monkeys out there, though.
#o#
O Moo.
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.
No one uses Haskell in a production environment, and no one is "well paid" writing Haskell. Some of the items belong on that list, but Haskell doesn't. It only exists for computer and computational scientists to feel smart within academia.
I still see job advertisements for mainframe programmers from time to time. How does one break into this line of work without access to a mainframe system?
It might be fashionable in academia and certain CS circles but I've never once seen it used commercially in 20 years of working in IT. Now maybe I've not worked in the right sort of companies but I've worked for some pretty big blue chip ones and small houses so I reckon I've got a good spread of experience there.
Here in Atlanta, there are very few Delphi developers yet tons of organizations that still use legacy apps based on Delphi 5 and 6. I can easily charge them $250 an hour (with a minimum of 4 hours) for simple changes and they're glad to pay it too. At some point down the line, they've been told it's way too expensive to have the applications re-written in a more modern language with a higher workforce base.
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.
Languages are not equally accessible. The most popular languages , like PHP, allow many people - almost everybody - to program, whatever their background is, and whatever the outcome (performance, maintenance, ...) of the application may be. Among this many people is diluted a rather low percentage made of some good developers who could easily adapt and program in something else, like R or Haskell (they don't do it because they don't need to).
In other words, hire R developers to make better PHP programs.
Slashdot, fix the reply notifications... You won't get away with it...
Maybe it would have remained popular if perl6 had delivered some time before Duke Nukem Forever....
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.
Ada?
Anyone?
Bueller?
Remember when Ada was your guaranteed ticket to riches and fame?
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 glad the summary clarified that proverbial cards needed to be played right instead of actual cards. I had always assumed that Tech jobs were handed out over heated games of actual poker.
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.
It's right on the verge of being a lucrative language almost no one uses.
Has no knowledge of pointers, but people are fustrated using it in legacy code.
There is always jobs out there. Really it's better to figure out what style of programming/development you want to do, then go out there and get damn good at those most relevant languages. It's certainly good to tinker in different ones that might fall outside just for excercise and just a new experience. However, focus on you want, build your core and there will always be positions to suit you skills in my opinion.
You can make good money two ways. 1) Be able to do something not many others can do for which there is a need OR 2) Be able to do something not many others want to do for which there is a need. You can make a lot of money if the activity fills both requirements and is under served. If you enjoy or at least can tolerate working with unpopular technology for which there is a need you can make a nice little living for yourself so long as the need remains and is not over served.
And of course x86 or RISC Assembler...
old languages never die, the programmers just start charging a prohibitive amount of money to code in them. Forth is only justifiable doing embedded programming when you don't have an OS. APL and J are only justifiable if you don't have a popular OS, AND you're stuck with a low speed printing terminal.
Not holding my breath for My LotusScript skills to come back into style.
Been programming since the late 70's in one form or another. Probably 98% of the stuff I have worked on is C, C#, VB or Java. The only reason it's not 100% is because to begin with it was all stuff like Dbase III, FoxPro, Access, DataEase and some assembler. I've not been asked to tackle anything other than the C/Java/VB variants since about 1990. Where exactly are all these other (non web related) languages used?
I want a list of atrocities done in your name - Recoil
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.
You may not get to use much Haskell on the job at Google, but I guarantee you that really knowing Haskell is one of the best ways to *get* the job.
"Skill shows through where genius wears thin." -Wittgenstein || Religion: uniting aviation and architecture.
It's not being an expert at some particular language that ends up paying. It's being an expert. You will always have to play your cards right but there are high paying jobs in any of the languages. Figure out the style you like, become an expert in one of its mainline languages, play your cards right, profit.
Lucrative is relative. Yes, COBOL programmers are in demand right now, because most of them have retired. Does that mean somebody just starting out should expend the resources and time to learn COBOL? Probably not, because the return on their personal investment would be less than if they spent it on more current/in-demand technologies. OTOH, a programmer that already has COBOL experience, can still find employment.
It's like buggy whips. As the buggy was replaced by the automobile, the demand for buggy whips declined. However, until horse buggies were completely gone, there was still a demand, albeit smaller than in its heyday, for buggy whips. If you were an experienced buggy whip maker, you could still find employment making buggy whips. However, it would not have been a field for a new apprentice to enter.
Likewise with COBOL and the other languages mentioned. There is still demand for programmers with that knowledge, but it isn't a growing field. At some point the cost to maintain the code will become higher than converting the code because the cost of COBOL programmers will be too great given the supply and demand curve. For those who currently are COBOL programmers, that bodes well, but not for somebody just entering software development.
BTW, I use COBOL in the above languages, but the statements apply to most long lasting programming languages, not just COBOL.
I can see where they are coming from. I am a Physicist turned programmer. I was lucky enough to pick up some programming skills during school and turn it into a career. My main development environment is LabVIEW (one of the least popular languages ever) and I make dam good money doing it. Sometimes I make more per month with my 10-20 hour a week side gigs than my 40 hr/wk at MSFT because people will bring me in to do the architecture of a program, but I don't have to deal with ongoing support.
But I totally agree with the general view of not getting boxed in. I am learning C, C++, C#, Python and such.
Is scala unpopular?
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.
Most any programmer worth their salt is language-agnostic. Programming languages are merely tools in the toolbox. Different languages are more or less suitable for different tasks. If I'm manipulating text, Perl and Regex may be the way to go. If I've got to build a web CRM for IIS, then I'll use C# and ASP.net. A similar CRM for Linux and I might use PHP, when I'm building my UAVs and multi-copters I'm using C++. They are ALL very similar. At the end of the day, all of the computers we use computers are Von Neumann machines and operate on the same basic principles. All programming languages have Syntax, most are similar. Most every programming languages also has built-in libraries and methods that are the building blocks for more advanced methods and objects. But once one knows a few languages and understands the ideas behind them, learning a new language is not difficult. What takes more time is learning the libraries that one has access to. Knowing what code is already written for you is extremely important.
I've seen a lot of programmers spend hours and hours writing a method that was already available to them in an external or system library... That's the biggest mistake I see people make when they are working with a language that is new to them. LEARN YOUR LIBRARIES!
The knowledge that consistently pays best is how to bring a project in on time, to budget, working and accessible by users, and how to communicate well with other people.
Korma: Good
E*D*M*T*P*J*
Where E=documented experience, D=degree or other credential, M=motivation, T=talent, P=practice, and J= the number of jobs available.
If you have a really high E for COBOL, maybe it will overcome the low J. Same deal with a lot of these other unpopular languages. That's not to say "life" won't develop on some unlikely "planet", but it's not the best place to look.
Standard disclaimer: I'm leaving out some factors, and any ridiculous inference you've just made is not what I meant to imply.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
A programmer should be able to pick up another language in a matter of weeks and master it within a year. Do your best in whatever language you like or need now. While it's fun to talk about the pros and cons of different languages, the idea of being stuck in a language is silly.
DISCLAIMER: You may have to network socially to bypass those who rely too much on words in resumes. You may have to do a couple hobby projects. You may have to take a pay cut while an employer waits for you to get up to speed.
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.
What are you looking for?
If you're looking for a steady paycheck, or you're a talentless hack that can't compete with a flooded market, or you're a self-starter that can master a weird language quickly without any instruction (are there even COBOL books out there anymore? ;), mastering COBOL is a worthy route. As the work is out there, and the employees aren't, you'll be nice and safe demanding a reasonably good salary. Just know that the company you're working for will be largish, established, and not giving out any high-flying stock options. You'll be able to retire in 20 years... probably with something old people like to call a "pension".
If you're looking for a lottery payout in the form of an IPO, or you're interested in cutting edge technology, or you're not sure what you want to do, or if you have no life and actually enjoy working 80 hours / week, or you want to do mobile phone development... then go for the more popular languages.
it is about the codebase. Learning the language takes a week if you are going by a book and a day or 2 if you have actual working code to learn from. However, learning a codebase takes months/years.
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.
So basically, there is no superior language. Rejoice, no more fanboism on C/C++/Java/PHP/Python/Fortran/COBOL
Only languages that are popular...
Well except Math.
Go learn brainfuck and whitespace, and see how many jobs you can get with *those two* under your belt.
(and LolCode, too!)
https://app.box.com/WitthoftResume Code: https://github.com/cellocgw
For few years in the 90s I worked writing production code in Eiffel. The job was very well paid....
The Rolling Stones make a lot of money, that doesn't mean that you should start a band. There are countless garage bands that make no money.
Sure COBOL can net you big bucks, and a really great set of very stable clients; but how many of those do you think there are? and how many near you? that you can approach? and have the "other" industry qualifications that they require?
Look, if you are passionate about old industrial equipment, then sure, you may be the guy for the job.
If someone puts together R, Haskell, Cobol and Fortran and declares them unpopular my bullshit detector goes off-scale. That person obviously has no clue.
What exactly does make a language "unpopular"? That it isn't used to build whiz-bang websites or smartphone apps? Do they realize that languages like Cobol, Fortran and R are fairly specialized tools (data processing, math and statistics) and thus they will always live inside their little (or big) niche. Comparing these with something like C#, JavaScript, PHP, Swift is just retarded, it isn't even apples to oranges comparison. It is like declaring Matlab "unpopular", because there are no apps in Apple's AppStore written in it. About as relevant as yesterday news :(
I don't really get what is the point of this type of article. Good programmer must learn to adapt, if someone thinks that they will learn *THE LANGUAGE* and then live off it until retirement, they are either being delusional or extremely stupid. Learn the underpinnings of the field instead - logic, theory of computation, language theory, data structures and algorithms, structured/object oriented, functional and declarative programming (to at least know that there are other approaches than just the usual imperative code!). Those things are going to be way more useful for any programmer than learning one or two programming languages. That is something that you will typically do in a few days/weeks when you will actually need it - if you know the basics and have some programming experience under your belt already, picking up a new language (not becoming an expert!) is easy.
Once a formidable language for anyone who didn't like the Microsoft tooling at the time, PowerBuilder has been purchased by SAP (via Sybase) and is now not only slated for a major upgrade (version 15), but Sybase has promised 8 years of support going forward before a version 15 or furture versions will be end-of-life. That is a direct shot across the bow at vendors like Oracle (cough cough ADF 10 was a horrible disaster cough).
So yes, assuming SAP holds the line (and I see no reason not to assume they will) if you have PowerBuilder skills, then they will definitely be valued, all you have to do is find someone using the HANA toolset, or someone who already has a stable of developed PB apps that doesn't want to rewrite them JUST to get away from PB.
I kinda quit upgrading my Delphi install after Version 7 having switched to Java for the work I am doing going forward. I needed a 64-bit capable Delphi for something so I downloaded the Embarcadero Trial of one of the current Delphi versions.
Besides New Delphi being a complete pig on resources, there is no comparison of its machine "footprint" to Visual Studio let along Classic Delphi (of which Delphi 7 is the "standard" because that is where Classic Delphi development stopped). I didn't do much with the trial install because I couldn't figure out the settings and modes on the compiler and I consider myself an old Delphi-hand. Attempting to compile a legacy Delphi 7 app with it resulted in a barrage of compiler errors.
When I need to "do something 64-bit" (also cross-platform) in Delphi, I have switched to Lazarus/Free Pascal, which I understand is targeting Delphi 7 for clonage -- kinda like Linux distros targeting something somewhat but not completely unlike XP for the GUI experience with Microsoft having gone off into the ozone UI-wise with Windows 8.
So, is it just me, or do others view Delphi 5-6-7 as the Windows 2000/XP of that world and the new Embarcadero offerings as being a whole 'nother language culture?
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.
Patroclus: You told me never to change sword hands...
Achilles: Yes. When you know how to use it, you won't be taking my orders.
If you were ready to dabble in different programming paradigms or specialized languages... you wouldn't be asking us for permission.
Let's talk about R. Do they know what it is? I don't use it... I'm a sysadmin. But a number of my users do, heavily.
How 'bout if I describe it this way it's free, and so it's a *lot* less expensive than the alternative: MatLab. That *is* what it's used for, guys. So, maybe it's "less popular" becuase the audience that uses it doesn't write, say, games or websites in it?
mark
Unpopular Programming Languages That Are Still Lucrative
PHP? Judging by past comments on here it's massively unpopular.
Or did you mean "lesser-used"?
systemd is Roko's Basilisk.
The Hartford Insurers solved that problem in the 1960s.
They have training programs. COBOL, CICS, etc .... No degree necessary - just pass the aptitude test, the training program, and the probation period, and you're in.
That's why you never hear them about not finding "qualified" people.
I've been programming as an employed Java web app developer for a few years. If hypothetically, there is another company looking to hire for a Scala developer position, would it be a good idea to take it? Assume no previous Scala experience is required and the company is willing to fully train on said language. Assume its also a great company
In large scale, enterprise class systems COBOL is still used extensively. For operations like Payroll that move huge amounts of data around, COBOL is the gold standard. Why? Other than the fact that much of the code was written a long time ago and just works, there are very few languages that can process large quantities of SQL as efficiently and as quickly as COBOL. That's what it was designed for.
Now, you might argue that some of the modern languages can process just as quickly but many businesses are reluctant to change because:
1) The COBOL code they have now has stood the test of time. It has been battle tested. It's rock solid.
2) Many of the processes that COBOL handles are considered to be "mission critical" applications. If something goes wrong it will cause big headaches.
3) The investment required, in time and resources, does not justify the return.
So COBOL will probably continue to be around for a long time. What's it like to program in COBOL? It's wordy, procedural and in short not very sexy. But it's a good skill to have.
To be successful at COBOL it's not enough to just know the syntax. To be valuable to an employer you also need to know the business processes and rules that need to be implemented in the code. If you are going to program COBOL for a Payroll system you better know Payroll inside and out. If you can get to that level then you can have a very successful career.
1) Good for the resume. You never know where your next job might come from. Or your manager pops his/her head into your cube saying "We need to support client X and they only use language Y".
2) Most of the popular languages are imperative, I am not sure why. Perhaps because that is all that is taught or that Joe Average Programmer cannot wrap their heads around functional languages. Get proficient at at least one functional language. It will challenge how you think.
3) It's fun.
putting the 'B' in LGBTQ+
I did some consulting in COBOL waaaaay back when (1980's) to help debug an application for a client. It took me about 1 day to understand the syntax and such. Then, I became an expert in DIBOL (DEC's business oriented language - also an ANSI standard) in order to maintain and enhance the MCBA manufacturing software system. Thank goodness I don't have to write any code in those overly verbose languages any longer!
Or M as it's known these days. It's a horrific mess of a language, but there's still a LOT of legacy code out there and it's nearly impossible to refactor M databases into anything more modern. No matter how much I try to move away from it, I keep getting pulled back in. But hey, it pays the mortgage!
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.
I'm not a programmer. Lately I started reading through http://learnyouahaskell.com/. I haven't gotten very far yet. My only purpose was to get a handle on the syntax in my xmonad configuration file. I had no idea it could be used to make money.
In general, having a niche skill pays more if you can find a job in that niche. Companies that need that skill know it's a niche skill and one way or another end up realizing they have to offer higher salaries to attract the right talent. On the other hand, if you are an expert in COBOL and go to work doing web programming, they're not going to care, and your COBOL knowledge will have no impact on your income.
That all being said, I don't understand the general fear people have of learning new languages. Sure, it takes time and effort, but it should be considered part of the craft. At Ohio State, the CSE department used to teach a language called Resolve for its beginning courses. It was DESIGNED to make things like data structures and algorithms easier to code, avoiding a lot of the cruft of other languages that is unrelated to the code that matters. But students complaned and complained about learning a language they'd never use again. My thinking is that if they're going to be successful, engineers need to be willing and able to learn new languages on their own time.
At OSU, they eventually caved to student pressure and switched to Java. Why they chose Java is beyond me. Where I teach now, they use Python, and that makes a hell of a lot more sense to me. If you're entirely new to programming, there is a lot of boilerplate (from the perspective of the uninitiated) Java code you have to write just to do simple things that is unnecessary when writing Python.
What is R less popular than? That's the only language I've ever really heard of stats and math-types seriously using.
Anybody?
Nothing ever came along to replace COBOL which took data storage as seriously as COBOL did. COBOL has DATA DIVISION syntax for talking about file formats and databases. No other language has syntax for talking about the external representation of data. This is a lack.
Look at how much code goes into taking data out of an SQL database and into an object in Java or Python. And what a pain it is to change the code when the table format changes. It really is a lack that modern languages don't deal with external data well.
This is a special case of the marshalling problem. Programs are always packing data into some specified form for transport or storage. It's an operation which often needs to go fast, and is a clear win if done in hard-compiled code. Yet there's little language support for this. There are precompilers which compile Google protocol buffer definitions into C++ or Go. There are interpreters for Python which understand a SOAP protocol spec and decode, slowly, the XML accordingly. Those are add-ons. Language support for marshalling is very rare, if not nonexistent.
You can do a lot of things with R, it's more that there are things which are more succinctly expressed in R so f(x)=something can be translated into R code that looks relatively like that. Which was the goal of many other scientific programming languages. So in a sense R is a way of someone numerate in statistics being more easily convert the statistics into reasonable code. A bit like MATLAB is designed to make matrix manipulation reasonably obvious in the code.
In reality they are never quite as obvious as you'd hope, of course.
Anyone remember SNOBOL (StriNg Oriented and symBOlic Language)? My Dad was a systems analyst and worked a lot with COBOL and SNOBOL. I used to go in to work with him on the weekends when he'd pickup the output from his batch jobs (no real-time processing back then) and often I'd just play with the card-punch machine. We'd take the "chads" from the machine's bin and put it in a bag and take it home to use as hamster shavings...
Really? No disclosure on this rather stupid article?
c.f. http://developers.slashdot.org...
isn't a language, it's a technology.
Can't say I'm paying much heed to an article that confuses the two.
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.
Indeed. It helps that R is the learning language many stats programs use in college these days. Often the college kids no more than the experienced Matlab/SAS folks. It also helps that many "big data" databases will natively run R code. HP Vertica in fact will split and optimize R between all the nodes in the cluster.
R is definitely a language on the rise for big data applications.
Malbolge
D's a pretty good language, if you're looking for something a little higher-level than C++ and without the C++ warts, and if you can forgive a little language instability. It's not that obscure.
(Was TIOBE always such a JavaScript-only mess?)
The more tools you have in your box (that you are actually skillful with), the more valuable you will be to any given employer/client. I got my foot in the door at a particular trading shop because I could program in C/C++ on OS/2. Later on I did another job for them because no one there wanted to deal with SNA networking. Skills like that earned me a *lot* of money over the years.
Paid my rent for many a year. I dabble in it less now (some work in Powershell to do) but still my first love.
"The greatest lesson in life is to know that even fools are right sometimes" - Winston Churchill
HTML5 is, indeed, a programming language -- at least when paired with CSS3. You can implement Rule 110 in nothing but HTML5 + CSS3, and Rule 110 is known to be Turing-complete. Ergo, HTML5 + CSS3 is capable of any computable process, and is a full programming language.
It's a horrible programming language, but hey, when has that gotten in the way of widespread acceptance?
Critically thinking:
- Language to learn should have a high percentage chance of being used for more than 5 years
- Language to learn should have more than 2 guys developing the compiler and dev tools for it (see 5 years item above)
- Language to learn should run on widely used computers
- Language to learn should have moderate or larger installed number of production systems (excepting Silverlight)
- Language should have near professional quality compiler, debugger, dev tools, libraries and library documentation
- Language should be an easily sell to business/non-technical decision makers
- Language should have a good number of actual viable jobs listed on jobs site A, B and C
- Language should be from general purpose down to a moderate sided purpose; and not super specialized. General problems should be able to be solved in the language
- Language should not be an academic exercise language
- Language and its libraries should be updated 1+ times year with meaningful new functionality and not just a last stable build yesterday containing the unchanged, except for cosmetics, crud from 2 years ago
- Language libraries should have near commercial quality documentation with code examples for 1/3rd or more of the library methods; and documentation well beyond the method signature + 1 text line per method name and parameter
- Licensed for use in commercial systems without requiring republication of intellectual property (source code)
- Language with good integration to unit testing tools not really required since the code base is millions of lines and business will not pay $1 for developing/maintaining the production code and $0.50 for developing/maintaining the unit tests. A yearly event, like a simple government regulatory change, would invalidate thousands of unit tests and updating those thousands of unit tests would not be budgeted for.
- Language should scale to problems longer than 10,000 lines, such as, end of day global trading position roll-up for risk/compliance
In other words, a non-toy with longevity and quality tools/documentation suitable to use in a 1+ million dollar project project with an expected lifespan of 7-10 years.
This excludes many of the languages/libraries falling into either a) toy, b) academic, c) too narrowly drawn problem domain or d) expected to be a dead fish washed up on the beach in 2 years.
NB: We have about 2 million lines of MIT/BSD licensed open source Fortran/C/C++ numerical code linked to our application which is near impossible to modify both in time and cost.
Nice to see COBAL so beloved and well payed.
People programming in R are well paid not because they know how to code in R, but because they know how to do statictics. How to properly do statistics is much harder to teach and to understand than learning to code in R. But being able to code in R without this knowledge is almost completely useless.
For younger folks, if you want to learn and do some projects in COBOL and/or FORTRAN, even assembler, it will give you a different perspective on computing. It will possibly give you another tool to generate an income stream, but I would not do it for the money, it must, IMHO, be for the passion of learning and understanding of the history of this industry. A side benefit is the new skill set and opportunity for income that may or may not pay off.
In the day, there were other 'special purpose' languages. Forth, Easytreve, Snobol, EasyOut, RPG, APL, etc. These were all great languages for their purpose, some uber small and simple, some mathematically fantastic, some had optimized I/O, some just obtuse for no other reason.
A number of the languages you mentioned, R, Scala, Haskell, Clojure, go on this list. Most are for general use, most are good for learning, not necessarily designed for commercial use.
COBOL and to a lesser extent FORTRAN, only gained acceptance because the industry was forced into acceptance by the 900# gorilla in the room, the DOD. Like the Interstate highway system, what was done for military purpose this time became a boon to the industry. The DOD tried again with ADA, but that one failed to illicit such a great commercial response. (I am not defending COBOL or FORTRAN as great computing platforms, but as a necessity for the times.)
Right now, C and even C++ are getting a bit long in the tooth. Java too, but more from a language architecture and implementation than the base language itself. I think we do need some new or new implementation of a 'killer language' or so to consolidate education and industry. We should possibly break into a handful of 'great' languages. Bean counting, graphics, hard-real-time, 'super-cluster/mesh' computing, possibly even for portable devices, small and large control systems, even networking, and even with built in inherent security. What form will it take? That part of my crystal ball is very fuzzy. But I do see it needs to be done.
... "When you pry the source from my cold dead hands."
The 32-bit to 64-bit change is a big jump, but int (32-bit) and long (64-bit) have the same meaning in Java whether 32 or 64 bit, and the "integer models" of C and C++ are OS dependent, but they made some effort to ease the transition. Here, you are telling me that Delphi 2009+ is a totally different and incompatible language from Delphi 7, that they didn't even make an attempt at a smooth migration path?
That gets back to my original question/observation. It does seem that there is a "Lost World" of Delphi programmers and application users still living in the era of Delphi 7, either out of sloth, inertia, legacy systems, or that Embarcadero has gone off into the ozone layer of the stratosphere with their product offerings, and this Lost World is cut off from the Embarcadero World.
Oh, don't move to Atlanta because you are experienced in Delphi. The traffic alone in the Atlanta Metro area will make the 6-figure pay not worth it.
The reason that the old programs must be maintained, is that the people that wrote them were smarter than you and knew more about what the company needed.
If you throw it away and try to re-write the programs in a new system, they will lose functionality and much of the remaining functionality will be wrong.
The existing specifications are always incomplete, so the only complete record of what is running is the source code for the old programs.
Just because you find learning other peoples programs to be very frustrating, does not mean you can avoid learning it.
The second step, in learning anything new, is frustration. If you avoid frustration, you will never learn anything new.
By the way, I'm using the Clarion development system. http://www.softvelocity.com/
Shouldn't there be a disclaimer in the summary stating that Slashdot is owned by Dice?
I work in the Healthcare field, working in MUMPS (alternately M) which is a subset of Cache Object Script.
I have made over 100K every year for about 20 years (totalling over $2 million dollars).
M is a very concise language, which is backward compatible with code written in its very first version.
The language is not of the Algol/C/Pascal/Java family of syntax, so many people have a hard time writing it.
The data stored in M is accessible as persistent variables, so it functions as a NOSQL database, but requires
a totally indexed tree to syntactically access. Basically, the data is a sparse, overlaid, multidimensional array
indexed by strings of characters with values of strings of characters.
The functions in M include content-addressable access as well as common string manipulation functions.
Generally commands support a multi-processing shared computation space with hierarchical semaphores
and built-in fault tolerance least-recently-used automatic buffering of programs and persistent data.
M can also be very frustrating, prone to assumptions in code and data structures, as well as requiring high precision
coding and 24/7/365 availability. Major financial (banking and stock brokerage) systems use M, as do most
hospital/health-care environments which have been around long enough to be market leaders.
The name "MUMPS" definitely contributes to the language being unpopular, as well as code bases that
were written in intensely limited resource machines (M implementations ran 16 or 32 concurrent users on a IBM/PC
even though MS/DOS 1.0 isn't multi-tasking) These terse codebases many times were written by subject matter experts
rather than by professional programmers.
Nonetheless, M programming is lucrative, and will support a long career by anyone who wants to not worry about finding
a job. There is a lot of innovation going on in the field, especially where more popular languages are still struggling to
catch up with the capabilities of an almost 50 year-old language.
Yeesh. My school taught COBOL and FORTRAN, but only for non-CS majors. ME students had to take FORTRAN IIRC, but CS majors couldn't receive credit for either course. CS majors started with Pascal and went from there into C, C++ and assembly (Java wasn't a thing yet).
Downmodding is the refuge of the weak. Don't downmod, make a better argument!