Making the case for O'Caml as an introductory language

[wtd]

Making the case for O'Caml as an introductory language.

Let's compare it to some other popular choices and see how it compares. Let's call those choices Java, C++, Python and Scheme.

Tools

One of the critical aspects of instruction is that a good selection of tools exist to aid in teaching. I will disregard texts here as this is mostly about software tools, except to say that the language I'm trying to make a case for is at a disadvantage.

I think one of the most important tools a programming language can provide is some form of interactive environment: a quick and easy prompt to enter expressions or statements into and see a result, without having to write an entire program, save to a file and compile and/or run it.

Both Python and Scheme rank pretty highly here, and O'Caml is right up there with them. Java and C++ have no such polished environments. Java does have BeanShell, but the verbosity of the Java language does not work well with such an environment.

O'Caml's interactive environment earns special points for clarifying type information in its output and very clearly highlighting the source of any syntax errors.

Win: O'Caml

Java and C++ provide compilers, while Python and Scheme (as it is commonly taught) provide interpreters. Interpreters are often nice as they avoid separate compile and run steps. However, a compilation step does frequently catch problems with type incompatibilities that an interpreter leaves until run-time.

O'Caml provides both tools, offering greater flexibility, and remains statically-typed in its interpreted form, catching mistakes sooner rather than later.

Win: O'Caml

All of the languages mentioned have solid and open developer support, which is critical to their use in an educational environment.

Ambiguity

One of the biggest stumbling blocks I've noticed for students new to programming is ambiguity in the programming language they're using. A language which allows operator overloading, and in particular in Java's case overloads them only sometimes only serves to confuse students.

C++ is particularly notorious for this. Java is mildly better, but some might argue worse, as it allows for special cases, while C++ has codified its ambiguity, albeit with byzantine rules.

Python is much better, especially wit its indentation-based blocks and relatively simple syntax. New students may find list comprehensions and literals a bit confusing, and operator overloading can make things a bit odd. There's a fair amount of magic going on.

Scheme is very unambiguous thanks to s-expressions and essentially the lack of syntax.

O'Caml goes down a different road, with a lot of syntax, but ends up at a similar place since operators are almost never overloaded for different types, and keywords are rarely reused for different purposes (C++ I'm looking at you).

Win: O'Caml's static typing and strict enforcement of that allow it to slightly edge out Scheme for me in this area. It also gains special points for not allowing an "if" without an "else" or unmatched patterns.

Learning Curve

It has been my observation that students new to programming benefit from a gentle learning curve. To ask them to go from no knowledge to understanding high-level concepts in order to get started is asking too much.

Let's look at Java. To construct a basic first program, we have a class and a method with keywords like "public" and "static". We have objects like "System.out". This is a lot to throw at a new student who doesn't have the vaguest idea what it means.

The same thing in C++ demands a knowledge of namespaces and functions and operator overloading.

Scheme, Python and O'Caml win here, adding depth as students go, rather than dumping it all on them at the start and then explaining it over the duration of the course, but Python takes half a step back as soon as we start to delve into "everything is a object".

Win: O'Caml and Scheme tie

Breadth

A gentle learning curve is great, but we also want to be able to cover a lot of concepts with an introductry language. If not in one course, then in a couple of them.

C++ is a very versatile language, with support for a wide variety of programming styles. Unfortunately the support for many of these relies heavily on things like templates, which current tools do not support overly well with clear error messages. Debugging a template error is not something that should be forced upon students in an introductory class.

Java is very narrow. The only interest Java has is object-oriented programming. While one may argue this is good from a commercial standpoint, it limits its usefulness in education tremendously.

Python is much more broad than Java, and makes its breadth of concepts more easily accessible than C++. Unfortunately there is a certain callousness among the powers that be in the Python community toward functional programming which keeps it from earning top marks here.

Scheme does a very nice job with both imperative and functional programming, but object-oriented programming is a bit of an afterthought, and it shows, and while may might prefer it that way, I think not preparing students for this style of programming would be inadvisable.

Win: O'Caml supports imperative, functional and object-oriented programming well. It is the clear winner here.

Conclusion

Exploring four major areas of concern in an introductory programming course: tools, ambiguity, learning curve and breadth, we are left with a clear winner, and a strong case for taking a serious look at O'Caml as a language to use in such a course.

[jcollins1991]

Interesting arguments for O'Caml, but seems a bit one sided... In what ways might O'Caml lose to other languages? / Is there anything about it that might deter users of other languages from switching?

[wtd]

A lack of widespread industry adoption could be a ding against it compared to Java or C++ and to a lesser extent Python. Scheme is equally academia-bound.

However, I consider this to be something of a moot point, as an introductory language is fairly far removed from a programmer being ready for the workplace. There is time to learn Java or C++ or something else.

[TerranceN]

This may just be my inexperience with the language talking, but I find it very hard to read. Looking at some code samples on Wikipedia, I had trouble understanding what was going on, while similar examples in python and Turing, are far easier to read as an outsider to the language.

[wtd]

Mind elaborating and providing some samples?

Keep in mind I'm making a case for this as an introductory language. Lack of syntactic bias would lead to fewer such incidents.

