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]

Time for a car analogy!

Languages are like cars and programming is like driving. Every model is unique and has advantages and disadvantages. Ultimately, if you know the rules of the road and how to drive, you can get to where you're going.

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

[Anonymous Coward]

MUMPS is another example. It and its bastard offspring Cache are used primarily in health care settings.

Re:Yes if you can afford the time

[Anonymous Coward]

I would use Python only for scripting or in situations where I need to change the code often and I don't want to recompile. For prototyping I would use paper, some GUI editor or if code is needed, I would use Java. Why Java?
1. It comes with a lot of libraries that lets you do pretty much anything (GUI, network, database)
2. Even for things that are not included, there are usually 3rd party libraries that let you do it, with maven you can install those without problems
3. The code is easy to understand for newbies
4. The code executes quite fast
5. Writing the code is easy because of the IDEs, mostly Eclipse (I know many don't like it, but I can use it quite efficiently). Simple things like renaming a variable or a method or a class. Or extracting a method. Adding unimplemented methods etc. Or being able to go to class by typing its name. Or jumping into implementation etc.
6. Debugger that comes with Eclipse is quite good
7. There are free and easy to use tools for monitoring memory, threads etc.
8. JUnit, Mockito lets you write tests without too much trouble, with C++ you first need to decide which 3rd party framework you use.
9. You don't need two languages because the code works fast enough in production also.

There are disadvantages with Java, I know probably all of them. I actually didn't like Java much at first when I started working with it. I didn't want to learn yet another IDE. compiling and classpaths etc. was just too much hassle. But now when I know all of that, I really don't want to do anything big with any other language.

But don't underestimate paper for prototyping.

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

[Anonymous Coward]

Coward 4 hours ago
This is your boss Jimmy. GET BACK TO WORK STOP GOOFING AROUND ON SLASHDOT. For the record, he hasn't done shit since we hired him, and he's one more mistake from being CANNED. He couldn't solve an ASP problem to save his life, HE IS WORTHLESS. STOP BEING WORTHLESS JIMMY.

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

[Anonymous Coward]

And you'll write crap Lisp. Learning how to do some procedural programming in Lisp is easy. Learning how and when to use macros is a lot harder, or functional programming, or a few other things. You'll almost certainly find the Common Lisp object system weird, but it's very powerful. It has easy multiple dispatch, which Stroustrup wished he could have gotten into C++ somehow.

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

[Anonymous Coward]

Did you just say that C has type safety?

Python, being strongly typed is much safer than C.
WTF?

Re:Yes if you can afford the time

[Anonymous Coward]

Sure if you stay in Algol-land, but try to learn say, Haskell, just by picking up syntax.

Moron

Re:Yes if you can afford the time

[Anonymous Coward]

You obviously missed the basics because the differences between Lisp and say C, is not just syntax. Lisp doesn't really have syntax. Its semantics and concepts are about as far apart as you can get.

Writing C in Lisp will get you the same thing as writing C in C++, Java in Ruby, C# in Ocaml: crap.

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.

Re:Yes if you can afford the time

[Anonymous Coward]

If you are using C for numerical analysis you are as retarded as morons using PHP for web apps.

Fortran makes it much easier to wrote numerical analysis code and beat the shit out of C on performance.

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.

[mcrbids]

But... you'd be surprised how often it happens that I've learned a new tool, technique, or technology, only to be presented with an opportunity to use that new technology shortly thereafter.

You miss many opportunities simply because you don't see them as such because you lack the context, understanding, or tools to recognize them as such. Broadening your horizons helps you see the solutions and opportunities for what they are.

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]

Try Haskell and you will discover the limits of the value of knowing conventional languages.

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]

When we hire we don't require developers to know any particular language. The reason being is because we need people who are versatile enough to be good with any language. I never did anything like the stuff work on now before I started the job.

Re:No.

[doctor_shim]

Haskell is a fairly conventional language, depending on what conventions you're used to. If you've ever only known imperative languages, then Haskell will be new and scary to you. OP was talking about people with a broad enough background where Haskell isn't inimidating. Just neat.

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]

