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. . . .
This is one of my pet peeves. Every time one of my people learns some new language or tool, they think it's the answer to all of our problems and will go out of their way to try to use it to solve every little problem that comes up, whether it's appropriate or not. It's gotten to the point once or twice where I've actually had to ban certain things from our shop because they were causing confusion and slowdowns.
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.
Even if a language is really hyped, in reality it may not offer anything useful.
For example, I've heard a lot about Rust lately, so I decided to investigate it.
I started by reading through the tutorial and the standard library reference. They were mediocre, at best. Nothing about them made them more useful than the docs for the other languages I use often.
The language has some lofty goals, but most of the time it just ends up being an awkward subset of C++. Syntactically, they're quite similar. Semantically, C++ allows you to do what Rust offers, but usually with more flexibility. The memory safety that Rust claims to offer can be achieved in C++ using smart pointer classes, or even garbage collection libraries, for example.
Rust uses a lot of abbreviated, two or three character keywords, which may be quick to type, but they're nowhere near as convenient to read. When I see the abbreviation "fn", I don't think "function", I think "fuckin'". When I see the abbreviation "impl", I don't think "implementation", I think "pimple". At least C++ tends to use the full word.
I never thought that C++'s standard library was very good, but it's a pleasure to work with compared to Rust's. Rust's string handling is a particularly bad disaster, and this permeates throughout the entire standard library. Rust's standard library is pretty pathetic compared to C#'s, or Python's, or even to all of the Perl CPAN modules that are out there.
There's only one Rust implementation currently. I found it big and bloated, and pretty buggy, too. For a language that's supposed to help make it harder to write buggy code, their compiler and standard library implemented in Rust by the developers of Rust are pretty damn buggy! Just look at all of the GitHub issues if you don't believe me. At least there are multiple high quality C++ compilers for every major platform, both open source and commercial.
I went looking for sample Rust code to learn from, and a lot of the code that's out there is totally out of date. People got interested in Rust, wrote a half arsed library, put it on GitHub, and then forgot about it. Only code written or updated within the previous week tends to be usable. The only other Rust code base that I found that was of any appreciable size was Servo. But it isn't a good reference either, because it sometimes uses outdated Rust idioms. I also tried running Servo on my desktop, and it was the buggiest browser I've ever used (although it is still under development). For a browser written in a language that's supposed to prevent bugs, Servo was pretty damn buggy!
I just don't see why Rust is getting as much hype as it currently is getting. There's nothing special about it. Anything it does can be done when using C++. Often it's easier when using C++, if you can believe that! I kind of regret wasting my time learning more about Rust. I didn't get anything positive out of the experience, other than a greater appreciation for C++, and a reminder not to believe the hipster/Silicon Valley hype.
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.