How do you find O'Caml code for readability compared to the other languages I listed?

[jcollins1991]

If one were to look at any of the languages (with no prior knowledge of them) I think Java or C++ would be easiest to understand just because of indentation and how stuff is written.

code:

#let rec map f l =    match l with      [] -> []    | hd :: tl -> f hd :: map f tl;;

I think the short forms of a bunch of this stuff may be more confusing to people, which is why I like Scheme as a learning language because the syntax is faster to learn, once you know it it's easier to understand sample programs.

code:

let fib n =   let rec fib_aux n a b =     match n with     | 0 -> a     | _ -> fib_aux (n - 1) (a + b) a   in   fib_aux n 0 1;;

Overall the syntax of O'Caml looks interesting, but in larger programs it seems like if someone isn't very experienced they could end up writing extremely confusing code (though that's always a risk).

wtd: From the second code sample, is the _ basically the else of the language or something else? Also, what type of support does it have for recursion? IIRC Scheme is designed to be allowed unlimited tail recursive calls, does O'Caml have something similar?

[wtd]

To convert one sample:

code:

let rec sum xs =   match xs with     | [] -> 0     | x :: xs' -> x + sum xs'

In Python:

code:

def sum(xs):     if xs == []:         return 0     else:         x = xs[0]         xs_prime = xs[1:-1]         return x + sum(xs_prime)

That much clearer in Python?

[wtd]

The _ in this case is anything so yes it acts as a default case, and it also says to the compiler/interpreter: "I don't care about the value of this, so don't give it a name."

And yes, O'Caml's tools implement tail call elimination.

[wtd]

Another example:

code:

let stringify x =    match x with         1 -> "one"       | 2 -> "two"       | 3 -> "three"       | _ -> "some number"

Alternately, if we actually want that value:

code:

let stringify x =    match x with         1 -> "one"       | 2 -> "two"       | 3 -> "three"       | n -> "some number " ^ (string_of_int n)

[wtd]

Of course, we could always just use "if".

code:

let stringify x =    if x = 1 then "one"    else if x = 2 then "two"    else if x = 3 then "three"    else "some number"

But why bother with that mess when we can use pattern matching?

[wtd]

On the fibonacci example:

code:

let fib n =     let rec fib_aux n a b =         match n with               0 -> a             | _ -> fib_aux (n - 1) (a + b) a     in         fib_aux n 0 1;;   def fib(n):     def fib_aux(n, a, b):         if n == 0:                     return a         else:                     return fib_aux(n - 1, a + b, a)     return fib_aux(n, 0, 1)

The two are really not too different in terms of comprehension, once similar indentation style is applied. Of course, the Python example is contrived, as Python does not (and by its BDFL's wishes never will) support tail call elimination.

[bbi5291]

I think Haskell has nicer syntax for this sort of thing:

O'Caml:

code:

#let rec map f l =    match l with      [] -> []    | hd :: tl -> f hd :: map f tl;;

Haskell:

code:

map f [] = [] map f (hd:tl) = f hd : map f tl

O'Caml:

code:

let rec sum xs =   match xs with     | [] -> 0     | x :: xs' -> x + sum xs'

Haskell:

code:

sum [] = 0 sum (x:xs) = x + sum xs

I guess the purely functional paradigm of Haskell does hit students a bit hard though (with no direct support for imperative and object-oriented programming, only emulation with monads and whatnot).

[wtd]

Yeah. Haskell is a fantastic thing for students to challenge themselves with... but later on. It's a great language, but really high in magic content.

[wtd]

Versions of a very simple program written by just about every student early on. All done fairly naively. I haven't had time this morning to dealve back into Scheme, so whoever wants to fill that in, please do so.

code:

#include <iostream> using namespace std; float farenheit_to_celsius(float farenheit_temp) {     return (farenheit_temp - 32) / 1.8; } int main() {     float input_temp;     cout << "Input temperature: ";     cin >> input_temp;     cout << "In Celsius: " <<  farenheit_to_celsius(input_temp)" << endl;     return 0; }

code:

public class TemperatureConverter {     public static float farenheitToCelsius(float farenheitTemp) {         return (farenheitTemp - 32) / 1.8;     }     public static void main(String[] args) {         BufferedReader input = new BufferedReader(newInputStreamReader(System.in));         System.out.print("Input temperature: ");         float inputTemp = Float.ParseFloat(input.readLine());         System.out.println("Celsius temperature: " + inputTemp);     } }

code:

def farenheit_to_celsius(farenheit_temp):     return (farenheit_temp - 32) / 1.8 print "Input temperature: ", input_temp = float(raw_input()) print "Celsius temperature: ", farenheit_to_celsius(input_temp)

code:

let farenheit_to_celsius farenheit_temp =     (farenheit_temp -. 32.) /. 1.8;; print_string "Input temperature: ";; let input_temp = read_float ();; print_endline ("Celsius temperature: " ^ (farenheit_to_celsius input_temp));;

[bbi5291]

Scheme:

code:

(display "Input temperature: ") (display (format "Celsius temperature: ~a\n" (/ (- (read) 32) 1.8)))

(Scheme might have a printf function, essentially the composition of display and format. I'm too lazy to check the standard.)