you know the saying, when you get a new hammer, everything's a nail.

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.

[Anonymous Coward]

Learn a language that uses a different paradigm : Try Scheme/Lisp, Haskell, Prolog

They teach you that procedural programming is not the only way, and how to think about problems in a new way

  and since C# has at least the basics of these in it now you will learn how to use it properly ...

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.

[Anonymous Coward]

You just described a good developer with any language and a bad developer in any language.

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.

[Anonymous Coward]

The support libraries are very important. You notice this when you try to write a graphical game in C and then write unit tests for it. And try to do the same next with Java. With Java and Python you need to think like this "If I need this functionality, there probably exists already a class or library that implements it, so I should just try to find it". With C you need to think "I probably have to write my own function for this as investigating all those 3rd party libraries would take too much time". It isn't really this black and white in reality, e.g. you don't want to write your own security algorithms in C even if it is a lot of trouble to find the correct library.

Another issue with you text is that even if Java is object oriented, it doesn't mean that you couldn't write the code partially using methods from functional programming. E.g. when you write methods in your class, try to write those so that they don't change the state of the object or its arguments. It is not pure functional programming, but it makes that method more easy to understand and test.

Or when you are writing C and you notice that you need to support 2 different filesystems, instead of writing the code into the same file, you can create two classes (files) where you put the methods with the same names and then use it in an object oriented fashion (there are quite some tricks you can use to make this real if you are really into it, but the most important part is to have the code in two files).

This gives you a good reason to study different languages and programming styles, because then you can combine different styles.

Re:No.

[HornWumpus]

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

Re: No.

[Anonymous Coward]

Everything doesn't have to be a highly finished product. Python and VB are the scaffolding, temporary buildings and braces of the software world. You might not want to build a house with them (though you could), but they serve a purpose, like any machine.

Re: No.

[Anonymous Coward]

Did you just put VB and Python in the same sentence? It is like saying that horse and carriage competes with electric car and electric car should only be used where hay is not readily available.

Re:No.

[Anonymous Coward]

"the average coder doesn't know an applicative functor from a warm puppy"
Ouch, a kick in the monads!

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.

Re:No.

[Anonymous Coward]

Wow. Your language grouping is complete nonsense!

Javascript with C++!?!
Python with Fortran!?!
Smalltalk with RPN!?!

Here's something far more reasonable that includes most of the top 50 languages on github.

Scheme, Common Lisp, JavaScript, CoffeeScript, ActionScript, Emacs Lisp, Clojure, Lua, R, Ruby, Julia, Dart, Racket, TypeScript, Elm

C++, D, C#, Java, Objective-C, Swift, Smalltalk, Visual Basic

Python, Perl, Groovy

C, FORTRAN, Go, Processing, Rust, Vala, Pascal, Delphi, Eiffel, Ada, Tcl, PHP

Haskell, Scala, OCaml, F#, Standard ML

Erlang, Elixir

Cuda, OpenCL, HLSL

Prolog, Mercury

Matlab, Mathematica

Coq, Agda

VHDL, Verilog

Re:No.

[Anonymous Coward]

That is part of the learning process numbnuts

Re: No.

[Anonymous Coward]

I think you are confusing Ruby with Rails.

It is a common mistake for dipshits to make

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

[Anonymous Coward]

Mono?

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

[Anonymous Coward]

The biggest problem with with UI libraries.
Winforms has some mono support, but is pretty much dead as far as getting it all the way there goes. and since it's no longer developed in .net that is not likely to change.
WPF is windows only.

We're still missing a *good* cross platform (just for desktop even). UI library

There are a handful of third party ones out there, many of them though haven't been updated in a long while, indicating that the project is dead in the water, and a couple of not quite good enough ones out there too.
EmptyKeys looks promising, but needs better documentation, easier to get running examples, and the basic textbox is missing some key features i.e. when you double click a textbox, it should select existing text.

Re:Doing it now...

[Anonymous Coward]

Mono's speed for anything serious is absolutely atrocious. We made an effort to move to it to get our app off of Windows, and the performance was such that we had to cancel the whole idea. We promised a big customer we'd get off Windows, and so we had ample business reason to succeed, but just couldn't get it optimized to run effectively on Linux.

