I've reached a point in my career where I want to consider myself less "an {x} engineer" where {x} is a specific programming language, and I want to be more of a language-agnostic software engineer.

The obvious next step is to start learning as many languages as possible to build experience, but there's only so many hours in the day and I'd rather go about this in a more efficient way. Also, my end goal is not to be practically proficient in 20 languages, but rather to understand more deeply the variation among programming languages and what tradeoffs and design choices they made and why.

I tend to learn better when I can see an overview of the topical landscape first, before diving into the details. Is there a good, long-form (i.e., not a blog post) work on comparative language analysis that does a good job exploring the variations in programming language features? Or maybe, alternately, a good coverage text on programming language design?

closed as off-topic by gnat, Steven A. Lowe, Jimmy Hoffa, user40980, user53019 Sep 15 '13 at 2:16

This question appears to be off-topic. The users who voted to close gave these specific reasons:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – gnat, Jimmy Hoffa, Community
  • "Questions seeking career or education advice are off topic here. They are only meaningful to the asker and do not generate lasting value for the broader community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – Steven A. Lowe, Community
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 6
    The next step as learning as many languages as possible perhaps you'd rather learn as many paradigms as possible. It's relatively easy to switch from Java to C#, but Java to Lisp or Haskell is considerably harder because the differences in design choices between paradigms are much bigger – jozefg Sep 13 '13 at 21:28
  • 1
    If you go based on paradigms, the wikipedia page will get you a decent ways along. :) – jozefg Sep 13 '13 at 21:29
  • 1
    rosetta code is a good site to see how different languages solve the same problem. From there, you can research interesting/compelling differences. – Telastyn Sep 13 '13 at 22:16
  • 2
    I have a book on my shelf called Seven Languages in Seven Weeks. I have never read past chapter 2. But maybe you will. – kojiro Sep 13 '13 at 23:55
  • Many universities have a course under the name of Principles of Programming Languages; there are also many books covering the traditional material for such courses, most of them interchangeable. These books and courses survey a lot of languages to give you a feel for what the landscape loooks like and to give you the basic concepts familiar to language designers and researchers. If I had to choose one book to recommend, I'd go for Michael Scott's /Programming Language Pragmatics/. – ibid Sep 16 '13 at 6:27

Jean Sammet's Programming Languages: History and Fundamentals is a good place to start. From the top Amazon review, it gives is an overview of about 120 languages, with examples from about 30.

Wexelblat's History of Programming Languages and Bergin & Gibson's History of Programming Languages, Volume 2 cover quite a bit of territory.

