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.

Comments

Yes if you can afford the time

[juanfgs]

/thread

Re:Yes if you can afford the time

[houstonbofh]

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)

Re:Yes if you can afford the time

[JMJimmy]

Not quite.

The simple answer is that once you learn how to code it doesn't matter what the language is. Sure you need to learn where the limitations are, efficiencies of the language, syntax, etc but at their core most programming languages are the same.

I taught myself PHP/JavaScript/etc back in the day, took a few courses with Java but never touched a lick of .NET/VB/ASP. Without knowing anything about how someone had coded a page in ASP.NET, simply looking at the output times, I was able to diagnose an issue, code & test a framework for a fix to be integrated into his code. It took me all of 2 hours and access to language documentation to "learn" ASP.NET and managed to triple the efficiency of the code.

Re:Yes if you can afford the time

[flargleblarg]

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.

Re:Yes if you can afford the time

[Grishnakh]

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.

Re:Yes if you can afford the time

[Grishnakh]

I wonder how your performance would compare if you wrote that code (the production code I mean) in C++ rather than C. C is missing all those features, whereas in C++ you can get most of them using the appropriate library. Lots of C++ libraries have hashes (I like Qt's implementation personally), and it also has autovivification.

Re:Yes if you can afford the time

[JMJimmy]

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.

Re:Yes if you can afford the time

[Anonymous Coward]

Given that you are fluent in both Python and C maybe you should take a look at http://nim-lang.org. Nim has replaced both my C and Python habits, and has taught me a few things I would have imagined ever in C or Python.

Re:Yes if you can afford the time

[jythie]

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.

Re:Yes if you can afford the time

[phantomfive]

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.

Re:Yes if you can afford the time

[jythie]

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.

Re:Yes if you can afford the time

[scamper_22]

I find this one of the great tragedies of software development. I'm not saying the alternative would be better. I don't know how it would play out. I'm just commenting here.

Any of the 'big' languages (c, c++, java, c#) have all the ability to make things really easy.

Heck, I recently started using c# as my main scripting desktop scripting language (cs-script). I end up writing slightly more convenient wrapper so you don't end up worry about exceptions as often and polluting scripts.

You could for example have a generic Object map in c# and use it for all kinds of data passing just to get things working. Heck, one of my prototype techniques is often to just pass a map as a function parameter knowing I will be adding/deleting things as needed.

Heck, with a little bit of work, I'm sure someone could write some useful utilities/objects to make c#/java meet 99% of the use cases.

Instead for too often, people run out and build a whole new language.

Re:Yes if you can afford the time

[JMJimmy]

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.

Re:Yes if you can afford the time

[JMJimmy]

Well said.

Re:Yes if you can afford the time

[master_kaos]

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.

Re:Yes if you can afford the time

[nabsltd]

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.

Modern FORTRAN won't be that big a deal for anyone familiar with C and bash. Same looping structures, free-form code (indent however you want), etc., but just no braces to mark blocks.

Re:Yes if you can afford the time

[jythie]

Does anyone actually use modern FORTRAN though? I only ever see the '77 variant and the rare job postings I looked into indicated that was the version they were hoping to find people for.

Re:Yes if you can afford the time

[mr_mischief]

Also "M".

Re:Yes if you can afford the time

[mr_mischief]

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.

Re:Yes if you can afford the time

[DoofusOfDeath]

> Does anyone actually use modern FORTRAN though?

Some physics models do.

Re:Yes if you can afford the time

[jythie]

Interesting. Last physics project I worked on standardized on f77 across the project, but it was one of those 'decade to build the device' ones that kinda encouraged using older standards simply by virtue of not changing what they started with.

Re:Yes if you can afford the time

[servant]

As a retiree, I look at programming as a fun thing. I did do COBOL and FORTRAN and assembler for pay in the past (PL/1 was my favorite, but did more REXX than anything).

But to get me to program again in any language, I need to be paid enough to cover MY 'threshold of pain' involved in working for someone else.

My threshold was less when I needed to feed, clothe, and house my family. Now days, that is a LOT easier to do, so I can set my threshold where I want it to be.

My current consulting rate for a rusty programmer/sysadmin is $80/hr + expenses on a W2. That is enough to get me interested. Less than that, give GEEK SQUAD a call and see if they can help. (I do get some consulting at that rate, but mainly give away services to help local 'little old people' get their AOL account working again).

---

I hated COBOL, but did enjoy maintaining code that had gone through 'automatic' PL/1 to COBOL and then back to PL/1 translations ... they were worse that just maintaining COBOL or PL/1 (or even accounting programs in FORTRAN IV years before). But if COBOL is that important, folks will pay ANYTHING to get their systems running. If they are smart, they also pay to have the system re-analyzed and re-built using a newer and more maintainable systems. Systems designed for punch cards, tapes, and paper printouts need to be re-designed to work well in interactive environments (old ones tended to be batch only, now days, batch is OK but interactive is better if the application lends itself to it. And real-time is a different beast than interactive too - especially 'hard real time', that yes, I did some of all of it over the years.)

Re:Yes if you can afford the time

[angel'o'sphere]

Insightful but wrong!

Smalltalk, Lisp, Prolog, Haskell and (C, Pascal, Fortran) all work completely different.

You don't jump form C++/Java/C# to SmallTalk in a day.

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
That is nonsense, too.
Obviously the creators of Java can, why can't you?

Re:Yes if you can afford the time

[JMJimmy]

Based on the 30 second look at Lisp code the other day, I'd be comfortable with it within a day. I'm not going to be a rockstar but I'd be able to get by. Heck, I tought myself PHP/MySQL/JavaScript/HTML in 3 weeks on the fly.

As to the anecdote being nonsense, here's a reality check for you:
Java 7
Learning a package a day: 210 days
Learning a class a day: 11.03 years (4027 classes, number does not include subclasses)
Learning 10 methods a day: Honestly, I'm not going to figure out how many methods are in Java but needless to say it'd likely take you over 100 years.

Re:Yes if you can afford the time

[angel'o'sphere]

Oh he meant "methods" as in "functions"?
I assumed methods of thinking and / or developing.

Why would anyone want to "learn" the packages and classes and methods of a programming languages base installation is beyond me.

90% or even 99% of it you simply get by using the IDE wisely.

Ofc. there are corner cases ... but my amount of "packages" and "classes" I know after nearly 20 years of Java development is rather low. I'm not interested in learning such stuff, and I never needed to.

Re:Yes if you can afford the time

[flargleblarg]

I did say that, yes. I find C's compile-time type safety to be quite good. With the right compiler warnings enabled, it prevents me from accidentally storing a uint64_t into a uint32_t, and from doing stupid things like int64_t x = -10 * y when y is of type int or int32_t. (The correct code is int64_t x = (int64_t)(-10) * (int64_t)y;.) My C compiler is meticulous about catching things like this at compile-time, and I love it.

The only perils I find with C's type system is in void pointers, for example when implementing a comparison routine for qsort — but I really wouldn't call that perilous.

No.

[Anonymous Coward]

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.

Re:No.

[mlts]

On the other hand, once you learn a few programming languages, it becomes easier to know others, (assuming something that isn't completely different, such as a procedural language (C or Java) versus a functional programming language (Lisp, Scheme), versus assembly language.

If you know C, you can consult the camel and make functioning perl code. So, it might not hurt knowing a non mainstream language, and may not take too much of your time, relatively.

Re:No.

[Anonymous Coward]

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.

Re: No.

[Anonymous Coward]

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.

Re:No.

[Anonymous Coward]

There is enough similarity between programming languages that there really is no point in learning any more than what you need.

That's true with a lot of the "C-with-X" type programming languages that are out there (e.g. if you know Python/Perl/Ruby you probably don't need to also learn Ruby/Python/Perl unless you have to), but there are also programming languages that are built around a wholly different philosophy, and I would argue that people *would* benefit from learning one of them, even if you don't actually ever use it.

The canonical example is Prolog. Not used for anything much in particular, but a completely different way of thinking about programming, and something that will definitely make you a more well-rounded programmer if you do learn it. Likewise, if you've never worked with a functional programming language, learning Scheme or Haskell will be a benefit. Something like Eiffel is good to learn design by contract. Heck, even esoteric languages like Brainfuck and Unlambda can be worth learning (but never using) for the different perspective they give on how to accomplish a programming task.

Of course, by "learn" here I don't just mean learn the syntax. By "learn" I'm referring to knowing the concepts behind the programming language, and understanding what is "correct" or idiomatic for that programming language, rather than "can I transliterate this FORTRAN program into Scheme syntax?" It's not "will I ever use this language" or "will this look good on my resume" but "what is the philosophy of this programming language, and what can I learn from it"?

Re:No.

[Anonymous Coward]

only will take a couple of days to get going and a couple of weeks to get really good.

This has always been my experience and is particularly good for contract work. I've always sought out obscure and obsolete systems. Well, technically all past tense because the money was so good I retired young.

I'm not hip on the newer languages, but don't need to be. And you are very correct in the amount of time it takes to learn a new language, especially the older procedural ones. I was very familiar with C, yet within literally minutes was writing Pascal code conversationally which is why I've always been confused about language wars. {/} begin/end, ; , who cares. Follow the money

Re: No.

[Anonymous Coward]

Ruby excels at giving a false sense of productivity.

There's nothing productive happening when it allows a junior dev, typically a hipster who dropped out of high school, the ability to artisanally craft slow, bug-ridden CRUD web apps. It's even less productive when such systems start losing data, or become too slow to perform their basic functionality. And it becomes even less productive than it already was when it becomes necessary to hire Java, C# or even PHP devs to come in and rewrite the system so that it actually works.

Re:No.

[Wycliffe]

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.

As a programmer, I can somewhat agree but if you're trying to get hired as a COBOL programmer chances are that you'll move
to the top of the stack if you actually know COBOL and can list it on your resume.
Also, just because you've been coding in one language for years and you can start writing functional code in a different language
after a couple week, you're not going to be as skilled at the nuances of that language as someone who has been using it for
several years.
I consider myself an expert in c, c++, and perl. I can read/write php and python just fine but I don't consider myself an expert
in them. It takes me longer to write code, find modules, debug, etc... in a language that I'm not as familiar with and having
hired people and cross trained them for a new language I can say that it takes about 6 months or longer for a new programmer
with a new language to be as fast in the new language as they were in the old language.

Re: No.

[PPH]

Everything has tradeoffs.

I agree.

Re: No.

[Marginal Coward]

Here's one you missed:

Python excels at being the jack-of-all-trades, though most of its trades have other masters (see above.)

Re:No.

[chipschap]

The thing is, HR departments don't understand that learning a new language, if you already are good with a few, is no big deal. HR people ask for things like 10 years of experience in Language X and they don't listen to reason, even if Language X has only been around for 2 years.

Re: No.

[RabidReindeer]

Python excels at quick-and-dirty. Unlike many of the scripting languages, it's applicable to a wide range of environments and usages. It doesn't require the time devoted to rigor that Java does nor the time devoted to avoiding pitfalls that C/C++ does. It's not "write-only" and the syntax isn't littered with cryptic constructs. It doesn't induce writers cramp like COBOL and it handles strings more graciously than FORTRAN. If you have one-off tasks that don't need polishing, what you hacked out in a short period is probably going to make a reasonable amount of sense when you or someone else picks it up again a year or 3 later.

In the Windows world, this is a niche that VB occupies. In the wider world, where VB isn't available, it's Python.

Re:No.

[Anonymous Coward]

OP was talking about people with a broad enough background where Haskell isn't inimidating.

How did you reach that conclusion? It's a two sentence post from an AC that doesn't cite a single language or programming paradigm. Yet somehow you've managed to characterize his precise meaning.

Re: No.

[Tailhook]

And it becomes even less productive than it already was when it becomes necessary to hire Java, C# or even PHP devs

Yeah, I've noticed how everything written in Java, C# and PHP are brilliantly fast and bug free.

Re:No.

[RabidReindeer]

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.

Re:No.

[tompaulco]

There is enough similarity between programming languages that there really is no point in learning any more than what you need.

Well, there is a point, but it is a stupid one. If you are trying to get a job and the new company needs people who know $new_unproven_language and you only know 100 other languages, then HR won't let you through the gate, even though someone who has learned 100 other languages obviously could learn a new language in a few days or weeks.

Re:No.

[Anonymous Coward]

Haskell is a fairly conventional language

Oh horseshit. Haskell might be old hat to hipsters that blog about boutique languages all day, but the average coder doesn't know an applicative functor from a warm puppy. Almost none of our "conventional" languages provide even something as simple as function composition.

Relative to common languages Haskell is not "conventional."

Re:No.

[Cro Magnon]

Yeah, even if you have 5 years experience in Language Y, which is very similar to X. :-P

Re:No.

[Anonymous Coward]

Nonsense.

There is *significant* variability in programming languages. Even among popular languages, the difference between Java and JavaScript is pretty drastic. Techniques that make sense in one can be basically nonsensical in the other. On the other hand, there are techniques that one language makes really obvious that you wouldn't think of in another - consider the use of dynamically typed global object stores in some C++/Java game engines.

When you get into less common languages, you see things that are *really* different from normal practice. In Haskell and Clojure every object is an immutable value. You can't change things - you can only make new ones. If you haven't seen this before it sounds silly, but it turns out to be a really powerful technique that gets used in any language. And then there's languages like Factor or ZPL that are really obscure, but also completely different from anything in common languages.

If you haven't used languages / environments / techniques with all of the following properties, you're not working with a full toolbox:

• Garbage collection
• Unabstracted manual memory management (e.g. C)
• Very strict static types (e.g. ML, Haskell, Rust)
• Class based OO in a statically typed language (e.g. Java)
• Class based OO in a dynamically typed language (e.g. Ruby)
• Prototype based OO (e.g. JavaScript)
• Dynamic metaprogramming (e.g. Io)
• Template metaprogramming (e.g. C++)
• LISP-style macros
• Thread / mutex concurrency.
• Enforced message passing concurrency (e.g. Erlang or a distributed MPI application)
• Lightweight threads (e.g. Erlang, Go, Haskell)
• Event-based concurrency with callbacks (e.g. nodejs)
• Software transactional memory (e.g. Clojure)
• Data parallelism (e.g. OpenCL)
• Efficient arrays without abstraction (e.g. FORTRAN)
• Enforced immutable data (e.g. Haskell, Clojure, Erlang, ML)
• Full-array operators (e.g. APL)
• RAII (C++, Rust)

And that's the stuff I can think of offhand. There's more. And every one of those things is a powerful tool that makes some hard problems simple, but many of them can't exist in the same language at the same time. You can't have immutable data and efficient raw arrays. Having static types and dynamic metaprogramming at the same time would be tricky and probably unusable. Having RAII and GC at the same time is basically unsolved. So no one language can do everything.

Re:No.

[Half-pint HAL]

OP was talking about people with a broad enough background where Haskell isn't inimidating. Just neat.

Where does he say that? It's not in TFA, TFS or the ACs post.

There are some significant paradigm differences between superficially similar languages. If you don't know list/generator comprehensions, you don't know them. I started learning Python several years ago for a project that has been going quite slowly, and even now I stumble across the odd for loop that I struggle to understand because I wrote it in a C style. Refactoring to a comprehension makes the code more readable and debuggable, but when I came to Python with the mindset of "if you know one language, you can pick up any other language easily", so I wasn't on the lookout for that sort of thing.

I had also completely glossed over the power of local functions -- even though I read lots about them -- because they weren't in my active mindset. Then I did Dan Grossman's Programming Languages course on Coursera, and was forced to look properly at local functions, and learn them. Now whenever I'm debugging my code, I find myself abstracting out bits and pieces to local functions wherever appropriate.

When I first "learned Python", I was basically coding in braceless C with Python objects thrown in for good measure. If you have a specific task to complete while you're learning, all too often you end up just focusing on getting the job done and you hack through it, and the knowledge of the language you glean from the process is incomplete and hacky.

Re:No.

[HiThere]

Different langaguages are different.

OTOH, I disagree with the basic premise of the article. It is my belief that one shouldn't learn a new language to improve ones job prospects, but rather to improve ones skills as a programmer. So if you know C++, then you don't learn C# or Java, but rather Eiffel, Lisp, or Haskell, or possibly OCaML.

OTOH, If you already know C++ or Java, it's certainly easier to learn Python or Ruby. So easy that a basic knowledge can be learned in a day. So if you're tight on time, that will allow you to expand your capabilities in small increments. (But a basic knowledge won't teach you the libraries, which is where the important differences lie.)

FWIW, I first learned Fortan, actually FORTRAN, since it was before Fortran 77 was standardized. But then I went on to Snobol, PL/1, etc. I never did really master LISP1.5, but I didn't have access to a running implementation. With Lisps a decent IDE is nearly a necessity to start with. (Currently, if you want to pick up a lisp, I'd recomment Racket Scheme from PLT. It's got a decent development environment.)

OTOH, I dropped C++ about 20 years ago, and am no longer fluent in the modern dialect (something I keep meaning to correct). My current favorite language is D (Digital Mars D, or dmd), before that I cycled between Ruby and Python. Before I retired I normally wrote in whatever my employer chose, which, towards the end, was MSAccess Basic...a really foul language. So foul I wrote routines in Eiffel that did the work and just used the MSAccess Basic as a driver. Not only was it faster to write, it was also faster to execute, and unlike MSAccessBasic, the programs wouldn't arbitrarily start failing after a few months of use. (In the AccessBasis I used to need to save the programs as text files so that I could re-import them after the system corrupted them. Figuring out that there wasn't actually anything wrong with the programs took a lot of quite furstrating debugging, since a newly entered program would work properly. It's my guess that the system was storing some invisible binary code in with the source, so the source became unusable when the code got corrupted...why the code ever got corrupted I never found out, but it happened repeatedly to many different programs.) I presume that MS has by now fixed the problem, but it persisted over at least 5 years and multiple different versions of MSAccess.

Re:No.

[HornWumpus]

What they are asking for is 10 years experience slinging bullshit.

Re: No.

[narcc]

Unfortunately, it can't seem to maintain compatibility between minor versions, it's syntax is so fundamentally broken that anonymous functions were crippled, and only in the less-popular new versions does something as basic as the print function usable.

The world was better off with VB.

If you are optimizing only for pay ...

[Anonymous Coward]

you are doing it wrong, IMHO. Learning languages always broadens your horizon. Whether you want to spend your time doing that instead of getting more work done with a language you already know, or spend it doing something else entirely, is another question of course.

Re:If you are optimizing only for pay ...

[Darinbob]

If you are optimizing for pay, learn ALL the languages, because whichever one you choose may become obsolete in a couple of years.

Programming languages are for luddites.

[Anonymous Coward]

Only Windows 7 luddites use programming language. Modern app appers write apps written in App Languages!

Apps!

Re:Programming languages are for luddites.

[fisted]

Only Windows 7 luddites use programming language. Modern app appers app apps apped in Apple's App apper!

FTFY. Next time at least do it right.

Doing it now...

[Rinikusu]

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.

Re:Doing it now...

[bobbied]

My only problem with C# is that pesky vendor lock in. For now, you gota run that on Windows. I don't mind Windows, but I do mind being forced to use it.

Re:Doing it now...

[Idimmu Xul]

mono wants a word...

Re:Doing it now...

[micahraleigh]

Vendor lock in: yes.

Windows only: not so much

Re:Doing it now...

[bondsbw]

Not true, C# has been off of Windows for a long time by way of Mono.

Microsoft is open-sourcing .NET Core, which supports ASP.NET v5 on Windows, OS X, and Linux.

Kerbal Space Program is an example of a game that was written in .NET (I believe specifically in C#) but is available on OS X and Linux. External plugins can be created in C#.

Xamarin provides a way to write native cross-platform applications using shared code and native user interfaces.

I think it's fair to say, we're well past the day where anyone can claim that C# is completely locked to Windows.

Re:Doing it now...

[bobbied]

Not true, C# has been off of Windows for a long time by way of Mono.

Mono with .NET support is at the whim of Microsoft's choice to release the .NET framework into open source.

Not to mention that Mono exists at the pleasure of Micro$oft who could easily kill it with a simple infringement lawsuit. I'm not saying they'd win, only that such a suit would kill Mono which has no resources to fight such a thing.

Re:Doing it now...

[Marginal Coward]

I think it's fair to say, we're well past the day where anyone can claim that C# is completely locked to Windows.

The word "completely" seems like a pretty strong hedge here. Sure, Mono exists, but it seems to be a bit of an unloved stepchild of the Open Source world, which generally seems to regard all things with any relation at all to Microsoft with some combination of hostility, suspicion, or at least disinterest. So, is Mono "a real boy" now in terms of being a full-fledged alternative to .net at all levels including features, libraries, tools, etc., or is it actually an unloved stepchild, as I seem to have perceived?

Re:Doing it now...

[Grishnakh]

Not true, C# has been off of Windows for a long time by way of Mono.

The conventional wisdom here has been that Mono is always a few steps behind MS's implementation of C#, so it's not fully compatible.

I don't know if that still holds true, but it used to be the general understanding.

Re:Doing it now...

[Daltorak]

My only problem with C# is that pesky vendor lock in. For now, you gota run that on Windows. I don't mind Windows, but I do mind being forced to use it.

Ermm..... C# and VB.NET are Apache-licensed, open-source projects, hosted on Github, built with Jenkins. running under Linux and Mac OS X as well as Windows. Forking is encouraged, pull requests are taken, and you can talk directly with the Microsoft people who're paid to work on this stuff in a Gitter chat room, through issues on Github, and so on.

And yet people still drone on about vendor lock-in with these languages. Amazing how little fact-checking people do before posting sometimes.

Re:Doing it now...

[BaronAaron]

If you're expecting Mono to cover every aspect of the .NET runtime you're missing the point. I look at Mono as an excellent, open source, managed runtime environment and language that also happens to follow the ECMA standards Microsoft released for the .NET CLI and C#.

People expect Mono to be able to run any .NET app under the sun on any platform. That sometimes works, sometimes doesn't depending on the app. It's much more suited developing a new apps that you want to be cross platform.

As other posters pointed out, this is all a mute point anyway. .NET is now open source under MIT license. The Mono team is working closely with Microsoft on merging the two code bases.

Re:Doing it now...

[RabidReindeer]

When an app dives into one of the Windows-only assemblies, Mono's word is "broken". .Net and Java are a lot alike. Both are "universal" platforms (originally) sponsored by vendors of operating systems. But .Net is turned inwards whereas Java is turned outwards. Indeed, the only reason .Net exists is because Sun wouldn't let Microsoft weld Windows-only functionality into their version of Java.

Re:Doing it now...

[shadowrat]

C# isn't as limited anymore

Re:Doing it now...

[phantomfive]

Mono works fine as long as you have at least one person on your team writing in Mono, not Visual Studio. That way you won't accidentally build on incompatibilities.

Re:Doing it now...

[seyyah]

As other posters pointed out, this is all a mute point anyway.

That's what they all say.

Re:Doing it now...

[HiThere]

If I read the article announcing the release correctly, then while the basic C# language is (probably) open source, it's definitely not free. You can't make a version of it without the agreement of MS, and the released version by MS is ... incomplete. Parts of it are portable, others aren't. So you can only use it as MS desires.

IIRC the release agreement said something like "permission is given to any full and complete implementation that fully implements the specifications" I forget whether the specifications were subject to unilateral change by MS, but even if they weren't it means that the language cannot be implemented by anyone except as desired by MS. Also, of course, the libraries were not made available, which reders it essentially useless except on MSWind machines.

Now just because their public promise didn't allow something doesn't mean that they won't ignore any "infringing" code as long as they feel like it. But it does mean that only a trusting (characterization deleted) would put their own time and effort behind it...without some form of idemnification.

So I'm going to pass on C#. It'd rather trust Oracle's Java (which I also avoid, though not all the time).

Re:Doing it now...

[HiThere]

Not clear on what you consider "good". The ones that occur to me are WxWidgets, Qt, and Tcl...which can be good depending on your purpose. All of those can be used on Linux, Apple, and MSWind, and probably on BSD. All of them can be used from C, C++, Python, and Ruby. And, I assume, other languages.

If you want a good graphic builder IDE, then Qt has some quite decent tools. I'm not sure about WxWidgets. Tcl used to, but they seem to have died of neglect.

Then there's Java which goes its own way, and has it's own GUI, and IDE with a gui-builder...but while adequate for many purposes, I find the Java gui to be limited even when compared to Tcl. Still, it *is* cross-platform.

So I guess it comes down to "what do you mean by 'good'?".

Re:Doing it now...

[mr_mischief]

I think in the context of the thread AC meant "good UI library that ties in well to the CLR". Sure, there's Qt, Wx, Gtk, SDL, Tk, etc etc. But how well do those tie into C# and let you run on Windows, Linux, and other platforms with Mono?

Re:Doing it now...

[Darinbob]

You usually can not take any old Windows .NET application and run it under Mono without porting it. Therefore, as a "run everywhere" platform it is lacking. The entire goal of microsoft in creating .NET was to kill the cross platform applications, after they lost out in controlling/subverting Java.

Re:Doing it now...

[Darinbob]

This is Microsoft. Vendor lock in is the one and only goal. Do not believe their marketing that they have changed their stripes and are now proud supporters of open source. Their track record says that they are not trustworthy. Trust must be earned.

Re:Doing it now...

[vilanye]

open sourcing it doesn't magically make it cross-platform.

It will be years before it comes close to being usefully cross-platform, at best.

little-known programming language

[rossdee]

APL

Re:little-known programming language

[avandesande]

Many of the problems with APL have been fixed in J, of course if you are going to work on old APL systems it would be your first choice.

http://www.jsoftware.com/

Re:little-known programming language

[Dadoo]

At least most people have heard of that language. Check out Databus (http://en.wikipedia.org/wiki/Programming_Language_for_Business), sometime. Yes, people still use it; I had to go to work early, this morning, to fix a problem that was caused by one of its many limitations.

Re:little-known programming language

[HiThere]

If you're going to consider obsolete languages (the keyboards are no longer made) I'd nominate Prograf. It was a dataflow language that would have been great for multiprocessor systems except for two problems:
1) It was released for the Mac System 3 and never successfully transitioned to later systems, and
2) There was no text representation of the programs, it was all graphic, which was quickly too verbose to handle as the programs increased in size.

Re:little-known programming language

[mjwalshe]

I raise you LINQ :-)
A super rare Unisys Language

Re:little-known programming language

[Darinbob]

MUMPS is alive and well. Well, alive and not dead yet anyway.

Re:little-known programming language

[servant]

FORTH

Correct answer, in the first 2 posts: It depends.

[Anonymous Coward]

Post 1:

Yes if you can afford the time (Score:2)

/thread

Post 2:

No. (Score:2, Insightful)

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.

Additional commentary

But really this is an ill-posed question, and slightly offensive. Why are we treating all "programming languages" the same? There are obviously different tools that come and go in terms of usefulness. The question, as it is posed, is nonsense. If it is little-known because it is no longer useful, then it might be worthwhile to learn if you are into the history of programming languages. If it is little-known because it was designed to be like that, such as Brainfuck, then it might be worthwhile to learn it if you are a masochist. And so on....

A good point

[grimmjeeper]

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.

Re:A good point

[houstonbofh]

The answer is a qualified yes—so long as the language or skill set in question is clearly on the rise.

Very much this.

Not just this... If it is rising faster in programmers then it is in the market (which happens a lot with highly hyped languages) than you will be in a flooded market. Unlike the "dieing" languages that keep people in them forever because the need is so great. Obsolete languages can pay VERY well, and you can take your pick of jabs and locations.

Re:A good point

[gstoddart]

and you can take your pick of jabs and locations

Ooooh ... poke me in the elbow again!!

Re:A good point

[grimmjeeper]

and you can take your pick of jabs and locations.

Yah, I could get one of dem dere jabs in Chicago. Den I could watch da Cubbies, da Bears and, of course, da Bulls. ;)

Re:A good point

[grimmjeeper]

Trouble is, drudgery tends to dull your skills. Those who want to stay connected to the cutting edge won't be able to put up with drudgery for long. They will find themselves fighting against the inertia that comes with the drudgery, get fed up with the job, and leave to join something more cutting edge to begin with rather than stick it out for decades until retirement. If you're the kind who can put up with decades of drudgery, you will be so far from the cutting edge when you retire that you won't have any idea how to catch up with the cutting edge after being so far behind for so long.

Re:A good point

[Dutch Gun]

Question: is some other language actually replacing Ada for aerospace, DoD projects, and other mission-critical type projects, or is it you just don't want to work on those projects anymore?

Re:A good point

[Rinikusu]

Send me some job links. I'm in my 40s and looking to get off the cutting edge and settle down into maintenance mode code bases. I was *built* for drudge work.

Re:A good point

[grimmjeeper]

I actually like working in the aerospace field. I just don't like working on Ada because it has no future. Fortunately, Ada projects are becoming more and more rare.

Civilian aerospace vendors pretty much dropped every trace of Ada from new projects as soon as the FAA mandate was dropped back in the 90's. All new projects that I know of are in C and C++. There could be others that I don't know about. Same thing happened in the defense industry. Technical merits of the language aside, it's a lot harder to find people willing to work in Ada than it is to find C/C++ programmers, not to mention Ada development tools are harder to find and more expensive when you find them generally.

There's still a lot of Ada code out there because it's there and it works just fine for the task at hand so why bother changing it. They'll maintain it and even add significant expansions to it. But when it comes to new projects, more often than not they'll go with C/C++.

I've worked on a number of DoD projects that were coded in JOVIAL for the MIL-STD-1750A processor back in the 80's and they've all been translated over to C when the new hardware was commissioned to replace the 20 year old boxes they were running. I've been a technical lead on some of those conversion projects. There was never any question about whether to translate to Ada instead.

While C is a pretty loose language, civilian and aerospace jobs tend to work within a tight coding standard which is strictly enforced (more or less by project). They'll use standards like MISRA-C or something like that which put significant restrictions on the more risky constructs in C. Combine that with the exhaustive documentation and testing they have to do (no matter what language they use) and you end up with a product that's virtually bug free compared to a commercial product.

I'm not doing aerospace right now but I am designing software for satellite systems and the standards/documentation/testing environment is very similar to aerospace. I'm working in C++ on my current task. Well, a subset of C++ anyway.

Re:A good point

[grimmjeeper]

Look at industries with huge legacy code bases that aren't going anywhere. I'm sure you could find a home in an insurance company maintaining their COBOL code that hasn't changed a whole lot in the last 30+ years and won't probably change much for the next 30+ years.

Re:A good point

[HornWumpus]

Just be aware that all companies that sell products identical to their competitors (e.g. insurance) are run by the marketing departments.

On the upside if you know shit from shinola you will be a star among their staff. On the downside, you will still report to a marketer that was promoted to director of IT.

Re:A good point

[Dutch Gun]

Interesting, thanks for the response. I suppose it makes some amount of sense, because for every possible chip out there, it generally has a C/C++ compiler that supports it. And it's not surprising that you'd tend to find a lot more people well-versed in C or C++.

C++ gets a lot of hate (some deserved, some not), but you can actually use it in such a way that makes it very difficult for programmers to make silly mistakes like clobbering raw memory, and all in a way that requires little or no overhead beyond equivalent C code. I think that's part of why it's so popular in game development (my particular field).

And as you indicated, an effective strategy is to find a subset of the language that works well for your project and stick to that.

Re:A good point

[grimmjeeper]

A lot of the motivation for restrictions in avionics software center around what is considered safe.

For example, you have to put curly braces with every conditional and loop in order to avoid problems like the Apple "goto fail" bug. It's not a cure-all but rules like that help avoid bugs. There is also a heavy focus on determinism. That is, your code needs to be predictable in how it will execute. Take for example the STL vector class. Basic container class that everyone uses. But here's the thing. How long does it take for a push_back() call to complete? It depends. Have you filled up the currently allocated memory? If so, there's a huge delay while the class allocates more space and copies all of the data, including calling of the copy constructor and the destructor on every object. The bigger the vector is, the longer that takes. The more complex the constructor/destructor, the longer it takes. But in an avionics environment, you have to meet strict timing requirements. You can't have the flight controls freeze up while you wait for your push_back() to complete. That would be "bad". And what do you do if you're out of memory and the push_back() fails? Unhandled exceptions would cause a reboot of the whole system which, again, is "bad". Do you want to go through the hassle of doing a try/catch with every single use of the container? I don't. So the alternative is to limit the use of systems that are unpredictable. So basically the entire STL is off limits. At least the container classes. It makes some coding tasks harder in some cases but it does make them safer. And when it comes to the computers that keep the plane from making unintended contact with the ground, I'll go with the inconvenient but safe route

As an aside, these kinds of issues is what they tried to deal with when they designed the Ada language. Their intention was to build a language where the only option was the "safe" one. You have to explicitly do a great many things that you can do implicitly in C/C++. They take away a lot of rope to keep you from hanging yourself. The trouble is, it was designed by a committee and it's full of things that make it unpleasant to write code. Sure, you can get the job done. But it's more work. And like reflexively hitting OK on popup dialog boxes without thinking, a lot of that "more work" doesn't end up preventing people who are determined to do the wrong thing from going ahead and doing it. Then there was the Ariane-5 rocket explosion that proved people can make fatal mistakes regardless of the language involved and just because a piece of code worked on the previous generation of hardware, it's not guaranteed to work flawlessly when you drop it into new hardware. That being said, Ada isn't a terrible language. There's just no really good reason to pick it over any other.

Re:A good point

[houstonbofh]

They got jabs in Boston and New York too... They talk about jabs in Jersey, but the don't have any... :) Damn Auto-correct....

Re:A good point

[Darinbob]

I'd rather being doing Ada (which I'm not) than doing some brand new language that every kid in the world thinks is the next best thing ever. Modern versions of Ada are pretty good, no reason not to do them other than the coolness factor.

