Someone told me that learning Haskell would serve to help me be a better programmer in the languages that I already use. Is this claim true or false? What other languages besides Haskell would help me become a better programmer? Common Lisp? Ada? Smalltalk?

I should preface this by saying that I am already interested in attempting to take on haskell, but I'd like to hear your ideas on this topic in general.

Yes, learning new languages gives you more perspective on programming in general, and exposes new idioms and constructions that aren't as obvious in the languages you already know. You should seek out languages that are as different from what you already know as possible. Haskell is usually a good bet in that regard, as are lisp and smalltalk. Wikipedia also lists several different paradigms; you should know something about as many of them as possible, preferably by learning at least the basics of a language in that paradigm. I find it's usually best to learn the essentials of a paradigm by learning a language that focuses heavily on that paradigm. Multi-paradigm languages often lose or hide some of the finer points, like how C++/Java has an inferior object model to Smalltalk, Ruby and even JavaScript, because they just bolted on some of the OO concepts onto the then-prevailing paradigm instead of fully embracing the paradigm.

It is practically impossible to teach good programming to students who are motivated by money: As potential programmers they are mentally mutilated beyond hope of regeneration.

Seconded, with the added mention that you should learn not only paradigms like functional vs OOP, but also type systems. Haskell's type system is very strong, and very static. LISP is weakly dynamically typed. There are other type systems out there, like duck typing, which has interesting quirks, and dependent typing, which Agda uses. Knowing how all of them work will make it easier to see how many parts of a larger program fit together.

<quintopia> You're not crazy. you're the goddamn headprogrammingspock!<Weeks> You're the goddamn headprogrammingspock!<Cheese> I love you

I used to be skeptical of the notion that learning a language with an unfamiliar paradigm makes one a better programmer. However, I enjoy learning new languages, and began studying Haskell for that reason. Turns out, it's had a big influence (for the better, I think) on my programming style in Python. I have now drunk the Kool-aid, and yes, I think Haskell would make you a better programmer.

Apologies for the awful picture, but this is more or less what pops into my head every time I read "duck typing":

One thing I will actually contribute is that it's important to learn the new languages, not just learn an old one and then start using a new one because "it's similar" to your old one. This leads to a good deal of the content of The Daily WTF.

The problem that I am having is that there are so many interesting languages that merit study. In my head right now, I am playing around with the idea of learning Haskell, Smalltalk, or Clojure. So many decisions!

No, don't skip on Smalltalk. I'd skip on Clojure out of those three (or switch it out with CL or Scheme, which in my mind are more LISPy.) Learn smalltalk, or if not then learn Ruby but read some smalltalk tutorials as well. It's not at all like Java.

Learning several languages at the same time can also work. It makes for great contrasts, making it easier to juxtapose their features and creative thoughts in the way of mixing things up. It's hard work though since there's just that much more material and it's easier to become confused.

It is practically impossible to teach good programming to students who are motivated by money: As potential programmers they are mentally mutilated beyond hope of regeneration.

Berengal wrote:No, don't skip on Smalltalk. I'd skip on Clojure out of those three (or switch it out with CL or Scheme, which in my mind are more LISPy.) Learn smalltalk, or if not then learn Ruby but read some smalltalk tutorials as well. It's not at all like Java.

Learning several languages at the same time can also work. It makes for great contrasts, making it easier to juxtapose their features and creative thoughts in the way of mixing things up. It's hard work though since there's just that much more material and it's easier to become confused.

May I ask why you would say skip Clojure?

EDIT: Also, I am a little apprehensive about smalltalk as well. There is a very small community, and unless you are using GNU smalltalk, you have to use one of those IDE's similar to the Squeak setup.

Clojure is just a lisp on the jvm. If you want to learn a lisp, Scheme or CL would be better choices since they don't have all that jvm noise going on. If you want to learn the Java platform, learn Java because it doesn't have all that lisp noise going on (not that learning a platform will make you much of a better programmer in the first place, and the Java language is pretty boring and narrow-minded as far as languages go.)

Smalltalk, on the other hand, is probably the language that has taken class-based object-orientation the farthest. It's one of the "extreme" languages that will change how you think about programming. In comparison Java's object system is utterly broken.

