Slashdot Mirror
Is It Worth Learning a Little-Known Programming Language?
Nerval's Lobster writes: Ask a group of developers to rattle off the world's most popular programming languages, and they'll likely name the usual suspects: JavaScript, Java, Python, Ruby, C++, PHP, and so on. Ask which programming languages pay the best, and they'll probably list the same ones, which makes sense. But what about the little-known languages and skill sets (Dice link) that don't leap immediately to mind but nonetheless support some vital IT infrastructure (and sometimes, as a result, pay absurdly well)? is it worth learning a relatively obscure language or skill set, on the hope that you can score one of a handful of well-paying jobs that require it? The answer is a qualified yes—so long as the language or skill set in question is clearly on the rise. Go, Swift, Rust, Julia and CoffeeScript have all enjoyed rising popularity, for example, which increases the odds that they'll remain relevant for at least the next few years. But a language without momentum behind it probably isn't worth your time, unless you want to learn it simply for the pleasure of learning something new.
Nice that TFA titled, "Should You Learn a Little-Known Programming Language?" shows a screenshot of JavaScript, but I digress.
Little known languages aren't always actually little known or used, just less and/or not main-stream. They are often languages used in specialized areas or use less common syntax and or structure - like PROLOG and LISP. As such, using them can often help a programmer think and problem solve in new/different ways that may help programming in more common languages. I know learning LISP help my recursion skills.
My LISP and PROLOG skills two are a bit rusty, but I've used (and was proficient with) several dialects of LISP and would probably enjoy a job using either language again.
It must have been something you assimilated. . . .
Every language has tradeoffs, otherwise we'd all just use the one that didn't make any sacrifices.
Ruby excels in productivity, developer workflow, infrastructure tools and flexibility but it's tradeoffs is actual speed and concurrency.
Go excels in concurrency, portability, team development and keeping you close to the metal but it's tradeoff is a much slower working speed for everything around HTML as well as a different way of thinking about problems.
Java excels at speed with the tradeoff of severe lack productivity and a dependency on a lot of extra tools to make the process even passable.
C# is actually a great language but the tradeoff is the Microsoft stack and costs involved (for the most part).
Perl excels at text parsing.
PHP excels at low cost web hosting due to lack of RAM commitment (256mb of RAM can still serve 1TB of PHP scripts...just not all at the same time).
Everything has tradeoffs.
There are probably less than half a dozen basic language syntaxes. COBOL/Fortran/Python, Algol/Pascal/Modula/Ada, C/C++/JavaScript/Perl/PHP, LISP/Scheme, RPN/Forth/Smalltalk. and so forth, not even touching other relatives of the forms I've just named.
What makes them different languages isn't the language, and it isn't really even the support llbraries (if any), It's the way of thinking that comes along with the language. Whether it's object-oriented, message-oriented, parallel-optimized, Functional, whatever, each language has its own characteristics.
As the old adage goes (something like) being able to write COBOL in 17 different languages. Yes, you can pick up the syntax in a few days and begin to get a feel in a few weeks, but most people won't think naturally in a language's mindset unless they've spent several months at a minimum at it.
COBOL is an excellent example
Is it? How come I never see job ads for COBOL programmers? I know no one who uses it. I have often heard that it is used in "banks" or for "business" programming. But I know several people that work as programmers at banks, and none of them use COBOL or are aware of it being used at all. They are all Java shops. Same for programmers writing business logic. So I think that all these myths about demand for COBOL programmers is a load of hogwash.
Perhaps ADA would be another example?
Ada was oversold in the 1980s, and quickly developed a reputation for poor performance, and heavy resource requirements. Few systems were written in it, and even mission critical military systems (which Ada was designed for) could commonly get an exemption to use something more sensible.
I agree, but I'd like to expand a bit.
It's not important to know a bunch of languages deeply. I think it's important to learn two or three languages fairly deeply and a few more at a shallower level.
One doesn't really know the right tool for the job until there's some experience with multiple tools. The more different the other languages are from you main language, the better one can judge the best tool. There are lots of different types of languages, and knowing a few types, their advantages, and their disadvantages can be really helpful.
An Algol family language, particularly from the Modula/Pascal/Ada/Object Pascal family or the C/C++/ObjectiveC/Java/D family, is a good choice for getting practical work done. Perl, Python, Ruby, JavaScript, Rust, Go, Lua, Erlang, or something else fairly popular and a little more separated from those other Algol-derived languages but not terribly so is not a bad second choice. It's good to be familiar with something from the functional camp: Lisp/Scheme/Arc/NewLisp or ML/SML of NJ/CAML/OCAML or maybe Haskell. Stack-based languages like Forth or Factor can be handy to learn, or something else in postfix like Postscript. Something actor-based or dataflow-based can open some lines of thought. Assembly isn't used directly much anymore, but nobody ever became a worse programmer from understanding it.