The popular languages are not ones that will give you a strong and steady career. The popular languages are the ones where companies want to hire the cheapest programmers who claim to know it, no matter where in the world they live.

Yes

[aaaaaaargh!]

Learn Forth now. Or something else.

Re:Yes

[Hotawa Hawk-eye]

The Forth day was yesterday. Today is the 5th.

Re:Yes

[RabidReindeer]

I think you meant "now Forth Learn".

Precisely!

Sure.

[fahrbot-bot]

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.

Is the Lobster an auto-post?

[xxxJonBoyxxx]

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.

Re:Is the Lobster an auto-post?

[31415926535897]

I've started wagering with myself about whether a particular "Slashdot article" will have a Dice link in it after reading the first line. I can guess with about 90% accuracy now.

Re:Is the Lobster an auto-post?

[Half-pint HAL]

Did you come to me because you are beginning to think this Dice account is just an autopost with a random list of possible values?

Re:Is the Lobster an auto-post?

[RyoShin]

The major difference, and the problem with Nerval's Lobster, is that prior to being purchased by Dice all submissions for their prior owners and sister sub-properties (GeekNet/Andover/SourceForge) would have a disclaimer attached to it so long as I can recall. This is no longer the case; the only way to know that this is a bought-and-paid-for placement ('cause Dice bought Slashdot) is that they're always "submitted" by Nerval's Lobster. Newer visitors won't know about the potential conflict of interest because it's no longer acknowledged.

