[loup-vaillant]

Verb vs nouns. Well, what are objects in OO? They're things that do this, and change that… This is a lot about what objects do, and what we do to them. On the other hand, in FP, one "does" only one thing: create new values. There is a lot of verbs in FP, but they don't do anything… Anyway, I guess I'll need to review that.

Instruction sequence vs Expression tree It's jot just Lisp. Ocaml and Haskell apply as well. We don't manipulate the syntax tree, but it doesn't mean it isn't there. For instance, the following is a valid Ocaml or Haskell expression:

  if condition
  then foo
  else bar (if condition2
            then baz
            else wiz)

This is not unusual code. Here is the C equivalent:

  condition
  ? foo
  : bar(condition2 ? baz : wiz)

This is a tree of nested expressions.

Functions as ordinary mathematical objects. I'm just saying that functions belong to the bucket of mathematical objects. As are integers. And sets. And lists… "First class" just mean we treat them as such. From https://en.wikipedia.org/wiki/First-class_function

> In languages with first-class functions, the names of functions do not have any special status; they are treated like ordinary variables with a function type.

[mindbat]

"There is [sic] a lot of verbs in FP, but they don't do anything"

This is both misleading and false. Functions, by their very nature, "do something."

Perhaps you're referring to the immutability of data in a functional language? If so, say so.

"We don't manipulate the syntax tree, but it doesn't mean it isn't there."

A statement so ambiguous as to be meaningless. All compiled languages have a "syntax tree" lurking in the background. It just so happens that Lisp and its variants let you manipulate that tree directly, rather than writing in code that gets converted to that tree at compile time.

Perhaps you're referring to the fact that in Haskell, you often don't control the order in which code is executed, unlike in an imperative language where you have explicit control?

"...just saying that functions belong to the bucket of mathematical objects. As are integers. And sets."

Nope. The quote you use has it right. The names of functions are variables, whose value is looked up like any variable. This lets you pass functions as arguments to other functions, or use functions as the return value for other functions. Functions are most definitely not just like integers in a functional language.

[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.