All of these are quite dated, covering languages from years, even decades ago. This is a Good Thing. It will teach you that there were such things as computers and programming languages before IBM invented the PC and Microsoft invented the operating system. (Yes, I'm joking.) It will also give you some perspective on where we came from, and how and why some of the old languages are in fact considerable improvements on their more modern successors.

Beyond that, you have to start digging into the old literature, of the languages your father and even your grandfather used.

I'm 58. My father and I learned FORTRAN IV at UT Austin in 1970. I learned BASIC and PASCAL a few years later, while still in high school. I started learning CDC 6600 COMPASS (central processor assembly language) around then, and got serious about it in Summer of 1973. It wasn't until quite a few years later that I actually started really programming in C. (I think it was 1987, hacking MIDI on an Atari 1040ST. I had a copy of the floppy-based Software Toolworks C for CP/M, but I never really did anything with it.)

You absolutely must learn LISP. I personally recommend the Scheme dialect, and I concur with the SICP recommendation in the other post. There's an online version at MIT, and a supporting site.

I strongly recommend learning FORTH, or at least reading Leo Brodie's Starting FORTH. It will give you a very different perspective on computing. There's an online version at FORTH, Inc., and they offer a free (as in beer) unlimited-duration trial system. FORTH, Inc. are good people, even though Liz Rather has retired, and even though she and I did disagree on one key point of what makes FORTH a great environment.

For a different perspective completely, read Henry Ledgard's paper "Ten Mini-Languages: A Study of Topical Issues in Programming Languages". Rather than discussing full languages, he constructs "mini-languages" that illustrate important concepts in programming language theory and design.

This will give you something to chew on.


Well since your goal is to understand language design, I think two nice books for this are

  1. Structure and Interpretation of Computer Programs

    This is more of an "intro to computer science" in general. It teaches Scheme, and uses it as a vehicle to explore a decent swath of computer science. If nothing else, this will teach you how to program functionally since Scheme is essentially untyped lambda calculus + a few primitives.

  2. Concepts Techniques and Models of Computer Programming

    Goes through several different paradigms in a delightful language called Oz. An excellent way to learn about functional, concurrent, logic, constraint, (real) object oriented, and several other paradigms. This is important if you want to really understand the difference between languages.

These are books, not essays. But you're asking to cover a lot of ground. I'd especially recommend (skimming) CTMCP since it will talk a lot about language design, it's a very good read as well.

If you just want a general overview of what the major paradigms are, I'd actually recommend good old wikipedian comparisons. This is just a surface overview however.


I do not know such a book and doubt that such a book can exist, because each and every language comparision will be inherently biased. Everyone has a programming language that dominates the perception of other programming languages. A relevant essay on this topic is “Beating The Average” by Paul Graham, a veteran Lisp hacker.

When setting out to get an overview of different languages, it is best to first get an overview of different paradigms, their history, and their interaction.

  • Structured Programming
  • Procedural Programming
  • Object-Oriented Programming
  • Functional Programming
  • Logic Programming
  • Dataflow Programming
  • Parallel Programming

Some languages can be categorized along axes of

  • static vs. dynamic typing
  • verbose vs. inferred typing
  • strong vs. weak typing
  • parameterized types?
  • compiled vs. interpreted
  • Metaprogramming?

Some Languages also share a common ancestry. E.g. the wide branch of C-style languages is dominant in todays languages.

We now have a large multidimensional matrix of different properties, and can pick interesting languages.

  • C does structured and procedural programming, has static weak verbose typing and is compiled. It is significant of the lingua franca of the programming world.
  • Haskell is a functional compiled programming language with an extremely expressive static, inferred and strong type system. In many respects it represents the cutting edge of language design.
  • The Lisp family contains many functional and imperative programming languages, usually with strong, dynamic typing. Interesting features are homoiconic source code, and the resulting metaprogramming capabilities.
  • C# is an imperative, object-oriented C-style compiled programming language with a rich static and dynamic type system including generics, type inference, and metaprogramming capabilities. It is one of the more modern and flexible languages as far as mainstream languages go.
  • Perl is an imperative, functional, and object oriented interpreted C-style programming language with strong, dynamic typing. It is significant here because it is strongly influenced by Lisp, Shell, and C traditions, and has unusual features in its language design.

Etc. I myself pick a new language once in a while, and play around with it for a month. While I cannot effectively program with it, I am usually able to confidently read sources afterwards.

An interesting idea is to read criticisms of programming languages, and to see what they do wrong. For example php was criticized as a “Fractal of bad Design” in a blog-post. Many other languages share these weaknesses, but it is interesting to see how others ship around those cliffs.

  • i agree with everything except strong vs weak typing, there is no precise definition of these terms... – jozefg Sep 14 '13 at 1:10
  • @jozefg “Weak typing is a type system I disagree with” – the tongue-in-cheek definition. Actually it is “a type system that can be subverted”. In C, I can cast things to and from the most different types: void* whatever = (void*) some_struct_ptr; /* lose all type information */. For C, everything is just bits and bytes without structure. Languages like Haskell do not allow such nonsense. – amon Sep 14 '13 at 1:22
  • 3
    Actually haskell allows this too, it's called unsafeCoerce. By this definition all languages except formal theorem provers (coq, twelfth, etc) are weakly typed. – jozefg Sep 14 '13 at 1:36
  • @jozefg Good point. I learned something today. – amon Sep 14 '13 at 1:41
  • 1
    @jozefg: It is only useful, I think, to talk about “strength” (≈ stricture) of specific aspects of a type system—memory safety, runtime errors, implicit conversions, &c.—and not of the system as a whole. – Jon Purdy Sep 14 '13 at 3:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.