It would be nice if they just made Nerval's Lobster an editor account so the robot could post itself, but they won't because they know that thousands of regular /. users will just block that editor; rightfully so, IMO.

Re:Is the Lobster an auto-post?

[bidule]

I'm beginning to think this Dice account is just an autopost with a random list of possible values.

Lorem ipsum dolor sit amet.

what languages?

[doctor_shim]

Most of those were platforms, frameworks, tookits etc. for domain-specific applications. Those almost always pay more. The only language in there was Object-Pascal. Unless that is used to solve a very pressing problem in a very competitive industry, it probably doesn't pay all that much.

Oldies but goodies

[nhtshot]

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.

Re:Oldies but goodies

[JustNiz]

Working in niche areas is great while it lasts (I know because I do too), but there's always a high chance that something new will entirely invalidate your niche's entire reason for existence within a year or two, especially if is all based around knowledge of one particularly obscure tool or technology.
Enjoy the ride but stay fresh with other more geneally marketable skills too, so that when the bubble inevitably bursts you're still employable for youir other skills

Depends

[Anonymous Coward]

For hobby yes. As a profession no.

old stalwarts

[ezakimak]

Cobol -- there's old apps that keep on running that are valuable enough to companies to keep maintaining, yet they aren't willing to rewrite
RPG4 -- same boat as Cobol--although arguably one of the least pleasant language environments
CL -- many existing apps, plus there are companies writing brand new stuff with it, it's just as powerful as ever, and quite nice to work with
I'm sure there are others

