Hacker News new | ask | show | jobs
by systems 941 days ago
on the choice of language to teach the course why sml

i think there are a lot of nicer choice

   OCaml , its basically sml only more popular and used more in real life
   Haskell , again more popular , and used more in real life 
   Idris , newer and said to be more progressive 
   F# , a more practical choice and similar to sml 
   a lisp , well if you want to focus on the functional part and less on the types part
2 comments

There's a few things which go into this (hi, I'm the instructor!).

One such reason is historical. Standard ML is a research language, and a significant amount of work on it was done by professors at Carnegie Mellon, who developed the curriculum for this course.

Even setting that aside though, I fully agree with the choice to teach it in SML. For transparency, I work professionally in OCaml, so I am not unfamiliar with it, and I enjoy it quite a bit. That being said, I think that the approach taken by CMU is best summarized as the fact that languages are ephemeral, and the concepts are what matters. We don't teach programming languages, we teach concepts -- so even if SML is not widely used, the tradeoff for having students have a simpler, less distracting, and better learning experience is well worth it.

OCaml has its own intricacies that make things difficult. For instance, you can go down a lot of rabbit holes with `dune` and `utop` and `ocamlc` and `ocamlopt` and all of these things, versus SML/NJ's simple interactive REPL. Another thing is that the language is just generally more "bloated" -- you can teach modules, but then what if a student starts running into first-class modules, recursive modules, or even beyond that, GADTs and classes and objects?

(as an aside, this is my primary reason for why I would not want to teach an introductory course in Haskell. To do anything, you suddenly need to understand the concept of type classes and lazy evaluation, and that's simply too much. I don't know much about the other languages.)

I think teaching is as much enabling students to succeed as it is to prevent them from shooting themselves in the foot. For an anecdote, there is an `Option.valOf` function (of type `'a option -> 'a`), which essentially is just a bad function that should be avoided where possible. Every semester, without fail, even though we never tell students that function exists, students are smart enough to use Google, and will use it anyways, ultimately harming themselves.

I think that same mentality applies to programming language choice, here. Keep it simple, keep it neat, and make sure that the students see what is necessary for their education, and not have to spend mental energy thinking about much more.

As a professional who uses F# every day, I appreciate this answer, even though it concerns me. Separating concepts from practical details is worthwhile, but can be taken too far. I think the FP community probably focuses a bit too much on theory. I would encourage you to consider teaching a more practical language, like F#, in the future.
I feel like F#'s commercial viability over other more computer sciencey FP languages is actually kind of a downside, from a "vibe" perspective. It seems like CS folks are not generally very interested in moving more towards the software engineering end of the discipline. Which is fair, because they are different things.
i think someone with a good grounding in sml could get proficient ocaml or f# in under a month. sml is absolutely the right language to teach a course like this in.
I agree with your first sentence, but the second one surprises me. If the practical language and the impractical one are that similar, why pick the impractical one?
sml is a smaller language, and a "cleaner" one in some ways. if your goal is to teach students the elements of functional programming, you want them to be able to concentrate on the core concepts, and not on the incidental details of the language.

http://adam.chlipala.net/mlcomp/ is a very good overview of the differences between sml and ocaml, which lets you see some of the tradeoffs each language has made.

having done the proglang course by dan grossman long ago, they use sml too, i knew lisps, ocaml, and others, but sml smallness was really really appealing
because SML is awesome, isn't going to change and is simple. you can learn the syntax in an afternoon, and really focus on learning FP semantics.
Albeit little, installing SML still requires some anount of gymnastics, google searching, and copying stuff from SO, GH Gists, etc.

Yes, I agree broadly with the line of thinking that says- if you are learning FP, you must be willing to do these, but a beginner might be disheartened and turned away- especially as someone learning alone.

totally fair!
The problem that is extremely verbose though. OCaml is much more concise.
Both languages encourage a concise, functional programming style but with different flavors and toolsets. They are comparable, in terms of verbosity.

I think these are correct implementations of the tower of Hanoi.

OCaml

    let rec hanoi n source target auxiliary =
      if n > 0 then begin
        hanoi (n - 1) source auxiliary target;
        Printf.printf "Move disk from %s to %s\n" source target;
        hanoi (n - 1) auxiliary target source
      end


SML

    fun hanoi n source target auxiliary =
      if n > 0 then (
        hanoi (n - 1) source auxiliary target;
        print ("Move disk from " ^ source ^ " to " ^ target ^ "\n");
        hanoi (n - 1) auxiliary target source
      )
function definition, if expressions, recursion are more concise in SML, string interpolation is nicer in OCaml
You SML code is incorrect, shows that you actually never coded anything in SML. SML requires that "if" always contains "else" clause (which is the norm for many functional languages). And this kind of stuff which makes SML unnecessarily verbose (OCaml has for operators, single line let definitions that do not require you to make use val and fun for different type definitions etc.).
I did Programming Languages, Part A, (to learn FP semantics) many years ago. It doesn't show I never coded anything in SML, it shows I made a mistake :/ .I no longer have Standard ML on my machine.

I thought having the `let` keyword encompass `fun` and `val.` was needlessly confusing. It's not concise. if `let` can mean so many things why not just do what Haskell did.

Again.. it not "so much more verbose." which was the initial point.

but I concede, my SML code is in fact incorrect.

No SML is more verbose, is pretty obvious. A simple "for" in ocaml could save lots boilerplate doing trivial recurison.