What Programming Languages Should You Learn Next?

simoniker writes "Over at Dobbs Code Talk, Chris Diggins has been discussing programming languages beyond C++ or Java, suggesting options such as Ruby ('does a great job of showing how powerful a dynamic language can be, and leverages powerful ideas from Smalltalk, Perl, and Lisp') but suggesting Scala as a first choice ('Very accessible to programmers from different backgrounds.') What would your choice be for programmers extending beyond their normal boundaries?"

Comments

Wrong Question

[jellomizer]

The question is flawed. Anyone worth their weight as a programmer doesn't care what language they
program in but. But Programing Methodoligy should they work with. Assuming that you use to
Object Orianted Languages (C++, Java, .NET) which are a deveation of Procedural Based Languges (C,
Pascal, FORTRAN). So after knowing those methodoligies perhaps you should study functional languages
(LISP, SCHEME, HASCAL) or Logic Based Languges (Prolog).

Procedural and Object Orianted languges tend to have the most programmers and is widly used

Functional comes next used in some Sciencetific applications as well handling a lot of AI type stuff.

Logical Lanagues are used less frequently because it is very tight sometimes too tight to expand into
a full application.

But most good programmers with experience in these languge classes are not normally worried about what
to program in. They may have their personal favorates but, can code sucessfully in any language
even if they never coded in it before. Because once you understand the classes the rest is just a
google search from finding the right command and syntax of the languge.

For example some differences between procedural Languges

        FORTRAN
                IF (X .EQ. 1) THEN
                END IF

        VB
                If (x = 1) then
                end if

        C
                if (x==1) {
                }

        Python
                if x == 1: ... ...
        BASIC
                IF ($X = 1) THEN
                END

Wow there are 5 different languges and they all look simular almost anyone would be able to figure it out

Re:Wrong Question

[ucblockhead]

Well...programmers usually care what languages they know when it comes to writing their resume. So while in one sense, you are current, in the career advancement sense, I'd go by what they want on Monster.com: (Java, Javascript, C, C++, Python, Perl, PHP.) True, any good programmer could pick any of those up in a few months (except maybe C++) but HR drones don't know that.