Now we're waiting on what MS comes out with, but .Net and C# for us is still firmly a Windows thing, in spite of Mono.

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

[Anonymous Coward]

Look for the C# versions of those, you'll find that they're no longer being actively maintained.

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

[Anonymous Coward]

Neither C# or .Net is 100% compatible with mono.

mono sucks ass.

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.

Re:Doing it now...

[Anonymous Coward]

Moot you fucking retard, not mute.

Not all of .Net is open source so mono will never be close to compatible.

It is also a total failure.

Name one significant app that runs on mono

Sigh

[Anonymous Coward]

Go, no
Swift, (if you want to make iOS apps, it's a no-brainer yes)
Rust, no
Julia, no
CoffeeScript, really? either use javascript or support a new client runtime. - Quit trying to make up for deficiencies by making up meta languages to hide the hideous choices.

Re:Sigh

[Anonymous Coward]

Don't discount Julia. If you are doing non-statistical numerical work (which is where R is the standard) Julia is already encroaching on NumPy and Matlab. Many teams are switching to Julia for new projects and not looking back.

little-known programming language

[rossdee]

APL

Re: little-known programming language

[Anonymous Coward]

Is that the language APK uses to write his HOSTS files in?

Re:little-known programming language

[Anonymous Coward]

MUMPS

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

strange company from Boomfuk ND needs Scalapython

[Anonymous Coward]

.. so drop everything and learn it.. lol

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

[Anonymous Coward]

Old drudgery pays well though. Enough to retire early allowing you all the time in the world to devote to whatever cutting edge project pique your interest.

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

[Anonymous Coward]

I think you meant "now Forth Learn".

Re:Yes

[RabidReindeer]

I think you meant "now Forth Learn".

Precisely!

Yes.

[Anonymous Coward]

Yes. It's interesting to compare how different languages solve different problems. OTOH, I wouldn't necessarily *use* one of these less popular languages. I've been studying Haskell a bit lately. I understand it's used in finance applications and a few other places. I have no desire to use it myself for anything in particular. It's worth looking at it though, just because it gives you ideas. Wrapping my head around the monad concept... whew, it's up there with call/cc in terms of bending your mind, perhaps mostly because the explanations suck. I think I can just begin to see how there are monad-like patterns in some other things I've done. So. Yes. Learning strange new languages is good, even absolutely useless crap like funges and INTERCAL. Using them? That's a different question.

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?

[Anonymous Coward]

So right. See for example http://developers.slashdot.org/story/15/01/06/1714242/little-known-programming-languages-that-actually-pay which may be seen as an answer to this question asked 4 months later.

Re:Is the Lobster an auto-post?

[Anonymous Coward]

Someday someone will take that MIT fake-paper generator and attach it directly to Firehose.

Re:Is the Lobster an auto-post?

[Anonymous Coward]

Nerval's Lobster has been an autopost account since the SlashBI days, which I think pre-dates Dicedot.

Re:Is the Lobster an auto-post?

[Anonymous Coward]

Well, at least dice-related articles are also nerd-related. Which is more than you can say for most /. articles these days. I for one welcome an argument about programming languages.

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?

[Anonymous Coward]

But Nerval's Lobster doesn't work for Slashdot. Or maybe he does, who knows?.

Besides, it's not like Slashdot posts everything the guy writes, he had a submission declined in February of 2014. That's practically yesterday.

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

Re:Oldies but goodies

[Anonymous Coward]

Fortran called. It wants you to know it's not dead yet, and doesn't want to get on the cart. :)

In all seriousness, I've been working in Fortran for 15 years, and have never once been afraid that I'll run out of work. I get what you are saying, and I concede some niche things can be pretty volatile. But others are incredibly stable, if not very popular.

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

assembly

[Anonymous Coward]

Kinda off topic but: I remember in the late 1990s early 2000s assembly language language was kinda popular. Some of the freeware that I downloaded was written in Microsoft Assembly. Even the readme.txt file mentioned that the program is written in MSAM for speed. Programs written in Borland Delphi 6 and above were popular too. I remember downloading some free software written in Visual Basic too. Some programs even had custom OCX controls. Not sure how I remember all these details.

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.

