What do you think? What is the ideal programming language learning sequence which will cover most of the heavily used languages and paradigms today as well as help to grasp common programming basics, ideas and practices? You can even suggest learning sequence for paradigms rather than languages.

N.B. : This is port of the question I asked in stackoverflow and was closed for being subjective and argumentative.


19 Answers 19


Python, Lisp, C, Haskell

Assuming the question was about an ideal learning sequence for newcomers to programming (since old hands at programming will have had their own (likely accidental) learning sequence), I'd suggest reading Norvig's essay on how to learn programming in 10 years, then:

  1. Python: Start with a dynamic, high-level, OO & functional language. Because it's really important for beginners to feel productive ASAP, and not be turned off by alien syntax, lack of libraries, lack of multi-platform, lack of learning resources, and lack of community. Python is highly readable, has tons of good libraries (esp. scientific libraries - a modern scientist/engineer must know how to program), is easily run from most OSes, has tons of tutorials and entire free books, and is generally user-friendly — all while still being powerful enough to grow with you as you become an advanced programmer working on large problems. It's also important to reinforce important+useful conventions for a beginner: code readability counts a LOT, and you should be writing code for yourself and others to readily understand.

  2. Lisp: In particular, at least skim The Structure and Interpretation of Computer Programs or watch the SICP videos, and have one's eyes opened very wide by seeing the foundations and expressive power of programming - one can do so much with so little. Learn how Lisp can express not just the functional paradigm, but OO, logical/declarative, and more - like the creation of new domain-specific languages. Read Norvig's PAIP to witness what a master can do with the language. Then check out Clojure, a modern Lisp dialect that could be one of the Next Big Things.

  3. C: Only because it's the lingua-franca of computing. :) Possibly optional these days if one is primarily a programmer in a particular non-software domain. I find it ugly but worth knowing about to get an appreciation for the underlying hardware. Go with K&R, of course.

  4. Haskell: Pure functional power. Where current Com.Sci. theory and practical expressive power meet. See Real World Haskell.

After the above tour, one would be very adept at tackling problems and expressing solutions in code, and be totally comfortable with the paradigms here:

alt text

  • I'd (naturally) substitute Smalltalk for Python as #1, but I say that knowing that Python (a) is wildly more popular than Smalltalk and that (b) getting Smalltalk to talk to other languages is as hard as it is in Java, which is to say hard enough to frustrate a newbie. Python's "scriptiness" looks like quite a large advantage. Commented Oct 15, 2010 at 9:38
  • I agree with your productivity statement. I think learning C as the absolute first language is a load of bollocks. But it should definitely be in the stack somewhere. Commented Nov 3, 2010 at 21:08
  • +1 I'm not sure if Haskell should be at the top, but to be fair, I don't know it yet and it's next on my list, so it may yet end up being the last language I learn.
    – Inaimathi
    Commented Nov 4, 2010 at 0:32
  • 2
    1-click to full size diagram @ i54.tinypic.com/168ity1.jpg
    – Mike Clark
    Commented Nov 4, 2010 at 0:58
  • I would +1 this if C was not in the list
    – Balog Pal
    Commented Jul 1, 2013 at 23:51