When I went to school, we were taught all these methodologies. (Though in my case I'm so old that OO programming was too new to be well taught.) I'd hope your average programmer would know them all before getting that first job. Sadly, I get the feeling I am mistaken.

But in general, I'd say, for instance, to use Javascript rather than Lisp as a functional language...not because it is better...not hardly...but because it is very marketable. (And sadly, most people with Javascript on their resumes have no clue it is anything but a Java clone.)

Re:Wrong Question

[whtmarker]

First,
learn to spell (or install firefox2 which underlines textarea typos in red)
methodoligy => methodology
orianted=> oriented
deveation => deviation
languges => languages
widly => widely
sciencetific => scientific
favorates => favorites
sucessfully => successfully
simular => similar

Second,
Never misspell when you code (not comments). Those of us who do know how to spell have to remember which constants, database field names, class names, file names, functions are spelled incorrectly and exactly how it was incorrect to avoid bugs. Another way to introduce more bugs is to go back fix misspelled words.

In summary, bad spelling = bugs

Third,
People these days don't read books enough. They can be on any topic, but if you want to be an expert in your field, read books in your field. As you read you will encounter technical terms. If you weren't familiar with the word write it down. This is how to learn to spell. It is when you focus your reading on professionally edited content instead of user generated content (blogs) you can improve.

[Some people have severe learning disabilities and I sympathize with them, this post is obviously not directed to them]

Re:Wrong Question

[EWIPlayer]

I'm sorry, but the parent comment is a bit "out there". If you had said something like, "Programmers don't care what language they program in, so long as they only want to be coding in one language just like they're coding in any other language", then maybe. But come on... It's talk like that which makes completely mediocre programmers. Do you know how long it takes to become truly proficient in C++ and OOP? Do you honestly want to tell me that you can come from Java (which doesn't destructors, for example) and simply apply your OO Java programming to C++ and be "good"?

Different languages exist because language A does not do what language B does. And, yes, they can contain a ton of the same kind of idea, which is exactly the reason you need to become highly proficient in them to get anything real out of them. You need to explore the differences not the similarities. I have worked with enough mediocre programmers and enough non-designers in my life, thanks very much. I want people to get deeper, very very deep into alternate languages so that they can broaden their thinking, not just their basic language skill set.

Learning a new language has little to do with that language and more to do with learning new ways of thinking. When I interview people that say that have any OO language, I grill them on OO more than I do on the intricacies of Java interfaces or C++ memory management. How you think is much more important to me than how many times it takes you to successfully compile a file.

Re:Wrong Question

[rijrunner]

There is another aspect to this.

Just learning a language is somewhat pointless. What are you learning the language for? Some languages do some things better than others. Some languages have entire corners of uses that many people never use.

If you are just going out and writing the same app in a different language, who cares? A lot of web stuff, it is irrelevant whether you use php, java, or whatever.

My first answer to the question "What would your choice be for programmers extending beyond their normal boundaries?" would be "quit writing the same crap".

If you've been writing cgi scripts, write a device driver. And use a language appropriate for it. If you're been writing the newest game that will blow everyone's socks off, write a Database app. Push your goals out there and the rest will follow. Stretch your goals into looking at the end goal and weighing the options in languages to get there. If all you are doing is jumping language to language at the same playground level, you're wasting your time. Languages are just a tool to build something, so build something. Something you have never done before. Unless your compiler is less than 20k in size, odds are you haven't explored a fraction of the versatility of the language you are using.

Bite off more than you can chew.

Re:Wrong Question

[geekoid]

any sane person would consider it for it's strengths and use it for that.

Re:Wrong Question

[corbettw]

Except that's not how you'd do it in most procedural languages today. Instead, you'd define a function and then call that function recursively. Eg, in Python it would be:

def add(x,y):
    return x+y
add(add(1,2),3)
6


So how is that fundamentally different from your Lisp segment, other than you used a built-in function and I created one that mimicked yours?

Re:Wrong Question

[anandsr]

FORTRAN does not use the stack and call semantics. This makes it much faster when writing modular code that is fast. The functions will be implemented as simple jumps rather than calls. Almost all mathematical libraries are written in FORTRAN.

Specialization Versus Breadth

[eldavojohn]

I seem to be at odds here with this mentality.

Stepping outside your comfort zone is a great thing if you have the time or need to do it. Me, I learned scheme & lisp, prolog, a number of instruction set languages and various scripting languages in my undergrad. Because I needed to see what it was like in realms other than Java & C++.

However, these days, I spend my free time looking at frameworks for the latter two languages. Do I want to know Ruby? Sure. But it's not going to make me better at my job. My employer has me jumping from JBoss to Weblogic to Websphere to Jetty to Glassfish to ... whatever's under the sun for application container and all the while I'm trying to be an expert at Maven (which seems limitless) and Ant so I can do a decent job building. Not to mention the UI aspects: JSF, Tiles, Javascript, AJAX, DHTML, JSPs, JSeamless, Flex, GWT ... they just go on and on.

I hate to say it but this specialization programming and time spent with other people's frameworks and libraries seems to make me more valuable in my own realm. You're right, it's a good idea for me to pick up Ruby (or whatever I'm supposed to learn next) because Java is not going to be around forever. But honestly, I feel a lot of people around me could stop re-inventing the wheel week after week at work and just take a couple days to tweak someone else's solution to work.

That said, Lisp & Prolog were my most favorite and least practical languages I've learned (I think Lisp stands for Lost In Stupid Parentheses).

I guess my answer to your question just another question: "What is your motive for learning a new language?" If it's to broaden your view of the world, go with something out of left field. If it's to be more valuable or better at what you do in Java, C++, Pearl, etc then I would actually tell you to start learning how everyone uses those languages.

Honestly, a lot of the older coders I know just don't have the time. The company will both pay for and tell them what they need to learn next or they ain't learning anything at all.

Re:Specialization Versus Breadth

[mckinnsb]

The interesting part about specializing in libraries or frameworks for a language you already know is that it often shows you how to use the language in ways you never thought of, or thought impossible.

Lately I've been doing a lot of stuff with JavaScript, and mooTools has been a framework I've invested a lot of time into. The first time I remember reading the tutorials, I asked myself "The hell? This is javascript?". After a while, I realized that with mooTools and a little creativity, I could create many flash-like effects, without flash. The same thing happened when I started to use CodeIgniter, a PHP framework. I had simply never seen PHP coded in that fashion before. Especially with PHP 5, CI becomes extremely OOP-like, with MCV and everything.When I went to school, the words "Object Oriented" and "Model View Controller" were *never* talked about in my PHP class (even during the advanced segments).

That being said, if you want something that will truly test your resolve as a programmer, I'd try to learn ML. It's not very useful, at all, (although some of its variants are used widely in scientific fields) but it will teach you a lot about type-checking, and how very *nice* a C or Java compiler is to you. Ruby is also a good thing to pick up, especially once you realize how awesome the migrations are in Ruby.

Python?

[freshman_a]

I'm surprised there was no mention of Python. I think Python is a good language to know. It seems to be used a number of places and forces people to write easily readable (and therefore maintainable) code. And I thought it was pretty easy to learn, especially if you have OOP experience.

Re:Python?

[TheRaven64]

and forces people to write easily readable (and therefore maintainable) code. I really need to bookmark this comment so I can come back to it next time I use a Python program. I have yet to encounter a single piece of nontrivial Python code that actually worked as its author claimed and didn't require debugging before actually being used. It is quite possibly the worst mainstream language, since it has half-arsed support for a load of different paradigms and yet manages to fail to support any of them well. On the plus side, most of the old VB programmers have migrated to Python, and it's probably a step up for them...

Re:Python?

[Otter]

I love Python, but it doesn't really serve as a good example for this discussion because of what another commenter refers to as "half-arsed support for a load of different paradigms". If you want to stretch your mind with immersion in a different way of doing things, Python's collection of diverse best practices isn't an efficient way to do it.

Re:Python?

[Russ Nelson]

I have yet to encounter a single piece of nontrivial Python code that didn't work as its author claimed nor any that required debugging before actually being used.

Maybe you need to hang out with better programmers, TheRaven64?

Re:Python?

[mollymoo]

Why on earth do you think code being readable means it has to work properly? That's a logical non-sequitur. Various languages can and do reduce or eliminate various classes of potential bugs, but none can force a programmer to write good code.

Re:Python?

[Alpha830RulZ]

Use google much? It seems to work pretty well there.

SQL is next for me

[damn_registrars]

I learned BASIC back in the days of the C64. I then learned Perl when I decided to try my hand at bioinformatics. I picked up C++ at the same time. But there was one language that was used regularly there that always made me feel like a fool.

SQL.

Everything about it seemed backwards and inside out to me. I had a hard time wrapping my mind around "accountant-speak" and "normal forms" (still not sure WTF that means). Yet i know it will likely be in my future. Too much data resides in tables now, and too much data interpretation comes down to data(base) mining. Even the perl::sql modules couldn't save me completely.

So I would say, if you plan for a career that is data-driven, learn SQL if you haven't already. It certainly doesn't seem to get easier to pick up as you wait longer - or at least it hasn't for me.

None of the above...

[Ckwop]

My advice would be to learn formal verification techniques. These can be applied across languages and across platforms. If you deploy them properly you can reduce your defect rate from 50 per 1,000 statements to 2 per 1,000 before the first test case is run.

That will save you far more time than the latest over-hyped platform. While everyone else is fixing bugs in their application, you've already moved on to greener pastures. It will increase your capacity to build really good quality software and not get in to flame wars over nonsense. Nothing quite ends an argument over style more than saying: "Yes, but can you prove that your approach is correct? I can."

Simon

Re:None of the above...

[Ckwop]

"Yes, but can you prove that your approach is correct? I can." You must be a joy to have as a co-worker.

I know that it sounds like I'm a shit but in the real world office environment, I'm no where near that pretentious!

That said, this does not detract from my underlying point: In this industry we are constantly told that the next big thing is going to revolutionize programming. We here this a lot about Ruby on Rail at the moment. We're told that if we just choose the right framework and programming methodology we can produce awesome software on time and on budget.

We fall for it every. single. fucking. time. until. words. lose. all. meaning.

The simple fact is that a large part of the time spent in a project is spent debugging the code we just wrote. Debugging is expensive. You typically have entire departments devoted to testing code. In fact, debugging routinely kills entire projects because it turns in to a very costly version of whack-a-mole and people eventually get tired and run out of money.

I am convinced that the key to improving programmer productivity is to get them to write the software correct, first time. It does not lie in a language or programming style.

Verification is not perfect. In my original comment I said that even after formal verification you can still expect bugs. After verification you can typically expect a similar error rate to conventional testing strategies. This is simply because you have to abstract things and you can make errors in your abstractions. Or you might simply make a mistake in your proof.

The point is, verification does not have to be perfect to be better than unit testing. It simply has to find more defects faster. The evidence out there is starting to suggest that it does. Certainly with very large products.

Simon

Re:None of the above...

[epine]

My advice would be to learn formal verification techniques.

Over my career, I wouldn't say that languages as such have been a major influence. Developing language-independent formal coding strategies has proven far more important. I've benefited from the writings of Dijkstra (immeasurably), Stroustrup, Iverson, Backus, Knuth, Plaugher, Stepanov, Brooks, Bertrand Meyer (with reservations), and not a lot else. I haven't learned anything profound from Wall, but thanks for all the Onions.

Machine code gave me a good underlying model of the machine. Essential for many debugging situations, esp. back in the day when compilers would often generate faulty code.

APL taught me the value and power of carefully reasoned primitives, the power *and* risk of concision.

C taught me how easy it is to write a loop that's impossible to validate mentally (and then I taught myself how *not* to write such code).

C++ taught me most of what I know about software engineering: programming in the large. C++ manages to be simultaneously better and worse than almost any other language one cares to name. There is a deep truth there that hardly anybody in the industry wishes to accept.

SNOBOL and PL/1 taught me that kitchen sinks are best used for washing dishes.

Perl taught me that it isn't at all difficult to write a complex regular expression that's harder to read than any APL program I ever wrote. I once had to program in APL on a teletype that lacked the APL character set, so every APL symbol was mapped to its ASCII counterpart based on key location. Reading APL code on this teletype was comparable to reading a particularly hairy Perl regex.

PHP taught me that useful code can be written in a language with no coherent center whatsoever.

LISP taught me that the human brain is not a stack machine. I grew up with Mechano. I don't understand the Lego people while all those identical bricks, and I don't understand the LISP people with all those identical cricks.

COBOL taught me separation of concerns: code should be code, comments should be comments.

Python taught me nothing at all. To me Python is just the metric version of PHP, which spares you the headache of guessing which functions calls are in Imperial or American units (roughly as arbitrary as whether a Wikipedia page uses British or American spellings). To be honest, I learned more from playing around with ChipWits many years ago. But I find Python enjoyable for some reason as much as I've used it.

Pascal taught me that the evolution of a complex program occurs along more than a single dimension. I never enjoyed a single minute of Pascal programming.

By far, I learned the most simply from reading Dijkstra (set aside an hour per page) and practicing the art of coding an algorithm in such a way that by the time you are done, your code couldn't possibly be wrong in any profound way, because you have captured the undiluted purity of essence.

Plaugher helped to convince me that computers are *especially* fast at doing nothing. Whenever possible, when a precondition is not met, I just let the code continue, mostly doing nothing (if every statement is coded not to execute in the absence of its precondition, this is an automatic consequence). When the routine completes, I check state variables to see whether the desired actions were accomplished.

I hate exceptions and have never conclusively demonstrated to myself why exceptions are necessary. I suppose to permit integration with code that *doesn't* rigorously guard every statement. I feel confident about my C++ code until the moment I enable exceptions in the compiler. Then I think to myself: this program could potentially fail in 1000 different ways depending on which exception paths are taken. It took the wizards of STL *years* to make the STL fully exception safe. That troubles me. A lot. More than all the other complaints about C++ piled to the moon and back.

Knuth was wrong about premature opt

assembly

[petes_PoV]

if you have only ever programmed in a high-level language, you should really learn a low level one. This will give you an appreciation of what actually goes on inside a processor.

Even if you never use it commercially, the background it gives you in terms of hardware will improve your ability to write efficient code.

Personally, I think this should be the first language that future programmers (as opposed to CS graduates) should learn.

Re:assembly

[muridae]

Let me second that idea, and then add to it. Assembly programing will give you a better idea of what your hardware is actually capable of doing, instead of abstracting everything behind objects and function calls.

My suggestion, if you know C++ or Java, is to learn something that isn't slightly object oriented. Pick up Lisp, Haskell, Prolog, any of them. Learn to think in a different direction. Learn straight C. If you really want a challange, hit http://en.wikipedia.org/wiki/Programming_paradigm and learn one language from each paradigm. You don't need to learn them well enough to think in them without looking at a grammar cheat sheet, but just write a simple program in each one. Say, populating a list and sorting it, or a Fibonacci generator.

Then, take your favorite language, and write something for an embedded platform. A telephone, hand held game system, a custom project using any old PIC/Atmel/MIPS/whatever. Get used to writing stuff where you can't abstract everything, because you have a bigger limit on memory and system functions. You don't need to do this in assembly though, by this point, you may find that you want to.

By the time you are done, you will look at programing differently. Not in a 'How do I do this in a language and library set I am comfortable with' way, but from a 'which tool works best for this situation' perspective. That will make you a better programmer.

Anything But Perl

[Perl-Pusher]

Python would be my choice. Perl isn't bad, just not my first choice for a beginner. Its way too easy to fall into bad habits. I started out in perl and looking back 5-7 years at some of my stuff, ouch! Its way too easy to find really bad, insecure examples on the internet code by using google. I've seen some really horrid stuff end up in production settings because a programmer found a few tid bits on the internet. Not that you can't find crappy python code. It just doesn't seem to come up as readily in a search.

Re:Anything But Perl

[notque]

So don't use code snippets without understanding them. Just because you can find fewer doesn't mean perl is bad language to learn first.

I have only learned perl, and am quite content with it as it does the jobs I need it to. I haven't been using it for 5-7 years, but I look back on code from 3 years ago and it's no less secure than anything I write now. I decided to understand any code snippet I used.

I think Perl is a fine first language as long as you start simply, and expand giving yourself time to take in the concepts. Enjoy the exploration.

I can't speak in comparison to any other languages obviously, but it worked for me.

Re:Anything But Perl

[samschof]

Learning perl as a first language is a bit like turning 21 in Las Vegas with a big wad of cash in your pocket. There are simply too many options and not enough experience to deal with it.

Perl allows everything from OO to shell script type syntax and you do see everything in between. I love perl, but for a first language, you are much better off with a simpler language that has strong type checking and strongly encourages structured programming practices.

Re:Anything But Perl

[merc]

I must echo the sentiments of the OP; although my experience has been a bit different. I came from a heavy UNIX/C background, which I enjoyed for many years. I began to experiment with Perl when perl5 was released (must confess I was not a big fan of perl4). One of the aspects of Perl that I always found delightful was the fact that it seemed to literally be a wrapper to C, or at least C-like. Not only does it supports system calls, and similiar C library API functions such as sprintf, et al, but without all the management headaches of C. It has a useful capacity to do extremely complex pattern matching with its NDA regular expression engine. Above all is the massive CPAN code repository that seems to satisfy just about any kind of computing need a developer could imagine.

Since then I have come to the conclusion that (at least for me) Perl can, within reason, satisfy just about any computing requirement I run across in my personal and professional life.

It's not all syntax

[shyberfoptik]

The fact that you think "mindless syntax" is the only difference between lisp, haskell, and c shows that you should probably learn one of these languages.

It depends

[natoochtoniket]

The right answer to most such questions is, "It depends."

What sort of tools will be useful in your future career? Or, what sort of knowledge will be interesting to learn?

If you are concerned with serious engineering issues, such as safety and correctness, you might want to learn something about "formal methods". Languages to look at include Z and B. And, of course, there's a little field called "computational logic."

If you are concerned with commercial byte-pushing, you obviously need to be conversant in SQL and an assortment of scripting languages. And, of course, there's a little field called "accounting" that might be useful.

I don't think there is any one right answer. The choice of intellectual tools that you will need really depends on the choice of what kinds of work you want to do.

Haskell, Scheme or Lisp.

[Kartoffel]

I've been spending the better part of today refactoring some ugly C++ that was written by a crusty old Fortran engineer. It might as well have been Fortran.

Please please please learn a functional programming language. Even if you don't use it in your daily work, your brain will be improved.

MATLAB

[Thelasko]

It's great for handling matrices, vectors, plotting and umm... well, that's all it's good for.

Re:Verilog

[exley]

This is a great example of mods and commenters (i.e. GP, currently modded informative) who don't know what the hell they're talking about. Parent post is correct -- while you can use Verilog for programming an FPGA (field-programmable gate array), Verilog has many uses in hardware design. It's called Verilog HDL (hardware description language) for a reason. Here is an overview of Verilog for the uninitiated.

Don't laugh.

[DA_MAN_DA_MYTH]

But I think a really good language to learn is ECMAScript or to the layman, Javascript.

Javascript is the language of the future. It's such a powerful language and so underrated. It's far beyond the whole switching images thing. It's an interpreted langauge deployed on more computers than any other programming language. (think web browser.) It's light, it's fast, it's dynamic. For a scripting language it offers you an extremely familiar syntax, C like. It's becoming the backbone of other environments, and other compiled / interpreted languages are being extended for scripting support.

Re:Verilog

[Neil Hodges]

And what makes those two languages worse than C++ (for example) is that they don't have static objects! Well, for most cases; I know C# has static structs and simple datatypes (integers, floats, etc). So if you don't like references, stick with languages that don't force you to use them.

Re:Verilog

[encoderer]

True, but if you don't like references, you might ask yourself why you're in this business.

I mean, sure, pointer arithmetic can be complex and convoluted, but, conceptually, if you find if HARD, you may not have made the right career choices.

Same thing with other techniques that get lumped in the "hard" category like recursion, closures, etc.

Re:Verilog

[redhog]

What is a CPU and what is a programming language? From a comp.sci. point of view, the input language of anything that can execute any algorithm, that is, that is turing complete, is a programming language.

Proof that an FPGA is turing complete:
An FPGA can emulate any set of gates and interconnections given a description of these as input.
A normal processor, e.g. a Z80 is a set of gates and interconnections.
Thus, an FPGA can emulate a Z80.
The Z80 assembler is turing complete.
Anything that can emulate something that is turing complete given the right input, is turing complete.
Thus, and FPGA is a turing complete machine and its input a programming language.

Re:Yes and no.

[ucblockhead]

The job market doesn't change that fast. The top-five languages from five years ago are all still extremely popular. If you learn the top five languages for today, you will most likely be in very good shape in five or ten years in the future. If you wait until you actually need the job, it'll be too late.

MMIX

[plstbb]

I would recommend http://www-cs-faculty.stanford.edu/~knuth/mmix.html

A great way to train your brain.

Re:Verilog

[sean4u]

Maybe you should have been +5 Funny, but not +4 Insightful.

An FPGA might very well be able to do very little. See Adrian Thompson's page, especially his 1990s work on evolving FPGA circuits.

'An FPGA' could be a very limited device.

Re:Going from C to others is a matter of right boo

[Serious Callers Only]

Well, I don't know, I'm half way through, never having used LISP before, and it seems like a nice introduction to me - surely it's best to start with the stuff that makes it worth learning? After all much of the whole point of learning another language is to absorb the culture which comes with it. Haven't read the other book you're recommending though so will take a look.