# Criteria for selecting language for first programming course

As a university-level CS educator, the issue of which programming language to teach in the first programming course often comes up for discussion. There are thousands of languages to choose between, and lots of religious fever (or fevour) supporting one language camp over another. All of this subjective bias surrounding each programming language makes it very difficult for an educator to choose one.

My question is:

What objective criteria can an educator use to select a programming language to use as the basis for a first year university programming course? What is the basis for these criteria?

Note: I do not want to see a list of programming languages and why they are the best one to use. The question isn't about the best language, it is about the criteria for selecting a language. Answers may however be use programming languages to illustrate particular points.

This question was inspired by another question which was deemed off-topic: https://cs.stackexchange.com/questions/1946/criteria-for-choosing-a-first-programming-language.

• Opened meta thread about whether this question is on- or off-topic: meta.cs.stackexchange.com/questions/362/… – Dave Clarke May 20 '12 at 19:23
• <Grabs popcorn> To paraphrase Otto Neugebauer: No first programming language known to man is capable of ruining everyone. – JeffE May 21 '12 at 8:48
• @Raphael: I think Dijkstra's response would likely be "Every first programming language known to man is capable of ruining everyone." – JeffE May 22 '12 at 7:34
• @edA-qamort-ora-y, yes, they should be exposed to several programming paradigms. No, that can not be done in the first course. – vonbrand Feb 25 '13 at 18:04
• We had SML simply because it's unlikely that any student knows that language before hand. This balanced every student more or less to the same level to start the course. – Markus Malkusch May 4 '16 at 22:32

My main concern is universality, in the sense that learning this programming language should make the student able to handle most programming languages.

As much as I regret it, this criterion excludes pure functional languages. It also applies to the course that should not use exotic features of the language.

... but this is only common sense.

• With monads as in Haskell, it's arguable that this criteria is not applicable to pure functional languages any more. – Dave Clarke May 20 '12 at 20:39
• @DaveClarke: monads are a very nice way of doing non-functional stuff. But isn't it too risky to first learn this stuff with the monad overhead instead of directly? (Maybe it isn't, I don't know!) – jmad May 20 '12 at 20:45
• @jdam: You're probably right. The problem isn't in the monads, per se, but in the generality and the difficulty in presenting good error messages to the programmer. The Haskell variant Helium addresses these issues and has been successfully used with first year students. – Dave Clarke May 20 '12 at 20:47
• @DaveClarke: wow I didn't heard of that. That's very cool! Unfortunately while that's very useful for learning Haskell, that does not address the problem that it may not help learning other languages. – jmad May 20 '12 at 20:59
• @Ben: my feeling is that manual memory management is something that is nowadays specific to some languages (and that you learn in these specific cases) more than a fundamental thing of programming. If you don't agree with that then I guess it does point to C (or C++). – jmad May 21 '12 at 6:20

I think simplicity and ease of learning is one of the main criteria. In an introductory course on programming we would like to avoid unnecessary programming hurdles and focus as much as possible on the principles of programming and algorithmic problem solving. The first year students often lack the ability to think algorithmicly about problems so the course is also about teaching algorithmic thinking.

Another criteria is usefulness of the language in the industry. We would not want to teach a language that is of no use in the industry. A clear majority of the students are going to work in the industry so one should have an eye towards what is being used (and will be used when students graduate) in the industry.

The third criteria would be the courses the students are going to take in later years. The courses, particularly the required courses, are not designed on themselves but in coordination with other courses.

The last one I can think of right now is the same as jmad's answer, the language should provide ease in learning other important languages. It should be rich enough and picking up the later important languages would be easy (here, important means important from the perspective of the students).

I think many universities have shifted their main introduction to programming course from Java/C++/C to Python although they might provide introduction to programming in other languages from time to time (often for non-computer science majors, e.g. C for electrical engineering majors) though they may show flexibility if the instructor wants to experiment with teaching another language once in a while.

