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.
There is enough similarity between programming languages that there really is no point in learning any more than what you need. If you find yourself in a position where you need to learn a new one, as long as you have a pretty broad background it usually only will take a couple of days to get going and a couple of weeks to get really good.
Only Windows 7 luddites use programming language. Modern app appers write apps written in App Languages!
Apps!
Bread and butter has been C# the past few years, currently enamored with f# and racket. I don't think I'll be able to find a job with these, but it certainly has returned me to a "fun" mode.
If you were me, you'd be good lookin'. - six string samurai
APL
The answer is a qualified yes—so long as the language or skill set in question is clearly on the rise.
Very much this. There is a reason why I, and many of my colleagues, leave Ada off our resume. I know more than one person who's stuck doing maintenance work on defense projects that haven't been cutting edge for more than 20 years because they hitched their wagon to obsolete languages.
The better companies are innovating and looking towards the future. Learning a new language that is on the rise is a good idea. Even if it doesn't pan out, the experience isn't always wasted. And you can demonstrate to future employers that you a good hire because you're good at learning new things in new environments.
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 week I seem to see a slight variation on:
"Is learning %s worth it?"
"What is value of learning %s vs. %s?"
"Would you learn %s to switch jobs?"
I'm beginning to think this Dice account is just an autopost with a random list of possible values.
I'm very well versed in PPC assembly. I've found a quite wonderful niche working on automotive controllers. I also have several subordinates well versed in Tricore (Infineon automotive CPU) assembly.
Neither of those will ever make it onto any list of "popular" anything, but we all make plenty of money doing it.
As important as those two languages are to what we do, I've never hired anyone that listed either of those things on their resume. The ones that did list them specifically had at best a rudimentary understanding and little other practical background that would make them useful.
Don't learn something because you think you can make money with it. Learn something because you like it and want to use it. Then, find an employer that values your talents and willingness to learn whatever they need you to learn.
That's the best path to a good paying job.
And if you pick the right one. A "language on the rise" may not be a good thing if everyone is jumping on it. By the time you learn it, the limited but growing market may be flooded. You can even pick a language that is falling off, as long as the programmers are falling off faster. A good example is COBOL. It is truly a dieing language. But with many COBOL programmers in their 70s+ the need is actually growing. (That said, you could not pay me enough to program in COBOL)
It's about training your mind to understand something hard. Learning a little language exercises will-power, discipline, and focus.
Start with How to Design Programs and work it through, from beginning to end, even if you are a good programmer.
Then go to Structure and Interpretation of Computer Programs. Work through the chapters that you find interesting.
Then start with learning Common Lisp. Even after 30 years existence, there is still no other programming language which implements everything that is possible with CL. There might be programming languages which are more specialised in certain language subsets that are also part of Common Lisp, but none includes everything that CL includes.
Then learn Common Lisp macros, and realise that to get at the same level of possibilities in other programming languages, you need to embed a Lisp system. But that will be a slow interpreter, and Common Lisp can compile.
COBOL is an excellent example, it has become niche, but will be in use on "mission critical" systems for years to come. Perhaps ADA would be another example?
If you want news from today, you have to come back tomorrow.
Over the years, I've worked with about 20 different languages. I learned a lot of them purely out of interest. Even if you won't need it for any "serious" or paying work, it can be useful to learn a new language that is different from the languages you know. For example, if you know C# you won't learn that much by working with Java; they're too similar. By contrast, if you try learning a language like Haskell or Go instead you'll get introduced to new ways of thinking.
In almost all languages, there are things you can do easily or "naturally" in it. These language (and framework) features usually influence how you would design a program in that language. And it's these concepts that are worth learning. For example, when I learned Ruby and later Haskell, I learned how powerful concepts like map/select or working with closures are.
This knowledge then transferred to the languages I usually work with; my designs in my "traditional" languages changed because of the things I learned while working with other languages.
So even if the new language is not "one the rise" it might pay off by indirectly improving your skills in the languages that you do get paid for.
Several years ago, I fought tooth and nail over selecting the new test automation framework we were going to start using at work. I wanted a nice, modern, resume-building language like Python/Ruby/Java. What did they pick? - a legacy internal system written in Perl (and abandoned by the original author who had left the company).
Over the last year, I've become a moderately skilled, OO Perl programmer, and it's worth six figures to me. Good enough. :)
- Necron69
Even if you never make use of the new programming language it is almost always worth getting your head around a new way of thinking about problems. You may not ever need to write code in Lisp but understanding what a functional language is and isn't good for is helpful in other languages. If you're building flight control systems then Python might not be the language to do it in but getting deep into it and start understanding why you'd want a metaclass in the first place can help you stricture your code better. There aren't a ton of job openings for Erlang programmers but there are lots for people who understand High Availability and Disaster Recovery and the background knowledge will stand you in good stead.
In short, yes, it's worth learning all the languages your brain can handle. Even if you forget the details the concepts will stick around and help you later.
If intelligent life is too complex to evolve on its own, who designed God?
The simple answer is that once you learn how to code it doesn't matter what the language is.
I couldn't disagree with this more. I don't mean to be flippant or argumentative; I simply want to say that my experience has been quite different. I think the langauge you write programs in is incredibly important. You want the right language for the task at hand. Just as an example, I often prototype new ideas for algorithms in Perl as a prelude to rewriting them in C. Perl (and I'm sure Python is as well) is great for a quick prototype and for proof-of-concept testing. But it's terrible for speed (compared to C/C++), and is also terrible at type-safety. When I rewrite something in C, it often runs 100 or 200 times faster than the Perl version. (Not for parsing and string-based stuff, but for integer numerical analysis stuff). But exploring the data structures and getting them worked out first is easier in a high-level language like Perl, with its dynamic arrays, hashes, autovivification, and so forth. Anyway, I rarely prototype something C, and I rarely write production code in Perl. For me, the choice of the language is one of the most important decisions I make on a daily basis.
You can't go wrong with REXX
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
One big factor, here, however, is how similar the language is to ones you already know.
For instance, if you already are well-versed in C and C++, looking at some D or Rust code probably isn't going to be hard for you. However, looking at something in Haskell or Lisp is. A lot of languages these days are very C-like and either imperative or object-oriented (in an imperative way), so to me it's really rather trivial to learn them; it's just a matter of learning what's different. But if you start looking at languages which are really different from ones you know, then it becomes much more challenging. Looking at one with syntax unlike C will be one factor (like with Python), but looking at something entirely different like a functional language will be even harder.
You get typecast. You could have 3 decades of C/C++ and mention that you studied APL for one semester in college and all the calls you'll get will be for APL jobs. I don't even list LISP on my resume, even though I became enlightened in LISP in the 90's. With LISP, enlightenment is a heady feeling where you suddenly see the elegance with which everything fits together, followed by the sinking realization that if you want to actually do anything with the language you'd have to write all the libraries yourself.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
The simple answer is that once you learn how to code it doesn't matter what the language is.
I couldn't disagree with this more. I don't mean to be flippant or argumentative; I simply want to say that my experience has been quite different. I think the langauge you write programs in is incredibly important. You want the right language for the task at hand.
I don't disagree with this at all. My point was that you don't need to go out and learn an entire language just because you think it might be useful to do. Once you know one or two languages it's not important that you know other languages, just that you know what situations other languages would be better suited for. When you run into one of those situations, it's just as easy to pick it up on the fly because you already have the core knowledge from the existing language(s) you've learned.
I think of it this way... a decade ago my professor gave us a little anecdote about how, if you learned 10 new methods in Java every day for the rest of your life - you'd be dead before you learned everything that was in Java. Since you can't "know" a language because it's constantly being created/changed/etc the best thing to do is understand rather than know.
I think you meant "now Forth Learn".
Precisely!
This becomes an even bigger deal if you are talking about jumping entire language families. Moving within things like C, Java, C++, Python, etc, most of the thought patterns associated with how you solve problems goes with you. Throw that same programmer into a FORTRAN, LISP, or eris forbid Prologue, and there will be a larger learning curve than just the syntax and limitations.
I don't think you understood the GPs point. He is talking about choosing a language to learn, not choosing a language for a particular task. Certainly, the language you choose for a task is important.
The reality is (and the GPs point) learning a new language shouldn't take you very much time. If you have to ask whether a language is worth learning, the answer is 'YES' because at that point you need more experience learning languages.
"First they came for the slanderers and i said nothing."
Though keeping with that analogy, cars might all be pretty much the same, but hand someone a motorcycle or a big rig and the learning curve makes it so knowing the rules of the road is barely even a start. And people handed a boat are really confused.
Certain languages will definitely take a little more time. Lisp is a great example - I've never had the need to use it so I just looked up some code for the first time... it is different but even with the differences I could see the basics at play. I could understand where a conditional started and ended, how certain loops worked, etc. and that's with a quick glance of a random piece of code from google images. Give me a proper doc and an hour I'd be good to go.
Actually, this is a good analogy. You can get from Texas to New York using an F150 or using a Yaris. But what is the purpose? Are you lugging your spouse and 3 kids for a vacation? Then maybe go for an SUV or minivan that provides comfort. Are you transporting some goods? Maybe a truck with a tailer. Is cost a concern? Maybe fuel efficient vehicle. Are you a hipster? Maybe a Tesla.
But even with these different requirements, you still have choices.
Or is it a punishment?
So rise up, all ye lost ones, as one, we'll claw the clouds.
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.