Eh, I think that leaving out first-class functions is unforgivable. The complete spirit of functional programming can be neatly summed up as:

"Functional programming is the creation of useful programs using only functions mapping input arguments (perhaps themselves functions!) to outputs (also perhaps functions!) without external state."

You can't leave out the function part of functional programming.

I would agree with GP that emergent code organization principles that come from eliminating side effects are the crux of FP, as far as being the bottom line of what makes it effective and worth internalizing.

Higher-order functions are a simple and powerful form of abstraction, but not much else. I could imagine something which has the software engineering benefits of an FP language without HOF, although maybe it wouldn't culturally be one.

I think getting enthusiastic about higher-order functions and trying to use them in OO languages can range from good to neutral to bad. On the plus side, code is usually shorter. On the negative side, it's not necessarily more readable, and types still usually expose the same amount of information about their inputs/outputs, which is "call me, anything can happen" (plus plenty of opportunity for lazy side effects, the most confusing kind).

This kind of becomes a name game, what is truly "FP". For many, FP is meaningfully defined as a focus on functions and it's silly to try to define that away.

There is something, "ML-alike FP" or, even, "Haskell-alike FP" which I might call "pure FP" which is what you say. This is less difficult to see as being centralized on purity more than "FP" at large. Presumably, you could have "pure" OO, classes and all, by eschewing effects just the same.

I have at least one bet in the pot that you cannot, though. I think the true beating heart of "pure FP"/"Haskell-alike FP" is the centricity of composition as a guiding design of language. This comes directly from some of the category theoretic heritage of the core languages here. Once you're here, the primality of functions themselves is hard to escape from. You can go a ways without HOFs, but the lack of richness of composition which you're stuck with is very painful. BiCCCs are a very sweet spot.

But a function isn't really a function unless it is referentially transparent. Having HoF, composability, etc.. is all a direct result of referential transparency.

Sure we can simulate these concepts in imperative languages, but the broken abstractions break down rather quickly since the laws are ignored.

It's just a function in a different, less observable category. That's not the worst thing. And, of course, I'd like to argue for "pure FP" too.

Really, I just want to sidestep the argument that is appearing all over this post: that "FP" is also this, and this, and this.

Sure. FP is terrifically poorly defined. The definition used in the article is rather more specific than what most people would say. But it has merits and should be discussed. Let's just not stumble over naming difficulties to do so.

So, I see what you're saying, but I maintain that without first-order functions, you can't do anything useful with code organization.

If you wanted to simulate that, imagine writing in C or C++ or Javascript using only functions, only returning copies of things changed by the function, and never referencing global state.

There's nothing particularly magic about that, other than better testability--it's just really slow and obnoxious imperative code. When you start passing around functions and currying values, though, then you're actually starting to see cool things happening.

I think you're making this too abstract to be understood without having already seen the light, perhaps an example would help?

Okay, sure, let's look at it in Javascript.

The task? Take a list of numbers, and produce a list containing only the squares of those numbers--and only those squares falling between 10 and 50.

  var inList = [1,2,3,4,5,6,7,8,9,10];
  
  var non_fp = function ( myListOfNumbers ) {
  	var out = [];
  	var temp = [];
  	var i = 0;
  	var j = 0;
  
  	// square the numbers
  	for (i = 0; i < myListOfNumbers.length; i++) {
  		temp.push( myListOfNumbers[i] * myListOfNumbers[i] );
  	}
  
  	for (j = 0; j < temp.length; j++) {
  		if ( temp[j] > 10 && temp[j] < 100 ) {
  			out.push( temp[j] );
  		}
  	}
  
  	return out;
  }
  
  var fp = function ( myListOfNumbers ) {
  	return myListOfNumbers.map( function (x) { return x*x; } )
  			      .filter( function (x) { return (x > 10)  && (x< 100); });
  }

The first has no side effects.

The second version has no side effects, and wouldn't be possible without first-class functions, and to me is clearly the more functional answer.

Suggested minor change to the non_fp one:

  var inList = [1,2,3,4,5,6,7,8,9,10];
  
  var non_fp = function ( myListOfNumbers ) {
  	var out = [];
  
  	// square the numbers
  	for (var i = 0; i < myListOfNumbers.length; i++) {
  		var x = myListOfNumbers[i] * myListOfNumbers[i];
                if (x > 10 && x < 100) {
                        out.push( x );
                }
  	}
  
  	return out;
  }

That's a correct change--I chose the implementation that I did so that it was very obvious how the things remap to a "functional" approach. :)

You see the point I'm driving at, though?

(and thanks for prodding me into writing code to illustrate things better)

> You see the point I'm driving at, though?

Yes, absolutely. I thought you were right on the money with the words but I figured a bit of code would do wonders to hammer it down.