The answer depends on your reason

[JustNiz]

if its academic or for fun, yes.
If its just to get a job then no, unless you want to gamble with the chance of getting a job in a niche market.

The question ain't "is it on the rise"

[Opportunist]

The question is "is it here to stay".

Take Ruby on Rails. Was the craze not even half a decade ago. Everyone was on Rails. Too bad they led to the chasm and nobody bothered to build a bridge over it.

So learning a language because some startups are crazy about it isn't worth it. But what is? How can you tell whether a language "gets big" or is a tempest in a teapot?

Easy. It ain't the language, it's the people using it. It's the movers and shakers of an industry that decide what will grow and what will perish. If Bruce Schneier started writing his code snippets in Splfurt (I sincerely hope there is no such language, I just made that word up) and if people from Metasploit pick it up and code their stuff in Splfurt, Splfurt is the new big thing in IT security and every framework, scanner, tool and whatnot will have to have Splfurt plugin support and new exploit PoCs will come written in Splfurt.

It's not the language. It's the people using it.

Re:The question ain't "is it on the rise"

[mr_mischief]

Rails fell off a bridge. Rails is a framework, though. Ruby's still useful without it. It's no more useful than Perl, Python, Clojure, or Javascript, but it's useful. Some quite useful things that aren't blogs are written in it. Puppet's one example.