Re:Swift is little known???????

[Anonymous Coward]

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.

Rubbish. Our HR department can't find anyone with the minimum 10 years experience required to be proficient in it.

Re:Swift is little known???????

[Anonymous Coward]

Your joke is old and stale. Please upgrade to CleverBoy 5.2.

Re:Swift is little known???????

[ArcadeMan]

Funny fact: CleverBoy 5.2 was programmed in Swift.

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?

[Anonymous Coward]

However since FPGAs are getting larger and it will be able to actually run sizeable algorithms, you will probably use VHDL, VHDL is a descendent of Ada.

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?

[Anonymous Coward]

Perhaps undeservingly... http://www.seas.gwu.edu/~adagroup/sigada-website/lawlis.html

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?

[Anonymous Coward]

It's "Ada!"

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?

[Anonymous Coward]

I know one place where they use Cobol, but they are currently planning on switching to another solution. Maintenance of the old system costs too much. The employees are getting normal salary for the area.

Demand for Cobol developers comes from the fact that very few are actually willing to work with it. I could personally quite easily learn Cobol well enough to work with it, would take about a week. But I have no interest. Companies want to get rid of it as soon as they can.

My advice, either:
A) Pick one language and try to master it. If there is need for that language, you could be the last person in the project if they reduce employees. If there is no need for that language, you are in trouble.
B) Try to learn several languages. You might be the first one to leave the project, but you can go to any project and continue your work there.
C) Learn many languages and master one of them. You probably can figure out what the benefits are.

Re:ADA?

[Anonymous Coward]

insurance companies use it

Re:ADA?

[Anonymous Coward]

Cobol is actually in live... but banks can't find capable Cobol programmers so they are running Cobol education for new employees.

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?

[Anonymous Coward]

I work for a very large package logistics company, and let me tell you, our universe still runs on COBOL. There's an IBM z series sitting next door that is still the heart of our location/postal/commit system, international billing, flight manifesting, etc. We've been trying to move these mission critical things for years, but quite frankly, management sucks at building talented teams and constraining the "architects" to the realistic and reasonable goals of system replacement and retirement.

Quite frankly, they keep trying to build a crystal palace, unaware that we live in a deepening swamp and what we really need is a pumping station. So now we have a number of these crystal palaces, half built, tipping over, on fire, and usually sinking into said proverbial swamp, but they do just enough that they're in "production" and their creators could collect their awards and move on. We can't just kill them because they do some minor part. It's frustrating and annoying. We're finally starting to get our act together and get serious about fixing this disaster, but I worry we're screwed.

Most of our COBOL folks either have retired or are on the verge of it. We're completely reliant upon vendors now for maintenance of these key systems, and quite frankly, they're in way over their heads. Anyone around here who actually knows both the business and IMS & COBOL can basically write their meal ticket. I don't work on it directly, but about half of my data is sourced from the mainframe. I've had to learn COBOL and working within the IMS environment as a survival skill.

Re:ADA?

[Anonymous Coward]

Nope, quite assure you that FDX still runs on a huge COBOL codebase. Source: I'm one of the greybeards. Our numbers are shrinking from attrition and buyouts, but the workload isn't...

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?

[Anonymous Coward]

Young pup... This is because many of theses companies that I've worked with don't post jobs on job forums that often and when they do, they likely don't mention COBOL. Younger developers (and I'm including anyone under the age of 40 in the category of "young") have never even seen COBOL code. There is no need asking for the skill if the developers are practically non-existent in the typical market-space.

Instead, some BIG companies tend to follow the same strategy that I ran into after college-- they recruit directly from universities. Kids that have a solid understanding of low-level comp-sci basics are quizzed. Pass the quiz, you get an interview. Pass the interview, you are paid moderately well to be hired and go through 3-6 months of intense COBOL training. Once you pass training, you become a professional COBOL engineer and are paid rather well.