• I wouldn't rate usefulness in industry terribly highly in an introductory programming course. A successful programmer out in the wild will probably have to learn a number of languages during their career, some of them "on the job", so the ability to pick up and learn new languages is a key skill that needs to be taught. Consequently I wouldn't expect the first language to be taught in a university-length course to necessarily be their strongest when they graduate. – Ben May 20 '12 at 23:31
• @Ben: Usefulness in the industry is specially important if the students are not going to major in CS. Where I come from many people go to work on biology or other sciences and, given how they wont have time to learn many languages, learning something common in their ecosystem like Python will likely be more useful then ML, Java or C. – hugomg May 21 '12 at 15:29
• Speaking as someone from industry (one particular industry, not necessarily representative), I don't think industry relevance is a factor when it comes to future tier-1 programmers. Exposure to multiple paradigms makes better programmers, even if in my domain (embedded programming) we mostly use C. Particulars of a language can be learned in a manual, general concepts are better taught in school. For incidental programmers (e.g. scientists), the priorities are different — but focusing too much on Fortran can make people ignore Numpy when that's what they should be using. – Gilles May 21 '12 at 22:13

Since we are talking about the first programming course in a Computer Science programme, I'd say the most important aspect would be what fundamental concepts of CS it will teach your students. Since there is no language that can teach all concepts at once, you need to consider what concepts will be needed further on.

I don't agree with @Kaveh's notion that industry relevance is important; it may be a bonus, but it is of minor importance here. With a solid foundation in CS principles, learning an "industrial" language in later courses will be relatively easy.

As a side note, regardless of the language chosen to be the first, it is important to subject your students to another, radically different, language as soon as possible.

