[loup-vaillant]

I meant expression tree, sorry. I'm not referring to Haskell non-strict evaluation either. My point stands in Ocaml as well. But yeah, expressions do relinquish explicit control of the evaluation order, for it doesn't matter (assuming purity).

On the other points, let me remind you that a function is a subset of the Cartesian product between its domain and its co-domain. How does that do anything? How does that isn't as ordinary as a mere set? Really, the only reason we feel that functions do something is because we generally perform only one action with them: looking up the result, given a parameter.

I insist because this is precisely this special holy first class status that makes functions scary. Remember the primal fear you felt when your high school teacher told you that there is an operator that can compose functions together? Neither do I. But it did make clear at that point that functions aren't that special. If they were, how could I write "f∘g" just like I would "x+y"? How could I write "f" alone, without an "(x)" right next to it?

Functions do have their specificities, and they are special in the sense that they are a tremendously useful, wickedly powerful concept. But they're still mathematical objects. Making them first class in a programming language just lift restrictions that were there only because it was easier to implement.

[mindbat]

I see. You're using function in its mathematical sense, not in terms of programming.

Perhaps the article would be clearer if you stated up front that you're trying to talk about the mathematical underpinnings of the functional programming paradigm, and not how imperative and functional programming languages differ in practice? From a practical programming standpoint, your characterization of functional programming is both incorrect and confusing.