You don't see these job posting because the ones that exist are likely vague and might not even mention "COBOL". Instead, they may mention working with legacy systems and would focus on the need for understanding low-level computer concepts and architecture. (I'm not sure why, but at least the few COBOL jobs I explored a while ago were presented this way.)

I guess this is the most cost effective way for them to maintain their infrastructure and with the influx of out-sourced labor (at least in America,) I imagine this tactic will continue for a long time. Why spend billions redesigning your entire system when you can spend, maybe, a couple million a year hiring and re-training new workers? The cost-benefit just isn't their, so the hire smart kids and internally train them on how to code COBOL.

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.

One size fits all?

[Anonymous Coward]

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

It really depends what you want to get out of your eduction. I think that I understand where your coming from, namely that eduction can be goal-oriented. That is, one can design a curriculum around some kind of objective function E.g., maximizing earning potential, employability. However, there are other approaches that I think are equally valid, namely that the point of an education is to learn how to learn. As someone with a liberal arts eduction, I cringed when I read the sentence that I've quoted above. Is It Worth Learning a Little-Known Programming Language? Absolutely, yes!

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.

Re:Won't hire 'monolingual' developers

[Anonymous Coward]

That's really a stupid restriction to put on potential hires. It's akin to Google's how many golf balls fit into a school bus. It makes you sound like you know what you are doing, but you really don't.

FWIW I've worked in at least 1/2 a dozen languages since the mid 80s, so it's not personal bias.

Here's an idea. How about seeing how well they solve problems in the language your shop uses? Just ask them to write a simple program (no more than 30 minutes) on their own time relevant to what they will be doing. Your shop does heavy DB business apps? Have them right a simple input/output form that connects to whatever database you use. Do AI? Have them create a simple rules engine or something. Don't over think it. You're not a psychologist and Myers-Briggs is total horse shit. Let them do it on their own time, look at their code and give them +100 for actually giving a shit enough to comment their code.

Also, there is no fucking way to determine the abilities and drive of a developer in an interview. It simply doesn't work.

That's why people come up with all these crazy ideas. You have to make your best guess, then see how they do over a period of time with various projects. The best solution I've ever heard of takes a manager with balls. He hired 5 people for 1 position, picked the best one after a month, then let the other 4 go. Worked every time.

I never had that option, so the best question I have is ask them about their favorite project recently then judge the passion. It's pretty simple. I'll ask a few silly questions depending on the language, then boom. I have as good a gauge as anything.

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? :)

Re:Sometimes

[Anonymous Coward]

Are you paid for your technical skills or because of your domain knowledge?

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.

Re: Rust isn't worth learning.

[Anonymous Coward]

It has been some time since I used Rust, but when I did there was a data type called Option that was used where other languages would use a null pointer or reference. It would store a value that may not be available. You had to call unwrap() to basically dereference it, to get the value. If you called unwrap() when a value wasn't available, it would be an error that I think was fatal, if I'm remembering this correctly. The end result was pretty much the same as with a Java app, where an NPE can terminate the program's execution. Rust wasn't any better in this respect.

Re:Rust isn't worth learning.

[Anonymous Coward]

Rust's string handling is a particularly bad disaster, and this permeates throughout the entire standard library.

Primarily because allocation is avoided where possible, and because it attempts to do unicode correctly.

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.

Re:Apex/Salesforce.com

[Anonymous Coward]

You sold your soul as well or just store it someplace safe during work hours?

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.

Learn any 2 DIFF languages, and you can learn any

[Anonymous Coward]

IMHO, after learning a 2nd language that isn't just a revamp of the first (ie: I'm not talking learning both C and java), should stretch your mind enough that you will be able to learn any language you want, given some time + practice.

So, the question is -- is that little known language different enough to be worth learning?

If you know java, C#, etc, then learning some other varient of C, is probably not worth the trouble.

If there's an employer looking for it, you can of course learn it. If you interview with them and don't know it yet, I would state confidently the languages you already know, and state that you are able to pick up new languages as needed, with some time and practice -- Faster depending on how close the language is to other things you know, and faster if you will have a mentor, but still that learning a new language is "a small hurdle, easy to deal with".