This is how I would do it:

  1. Python (or Ruby or Lua): An interpreted language, no types, you can get stuff done in a few lines. Huge library (Python is best for this I guess). You can go deep in algorithms because there are no distractions. No compilation necessary, just run. On top of that, with Python you implicitly teach good style, since indentation in Python is mandatory. You can teach Object Orientation as well (in Lua is more of a problem). The purpose here is to have a lot of fun, and show the student what can be done.

  2. C++ (or maybe Java): A typed, fast language. If you need Object Orientation, then you already know some concepts. The main idea is to "translate" what you did in Python and do it with the new constraints (mainly types). Now if you have the concepts right, adding types is not such a problem. The next step is to think more low level (Java doesn't help here), and teach pointers well. By this I mean explaining about address space, the CPU, the OS, a little bit so that you can start seeing beneath your program. A compiled language introduces the distinction between interpretation and compilation, very useful to explain what machine language is, etc.

  3. Assembly: Finally, no magic, you just talk to the machine. There is a debate about Intel and GAS syntax, it's not important. If you have MIPS, I believe its better for teaching, but I suppose x86 is more convenient since it is more widespread (x86_64 better since has more registers and niceties). You just have to remove some of the complexity and let the students investigate further if they want.

(These first 3 are the "depth". Until now, we've been going down until you touch the bottom, which is "close to the metal", as they say. I think this is very important, many questions in programming are solved when you have a clear idea of what is happening. When you know this, you can acquire further knowledge with confidence.)

  1. Scheme (or Common Lisp or Clojure): As @dukeofgaming said, Lisp languages let you teach recursion well (for this Scheme is best, since doesn't have explicit loops). But I would go and teach two other things: closures and macros. Macros are what separates Lisp languages from the others. Personally I don't like Scheme macros but this is not too important. I think Clojure macros are nice, for instance (but recursion in Clojure is not as clean, since the JVM doesn't have tail recursion). Closures are a very important concept, once you grok them you "see" Javascript instantly. Having studied C++, Python, and Lisp, Javascript becomes "trivial".

  2. Haskell: For a functional language, I don't think you can beat Haskell. Lisp and Scheme are considered functional, but to emphasize functional programming, you have to force the students to think without state. Haskell also has other very nice things, like currying, and pattern matching for "destructuring". I don't know Haskell a lot, but the conciseness of the code you can write is just beautiful. Knowing Haskell well makes the path to understand Erlang much easier.

  3. Forth: A stack language. It totally breaks your logic again (if Lisp and Haskell wasn't enough). I would go as far as teaching Jones's Forth since they know assembly and then you can totally understand what is going on. (Knowing Forth opens up PostScript, for instance.)

(So these last 3 are the breadth you were saying. For me, these languages are strange enough that they change your way of thinking. They did for me at least. And I think with these, you understand enough paradigms to learn a new language very quickly.)

Optionally, you can study these:

  1. SmallTalk: A purely Object Oriented language. To see what happens when you take Object Orientation seriously, the language doesn't need "if", "for". Everything is a message: big realisation again. (This would make Objective-C easy now.)

  2. Go: A (beautiful) language with an emphasis on concurrency. I find Go very nice and comfortable to program with.

  3. Prolog: Another paradigm of programming. I haven't written any Prolog but I understand it is yet another mind-bending language.

  • 6
    Python and Ruby (I don't know about Lua) are strongly typed languages. I think you mean that they are dynamically rather than statically typed. Commented Jan 31, 2011 at 12:08
  • 13
    Please treat C and C++ as two separate languages. Commented Jan 31, 2011 at 15:17
  • 1
    Bjarne says: "There is no language called "C/C++". The phrase is usually used by people who don't have a clue about programming (e.g. HR personnel and poor managers). Alternatively, it's used by people who simple do not know C++ (and often not C either)." Commented Jan 31, 2011 at 19:14
  • 1
    I would like for someone to argue whether assembly should precede C++. At that point it would be fairly easy to approach assembly, due to the simple concepts and a small set of tools provided, yet working with raw memory and raw memory references should be very helpful when approaching C++, where using nominal references to address both arbitrary memory locations and values confuses the sh* out of most people. Commented Jan 31, 2011 at 23:48
  • 1
    I gave my two CS students a weeklong course in a made-up assembler. basicaly I invented a minimal instruction set computer, and interpreteor. Then they could write (and see run) some very simple routines, complete with timing. Then I added stuff like data caching, and prefetching so they could see how architectural features interact with performance. I suspect an artificial assembler and computer might allow more flexibility and learning efficiency, if the purpose is didactic, rather than the acquistion of something they might use. Commented Feb 1, 2011 at 5:32
  • The one you need now
  • The one you need next
  • The one you need after that

Seriously, I may have learnt BASIC, COBOL, Fortran, Forth, Pascal and Prolog in my time, but I've never particularly needed to use them and I can't really see any way in which they've influenced my use of other languages, except perhaps misapplying paradigms from one in another. It took me ages to unlearn BASIC enough to actually write structured Pascal, a couple of years to stop writing Pascal code in C, and another couple of years to actually grok OOP when I started using Objective-C and Java. On the other hand, since I've been working (almost) exclusively in OO languages I've been able to concentrate on improving my use of OO languages, without trying to make them look like Scheme or PostScript.

  • 4
    You know, I do think there's some value of learning a new language even if you don't need it ... however I agree with the general sentiment that it's often better to learn a language because you think you'd find it useful rather because it's what you think you "should" learn. Commented Nov 3, 2010 at 16:32

It's hard to claim that any sequence is ideal, but I'll lay out a plan that I can justify:

  1. C

    Learning C demands patience and diligence, and will introduce you to the basic ways that computers deal with data and show you almost the widest set of responsibilities that a programmer can accept to deal with such a machine.

  2. Perl

    As an antidote to the rigor required by C, try the unbelievably forgiving Perl. What took a week to write in C you can write in an hour in Perl. It introduces a different kind of delight to be found in programming, and shows how excluding certain concerns and details frees the programmer to focus on different things.

  3. C++, or maybe Java

    Next see how C's focus on low-level and primitive aspects of programming serve as a foundation for raising the abstraction level, noting the trades one makes in efficiency when moving up in abstraction. Explore how to form abstractions that can still retain the efficiencies that matter for your program.

  4. Common Lisp

    This is the reward for the preceding slog. You'll find echoes of what you learned in all the preceding languages, and see how silly so many of the preceding concessions seem when programming in Lisp. C's preprocessor and C++'s templates prepare one to appreciate Lisp's macro system. You'll regain the ease of expression from Perl, the opportunities for low-level optimization from C, the abstraction-building capabilities of C++ or Java, and go well past them all. None of the preceding three — perhaps except Perl's debugger — will have prepared you for the interactive programming experience with a capable REPL ("read, eval, print loop"). Working with an image-based environment — which changes the relationship between your source code and the idea of an "executable program" — will change your whole idea of what it means to build a program.

Beyond those four, exploring other styles of programming, such as functional programming in Haskell, or logic programming in Prolog, makes for more comprehensive understanding of the range of programming — wide knowledge, if you will — but at that point your time is better served by improving your craft — deep knowledge — with any language you know.

Having tasted enough distinct languages, your view will raise to focus on the ideas that transcend any one of them. It's kind of like the difference between learning to drive your father's car and knowing how to drive any car: You may not enjoy having to drive the rental mini-van for a few days, knowing full well the pleasures of driving a favorite sports car, but you'll figure out how to operate it, and will surely coax more out of the poor beast than an amateur.

  • 4
    +1 for C and Common Lisp, but Perl as the second language?? :) Python would serve superbly as a dynamic language while also encouraging good programming habits — like code being very readable for yourself and others, in the weeks, months, or years after the initial writing of the program.
    – limist
    Commented Oct 9, 2010 at 17:50
  • 1
    Regarding the Perl recommendation: that's just me showing my age. Sure, today, Python or Ruby would be close substitutes, but both of them are more dogmatic than Perl, and more biased toward class-as-a-bag-of-methods-style object orientation that a new programmer coming out of C doesn't need yet. I recall that when I learned Perl, I was frighteningly productive immediately, and it wasn't for a long time afterward that I started using its object-oriented facilities. Too often, all that OO focus is just distracting and unnecessary ceremony.
    – seh
    Commented Oct 9, 2010 at 23:27
  • I disagree with your "the trades one makes in efficiency when moving up in abstraction" view. One of the pillars of C++ is that a program using C++'s facilities is never slower than an equivalent C program. For example, using virtual functions in C++ is never slower than simulating virtual functions in C. Commented Nov 2, 2010 at 19:59
  • True, Fred, and that's what I meant: taking advantage of features without thinking through how they work can introduce costs -- costs that you may have avoided before by avoiding the feature capability too, because it would have been prohibitively complicated or just insufficiently idiomatic to implement manually. For instance, complaining that RTTI is "too slow" immediately raises the question of how else you're going to solve the problem.
    – seh
    Commented Nov 2, 2010 at 20:38

1. Smalltalk

Designed originally at least in part as a way for children to use computers to learn. The syntax is simple enough to describe in a paragraph. It, like LOGO, exemplifies the "low barrier to entry, high ceiling" principle.

Smalltalk's a pure OO language in the sense that "everything is an object".

It also teaches many functional techniques, particularly in its Collection API: chaining messages, higher order functions, map, reduce, and so on.

The Squeak community is vibrant and welcoming. You'll also see many discussions of advanced techniques: much like the lisp community, there are many very experienced Smalltalkers on the mailing list willing to share their knowledge. (It doesn't hurt that the Squeak community has a large sub-population of professional educators.) There's also another list for beginners.


A logic programming language that will give you a very different view of computation to just about any other language. Prolog is also highly declarative (but not completely so: the ! or cut operator can have a significant semantic effect on a predicate).

3. Common Lisp

Substitute Scheme here if you like. Common Lisp is supports multiple paradigms, especially OO and functional. It also has a long history (Lisp is the second oldest still-widely-used language: only FORTRAN's older).

4. Haskell

(Caveat: I've only just started learning it.) Probably the purest functional language on the planet. It has a very advanced static type system. Handy intro books exist.

5. C or Delphi

You need to know how computers work. You need to know how memory and CPU actually function. Both of these are traditionally "close to the metal" and have communities that encourage thinking of how their language compiles to assembly.

Why this order?

Smalltalk's very easy to learn, so you can quickly start concentrating on solving problems rather than fighting a compiler ("low barrier to entry"). Once you start programming, there's also no artificial limit on what you can do - "high ceiling".

Once you have a fair idea of how OO works (and - with the proviso that there are MANY different understandings of what "OO" means - it's fair to say that OO dominates the marketplace), moving onto Prolog ensures that you don't start thinking that OO is the only way. Prolog is very different to most languages, and will stretch your mental muscles so you don't start thinking that you know everything.

Common Lisp, in turn, is a grown-up's language. It has a mature standard, it has been leading language design for decades (along with Smalltalk) - all those fancy new features your favourite language just acquired? Chances are the ideas incubated in either Lisp or Smalltalk. Common Lisp's also a bit warty, and you'll find wartiness everywhere you go.

Haskell's fourth on the list because (I'm told: I've only just started learning it) its purity means that some very common things (like I/O) are more difficult to do than in less purely functional languages. The Haskell folks also use some fairly exotic terminologies (words like "catamorphism", say), and you'd probably be better off with some programming experience under your belt before tackling it. (But I must re-iterate, I've only just started learning it! Take this opinion with a pinch of salt!)

And why C/Delphi last? Because unless you work in embedded systems, you really shouldn't have to learn programming thinking that manual memory management's all there is. Garbage collection worked well enough for a 1980s level machine. Your phone is that powerful!

Finally, I haven't put Erlang in the above list even though I really should.

  • 2
    Is this a learning sequence?
    – Wizard79
    Commented Oct 9, 2010 at 12:32
  • It's clearly a sequence (of length 1). Commented Oct 9, 2010 at 14:10
  • Less facetiously: I'll provide one step in the sequence, and you provide the other, and the community will vote on the ordering of said sequence, alright? Commented Oct 9, 2010 at 14:19
  • 3
    @Frank I didn't mean that. I expected full sequences. And I think, the ordering cannot be done by voting.
    – Gulshan
    Commented Oct 9, 2010 at 14:40
  • Please folks: if you're going to downvote, explain why. Commented Oct 9, 2010 at 19:28
  1. Python. An excellent introduction to programming. This will also tie in with any previous exposure to programming.

  2. Scheme. Also an excellent introduction to programming. If dealing with programming novices, you might want to teach this first and Python second. One alternative would be Python first and then Common Lisp instead of Scheme: more work, but more reward.

  3. C. A low-level language that stays close to the silicon. Good for learning what a computer can do. You could substitute some form of assembler language, but C is pretty close to the basics and much easier to work with.

  4. Prolog. Alternately, substitute any declarative-style general-purpose language, if you can find one you like better.

  5. Haskell. For the type system and pure functionality, if nothing else.

  6. There are several candidates here, as it's impossible to cover all the concepts with six languages. Common Lisp is well worth learning, if only for the macro system and object system (which is different from most others I've seen). Forth, Tcl, and APL are all odd languages that have seen some success, and one of those would be good to prevent the student from feeling like he or she has learned it all. Erlang would be good for concurrency.

  • "If dealing with programming novices, you might want to teach this first and Python second." Very much agreed. It's an approach my former university now takes and it seems to work very well.
    – pyvi
    Commented Jan 31, 2011 at 15:34
  • This is a pretty good list, I would probably reverse the order on Haskell and Prolog. If the student was particularly ill-experienced, then I would knock off six, bump the list up and start with something simpler.
    – Orbling
    Commented Feb 1, 2011 at 1:19

Many good answers have been provided, but I did not see anyone offering SQL. It's a completely different animal than most of the others listed and very important to any programmer who has to deal with databases.

You might also want to consider some OS level scripting 'languages', such as Batch, grep, awk, etc. 'Make' may also fall into this category.

One other language you may want to consider (if it isn't completely dead yet) is COBOL. It's sufficiently different from other procedural languages that it deserves some mention. Variations of C, Fortran, Basic, etc. have become so similar that once you are familiar with one, moving to another is not a big issue, but COBOL lacks a lot of the constructs taken for granted in the others. (It's been at least 20 years since I've done anything with COBOL so my observations may no longer be valid concerning this language.)

You might want to mention APL just from a historical standpoint--or let it rest in peace. Your choice.

  • 1
    The reason I didn't suggest SQL is that it isn't a general-purpose language. I'd rather hit the students with something declarative and more general, like Prolog. OS-level scripting languages offer nothing that a more general language like Python or Perl won't. Last I touched COBOL, it offered no concepts that you can't get better in other languages. I like the APL suggestion, not so much for historical value as that it's a very different language. Commented Jan 31, 2011 at 15:40
  • @David Thornley: I agree that SQL is not a general purpose language. SQL does have some interesting logical and set theory concepts as basic operations that don't come up in many other languages, eg. union, join, group by, etc. that are worth noting for anyone who may be dealing with databases.
    – oosterwal
    Commented Jan 31, 2011 at 16:34
  • All things I would like to see taught to a learner, though some of it has a historical feel to it. Learning the script languages is kinda essential, but could be done alongside the others, same for SQL, it is a service language to the primaries. If the student was very strong in maths, then starting with APL might be nice (or perhaps R, as it is a lot easier to read, but can be used similarly).
    – Orbling
    Commented Feb 1, 2011 at 1:22

I would suggest first reading Eric Raymonds "How to become a hacker" since he has some very interesting points about how to get started, including Lisp which has the "code is data and data is code" notion.

For programming I would also suggest Haskell, Prolog, SQL and assembly language (just some).

Regardless of what you want to learn, take the time to learn it properly and write non-trivial amounts of code. It is much like bicycle riding - you cannot learn it from a book.


First> What do you want to do when you start programming? Learning how to be a game programmer is different than learning how to be a database programmer for a business... is different than a web based programmer...

Second> Once you start learning, do you want to start high and work your way down? Or start low and work your way up. Learning C# (high level) is a lot different than learning Assembly (Low level).

A huge choice will depend on what you want to do. Programming a driver will most likely include C or Assembly... Programming a website will be PHP, C#, asp, etc... You won't touch assembly for web programming... etc...

As far as basics... once you decide WHAT you want to do, its easier to pick a language. I, for example, have become a data analyst at a hospital. So my "choice" of languages is SQL/TSQL/DB2 for data access, C# WPF for windows clients, Silverlight for web clients, some RPG/CL for IBM back-end logic...

Personally I stick to a good book + build your own program to practice the language. I like APress and loved reading C# 2008 Illustrated when learning C#. They have other books that encompass basics for the unlearned as well as the expert.


A newcomer only needs one language to start with, after learning the second language, they are already progressing beyond many competing developers. I would learn in the following order:

  • Smalltalk - this is the best OO gets, and simple exposure will open your eyes to the way things should be done. Best to learn OO concepts on.
  • Java or C# - provides a more architectural and planned approach to OO, while introducing statically checked types.
  • Ruby or Python - You can't appreciate it until you've felt Java or C#
  • Erlang - concurrency done in a way that makes it seem easy. It's much better than your OO languages or C can do.
  • Lisp, Haskell, or other functional language - it's a different approach to solving problems.
  • C - Either by building native extensions for Java, or implementing lower level algorithms, this is as close to assembly as someone needs until they write compilers

You may ask "where's C++?" and what about X? Honestly, learning multiple languages does a couple things: it enriches your experience, and it provides a drive to learn more languages. The list of languages I know well (Java, C#, Ruby, C++, Javascript) are all object oriented--but that's primarily because that's what I have to do at work every day. The list of languages I've been exposed to (Smalltalk, Python, Erlang, JESS, C, Assembly [Motorola 6502/6510], Go) have all taught me valuable lessons. I can at least understand what's going on with those languages. There's a lot I haven't explored, but very well may in the future. There's a few markup languages as well: HTML, XSL:FO, XSLT, CSS, XML, SGML that folks need exposure to if they will work with the web in any way.

After learning at least two different languages, I really don't think you should constrain what someone who has a desire to learn decides to pick up next. Learning should be an organic experience, and too much structure in the process creates a group of people who think exactly the same way. A monoculture so to speak.


Most of these answers seem roughly the same so I'm going to offer a different opinion. I've long held the believe that the best first language is Tcl.

Why? For one, it's very easy to learn. There's not much syntax to the language so the student can focus more on the concepts of programming and less on the syntactic peculiarities of a particular language. As of this writing Tcl has exactly 12 rules that govern the entire language (up from eleven for the past couple of decades).

For another, Tcl comes with a fantastic built-in GUI language, so you can get some relatively instant gratification and can learn the basics of event driven programming.

Third, it's extensible. Want to teach about a repeat loop? You can write a command that does a repeat loop so that not only can you learn how to use repeat ... until, you can learn how it is different than a while loop because you actually wrote it yourself.

Also, because it's extensible there's an easy segue into C. You can learn C basics, and learn how to either a) extend Tcl with new commands written in another language, or b) learn how to add a scripting language to a program written in C.

Once you've learned Tcl and C, most other languages lie somewhere between those two extremes and should be relatively easy to pick up. My complete list, with the four I would teach after Tcl and C are:

  1. Tcl
  2. C
  3. Python - for OO concepts, plus it's define-blocks-by-indentation behavior to contrast with other languages.
  4. Ruby - for a different take on OO, plus rails to learn about frameworks
  5. java - it's used everywhere, you need to know it, and need to learn about the JVM
  6. groovy - circle back to dynamic languages

Assembly Language, C, SQL, C#

I know, boring and old-skool. And the entire question ignores the really hard part of programming, which is problem-solving, domain modeling, and algorithm construction. But here's why:

  1. you can't fake your way through assembly language; you either get it or you don't. the compiler won't save you, there's no framework or library overhead, and you can't hide from the machine architecture; it is pure programming (at the beginner add-two-numbers level)

  2. after you've written a few assembly-language programs of more than a few hundred lines, pointers and memory management are no longer mysterious, and you should have started to notice patterns in the code (if, switch, array, loops, etc.). C brings those patterns out into the sunlight and lets them shine. The standard library is useful without being immense, but don't bother with macros/templates/etc. at this stage.

  3. now jump into databases with SQL. Don't go overboard with stored procedures, just get the basics of tables and queries.

  4. after you've written a few C programs of more than a few hundred lines, pointers, structures, and memory management are second nature, and procedural constructs are old friends. You will begin to notice higher-order patterns: these functions always go with this data structure, this part of the code is just like that part of the code except for methods X, Y, and Z, and so on. Add to this your grasp of relational data and now you're ready for an object-oriented language. With a massive framework and generally obtuse documentation. Welcome to the real world! Explore GUIs, write desktop apps, write web sites, write web services, write whatever you like. Go get a job if you're so inclined.

Are you now a programming Jedi? A code ninja? No, now you're merely competent. But you have a solid foundation to stand on to explore the shiny new fun stuff.


You need fundamentals:

  1. Machine code
  2. Assembly language
  3. C
  4. Lisp

After that it probably doesn't matter.


OK, this is the last day for bounty. And I am adding my answer. My suggested sequence-

C, C++, JAVA/C#, Python/Ruby, Any other language(Assembly/Lisp/Prolog etc)

  • I don't think the first language has to be the easiest one. Rather I think it should give the overall idea of how computer works keeping some abstraction.
  • Transition from C to C++ will be easier. There will be OOP, the most used paradigm these days.
  • Transition from C++ to C#/Java will be easier. I prefer C# because it incorporates many paradigms like functional programming.
  • When someone now come to dynamic languages like Python or Ruby, there will be a "WoW". It will be easier to feel the beauty of dynamic typing. But learning dynamic languages first and static ones later will cause, "Oh! Why I have to add all these?"
  • Now, the most used paradigms and languages are almost done. So, explore whatever you want. From Assembly to Lisp, Prolog or Haskell. And discover newer contexts ans features of various programming languages.
  • Here C is just for starting.
    – Gulshan
    Commented Nov 3, 2010 at 9:41
  • preference of C# over java depends on many factors I would say both are almost equal. Commented Mar 16, 2011 at 13:00

Scheme, C, C++

I will be biased and use the model my university currently uses for its core Computer Science curriculum. I was against it during my first year but in my later years I am grateful for it. The model is based on not requiring any programming experience but requiring the ability to learn.

  1. Scheme
    We are you are first learning programming, the less magic, the better. The teaching language of Scheme presents a clear and reasonable definition of a language, a really small set of axioms (the "magic") that you can build and expand on. Anyone who can understand functions in math can trace and reason Scheme programs. Starting with Scheme provides a clean yet powerful way to think about computation without worrying about the language specific details.

  2. C
    Moving from Scheme to C is a drastic one but allows you learn about the very important mapping of high level languages to low level languages. Learning the memory model (pointers, heap, stack etc.) and how programs are compiled and run, how pointers, stack and the heap work are essential skills. Through this low level understanding you can begin to analyze programs on a higher level (Big O). You can begin rolling your own abstract data types, playing with different implementations (say a simple hash table vs. a binary tree for a set).

  3. C++
    Through learning C and Scheme we begin to see different paradigms of programming languages and how they can apply to different problems. Now you can approach the scariest aspects of programming: choice and trade offs. Programming language choice can affect performance, readability, maintainability, robustness etc. For solving problems bigger than things you can hold in your head, this choice is great but also dangerous. C++ tries to make as few choices for the programmer as possible. Through learning C++ you will learn how to make these trade offs and choices yourself to solve your problems.

You might not use any of these languages in industry or ever touch them again, but the process of learning them helps you understand other languages you will use. Another aspect is you learn the tools around a specific language. Running gcc through the command line, learning Vim, stepping through a program using GDB, creating Make files, checking in code using SVN, writing shell scripts to automate testing etc.

Mind you the core curriculum also has other courses (computer architecture, data structures and algorithms, compilers, operating systems etc.). So just merely learning these languages isn't enough to be proficient at programming.


Going from a basic language to a high level one is the way to go. That way you still have an idea what's happening in the back.

  • C - Pointers & memory management
  • C++ - OO basics and still very popular
  • Java/C# - Most popular languages
  • Some basic assembly
  • Functional language - E.g. Haskell
  • Script language - E.g. Python
  1. Python. To get stuff done, do ordinary programming. Procedural, OO and (to an extent) functional.

  2. Regular Expressions. They're in the Python library, but it's a separate DSL.

  3. Shell (BASH or whatever). The "&", "|", ";" operators for combining processes are critical and unpleasant in Python.

  4. SQL. This is -- for now -- the lingua franca for data access.

  5. XHTML. This is -- for now -- the lingua franca for data presentation.

  6. CSS.

Maybe C if it became necessary.

  • You seem to have left out the "profound enlightenment" stage. Is that number 7?
    – Mark C
    Commented Jan 31, 2011 at 21:53
  • @Mark C: just trying to cover "most of the heavily used languages and paradigms today". In my experience, these "other" or DSL's are perhaps more heavily used than programming languages. I'm not sure this leads to profound enlightenment -- just exposure to a lot of languages that are actually used.
    – S.Lott
    Commented Jan 31, 2011 at 21:58
  • You're right, I see he did say that, then I noticed he also said "or paradigms". It was just in good humor.
    – Mark C
    Commented Jan 31, 2011 at 22:10
  • @Mark C: But SQL and CSS are the "other paradigms" that are the most interesting. Indeed Regular Expressions is a paradigm that causes many questions on Stack Overflow.
    – S.Lott
    Commented Jan 31, 2011 at 22:15

Start close to the metal:

  1. Assembler
  2. C
  3. C++
  4. C#
  5. Lisp
  6. Python or Ruby

Now the problem with such a broad approach is that no one can become even remotely capable in these languages without years of study.

  1. Assembler: 3 months
  2. C: 6 months
  3. C++: 2 years
  4. C#: 6 months
  5. Lisp: 3 months
  6. Python/Ruby: 3 months

Unless your intent is to teach them "Hello world", which should take about a month for all 6.


Why not go straight in and learn VB or C#. Both in my opinion are complete languages ranging from beginner to advance, imho.

  • 4
    Because that's not any breadth, and therefore not an answer to the question. Moreover, if you think one (or both) of those covers everything you should learn, you yourself need to learn more languages. Commented Jan 31, 2011 at 15:15

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