That works provided you always use datatypes, and always hide their constructors. So for instance

datatype age = mkage of int
fun birthday(mkage n) = mkage(n+1)

in a structure, with a signature including type age (not eqtype) and not including the constructor mkage. I’m not sure that’s really better than using opaque ascription – it seems just about as elegant as the relationship between Integer and int in Java. And you also eschew the explanation of functors as abstracted – in the sense of lambda abstraction, not data abstraction – versions of structures: the relationship between S and T in

structure S:>SIG = …
structure T = … S …

is like the relationship between S and T in

functor T(X:SIG) = … X …
… T(S) …

See my comment on “Modules Matter Most” – I still think there has to be a better way. And it seems to me that the way you are doing things – which you suggest is a better way in practice – amounts to explicitly hiding the identity of the types that you want to be abstract, rather than explicitly revealing the identity of the types (like Key.t in your IntMapping example) that you want to expose. Maybe what is missing is just a more elegant language construct to do that? Dare I suggest Java-style private?

What’s confusing is that the FP community still seems to be less privilege-balanced as a field than other subfields of CS, and I personally knew a lot more women in undergrad who preferred C hacking to ML. I wish I knew why.

“Related to this, avoid if-then-else entirely, and instead use only case analysis for branching, even when the value to be discriminated is a Boolean.” is something I will be using in my own programs

I will be using this in my own programs for now on. I think it makes sense and makes it easier to reason about my code than if-then-elses

Students with prior “programming experience” are, if anything, at a disadvantage, because they think they know things that are either wrong or inapplicable.

You should have said: Students with poor prior “imperative programming experience” are, if anything, at a disadvantage, because they think they know things that are either wrong or inapplicable.

Here are my basic rules:

* global state must be constant
* program by contract, verify invariants
* recursion is better than iteration
* correctness is more important than performance
* documentation is more important than features

The biggest advantage of a functional program is that the solution of the problem is basically the problem itself. For example, in Python, getting an array of the names of all persons in an array of persons in a functional form would be:

names = [person.name for person in persons]

This is much shorter and more understandable than the imperative version:

names = []
for person in persons:
names.append(person.name)

If person.name were knowingly pure, we could now easily run the first example in parallel. We can’t do this for the second version as we loose the notion of transforming one array to another one, but only have an iteration for which we do something in every step.

It’s like saying “start the laptop and login” vs. “open the laptop lid, press the round button, once the login screen is there enter your name in the first box and your password in the second box, then click login.” – in the first one you know what the goal is and could do it in multiple ways (you could enter the password before the username), in the second one you only know one way of doing it, preventing any further optimization by magic entities.

Functional programming is superior because we think about the problem, and not about a specific algorithm to solve it.