As jeremyjh already pointed out, this results in a pretty weak definition. You end up with JavaScript, Ruby, Python, and Objective-C all being lumped as "functional languages", and if you squint a little bit, you can put Java in there too (anonymous inner classes). I think C, C++ and C# could be as well, but I don't know them well enough.

So I don't think it's very productive to use a definition like this, but not because I want to be divisive, or "move the goal posts" or because I'm trying to be elitist here. It's because when a colleague asks you "what's functional programming?" I think it's much more helpful to describe the kind of programming that is encouraged in Haskell and Clojure than to just say, "well it's just map, filter, and fold in JavaScript".

Or we could be more precise and acknowledge there are several related features in the realm of "functional" and a language may have some but not all of them, and not make it into a fan club battle.

Same goes for OO, which has something like 9 well-known defining features.

I don't think my comment was making anything into a "fan club battle". I was specifically advocating the kind of precision you describe, because I think calling any language with higher-order functions a "functional programming language" results in very muddy waters.

The scenario I described wasn't hypothetical. When a colleague asked our whole office "what's functional programming?" I listened while someone told him that it was just map, filter, and fold. He'd used these in JavaScript already, and was prepared to accept that as an answer. I didn't think that was sufficient, so chimed in and offered some alternative features from other languages that I think are as important as higher order functions, mostly related to minimizing mutable state with managed references and persistent data structures. I think he appreciated my contribution, but I honestly don't know for sure. Maybe it just created more questions.

Rather than saying that higher-order functions is the defining feature of functional programming, I would say that it's an essential feature to support its object of defining programs in terms of (mathematical) function application rather than procedural state changes.

Does any higher order function application require state changes to implement as a specific lower order instance.

For example, an instance map is just a cons and a recursive call. No state change needed. You can say something about exposing unwanted details in the cons, but that is a hairier point of contention.

I'm not that old but I remember that, back in the days, functional meant just that you are able to use plain functions (without objects) and pass them around. By that definition, C is functional language, as scheme or lisp or javascript and many others.

I don't know why, but some years ago, "functional programmers" started to change and twist the definition of functional language step by step, until all those languages fell off and only Haskel remained as "functional enough".

I don't see much use in a definition of "functional language" that includes nearly every computer language. We already have a term for that.

I agree that "nearly every computer language" can be considered functional, as "nearly every computer language" can be considered imperative.

What I do not agree is when "functional programmers" claim that language is not "functional" just because it is not "pure functional" or Haskel alike.

well it's primary use seems to be providing a moving goal post for the functional side during the occasional OO vs Functional skirmishes.

That is required for parity with the OO side. Cf. Alan Kay on OO.

quite. Smalltalk is OO and Haskell is Functional are about the only (currently) accepted facts about the definitions of OO and Functional.

I always thought the fundamental difference between a functional and imperative language is that a functional language is built up from expressions, whereas an imperative one is built up from statements.

I think you at mixing words that look similar. It is a large problem in this sort of discussion:

Pure functions. (Only Haskell and friends are strictly pure, as is SQL if you squint.)

Higher order functions. (Java 7 doesn't allow you to pass around a callable function without embedding a link language with reflection or using one-method Runnable.)

First class functions. (Basic, SQL do not have this.)

Generic functions. (C does not have this. C++ does. Java does.)

These are three orthogonal properties a Lang age may have some or all of.

Doesn't function pointers enable passing functions around in C?

Yes, but you can't combine function pointers to create and return new functions.

Sure you can - just not anonymously. Kind of like how you can have "higher order functions" and "closures" in Java with anonymous classes - roughly equivalent, but awkward and not quite what the language was designed for. C is probably better in this regard than Java, but the lack of managed memory is a major drawback.

Right. SO you can program 'functionally' in those languages, but they are not 'functional programming languages' because they don't support it natively.

"just not anonymously"

Just not depending on anything in the environment either except globals, which is a huge limitation. So writing a function inc by = \x -> x + by becomes unnecessarily difficult for example.

then you just have a void* / fn ptr couple that you pass around..

Yes, but functions aren't truly first-class values; you cannot create new ones on-the-fly (proprietary extensions notwithstanding).

What does proprietary mean in this context? I'm sure it can be copied/implemented by for example gcc if they were interested.

I meant to refer to extensions implemented independently by one compiler or another. Clang and gcc both provide lambdas, but not in the same way, and there's no standard for it. (I could be wrong on both points; this is purely from memory, and could have changed.)

Thanks for your explanation. I had to look and I libblocksruntime which seems to be an open source lib for clang with blocks.

Actually, if you look closely you'll notice that not other language lets you do this either (except through an 'eval' or similar). What I think you actually mean is that this still doesn't let you use closures. But in fact it does! :D You'll have to do a lot of void * casting to make it work though.

C does not provide closures. You can pass around a struct with a function pointer and a data or state pointer though. That will let you achieve the same thing, but it won't be as pretty.