Swift is little known???????

[OzPeter]

It's only the language that a company with a $700 Billion market cap has decided should be the way to go to program all of their mobile devices.

If you play in the Apple ecosystem, then learning Swift is not "may be useful for a few years", it is a must for the future.

It's not about the nail

[__aabppq7737]

It's about training your mind to understand something hard. Learning a little language exercises will-power, discipline, and focus.

COBOL

[MagickalMyst]

COBOL - While outdated, is still used by many large corporations. It is rarely taught in schools anymore and the syntax is quite cryptic (imho) compared to more modern languages (such as looping, fuction calls, type casting, etc. in C++ or javascript, for example).

Specializing in COBOL could be a niche that is quite lucrative. Some of the largest fortune 500 companies - including big oil companies - still have crucial systems running COBOL applications on them.

If programming in such a bizarre language doesn't drive you to pull all of your hair out in frustration it just might be for you!

Or maybe just for bald people in general. :)

Lisp-likes and CS background

[chthon]

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.

ADA?

[Frosty Piss]

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?

Re:ADA?

[Anonymous Coward]

It is all ALGOL to me. I haven't encountered a new language in many years. Different dialects yes, but really new to the point where I need lessons beyond just quickly reading a book, no.

Re:ADA?

[Em Adespoton]

I think ADA is finally on its way out. COBOL and Fortran will still be around for years though. and anyone who knows their way around MATLAB will also be in high demand for years to come. Pick any language on which deployed hardware depends, and you've got a language that will need people who understand it for years to come.