• Industry relevance can be considered secondary but I don't think it is a minor issue. Since this is an introduction to programming course I don't see why one would want to teach all concepts in it, often there is a second course in programming and another course on the topic of programming language where various languages are discussed, and many other courses concentrated on specific application areas, e.g. programming for web, etc. – Kaveh May 20 '12 at 23:06
• @Kaveh: That sounds like the curriculum of a technical university to me. – Raphael May 20 '12 at 23:19
• "it is important to subject your students to another, radically different, language as soon as possible." -- absolutely correct. We set the freshers who think they can program straight by introducing functional programming first: almost all are new to this paradigm, and the more C(++) you have been exposed to the harder it apparently is. – Raphael May 20 '12 at 23:20
• @Kaveh: Languages designed for Getting Things Done In The Real World are not necessarily optimal for teaching concepts or developing skills. The goals are very different. – JeffE May 21 '12 at 8:35
• @Kaveh: I never wrote that knowledge of languages used in industry is unimportant. What I mean is that given a solid first programming language, later courses will have no problem teaching students something about what they'll actually do when they graduate. Having been part of teaching several introductory courses myself (as a TA), I'd say the skills you learn there are nothing like the ones needed in industry (there's too little time for that). If this is the case, then I find it better to give them solid concepts so that they can become better programmers, not just $LANGUAGE-programmers. – evilcandybag May 21 '12 at 10:47 As an introductory remark, consider the possibility of presenting more than one language (in one course). In my first term we where shown both SML and Java. The contrast had its very own and important message: choose the right tool for the job. But now for criteria, in arbitrary order. Difficulty to learn is a subjective issue, but important: you don't want your student to waste time on learning the language, but on doing things with it. Arguably, dynamic languages like Ruby may win on this front: you can feed them anything, and there are excellent "dummy" tutorials on the web. If I remember correctly, there are also studies that show that students who have not programmed before achieve better results with functional languages than with others. Richness: the language(s) must be rich enough for all the concepts you want to teach. For example, if you want to discuss higher-order functions, you need a language where functions are values, such as functional languages or Scala. Scalability: Chances are your students won't learn more languages on their own than those you show them. So you want your chosen language(s) to scale over the course of their studies: they need to write your pet exercises now, but may also attack a middle-sized project later. Java and languages with similar ecosphere are good choices here. Tool support: This is related to scalability. If you expect/want your students to be productive with the language, then good IDEs, build managers and libraries have to exist. Interactive shells (Ruby, Scala) are also nice thing, especially for starters. Tools have to work on all major platforms, too. Documentation: You probably don't want to actually teach the language but have students teach themselves with your (abstract) guidance. Therefore, good documentation is important. Arguable, the more popular and established a language is, the better the documentation. For example, Scala's documentation is quite poor (but improving). Tools like Hoogle are a plus. Availability: There are actually people who teach using Matlab or Visual C++. Consider that not everybody might have a license or a machine that can run the necessary programs. You should probably favor free languages that run on a variety of platforms. Cleanness: You probably want to shape the way your students think. The messier the language, the messier they will think; I would never propose PHP in a course. Dynamic languages in general have disadvantages here: they allow, sometimes even promote, bad habits. Which criteria are more important for you than others also depends on what you want to teach. Is this literally a programming course? Is it an algorithms and data structures course? Is it a course that introduces concepts of programming languages in different paradigms? Is it a course about software development in the big? • For example, if you want to discuss higher-order functions, you need a language where functions are values, such as functional languages or Scala. ...or C or Pascal, which have both had function pointers pretty much forever. Practically the only (mainstream) language this criterion actually shuts out is Java. – Mason Wheeler May 23 '12 at 5:24 • Trying to teach newbies a jumble of different syntaxes and underlying concepts is just brain-scrambling. – vonbrand Feb 25 '13 at 18:24 I'll throw in my own two cents although I believe this subject is a bottomless pit. Don't get me wrong, I think it's a fascinating question, but probably not one we will solve here to everybody's satisfaction. In a nutshell, I'd say that the language should do what you want it to do, in a simple and unambiguous a way as possible, and not more. My own experience comes from tutoring several generations of first and second year students with the Oberon programming language. People who know this language will recognize its influence in my opinions. Note that this language was used to teach "Algorithms and Data Structures". At the time (back then), functional programming and object-oriented design were taught in separate courses as of second year. Important: Before going into the specifics of any language, however, I would like to emphasize that the most important thing is to be absolutely clear, to yourself and to your students, about what the goals of your course are. Are you teaching programming per se? Or algorithms and data structures? Or software engineering? Before choosing a language, it's worth it to think a moment about where you're going with it. Differences at this level (goals) is what probably, in my opinion, leads to most disagreements on this topic. The points I consider important may overlap with several things that have already been said, but I believe most end up being subsets of one of the following four: • Simplicity: The students are usually there to be taught programming, algorithms and data structures, and not the features and intricacies of any specific programming language. Wirth used the Einstein quote "Make it as simple as possible, but not simpler" as a guiding principle in the design of Oberon, and there are several other languages out there that do it just as well. Your programming language of choice should be able to implement all the concepts required in your lecture, but should do this with the smallest possible set of features/details. The programming language is usually just the tool, not the goal. • Unambiguity: A close sibling of simplicity, there should be one construct for each concept, with as little overlap as possible. Think of it as there being only one "right" way of implementing every concept. Three different types of loops that semantically all do the same thing? Or fifteen different ways to increment a variable? Not good. This also makes correcting homework or generally just understanding your students' code a lot easier. Your teaching assistants will appreciate it. • Portability: Students will go to class with Linux, Windows and OSX machines, and the programming environment should be as similar (identical) as possible under all three. The results of any program should also be identical. This is another point that the teaching assistants, responsible for marking homework and dealing with questions/problems, will greatly appreciate. • Industry preference: Seriously, we should start worrying about this only if "Industry" itself ever decides what programming language it likes best. Since the invention of computers this has been a constantly-moving target. For the moment, if your students really learn how to program, then it won't be language-dependent. There are, however, some areas where industry manages to agree on a standard, e.g. VHDL for circuit design or SQL for database queries, so this is still a valid point. Again, how a language fits this list is strongly dependent on what it is you're trying to teach! • There's actually a split in circuit design between VHDL and Verilog. – avakar May 21 '12 at 9:12 • @avakar: Aw, crap. I'll fix this in my answer, thanks for pointing it out! – Pedro May 21 '12 at 9:36 • Yikes, read this and thought it one of my lecturers. +1 for Oberon, so long as the use lowercase keywords switch is automatically enabled; so painful to write WHILE expr DO stmts END etc. – Callum Rogers May 21 '12 at 10:19 • +1 for "what the goals of your course are?" and an additional note, one of the most common goal even if it isn't spelled is to give the basics for other things (courses and internships) which have programming as prerequisite. – AProgrammer May 21 '12 at 11:59 • One important point (at least today) is that it allow students to build visually attractive programs soon and painlessly. They are exposed to so many graphics-intensive applications and games that they naturally think that that is how computers are supposed to interact with people. – vonbrand Feb 25 '13 at 18:08 • Developing algorithmic thinking to solve problems as the main goal: One bad thing about using an object-oriented paradigm in the first course is, that getting new learners into things like inheritance, polymorphism, etc, distracts them from the above-mentioned main goal. In fact, introduction of any secondary considerations beside this core goal, like software engineering, portability, industry usefulness etc, are counter-productive, for the reason stated. • Not an Object-Oriented Language: Nowadays, most universities start teaching programming right with an object-oriented language. I think this is a mistake. There are things in the world that can be truly understood only in contrast to its opposite. Without being exposed to a procedural paradigm of programming (data and functions as two separate aspects of program), the basic idea of object-orientation (data and behavior viewed as intrinsically tied together) can be missed by many. And because, object-oriented programming is so important, missing its basic idea is not a small thing. Besides, since most probably in more senior courses CS students will program mainly in OO, they need to be exposed to the procedural side of things as well. So, at the end, I would go for a procedural language, avoiding advanced features, focusing on developing algorithmic thinking. But, by avoiding advanced features I don't mean avoiding challenging problems. I mean, that even challenging problems, students should be required to solve it using first principles, simple tools. • You can quite easily start with a subset of, say, Java first to show procedural style. Then you open up Pandora's box and show how the same stuff looks like with OOP. – Raphael May 21 '12 at 8:10 • @Raphael: It is impossible to avoid public static void main() in Java, which has to be within the context of some class. This makes Java less than ideal as a first language, though of course the hurdle isn't too great. – Dave Clarke May 21 '12 at 12:22 • A good IDE can defer public static void main() for a very long time. BlueJ is a good example of an IDE that lets students write programs without a single main anywhere in it. – Barry Brown May 28 '12 at 5:30 • The problem with OOP is that for the range of toy problems covered in the first year or so of programming it just gets in the way, without any clear advantage. OOP becomes important (and is appreciated) when your programs are a thousand lines or so. "Java without OOP" is horrible, lots of completely opaque stuff that "has to be written this way" goes against people learning, not parroting. – vonbrand Feb 25 '13 at 18:12 So, I'll dispense with my knee-jerk reaction immediately, which is that everyone should learn programming via SICP because Lisp is the Right Thing. There have been many good criteria offered already for selecting a language... simplicity and portability being among the most important. However, I also think it's vital for students new to programming not to get the wrong idea (or have no idea) about what's happening behind the scenes with modern languages. Although some of these other posts have offered excellent criteria, I'd like to use a particular language to illustrate what 'meeting the criteria' looks like. Some of these concerns have been addressed (far better than I could attempt to) in Joel Spolsky's blog post, The Perils of JavaSchools. Choosing languages like Java or Python closes over two of the harder (and most vital) concepts in CS; namely, pointers and recursion. Of course, teaching an intro course in C is going to be incredibly dense, while also likely missing many important concepts related to recursion. Likewise, a course taught in Lisp will have to address pointers under the covers, as car and cdr imply important concepts related to linked-lists, while letting the language handle the details. Basically, what I'm getting at, is that students need to understand the fundamentals of data structures and algorithms, as well as practical implementation. I also disagree with the suggestion not to use an object-oriented language. I think the utility of object-oriented languages to modeling the real world is a positive asset to new programmers, as long as the impedance mismatch is made clear, and that object-oriented languages are one paradigm among many. I would propose that Ruby (suggested as a possibility by another post as well) exemplifies many qualities to look for in a language to use for an intro to programming course. I'll justify this assertion momentarily, but first I want to comment on one trend that disturbs me in intro CS courses. I work at a university which, like many schools, has recently switched to using Python for its intro courses. I firmly believe that Python is the new BASIC, and the tendency of the language is to choose newb-friendliness over power and expressiveness, as I recently argued elsewhere. This is a disservice, and we need to think about the programmers they will become, not the newbs they are at the moment. Anyhow, justifying Ruby as an introductory language... • Ruby, although not tail-call optimized, does recursion rather well. So there's that. • Ruby is multi-paradigm. Although it is a pure object-oriented language, it also embraces functional programming, as well as having some imperative, C-derived training wheels tacked on. Compare this to Python, which is a procedural language with some tacked-on OO (although the bolts are showing), and some functional elements (which Python's BDFL has repeatedly tried to excise). • CRuby (aka MRI or 'Ruby Classic') is written, and extended, in C. You can teach students about pointers, memory management, and the dread god malloc() by teaching them to extend the language in C. • Even thought it's a high-level, dynamic language, you can teach a lot about data structures, types, etc.; there are libraries (gems) for anything you could imagine, from red-black trees to doing odd things with duck-typing. Anyhow, there's no substitute for learning many languages, from many paradigms, whether you use them professionally or not. Basically, I think everyone should understand, if not use, C and Lisp. Ruby is the best compromise I can think of for an introductory semester. Anyhow... that's my US$.02. I'm not trying to convince you to use Ruby, mind you... just using it as an exemplar of qualities to look for in a language for teaching an intro course.