Ruby also does very well in that regard. It adds some modernisms and hides some of the object-orientation behind the curtains, but if you look for it it's still there somewhere in the vicinity of meta-programming. (I don't know that much smalltalk, but I have a feeling that what rubyists call meta-programming smalltalkers call just regular programming.)

It is practically impossible to teach good programming to students who are motivated by money: As potential programmers they are mentally mutilated beyond hope of regeneration.

What amazed me about smalltalk the most was that literally everything is an object. I mean that in a sense beyond what is typically meant when something like Python or Ruby says that. I mean, the very environment you work in is made out of the objects that you are working on. You don't actually have to know much smalltalk to realize that any other language is only pretending to be object oriented.

The most kickass web-framework I've ever seen also exists for it (seaside). You can interact with objects on your webpage and add code to them as it's running. It's based on top of continuations and all of your objects are real, live smalltalk objects existing in your image.

For a harder question, why would it make you a better procedural programmer?

My answer to this: even in procedural languages, sometimes you deal with algorithms that are easier to work with conceptually and understand correctly if you're dealing with ideas that are more greatly emphasized in other languages, such as recursion, functional programming, etc.

For instance, binary searches are basically a recursive process, even if you're not implementing them "recursively". To me it's clearer to think about the algorithm as a recursion (i.e. base-case, reductive step, etc.) rather than an iteration (series of repeated steps which produces a desired effect). Each reduction step is a change to your lower or upper bound extents. So personally, I found that having experience with recursion and an understanding of how recursive implementations can be transformed into iterative ones helped me think about the process of that algorithm clearly and implement it and its variants (lower_bound, etc.) correctly.

Overall, I'd say it gives you a wider vocabulary for expressing program ideas, and therefore greater power to express those ideas effectively. That's my opinion anyway. But there's a lot of other things that can make you a better programmer, too: learning algorithms is a big one.

---GECI want to create a truly new command-line shell for Unix.Anybody want to place bets on whether I ever get any code written?

One language I would suggest learning is assembly (Even though many programmers cringe at the thought). And not just assembly for assemblies sake, but learn what your compiler is ACTUALLY spitting out.

It really changes your view on what code looks like and gives you a deeper understanding on what exactly is happening when you do x. Now, provided, this applies mostly if you want to do performance coding. However, I think it is just a good general tool to be able to look at some functions assembly and understand what is going on.

I'm certainly not advocating writing every (or any) project in assembly. But rather just learning what it would take to be able to. It is certainly a perspective changer. I just don't see multiplication or division in the same light anymore . Of course, with learning assembly you should probably read up about computer architectures as things like the order of instructions really can make a big difference in regards to how fast a program runs.

Actually I think learning any language which differs significantly from the languages that you already know will be very educative and therefore make you a better programmer. This might be because it is your first language (i.e. "the languages that you already know" is an empty set), which will usually be the most important eye-opener in your programming education, or because it confronts you with different paradigms (as is the case with several well-known languages), or because it confronts you more directly with the hardware (as in assembly), or because it confronts you with the very essentials of some computational model (like some esoteric languages), or just because you have to totally rack your brain over them (as in some other esoteric languages). Things that are not languages can also make you a better programmer, for example frameworks.

I included languages (and other things) of all of these categories in the list below, more or less in the order of these categories, though it's not my intention to claim that the categories fit well to the languages. Also the list is not meant to be exhaustive, but I do think a language on this list is always likely to be educative (and therefore make you a better programmer), unless you already know a language that is very similar (but other languages that are on the list do not count as such).

Python (or Ruby/Scala/Groovy)

Javascript

Lua

C++

Ada

Smalltalk (or some dialect)

Java or C#

Perl

FORTRAN

Erlang

Lisp (any dialect)

Prolog

Haskell

assembly

CUDA

Forth

J

Brainfuck

Unlambda

FRACTRAN

Zombie

Whitespace

Piet

Qt

OpenGL

regular expressions

being able to run a full development cycle within a terminal

being able to run a full development cycle within an IDE

(I didn't learn all of them myself yet, by the way, but I'm on my way.)

Edit: improved the list a bit as discussed in my next post in this thread.

It also made me realise that my list contained a few errors. "Eiffel" should have been "Erlang", "LISP or Scheme" is not a proper choice, and Lua and Forth were missing altogether. I have corrected the list now.