I once new someone who helped a Telecom deploy their COBOL stack -- she was pulled out of retirement some 20 years later to help them migrate it to a more modern platform, as she was the only person from the team left alive who actually understood how it all worked.

Re:ADA?

[ShanghaiBill]

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.

Re:ADA?

[jythie]

I see ads for COBOL now and then, but I am East Coast where a lot of that infrastructure is sitting. While not every day kinds of ads, when I was job hunting I would see at least a couple per week. About the same as FORTRAN.

Re:ADA?

[gb]

If a skill set is sufficiently rare then it's not very cost-effective to advertise for it on the open market - but that doesn't necessarily mean it's not a very valuable skill set.

Re:ADA?

[Dutch Gun]

I was under the impression that Ada is still widely used in many mission-critical systems. For example, the latest Boeing planes' software (777 and 787) is nearly all written in Ada. I haven't heard about another language making inroads in those applications, but I suppose it's possible. More likely IMO is that the relative percentage of mission-critical software has shrunk compared to the explosion of commercial software.

Keep in mind language "popularity" is very industry-specific, so it's often a bit misleading to look at global rankings of language popularity. For example, in my own industry (videogames), C++ is completely dominant for game code, C# is very popular for tools, and Lua is popular as an embedded scripting language. If you look at Lua on it's own, it typically ranks pretty low compared to most languages, but there's no doubt it would be much higher if constrained to just my industry.

Re:ADA?

[Rinikusu]

What region are you in? Most of the COBOL stuff I've been exposed to are with .gov contracts. The USPS still has mainframes and the shop I used to work at had around 15 graybeards (and one quickly graying 30 something developer they poached from another team). FedEx may still have a COBOL team if they haven't migrated from their mainframes yet (they may have completed their migration to java), and that whole DC/VA corridor is apparently full of government contract companies that still write and maintain COBOL codebases. In Silicon Valley? Not so much. Maybe Sacramento, I think they still have a ton of payroll and tax stuff. Chances are, most of these positions are already filled before they even list the job. They bring some "bright" person over from accounting or they poach from the local community college that still has a COBOL class or two (Southwest Tennessee Community College, for example, still has a COBOL based track as of 2002; but not sure how it is now.. AS/400, etc).

Re:ADA?

[radarskiy]

"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."

Probably they're only average programmers, so they are assigned to safe areas like user interfaces and web sites.. You don't need software engineering for *every* problem.

Re:ADA?

[jittles]

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.

In my current city there is a company that writes software for mortgage companies. Their back end systems were all written in COBOL. They pay a small fortune for experienced COBOL developers, but they are transitioning all of their code over to Java. I also worked on a project for the Department of Defense that was originally written in Fortan, then had new code added as ADA and my company at that time worked to convert all the ADA and Fortran to C. That was about 6 years ago, though.

Re:ADA?

[Creepy]

When I first started looking for a career, COBOL was very common in banks and they recruited heavily for students just out of college (less than 20 years ago) and were willing to give them time to learn the language. As I understand it now, nearly all the COBOL is done at the mainframe/backend and the front-ends are all stuff like ASPs, JSPs, java, etc. I'm guessing the jobs are still there, just a lot less of them.

As for Ada, yeah, it was designed for and used by the US DOD and even required by them until 1997.

My personal rarely used language is Forth, which I learned to hack Open Firmware so I could make my mac boot either Yellow Dog Linux or OS X (installed on separate drives). That saved me a cable swap (boot ordering didn't work so well - the mac always wanted to format the unknown drive), but eventually I just started using XonX and not using the dual boot, and that was similar to my older setup that ran OS 8 on Linux (MacOnLinux). Been 10 years at least, so I doubt I could still program Forth without a refresher.

Re:ADA?

[judoguy]

I have a friend who retired in his sixties and was then lured back into the work force by contractor rates he simply couldn't walk away from. Some companies had to have an experienced COBOL programmer no matter what it cost.

Still cheaper for a few years than "Let's quickly re-write the mission critical application in xyz++" Yeah, it was going to be re-written at some point, but keeping the beast running until then was not optional.

Re:ADA?

[RabidReindeer]

In my current city there is a company that writes software for mortgage companies. Their back end systems were all written in COBOL.

Located in Northeast Florida, you say? Has an NFL team?

I liked Ada. But when I used it in school, it took a medium-sized IBM mainframe and chewed it down to the same sort of performance I could get doing Fortran on a Z-80.

Ada might have been a bigger hit had it been introduced more recently. I doubt it's much more of a burden than Java, and these days even cell-phones have the power of a medium-sized IBM mainframe from back then.

Speaking of what makes each language different, Ada's claim to fame was that your could define both range and domain on its functions and the type-defining capabilities were so rigorous that the infamous we-used-inches-instead-of-centimeters bugs were all but impossible.

Re:ADA?

[russotto]

They're not ALL Algol. There's the LISP-likes, plus OCaml and Haskell.

Re:ADA?

[ajdlinux]

I'm a bit sad that Ada is on the way out, though it's not entirely dead - a friend of mine who is currently in his 3rd year of a CS degree was just hired as a part-time developer at a local Ada startup - possibly the only time I've ever seen a job ad for an Ada web developer who also knows JavaScript...

Re:ADA?

[jittles]

Hah. Have I worked with you before? Small world.

Re:ADA?

[frost_knight]

I currently work for a refrigerated shipping and warehousing company. The in-house warehouse management system is all in COBOL. One of my responsiblities is the care and feeding of the WMS system and the database cluster back-end.

This WMS chugs along and weathers everything that gets thrown at it. It really is the most bulletproof system I've ever worked on.

Re:ADA?

[angel'o'sphere]

a reputation for poor performance, and heavy resource requirements.
That is nonsense.
Ada is as efficient as C etc. actually all languages that get compiled down to machine code (as not to byte code) are similar efficient.
If you want a COBOL job, look harder.
There are plenty of them.
All the damn Y2K programs problems I have fixed, are still running: because the Y2K problems are fixed.

Won't hire 'monolingual' developers

[david.emery]

I explicitly will not hire any programmer who knows only one programming language (C and C++ count as 1 for that score.) Learning a different programming language introduces you to alternative ways to think about problems and solutions. Lisp or Scheme, Ada or Eiffel, COBOL or MUMPS, all provide a different perspective on software design, coding, test and integration.

Too many hiring managers play "buzzword bingos" in search of "flying purple unicorns," candidates whose buzzwords match their current search list. Sure, you can make a living chasing buzzwords that way, with a combination of (primarily) resume engineering and (secondarily) training. And some people who do this are actually pretty good developers. But many more don't know how to apply the technology, they're just able to produce toy programs learned from " for Idiots" who produce the stuff documented on http://thedailywtf.com/ But the people I want are those who can think creatively about a problem, using more tools than just one hammer, and who can learn new stuff on the job. What's the half-life of a technology these days, 3 years?

Re:Won't hire 'monolingual' developers

[david.emery]

My experience (35 years worth) differs from Mr Anonymous.

Learning new mindsets

[DarkDust]

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.

Re:Learning new mindsets

[phantomfive]

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.

"A language that doesn't affect the way you think about programming is not worth knowing." — Alan Perlis

Re:Learning new mindsets

[TeknoHog]

"A language that doesn't affect the way you think about programming is not worth knowing." — Perl is

FTFY.

It is worth it.

[t0qer]

They might not be programming languages per se, but I've spent a lot of time with autohotkey, NSIS, apple applescript and the like. The one thing all of these have in common is quick, clean looking applications with a narrow degree of focus; automation and deployment.

I've done some pretty nice tricks with them, mostly from a IT side of things. I've done a few applications with autohotkey. One startup I worked at couldn't really customize their helpdesk system, but wanted more info from tickets. I made a nice little app that took it from editing a txt file, to a few tabs of checkboxes, radio buttons, etc that would copy the answers to the clipboard.

Automator has helped me tons, especially when creating apple accounts. I started with a script I found, and I've been customizing it for our own needs within the company. We have a few services that only have a web interface to administrate them. Using the appleIDautomator script as a base, I've been able to tweak it to set these up as well.

Finally did an active directory rollout a few weeks back and needed to bundle meraki, bit9, and forsit's profile migrator. Bundled all 3 setups in NSIS. I've done even better installers than that with NSIS. I took a 7 server JBOSS application, bundled mysql, apache, etc and made an installer that even did CRC checks on the files post install. Meh, it did all kinds of crazy stuff, changed the machine name, added entries to the hosts file. It cut the install time down from 40 hours to 4.

Learn R

[Anonymous Coward]

not little known and not obscure, but certainly worth to learn and sure to bring in the cash.

R

Re:Learn R

[u38cg]

Hmm. I'm not sure that R is useful unless you have the domain knowledge. People using R want to solve statistical or numerical problems, and most of the skill is in the problem domain and then programming appropriately. Just knowing R syntax and object model is not enough to be useful in the the typical R user environment, I think.

Languages and Frameworks

[sanf780]

I suppose that the usual thing that happens is that with a given language you have a given set of frameworks. As such, there are languages that are better suited for a given task. For example, if I had to do many string operations, perl and its related frameworks would suit this one the best.

So, the less popular a language is, the lower number of accessible frameworks you will have. As such, please scale down your goals accordingly. You do not want to reinvent the wheel again, unless you are only focused on the wheel.

Sometimes

[Necron69]

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

Re:Sometimes

[Marginal Coward]

To quote Adam Smith:

THE five following are the principal circumstances which, so far as I have been able to observe, make up for a small pecuniary gain in some employments, and counterbalance a great one in others: first, the agreeableness or disagreeableness of the employments themselves; secondly, the easiness and cheapness, or the difficulty and expense of learning them; thirdly, the constancy or inconstancy of employment in them; fourthly, the small or great trust which must be reposed in those who exercise them; and, fifthly, the probability or improbability of success in them.

So, if you're making six figures writing Perl, are you sure you're being adequately compensated for its disagreeableness? :)