Erlang does an even better job I think:

  [X * X || X <- lists:seq(1,10), X * X > 10, X * X < 100].

Or:

  [Y || Y <- [X * X || X <- lists:seq(1,10)], Y > 10, Y < 100].

Slightly longer, but without that X * X repetition.

Yep. Erlang/Elixir is actually kind of a joy to work in for math stuff. Shoot me an email if you'd like to chat about that.

I'm slowly slogging my way through Project Euler in Erlang, it's my default way of learning anything new and so far I've been making progress but I'm pretty sure that what I'm writing is absolutely horrible non-idiomatic erlang. I will probably take you up on that but after I've learned a bit more so at least I stand half a chance of understanding you.

I am probably making a similar point to "gracenotes" here, but as I see it the functions in functional programming are simply a tool that can be used in order to achieve side effect free programming. They are not what really defines functional programming as a concept, even though they share the root name "function".

Yep. It always amazes me when die-hard OOP'ers get it all wrong and think FP is at war with their beloved OO. Well no. Plenty of FP languages exist that combine FP and OO together. Scala.. F#.. OCaml.. etc.

It always amazes me when die-hard FP'ers get it all wrong and think OOP is at war with their beloved FP. Well no, plenty of OOP languages exist that combine FP and OO together. Scala.. C#.. Clojure.. etc.

C# at least doesn't do immutability per default, which is another classical property of FP.

Most functional programming languages don't do immutability by default (which anyways, is an aspect of the library that can choose to be or not to be; LINQ definitely is). There are also no true scotts men.

Considering there is no (AFAIK) agreed upon definition of what an FP language is, I'm using classical as "common and found in older FP languages", not saying that an FP language which isn't immutable per default is not FP.

I'm think of Haskell, OCaml or (AFAIK) Erlang. From what I read, Clojure has also a lot of emphasis on immutability.

Haskell and OCaml aren't really that old. I'm thinking ML and Lisp, scheme, which don't focus on immutability.

Both clojure and haskell have mutability, just at differing granularities (haskell monads, clojure replace the world object). They can do it with referential transparency though (which is probably your meaning, obviously pure immutability is impossible and not sensical).

Haskell is from 1990 and OCaml from 1996, it's not awfully recent.

> Both clojure and haskell have mutability, just at differing granularities (haskell monads, clojure replace the world object). They can do it with referential transparency though (which is probably your meaning, obviously pure immutability is impossible and not sensical).

Well, you have to have to be able to manipulate state somehow (even if, at least on the surface, the state monad emulates mutability, as opposed to, eg, OCaml's notion of mutation, which is very explicit in what it does). But the point is that it is not the path of least resistance in these languages.

They are not very old either, at least not compared to Lisp (60s), scheme and the MLs (70s/80s). Haskell is quite brand spanking new in comparison to the old guard.

What C# lacks for me in FP, case matching, has little to do with purity. The FP story involves purity but is not dominated by it. List comprehensions still work in C# even though you can theoretically side effect in your select and filter functions.

Did you just illustrate his point? No one in the comments mentioned OOP and you were the one to bring it up to disparage it. He was just responding to your hypocrisy.

"Bring it up to disparage it"... uh what?

You've got it wrong. OOP'ers have no problem using FP. It is die-hard FP'ers who would disparage OOP whenever given the chance.

I think you're right. OOP'ers tend to not understand FP, and when they do get it, they are happy to use it. On the other hand, die-hard FP'ers tend to look down on OOP'ers.

I'd bet many FP'ers don't really understand OOP either. They tend to think creating complex hierarchies is necessary and algebraic data types and modules magically fix everything.

How many functional programming languages do you cross of the list of functional programming languages if you make that claim? At the very least anything Lisp related, all the ML languages as well. You are pretty much left with Miranda, Haskell, and a few related languages.

An FP language doesn't preclude non-FP code, just like OOP doesn't preclude ... procedural code? I'm not sure what the opposite would be but it exists (think Matlab code).

I would argue that the lisps are not very functional languages (both in the importance of effects and the style of code I've seen written in lisps), but Scala provides for a lot of FP assurances (val over var, good FP-y libs), and people in the community value effectlessness. So I'm comfortable calling Scala a FP language.

>You are pretty much left with Miranda, Haskell, and a few related languages.

Agda and Idris as well.

The bar for what constitutes "FP" has been changing since the 50s. Doesn't sound unreasonable to me.

Functional programming used to mean programming with first class functions and closures; they even put it in the name "functional"al programming (just like OOP meant program with objects, whether this involved classes or not).

So that is Lisp, the first FP in the 60s, and then the MLs of the 70s/80s. They knew about purity, and even preferred it (for things like list comprehensions, it is very useful), but were never very dogmatic about it.

Would concatenative languages apply ?