If you only know java / C type languages, and you want to learn something different, like one of the Lisp / Scheme type functional /recursive languages, then I think it is a worthy exercise. It will help you to approach problems differently. Or, even if your default approach never changes, it will give you an alternate approach that can be used to think about a problem in a new way.

The real key is you need Time + Practice. You won't know it instantly. Some employers will want you to already know the language they use. In that case, your only option is to learn it yourself ahead of time, or try to stretch the truth. But you also won't learn the language just from reading a book. You need to write programs, have them go wrong, debug them, enhance them, etc.

Which, can be a problem if you are already working full time with a different language. Trying to switch between your "day job" language, and your "after hours" language will make it harder. Not impossible, but harder.

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.

It depends.

[Anonymous Coward]

Learn at least one of each: postfix, infix, outfix, prefix, textural and visual language and you're done.

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.

FORTRAN makes me a lot of money

[Anonymous Coward]

I bill out at $450/hr for maintaining 30 year old FORTRAN code that does computational electromagnetics for some alphabet soup agency in DC.

Re:FORTRAN makes me a lot of money

[Anonymous Coward]

For some reason, most high-end computational physics codes are written in fortran. I've also made my career programming mostly to FORTRAN77 standards on them. Online fistbump.

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.

Arcane build/script/regex languages.

[Anonymous Coward]

Arcane build/script/regex languages.

The "obscure" languages I use every week which seem to give me rare and valuable skills are:

Bourne shell
perl
sed
awk
Make
python with regex.

Basically anything used for non-trivial build scripts, auto-code-generation and regex parsing. Almost no young "developer" seems to know how to do these things any more, although a few old school guys and sysadmins know a thing or two.

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.

Common DSLs

[Anonymous Coward]

Learning a language with a little different paradigm can be very educational and profitable.

Spend some time learning something like SystemVerilog/VHDL (for RTL design), MATLAB (for general math), or R (for statistics).

It certainly can be

[eighthdev]

"Obscure" languages often are extremely useful for some applications. As an example, "awk" is a serious power-tool for dealing with tabular data. My own "8th" (8th-dev.com) is a new, and currently still obscure language, but learning it will give you the ability to write cross-platform applications with the same source code. If that's not useful to you, then you wouldn't be interested. But if it was, spending some hours to check it out may pay off big.

Help me out here!

[Okian Warrior]

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.

But but... I was just scolded a couple of days ago about the differences between languages!

I was told that different languages will force me into different modes of thought!!!

I'm so confudded, I don't know *what* to think any more.

Golden Handcuffs

[Anonymous Coward]

If you get out of coding non-esoteric programming languages, you are going to be nowhere near the top of your game anywhere else, or at least that's how a recruiter will see it.

Yeah, you're the master of Cobol, which is fine-- until you want to work somewhere else, or God forbid they shut down whatever it is that needs your leet Cobol skills, or your workplace starts to suck, or you don't want to live in Bloomington, Illinois.

Also, if you're doing it purely for the financial gain, the payout-to-effort ratio is a little lean.

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.

Here's a pro tip

[Anonymous Coward]

Learning something new never hurt anybody. If anybody is telling you that learning X will hurt your ability to Y, they are lying.

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:Haskell

[Anonymous Coward]

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.

I've been maintaining, (Rewriting that is) Java EE code, that was written by people who obviously knew how to code, but they didn't know shit about Java and knew even less Java EE. And quite frankly, they didn't know shit about software architecture either.

"But Rust isn't competing with XYZ!"

[Anonymous Coward]

You bring up something I forgot to mention: the "But Rust isn't competing with XYZ!" excuse.

Whenever one person points out serious flaws that Rust exhibits, one or more others will come along and say, "But Rust isn't competing with XYZ!", where XYZ is Go, or Python, or Java, or Ruby, or D, or Erlang, or Haskell, or C#, or some other language that is in fact competing with Rust for a share of the market.

Claiming that Rust is only competing against C and C++ is a dumb thing to do, since C and C++ are both used for low level and high level programming. Rust is in fact competing with every other language out there, high level or low level, whether the Rust community likes this fact or whether they don't.

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.