Rust isn't worth learning.

[Anonymous Coward]

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.

Re:Rust isn't worth learning.

[Grishnakh]

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

I just don't see why Rust is getting as much hype as it currently is getting.

I'm not a Rust expert, but I think you're trying to use a hammer to turn a screw here. As I understand it, Rust was never meant to compete with C# or Python; it's supposed to be a system-level language, which means it competes with C and C++. Both of those have pretty lame standard libraries and absolutely horrible string handling. If you want to do real string handling in C++, for instance, you'd be an idiot to use the standard library, and really should use a different library. My personal preference is Qt; string handling in Qt is wonderful and easy, and extremely readable unlike some other C++ libraries I've seen.

From what I read on Rust's wikipedia entry, it appears to be intended to serve much like C or C++, but with memory safety. Null pointers aren't allowed.

Apex/Salesforce.com

[Coldeagle]

I'm a Salesforce.com developer, which uses Salesforce's custom language "Apex" as well as "VisuaForce". These two languages are bastardized versions of Java and JSP respectively. They are highly in demand because Salesforce enforces governor limits which enforces "best practices" to be followed. For example, you can only have 100 queries in a single run so you can't do a loop and query the datbase. I make mid 100k a year in southern California, but can demand more, especially if I wanted to do full time consulting. Consultants can make $100-200 an hour.

It's always worth learning a new way of thinking

[nickovs]

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.

Success Story

[Tablizer]

Past paid experience with obscure and legacy languages saved my arse after the dot-com crash dumped tons of coders back into circulation on the west coast. I got no offers until I down-played my web experience and highlighted pre-web experience and languages. You never know what experience will come in handy. It's similar to investing advice: diversify your portfolio.

It depends on your goal

[Tony Isaac]

If you simply have intellectual curiosity, why not? But if you want to use your knowledge commercially, you might want to focus on languages that businesses actually use. A language is much more than a set of syntax, it's an ecosystem. Try finding code snips on StackOverflow for your new language...good luck with that! The majority of the benefit of using a particular language is not the syntax, but the community support.

LOLCode FTW

[gregOfTheWeb]

http://lolcode.org/

REXX RULZ!

[ArhcAngel]

You can't go wrong with REXX

Re:REXX RULZ!

[Wargames]

Totally!

Nope

[Greyfox]

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.

Depends

[gman003]

As always, the answer is "it depends on a lot of things":

1. Is the language little-used because it's a special-purpose language? UnrealScript probably doesn't crack the top twenty as far as general programming languages go, but in the game dev field it's probably one of the biggest. Using a specialized language for a specialized task is fine - usually even a good thing.

2. Is the language little-used, but library-compatible with a more common language? Clojure is a rare language, but it can call Java libraries and code, which is a massive boon. Actual programming languages don't matter so much as the libraries they allow you to use, and if you can piggyback on a bigger library of libraries, you can go far with a small, obscure language. This isn't sufficient to make the language OK to use, because:

3. Is the project going to be worked on by more than one person? Personal projects, sure, use whatever language you feel like. Small groups can decide what to use. But if it's a big project that's likely to cycle through developers, think about the impact using an uncommon language will have.

4. Is there something about your problem that makes common languages inefficient or ineffective? Is the uncommon language objectively better at the exact task you're solving? Or is it just "the syntax is slightly cleaner"? This isn't a full deciding factor, but unless the language shows promise as being useful in the future, I wouldn't use it on a personal project.

Not so easy to get rich

[Ketorin]

Do keep in mind that with these niche languages the markets are small, but so are the circles. Many job openings are not public and require previous references, some times some niche language is largely controlled by handful of big software houses.

The truly obscure one aren't even publicly documented, because they are considered business secret. Sadly, even the peer to peer is too busy with music and movies to bother with some ISO/ANSI/JIS standard needed by maybe twenty people in the world. If you have the docs or can pausibly deny having them, you get the job.

I wouldn't learn a language just in case with dollar signs in my eyes, unless I personally knew the place and people who needed the service.

Beyond that, the world is full of little unknown languages. The industrial equipment for example almost all run their own bastardized version of basic.

No...but faking it before a job interview is ok.

[sarkeizen]

I'll assume the main reason to do this is to get a job, one that in particular advertises for a specific set of skills. One of which is an obscure programming language. Unless you have nothing to do it's probably more worth your time to spend a day before said interview learning enough to fake it. If you want to lie or be honest about this on your resume or in your interview that's up to you and how well you think you can pull that off but if you want your resume to get past HR and make a short list AND you are actively pursuing multiple opportunities. This is probably your best bet.

Barrier of entrance

[Ketorin]

True, with the truly obscure ones having an access to the environment to actually train and test one's skills in practice may be the biggest barrier.

Surely, anyone can download Kuka and Hyundai robot manuals (I think with these manufacturers this includes even the maintenance manuals) online, but buing the $20000 robot to get the experience is another thing.

Robot programming is a bad example, as an engineer in that field is mostly expected to pick it up "on the fly", but the guy who truly can shave off seconds from the execution time in a critical application gets paid handsomely.

Stop trying to predict languages, follow paradigms

[plopez]

Predicting the future is hard and often just look. But you might want to learn an new paradigm. E.g. functional programming. If you haven't done, it will be eye opening. Or a different environment, esp. if you have only programmed in a MS environment look at non-MS languages and IDEs. People who can work in both are in the biggest demand. Or network databses vs relational databases (though you can build a network schema in a RDB, since a network is a relation), etc.

Look for differences and analogies and analogies between analogies.

Yes, if you have a specific reason

[ZeroWaiteState]

You have to balance the cost of throwing away the code and processes you know against the benefit provided by the language. The whole point of the language is to make it easier to express logic. If switching is simply creating an artificial barrier without providing something substantial you are wasting your time. That being said, there is a subtle shift going on in most languages and toolchains right now. It is a trend toward share-nothing actor based concurrent systems. The reason for this has to do with scalability and correctness. Thread-based concurrency does not scale as well as userspace lightweight FSMs, and maintaining correctness with shared state gets very difficult as the number of processors goes up and their caches get further apart on the chip. That's one reason NodeJS has taken off, because it implements a very lightweight concurrency model subject to certain limitations. Learn a language/toolset geared for this and it will be time well spent. Another shift is toward functional progtamming. Most functional languages share similar characteristics, so if you get a firm grasp of one the others won't be too hard to pick up.

