Live data from Hacker News

15-150: Principles of Functional Programming

brandonspark.github.io

21–30 of 146 posts

Re: 15-150: Principles of Functional Programming

#21
post #15

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

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.

Re: 15-150: Principles of Functional Programming

#22

Great resource! Forgive my ignorance but why do so many modern functional programming courses use Standard ML instead of a Lisp dialect? Is it because of its built-in type-checking, or is it just how it's always been taught?

My opinion: marketing. In my experience, if I tell someone „look here is Lisp“ they turn off and roll the eyes with a „ohh that DEAD origramming language“. If I instead say „look this new state of the art language called ML“ I get full attention and respect.

Re: 15-150: Principles of Functional Programming

#24

Does this include exercises? I didn't see any and I always find that the most useful part of learning.

Not exactly exercises, but there's https://smlhelp.github.io/book/docs/ which supports the course and explains each of the concepts as well as library documentation at the official class site, http://www.cs.cmu.edu/~15150/resources.html

It looks like their current workflow keeps exams and homeworks off the internet effectively, but there's a 6-year-old codebase at https://github.com/zhengguan/15150-1 with 10-year-old homeworks and such.

Re: 15-150: Principles of Functional Programming

#25

Great resource! Forgive my ignorance but why do so many modern functional programming courses use Standard ML instead of a Lisp dialect? Is it because of its built-in type-checking, or is it just how it's always been taught?

It is statically typed, there's a lot of depth to that side of things (Curry-Howard isomorphism)

Re: 15-150: Principles of Functional Programming

#26

Does this include exercises? I didn't see any and I always find that the most useful part of learning.

Unfortunately, it does not. These lectures are "mine", in the sense that I developed all of them myself, but the homeworks and lab exercises are the combined efforts of generations of TAs and instructors from the past. It wouldn't be right for me to give them away. (they are also reused from time to time, so there are academic integrity concerns with that also)

Re: 15-150: Principles of Functional Programming

#27

Wow, he went from taking his bachelor to lecturing. I always dreamt of that when going through my degree and encountering courses that needed a thorough rework.

tbh if I were in a class taught by someone who had JUST finished their bachelor's degree, I'd take a lot of it with a grain of salt

Re: 15-150: Principles of Functional Programming

#28

Great resource! Forgive my ignorance but why do so many modern functional programming courses use Standard ML instead of a Lisp dialect? Is it because of its built-in type-checking, or is it just how it's always been taught?

The value of purely functional programming languages, as opposed to functional programming languages like lisps, is that you get referential transparency, which means that when you define `a = b`, you know that you can always replace any instance of `a` with `b` and get the same answer. This is a very natural property in mathematics (algebraic rewritings are basically just this property writ large) and so it helps to draw nice parallels between the familiar notation of functions from mathematics and the "new" and "confusing" notion of functions in functional programming and other declarative languages.

As other posters have said, strong typing is also a nice property for lots of reasons, most notably it gives a platform to talk about ad-hoc and parametric polymorphism.

(I lecture on Functional Programming at the University of Warwick, where we use Haskell.)

Re: 15-150: Principles of Functional Programming

#29

Does this include exercises? I didn't see any and I always find that the most useful part of learning.

Unfortunately, it does not. These lectures are "mine", in the sense that I developed all of them myself, but the homeworks and lab exercises are the combined efforts of generations of TAs and instructors from the past. It wouldn't be right for me to give them away. (they are also reused from time to time, so there are academic integrity concerns with that also)

(but I have thought of developing my own exercises independently to go with the lectures, to post on my website. This is generally a lot of work, though, so this might take some time, depending on how much people would benefit from it.)

Re: 15-150: Principles of Functional Programming

#30
post #22

Great resource! Forgive my ignorance but why do so many modern functional programming courses use Standard ML instead of a Lisp dialect? Is it because of its built-in type-checking, or is it just how it's always been taught?

My opinion: marketing. In my experience, if I tell someone „look here is Lisp“ they turn off and roll the eyes with a „ohh that DEAD origramming language“. If I instead say „look this new state of the art language called ML“ I get full attention and respect.

No, it's definitely not because of marketing. SML is more of a dead language than most lisps. SML is used because it has a strong type checker, which is much more conducive to learning, and just having resilient programs in general.
Post reply on HN