Maybe this tendency to point to the competition, rather than just fixing the goddamn problem, is because Rust is so tied to Mozilla. We see the same excuses from the Firefox community. Instead of fixing Firefox's flaws, they just point to Chrome or IE and say "But they're worse!" or something to that effect.

Enough with the excuses. Fix the problems with Rust, instead of trying to redirect the blame elsewhere.

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.

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

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.

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

[Anonymous Coward]

C++ can be used for systems programming, for application development, and even for short scripts. Thus it competes with all other programming languages. If Rust is to be a replacement for C++, then it will need to excel in all of those areas. It, too, is competing with every other programming language out there.

Your experience is sadly limited.

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

I would say that you should learn at least one example from each of these classes of languages before you are qualified to claims like that:

machine language (seriously)
assembly language
fortran-like (seriously)
C-like (in a unix environment, specifically)
ML-like
lisp-like (prefix notation with lambdas and cons based gc)
apl-like (array notation and array based gc)
forth-like (concatenative notation - ignoring gc)
sql
"enterprise" (cobol, javabeans with spring, whatever...)
haskell-like
dependently typed

Within one of these language families, I can see that claim being accurate. Sometimes. If your problem domain is also constrained enough.

But start jumping families, or start trying to do something *useful* with your knowledge, and I think you'd start singing a different tune.

Do you know how a computer works?

[Anonymous Coward]

Do you know how a computer works?

The language you program in is translated It is going to be compiled or assembled into machine language or interpreted by another program that constructs machine language.

All you are doing by learning another language is learning to say in different ways commands that will end up being the same directives to the hardware. In effect, you are just learning how to use different translators.

The key is to know which translators give you the best service. Do you want to get the best program performance on the hardware? Or do you want to say what you want efficiently? Or do you want to write in brainfuck? It's all just a few levels of indirection.

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

RPG IV

[Anonymous Coward]

I had Pascal, COBOL, Fortran, Ada, LISP, C in my pocket. Then I came across this little beast. There are some companies (one of which I currently work for) that use this language in a major system. It is outsourced. For good reason, the syntax differs based on what column of the screen the code uses.

You won't work for a big company and work with this language you will work for a small company that does all of the stuff the big company doesn't have time for.

popular schmopular

[Hognoxious]

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

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.

Re:Stop trying to predict languages, follow paradi

[Anonymous Coward]

I completely agree. Learn paradigms, languages are not terribly difficult to learn (perhaps harder to 'master') but most good companies don't focus on the language as much as your ability to learn and your experience with certain paradigms. I've lost count of the languages I've used and I avoid candidates that are fluent in a language but can't speak to real Computer Science topics. A good Computer Scientist learns what is necessary to tackle a problem, not force their skills to solve a problem using only tools they know.

PowerBuilder

[Anonymous Coward]

Unless of course, it's been around for 20+ years, and simply refuses to die.

Go PowerBuilder

Is Java really a programming language?

[IWantMoreSpamPlease]

Or is it a punishment?

Re:Is Java really a programming language?

[Anonymous Coward]

Or is it a punishment?

My father was doing colbol. He missed the Y2K train, only to be fired a few years later from his permanent position (can you guess even I am bitter about this).
Thus he never gained a lot of money. If he had the guts to go independent he would have got maybe 3x his salary .
His job for the lost few years, as i understood it was to do string replacement and depressed him.
I guess it s fair to say than big companies have trouble managing decades old applications and are ready to pay to at least maintain if not transition their applications. The market is not in coding new functionalities, but just have it work today.

Re:Is Java really a programming language?

[Anonymous Coward]

Which would you rather have, a billion Indian engineers writing garbage in Java, or a billion people with nothing better to do than advance India's nuclear programme?

Don't be a dilitante

[Anonymous Coward]

Learn FORTRAN and get on with life.

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.

If learning a new language is a challenge...

[gweihir]

...then you are in the wrong business. If the language is interesting, learn it. If you have trouble doing so, change careers to something you have actual talent for.

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-)

Of course

[Anonymous Coward]

That you have to ask that question proves you should find a McJob.