views:

810

answers:

8

Languages like C, Haskell, Lisp, Smalltalk, and assembly language are often touted as things every programmer should know for their effect on the way one thinks about programming, even if they're used very little in real world situations. However, to really learn a language in depth to the point where you know not only the syntax and semantics but libraries, idioms, all of the relatively obscure features and dark corners, etc. and can get real work done in it requires a pretty serious time commitment.

When dealing with languages like the above, at what level of depth do you start to get to a point of diminishing returns? For example, if you're learning C just to expand your horizons, is it ok to stop when you feel you have a pretty good handle on how pointers work and what it's like to manage memory manually, or do you need to do a serious project or two? When learning assembly language, do you need to be proficient in writing it, or does being able to understand its structure and recognize common idioms from higher level languages, like loops, virtual function calls, stack variables, pointer dereferences, etc. count as "knowing" assembly language? More generally, is it important to learn the whole language, or just to thoroughly wrap your head around the concepts that make it different from more mainstream languages?

This is about my level of knowledge of C and assembly language respectively. Haskell and Lisp are next on my agenda. Are these reasonable depths of knowledge for C and assembler? What are similar benchmarks for Haskell and Lisp?

+14  A: 

You should learn them to the point where you are comfortable working in them, but not to the point where you understand all the idiosyncratic issues. You should pick a mid-sized project and complete it. Once you have done so, you probably know enough to move on.

You'll get the learning from understanding the parts that make the language different, not from becoming a master. It is important to actually use the language though. If you only read about it, you'll likely miss a lot of the benefit.

Steve Rowe
"Implement a non-trivial project" is my benchmark for knowing a language. Less than that doesn't count.
dmckee
That's probably better than my original phrasing of "mid-sized" project.
Steve Rowe
If you feel some phrasing is better, you can edit answers!
ShreevatsaR
+6  A: 

Learning vastly different languages is beneficial because of the perspectives that doing so will give you with respect to problem solving.

Go for it. Write some programs that solve real problems in C, Java, assembly, Haskell and Lisp. Your brain will thank you for it.

Ben Hardy
A: 

I think that this question is based on what you are doing. If you are looking to program in C for a project, then you should know as much as you can so that you can do you best on the application. Likewise if you're developing in ASM, then I think the same thing. If you're developing in HLSL because you're interested in how it works with DirectX, you should be ok by just understanding basic implementations of it. Of course, the more you want to learn the better. I don't believe in diminishing returns on learning more about a language.

Suroot
A: 

You don't really know a language unless you do some legitimate development in it. That's why a course is good if you can afford it. Or, something like the Sun Java Developer's Certification. You can legitimately say that you can program in the language, because you have. One of my co-workers likes to write a directory listing when he's learning a new language.

Jack BeNimble
+1  A: 

What was the question?

Just learn lisp. It was made for thinking about.

Flinkman
+1  A: 

My votes would be

  • Common Lisp for teaching language semantics are constructed and extended
  • and Haskell for teaching (static) typing theory, pure functional semantics and lazy evaluation

Common Lisp is, in terms of expression, a super-set of C. Haskell is too. Though neither Lisp nor Haskell contains the other. I think it's more important to read/debug assembly than write it though, and only after you've written a lot of code.

It's important to have an idea of how your computer does computation, but Lisp was originally designed to model computation, so I think in the end you'll learn more from it than from mastering assembly programming. Some experience with how computers actually move bits around and how caching works and such helps in developing an intuition about performance, but learning assembly language alone is insufficient -- you also need to know how OS's manage virtual memory, how set associative caches affect memory locality and stalls, the effects of out-of-order processing (or on some recent in-order mobile processors, how much some apps suck when OoO is removed) etc. You learn this in a computer architecture course, not from programming directory listings in x86 op codes.

So yeah, learn Common Lisp and Haskell. I assume you already know one of C++, C, Java, C#, Basic, VB, Javascript, PHP, Perl, Ruby, or Python (in no particular order).

Aaron
+1  A: 

Those are all quite different. I don't know about APL, but the other three have very different things to teach you:

Lisp brings you across the language designer/programmer abstraction - most languages have a set of statements that you need to work with: "if", "throw", "new". Lisp lets you make new ones - from "unless" as the opposite of if, to "choose/fail" for non-deterministic programming. Reader macros let you extend the parser of the language - this is a language built with Inversion of Control in mind, long before there was a name for it.

Haskell teaches you math and type systems. I haven't worked in it much, but the first thing I learned is that type systems and code are separate, even though all languages I've worked with them in (Java, C++) mix the two together.

C teaches you how computers work. To really understand C (of C++), you have to understand assembly. Similarly, to really understand Java, you should really understand the JVM.

Andrey Fedorov
+1  A: 

I have to agree with Andrey Fedorov, when you look at a new language I think it is important to investigate what makes it different. Every language was designed with some goal in mind, that goal can vary a lot and it may be implicit or explicit.

I think the lisp ideas are something like:

  • A very small core language with the rest of the language programmed in terms of that. I can't speak for every lisp but ANSI CL has 25. Lisp definitely has the feel of "bootstrapping" yourself a language.
  • The language is defined not as a context-free grammar on top of a particular stream of tokens, but as lisp data structures that the reader can understand.
  • Furthermore, you can tweak the reader to change what sorts of things lisp recognizes as lisp. If you don't like parenthesis, you could remove them!

What I find most interesting is learning whole new paradigms (styles, etc.). Going from structured/imperative to functional to concatenative to multiprocess/concurrent to logic to etc. is what really stretches my mind. So for me it isn't the language so much as the style.

twopoint718