• "I firmly believe that Python is the new BASIC" -- copy that. "two of the harder (and most vital) concepts in CS; namely, pointers and recursion" -- I have never learned a language that deals with pointers explicitly, and I have never missed anything. When I learned how compilers work, pointers where explained quickly enough. – Raphael May 21 '12 at 8:08
• I agree that a multi-paradigm language has its charme (although teaching two to threee "pure" languages might be better), but I won't choose Ruby for that reason. Other languages to a better job, imho, in particular with respect to the basic library. Scala, for example, has a whole library of immutable collections. – Raphael May 21 '12 at 8:13
• I also believe that Python is the new BASIC. But why is that an argument against Python? – JeffE May 21 '12 at 8:44
• @Raphael, pointers are hard only when you start with C which somewhat forces you to be exposed to pointers when too many things aren't settled down and where they have a confusing relationship with arrays. Pointers weren't hard for me when I self-taught myself Pascal. Pointers weren't hard for people in my class who were taught them in Algol 68 (they are named references there, but they are pointers by another name, just like in Java; what is hard in Algol 68 is the automatic dereference rules), pointers isn't even hard with C++ if you don't start by teaching the C subset. – AProgrammer May 21 '12 at 12:11
• @DaveClarke: It indents with whitespace, which more than makes up for those. – Raphael May 21 '12 at 12:13

