Criteria for selecting language for first programming course

Question

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.

Answer 1

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!

Answer 2

• 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.

Answer 3

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.

Answer 4

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?

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

(migrated answer from https://cs.stackexchange.com/questions/1946/criteria-for-choosing-a-first-programming-language/)

Answer 13

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.

Answer 14

Criteria for selecting a programming language for teaching a first course.

Simplicity
    One should be able to express the solutions to problems,
    by slowly introducing new concepts.
Necessity
    without over specifying and without extraneous boilerplate,
    nothing required that isn’t part of the solution.
Portability
    The result of evaluating must be bit for bit identical, everywhere.
Accessibility
    The number of unique implementations should be a nonnegative integer
    less than one.

Criteria for selecting a programming language for assignments

Any.
The solution must be correct, and verifiable, somehow.
The TA/grader may have a lot to learn--no harm in that.

Criteria for selecting a programming language for teaching later courses

Exactly the same as above.
Pseudo code is always preferable, unless compilation is required.
If compilation is required, pick a language for the concepts taught.
Change languages as needed—to suit the material.

Criteria to avoid

Whatever students claim to want.
Whatever industry claims to want.
.Whatever makes it easier to grade assignments.

Criteria for selecting a programming language to teach as a class

Whatever you like.
Whatever you think is useful to know.
Whatever a sufficient number of people want to learn.