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

Wrong Question

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

Going from C to others is a matter of right books

You're right that if you know one C-style language you know them all, and in order to expand your development skills you should learn other styles of languages. However, a major problem is that there aren't so many references for non-C-style languages as there are for C(++), Java, Python, and Ruby. Though Lisp is something all developers should encounter, most Lisp books on the market are antiquated. (However, thank goodness for the relatively modern Practical Common Lisp [amazon.com] by Seibel.) I wish there were more tutorials out there for the exotic languages that might really teach you new tricks.

Re:Wrong Question

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

If you've never checked out Erlang [wikipedia.org], I recommend it. I've programmed seriously in at least a dozen languages, but this one really made me think. It has sophistication in concurrent programming [wikipedia.org] that I've not seen before. Plus, there's a great movie [google.com]!

Re:Wrong Question

Yup, I'll second this. Parallel programming is going to be a HUGE deal in coming years, and current languages don't handle it well - threading is complicated and prone to errors, leading to product delays. Erlang handles parallelism very elegantly and in a low-fault manner, as it must as it's used in critical telecoms applications. Unfortunately, the language also has a high barrier to entry as it is not Algol-based (like C, C++, Java, etc. are).

Re:Wrong Question

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

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

PRINT *, 'What is wrong with using FORTRAN 77? It is a perfectly fine lan'//
    1 'guage that offers the flexiblity for all generations.'
    PRINT *, 'Where else can I write code that will run on todays system and '//
    1 'still be able to back it up on punch cards for safe keeping that wil'//
    2 'l last for decades'

Re:Wrong Question

Agreed. It's a sad day on /. when I look at purported code examples and say to myself "Hmph. BASIC poser."

"BASIC poser" may be the saddest phrase in the geek sublanguage of the English language.

Re:Wrong Question

Functional languages seek to express all operations as a chain of functions which operate on data and return other data. "Function" is used in its mathematical sense here. Purely functional languages discourage state, and don't allow mutable variables. The lack of state and mutability give rise to some power; effortless parallelizability, for instance.

Logic languages are something different altogether. They provide a framework for defining the rules of a system, then searching for answers which fit the given rules. Logic programming is not useful for general-purpose tasks, but can hugely reduce programming time in tasks which are difficult to solve any other way.

Specialization Versus Breadth

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.

Python?

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 [wikipedia.org] 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.

SQL is next for me

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.

I understand that COBOL is pretty hot...

I hear that COBOL is a pretty good language to learn. It isn't new, but it is old enough to make a comeback (like disco, aviator glasses and big hair)...

None of the above...

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

"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

assembly

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.

Whitespace

I think Whitespace [wikipedia.org] is worth learning, if only to be a smartass on exams where the prof specifies you may use "any" programming language. Just leave it blank, then after the exam spend a few hours figuring out how the hell you would solve the problem in whitespace, and bring a proof of concept on a USB flashdrive to fight the inevitable incorrect grade you receive for the problem.

I have yet to find the courage to actually attempt this. . .

Re:Whitespace

That settles it. My next language will be lolcode.

KTHXBYE

Get the Little Schemer

Like a lot of people have commented on this thread, it's past time for you to learn a functional language. I'm not sure if it is true, but new CS students at MIT used to have to learn Scheme as their first language. Learning a functional language will transform your programming ability.

I recommend the book The Little Schemer [neu.edu] This book is like no other programming book you have ever used. It is a socratic dialog between you and the interpreter. Questions on the left, answers on the right. It is meant to be used with an interpreter.

Once you make it through this book you'll be a much, much better programmer. You'll also have an easy time learning languages like Haskell, which is used quite a bit in academia and is useful for real world software.

So buy a copy of the Little Schemer and download an interpreter, Dr. Scheme is pretty good, and get cracking.

Re:What Languages?

FORTH learn to want I would why?

Re:What Languages?

Because what Yoda would use is it.

Re:Anything But Perl

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.

It's not all syntax

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.

Re:Verilog

Verilog is a hardware description language, not a programming language. It may look like a high-level language -- wire assignments look like variable assignments, module instantiations look like function calls -- but conceptually it's completely different. Furthermore I don't know how applicable it's going to be for anyone who works in software design, which is the audience this question seems geared towards.