When choosing a first programming language, there are many issues that need to be considered. Many of these have been considered in the answers above. I include 3 more as these were a part of my answer to the closed question ( https://cs.stackexchange.com/questions/1946/criteria-for-choosing-a-first-programming-language ) that originally inspired this question. I've copied my answer here (and modified it) based on the current policy of deleting closed questions.

Here are 3 points to consider, using a few programming languages as examples.

## Programming in the large vs programming in the small

When first learning to program, one needs to learn how to program in the small, before moving on to learn mechanisms to help programming in the large.

By programming in the small, I mean writing programs with fewer than 100 lines. These programs will involve algorithms that manipulate simple data structures, have simple control flow, and will solve simple problems. They will in general not be considered as applications.

By programming in the large, I mean writing large programs built from many components/classes, building on top of an API, with a GUI, a database, possibly in a client-server configuration.

The things a programmer needs to think about when programming in the small are very different from when programming in the large. Programming in the large requires the programmer to think about modularity, good interfaces, good design, reusability, and many other issues. Modern programming languages provide many constructs to help program in the large. These constructs include classes, modules, interfaces, information hiding, etc. When programming in the small, these issues are much less important.

A programming language such as C++ has many features to help programming in the large, but it is more difficult to sit down and start writing a very simple program. Java is similar.

On the other hand, a language like Python, Ruby, Scheme or Haskell makes it much easier to directly write a program.

## High-level vs low-level

Languages like C++ and C are rather lower-level language. They enable the programmer to manipulate references into memory directly. Although, this allows one to write very efficient code, the low level details can be difficult for a first programmer to learn the language. Some would argue that these low level details get in the way of writing the logic to solve the problem.

A higher-level language like Python makes it easier to express concepts more directly in terms of the problem domain.

## Staticallly Typed vs Dynamically Typed

C++, Haskell, Java and many more languages are statically typed. This means that the compiler automatically finds places where potential errors occur based on the expected types of values at each location in the code. There is a bit of a religious war about whether static typing is a good thing or not, but I will steer clear of that one. One problem with static typing for new programmers is that the error messages reported by the compiler are often difficult to understand. This is especially the case with C++ templates and Haskell programs in general.

Python, Ruby and Scheme are dynamically typed. This means that errors are detected while the program is running. One can argue that this is too late to detect the errors (but one can also use testing to avoid such errors). Again, avoiding the religious argument, the advantage of the kind of errors that one encounters when writing simple programs in a dynamically typed programming language are of the sort this object does not know how to do this operation. In the context of a small program, these errors are easy to understand and track down.

Languages like C have weak typing, meaning that although the compiler helps out with some errors, the run-time fails to trap others that occur, such as invalid memory accesses. As a result, the error message returned to the programmer is akin to "Program crashed". A dynamically typed language would trap these errors and convert them into a more comprehensible error message.

## Others

For other languages different considerations may come into play, such as the support provided by the programming environment, the available APIs, quality of books and online tutorials, etc.

• Heartily agree. – vonbrand Feb 25 '13 at 18:26
• I also have my own preferences about the "static vs dynamic types" contention. However, in a general CS program, as long as both are taught as some point, I believe the order does not matter so much. If only one side of the coin is presented, however, that's a big issue for me. – chi May 4 '16 at 18:40

I would say, that the language (under some limitations) does not matter as much, as what you do with the language. You can learn about the same about software development, algorithms, object oriented programming, computer hardware and so forth in most languages. The key is, to develop something interesting, which utilizes all of these concepts.

Fascinating question; I like your emphasis on objective criteria. We want freshmen to learn:

programming concepts: The first programming language must support: function calls, iteration, recursion

fundamental ideas: The first programming language must support arrays (for the first steps in a gentle introduction to how how memory really works and how pointers work)

practical programming skills: how to use the debugger, how to use the profiler, how to solve large problems (a high level language), how to put together large systems, how to break down problems (decomposition of problems), how to avoid writing complicated code, how to communicate to humans the intent behind an (often cryptic) series of executable statements.

the fact that pre-written libraries exist for things like sort(), and how to use them -- i.e., the fact that it's not necessary to write everything from scratch.

Other criteria for a first language:

interpreted (quick feedback helps the learning process).

an interactive environment which speeds learning, testing, and debugging.

high-quality source code is available for students to read in that language

"easy to read", "syntax that approaches natural language" (to make it easier to read and grade the SourceCode)

portable (runs on Mac OS, Windows, Unix). At least one free software implementation of the language.

fast to teach, "few gotchas" -- for example, "[I]t may be faster to first teach beginners Python and then Java, rather than Java as a first OOPL." -- "Comparison of Object-Oriented Progamming Languages" and TelescopeRule

Matthias Felleisen developed a programming language with error messages tailored to a beginner audience. He emphasizes that the particular language choice is not as important as teaching a good design methodology. In fact, he sees the first CS course as a Liberal Arts class, teaching critical thinking, problem solving, and attention to detail.

criteria for a second programming language

Stuff we want students to learn, but perhaps this can wait for the second programming language:

a "relevant" language that is "not too esoteric"; something "popular in the industry"

Complexity theory: how to recognize tasks that are impossible with current technology.

higher-level stuff: how to pick the right tool for the job, how to use a compiler, structures, object-oriented programming, functional programming, logic programming, compiler design, composing and manipulating functions (in the Lisp/ML sense), concurrent and distributed programming,

low-level stuff: pointer arithmetic, computer architecture. memory management, stack frames, assembly programming, machine architecture, device drivers and operating system design (so the machine won't "seem like some frightening black box they can't penetrate")

EDIT: I find it disappointing that posting a summary of something that I wrote, in collaboration with many others, "may not be a legal post".

So I'm adding a more formal citation to my previous informal link, attempting to comply with fair use and other wiki copyright issues.

This answer is a summary of Freshman's First Language (Anon 2011) at the Portland Pattern Repository.

(Anon 2011) Many anonymous and various other authors. "Freshmans First Language". Portland Pattern Repository. September 27, 2011. http://c2.com/cgi/wiki?FreshmansFirstLanguage.

• Have you checked with the original authors whether you are allowed to reproduce their content? The source is a corporate website and I could not find a declaration that the content was free, so this may not be a legal post! – Raphael May 27 '12 at 15:52
• @Raphael The source is a wiki (so potentially has many different authors). If the author (any co-author) of this material does not want it included here, he should send a DMCA takedown notice to the [contact address listed at the bottom of this page](mailto:team+cs@stackexchange.com). Furthermore, the information is not covered by copyright, only the way it is expressed. A bit of refactoring and RemovingWordsRunTogetherWikiWikiStyle would improve this answer and remove any risk of copyright violation. – Gilles May 27 '12 at 16:10
• + Good answer, but I have one nit to pick - profilers. There is no theory behind them - just "common knowledge". It's not generally appreciated among academics that there are many problems they don't find, and another technique does. Check this link. – Mike Dunlavey Dec 5 '13 at 17:27

My first programming language was a toy assembly language. The second was Fortran. In between, I was taught an "algorithms" notation, which was roughly Algol 60. I turned out quite ok. In fact, I think what I was taught was pretty much perfect.

When I first looked at functional programming, in research papers though not in an implemented language, I went "wow, this is completely different. It is quite mathematical!" Most people that get taught functional programming still have the same kind of "wow" experience. I think that is great.

I think imperative programming and functional programming are two completely different ways of looking at the world. We would disservice to our students if we rob them of that diverse experience.

The best first programming language should be something that is as simple as possible and as clear as possible, so that the students are able to focus on how to think clearly. Unfortunately, the simplicity and clarity of assembly, Fortran and Algol 60 are unmatched by most modern day programming languages. Haskell is a good exception. But, Haskell would make my ideal second programming language, not the first. Eiffel or Oberon could perhaps fit the bill.

At The North Carolina School of Science and Mathematics, we have introduced students to Python since 2004. We use it to teach procedural programming, because we think that the ability to write short, correct procedures is vital to progressing later with heavier tools, including OO programming.

We like it for these reasons.

1. Python is not a free-format language. It forces the students to write their code in blocks using indentation. (As a technical note, we use the vim text editor and put [set tabstop=4 set et] in the .vimrc to eliminate annoying problems and for code indentation to be noticeable but not to cause ugly excessive horizontal drift). Our students get used to seeing the hierarchical structure of programs delimited by whitespace. As a result, their formatting habits tend to be very good as they program in other languages.

2. Python's syntactical simplcity makes it beginner-friendly. Simple programs can be written with a minimum of arcane keywords and magical incantations. We want student who wouldn't ordinarily think of programming to try it. Note the lovely simplicity of Python's hello.py; it is crystal-clear what is happening.

3. Python is dynamically typed and duck typed. This makes introducing variables easy. I tell my students that variables are just labels. They point at objects. You send a message to an object using the variable name, much as someone sends a message to you by calling you on the phone.

4. Python is a tool that ambitious students won't outgrow. It has sophisticated libraries that do hosts of useful stuff. It is a powerful creative tool that is accessible to beginners.

5. Python is free and runs on all major platforms. Our school is a heterogeneous OS environment with all sorts of machines. We do not have to worry about headaches such as compatibility issues. It will run on just about any computer.

6. Python has excellent documentation. We encourage our students to explore, tinker, and color outside of the lines. They learn about using Python documentation early and often wind up exploring cool stuff outside of class.

We have been very pleased with Python.

• Welcome! This is a nice case study, but does little to answer the question after selection criteria, imho. Reading your items backwards can kind-of do that, but I am not sure whether you intended it that way. – Raphael Aug 11 '12 at 23:41
• No particular order was intended. It's an "and". – ncmathsadist Aug 11 '12 at 23:44

TL;DR: There's no way to objectively answer this because there's no objective basis for the criteria behind it. It's as arbitrary as trying to debate if blue is, objectively, a "better" color than red, or if vanilla ice cream is objectively "tastier" than chocolate.

I think there're some wonderful posts already present, but I'll add my own 2 cents.

What objective criteria can an educator use to select a programming language to use as the basis for a first year university programming course?

This question is akin to asking if there's a way to objectively choose the first ice cream flavor someone else should try when visiting an ice cream place for the first time. No, there is no objective way to choose something that's inherently subjective.

Why? Because even when we look at the reasonable criteria mentioned in Pedro's answer, everyone will still have a subjective view of how each factor "holds up" against the views of someone else.

For example, is Ruby objectively "simpler" than Python? Simpler in what sense? With respect to what? What does "simpler" mean for you? Does it mean "fewer lines of code"? Does it mean "easier to read and understand"? What about others? Why should anyone agree with any particular selection here? I don't think we can answer that question objectively.

This leads to the next question.

What is the basis for these criteria?

As reasonable as some criteria might be, I think this is more grounded on subjective preference than anything else. For example, there's no reason why I should just accept Pedro's criteria of simplicity, unambiguity, portability and industry preference -regardless of how reasonable some might think it to be. In fact, industry preference is subjective by definition and would simply lead to a vicious circle. (Everyone gets trained in it, so everyone uses it in industry, which is why everyone gets trained in it, ...)

For example, why not

• Efficiency: Execution times and memory footprint can actually be measured.
• Size: The fewest number of reserved words possible would make the language easier to learn.
• Feature Set: A wider set of supported features (e.g. lambdas, generics, object-orientation, operator overloading, etc.) would allow you to teach more concepts without having to switch languages and go back to square one.
• Interoperability: A language that makes it easy to work with other languages and native systems (e.g. Win32 API from C# or Python, etc) could be raised as a better long-term time investment, etc.

The point is that, while I could come up with a different set of evaluation criteria and still be considered reasonable, we can't claim it's objectively superior/inferior to someone else's.

In conclusion, there's no objective basis for the criteria. It's as arbitrary as trying to debate if blue is, objectively, a "better" color than red, or if vanilla ice cream is objectively tastier than chocolate.

That is not to say that you can't have good reasons to justify your preferences, but at the end of the day, they're just your preferences.