It's a major characteristic, often cited as a positive. I included a reference to eval(), as well. Please enlighten me as to what they're really about, then?

It is a major characteristic and it is positive. I work with backend services in clojure, we have a huge codebase and many programmers working in parallel in the project (6 right now). The code is straight forward, short and elegant with immutable functions and some few macros. It's the first time in my 10 years programming career that I can say that about the codebase I'm working in. I agree that it's hard to understand the benefit if don't know FP to some degree and don't have much experience working with it (Paul Graham blub paradox).

FP has many characteristics—at its core it's about programming with functions as first class values—but it was never about having no side effects, just about controlling side effects.

Go has first-class functions and closures.

Every pure FP approach to side-effects I've seen has been a mess, stuff like with-open-file. It's fine if that's the minority of your code and you're getting enough out of being able to pass code around as lists of nested statements to make that worth it. For go's stated use case, it's not worth it.

WITH-OPEN-FILE is not about controlling side effects at all; it's about making it hard to forget to close the file. Go's analogue is "defer".

In any case, I don't even know what we're arguing about anymore. My point is simply that FP is not about having no side effects, and saying "side effects are important" does not argue against the value of other FP innovations, such as HM-style type inference, option types, pattern matching, first-class functions, algebraic data types, etc.

When you say having no side effects is not a FP characteristic, then I say Hindley-Milner type inference, option types, pattern matching and algebraic data types aren't either. Many functional programming languages aren't even statically typed.

I'd go a step further and say that controlling side effects, as a consequence of pure-functional design, is a bigger part of FP than any given type system. But hey, what do I know, I just did the SICP exercises a decade ago and forgot about it afterwards.

We're in agreement that functional programming encompasses a range of characteristics and is hard to define.

You're saying that the type system has something to do with functional programming.

I'm saying that if Scheme, LISP and Haskell are all functional languages, obviously the type system is besides the point -- they're radically different in that aspect. Functional programming is about functions.

I'd say Scheme and Haskell are functional languages, as they emphasize programming in a functional style: Composing functions to process values. "Value-oriented programming".

I never understood why anyone classified Lisp (typically CL) as a functional language, as it isn't any more functional than Python, Ruby or Perl.