Productivity and solution breadth are reasons

[GodSpiral]

I think most languages are the same. There is a productivity vs. speed tradeoff, but:

A functional programming style, can be done in C if you just accept that minimizing global variables and pass functions by their pointers. Learning a functional language is likely to improve your C style and pointer management faster than how you might develop a functional style out of your own assumptions of what it might mean.

Class based OOP programming can also be done with C implementations. The only benefit of OOP is that it lets you write more without thinking first. Defining data types first and data organization, and then later simply patching them together. Its very similar to relational DB models. Most programming is done this way, because it is the most accessible to people to write code before understanding the problem. Its very useful when the problem comes from someone else and not perfectly specified.

One exceptionally highly productive language that still fits both of the above paradigms but also expands your solution processes is J (Jsoftware.com).

Regardless of how popular it is, this language can be the best tool for some to most applications. If you were paying for your own time, you might use it if you know it. But even if you only care about employability, J will make your programming in any language better, because a consise J solution tends to map to a consise solution in other languages.

Yes

[jgotts]

I'm firmly in the yes camp.

Since I began programming in 1985, I've encountered dozens of languages. The popularity of every language waxes and wanes, and occasionally it will wax and wane a second time (perhaps like Java is doing today). Programming languages never completely disappear, but the trend in usefulness of languages is on the rise due to more sophisticated toolkits.

Knowing these facts, it's never a bad thing to learn a new programming language. Since languages never completely disappear, you never know when your knowledge of that language may come in handy. I occasionally get job offers to work on languages and APIs that I haven't touched in 15 or 20 years. Software can have an even longer life. We still use software that's 50 years old (via ATM networks that connect to bank mainframes, for example). I once used a bank API that had a ridiculously complicated link like including -lcobol. It is possible that I was linking in code on that Linux system that was older than me.

If you're looking to learn a little-known programming language, lean towards a newer language. As I said, newer languages can do more, and do so more compactly.

Finally, think of the big picture. As a programmer, you do programming. The language is your tool. What your job really is is creating and manipulating mathematical expressions. I know that sounds super boring but that's what programming languages are, a way to make dealing with math a bit easier. The more ways you learn to deal with this math, the better programmer you will become. Think of repairing a car. The best mechanic in town might work at a Mercedes dealership, but if you put him in a GM dealership he would probably become their best mechanic after a short time. The job is not the tools.

Haskell

[John Bokma]

So you haven't discovered Haskell yet... No idea who modded you insightful but a more realistic view can be read here: http://norvig.com/21-days.html (currently down). Sadly I know and then have to maintain code written by people who seem to think like you. I really don't get it why this myth is still alive.

Re:"But Rust isn't competing with XYZ!"

[Grishnakh]

When pretty much every other language out there, including C and C++, can do string handling better than Rust can, the problem isn't with the fact that competition is happening. The problem is solely that Rust's string handling is total shit.

You're kidding, right? I've never used Rust, so I can't testify to its string handling, but I'm very familiar with C and C++ and using strings in both, and they both completely suck. C is absolutely horrible, and C++ is terrible too if you use the standard library. You only get good string-handling in C++ by switching to a library like Qt.

As for what it's competing against, that's just ridiculous. No language is competing against every language out there; every language has its strengths and weaknesses. C is really good at low-level programming that's one step above assembly, but it sucks at a lot of things (including string handling). Perl is excellent at string parsing, but sucks at performance and readability. R is really good at math, but completely unusable for writing an OS. I'm sure Rust fits in there too somehow. The point is, you can't just compare Rust, or any language, against any other arbitrary language and then bash it because it fails. Is C unusable because it sucks at text parsing? If text parsing is what you need, then yes, but if you're writing an OS kernel, then no.

It boils down to luck

[msobkow]

I was lucky enough to learn how to program in Neuron Data's toolkits before the 1.0 release of the GUI components were released to the public. I rode that gravy train for about 15 years before the market imploded, with a peak of $120/hr. in the mid-late '90s.

But I didn't choose that route -- I got lucky that something I knew well turned out to have relatively high demand (at least compared to the number of people who really knew that tool well.) I could just have easily been unlucky enough to learn one of the other two GUI toolkits that Northern Telecom was evaluating at the time.

On the database front, I missed out -- I was tasked with evaluating the first release of Ingres, and have never seen that product again in my entire career. Fortunately I was able to wrangle some Oracle work and training with my Ingres SQL experience, and from there sidestepped to Sybase ASE, DB/2 LUW, and SQL Server. But I had to work at becoming an SQL expert (cross-platform); with the GUI tools, I just got lucky.

On the major downside, most of my GUI experience is now useless because the only place you'll find Neuron Data left in are old legacy/maintenance-mode applications. There is no new work being done with Open Interface Toolkit.

Eiffel

[richieb]

One of my most rewarding jobs, in terms of fun and money, was writing code in Eiffel. Your mileage may vary...

Re:"But Rust isn't competing with XYZ!"

[juanfgs]

The point is, you can't just compare Rust, or any language, against any other arbitrary language and then bash it because it fails.

GP raised more than the string handling problem.

I don't know much about rust but what I can observe is that most people use it as an example of a computer programming language done right. Wanna bash X language? then put Rust as an example of how to do it the right way. So that might justify GP point of comparing it against other languages

popular schmopular

[Hognoxious]

Do we mean popular as in lots of people like it, or as in lots of people use it?

Re:"But Rust isn't competing with XYZ!"

[Grishnakh]

I don't know much about Rust besides that the Wikipedia entry says, however just because some other people use it for comparisons with some other languages doesn't mean you can bash Rush just because it isn't as good as some other language at some arbitrary feature; you're just doing the exact same thing as them in that case. Besides, what other languages are they comparing to anyway?

It's one thing to compare Rust to a language which maybe it was intended to compete against, such as C++. It's another thing to compare it to some entirely different language, such as Lisp or Haskell or COBOL or even Perl; Rust certainly wasn't intended to directly compete against any of these.

Learn DataBASIC

[bhcompy]

Learn DataBASIC and you can work on PICK. All 15 companies that still sell PICK based products

Re:Learn DataBASIC

[OrangeTide]

15 different places? A new college grad could work 3 years at each one and have an entire career, and retire comfortably at 70.

I should have came to /. for career advice years ago.

Is Java really a programming language?

[IWantMoreSpamPlease]

Or is it a punishment?

Worth of Learning

[luis_a_espinal]

Is It Worth Learning a Little-Known Programming Language?

How sad that people have to ask such questions. What is worth? Worth with respect to what? For what?

Are such measuring worth in terms of potential monetary ROI? Or do they ever consider the significant value of learning for the sake of learning, stimulation of the mind, exercises which "laterally" help in being mentally agile and adaptable?

I lean to the later value of worth. And it is true that for a busy professional, sometimes time is not available, but to have to ask such a question, that is sad.

It's worth knowing a lot of things

[OrangeTide]

It's worth knowing a lot of things, even if those things don't directly translate into a bigger paycheck.

This doesn't just extend to programming either, you might enrich your life by reading a bit of the big three Greek philosophers, but it probably won't translate into improving your career strategy or make you more marketable.

But I would limit what programming languages you learn to ones that actually teach you something new about programming. If you already know C and PHP and Ruby, then you might not get much learning Python, but maybe FORTH or Lisp or Erlang or something even more exotic might teach you a little bit about different ways to solve problems.

Functional Java too

[kervin]

Same with Java and Scala. A strongly functional language that allows you to keep using the thousands of Java libraries out there.

Re:Correct answer, in the first 2 posts: It depend

[Darinbob]

We're treating them all the same because... Dice.

First rule

[cwsumner]

The first rule is: Learn more than one language!

If you can do more than one, then you will know how to learn others as necessary.
If you only know one, then you can get "stuck in a corner". And vulnerable to "if all you have is a hammer, then every thing you meet looks like a nail."

And anyway, knowing something others do not can be, with a little luck, quite valuable. 8-)