Education is an issue. Very few programmers actually know what functional programming even is or how it can help.

Also 40 years ago we had what? LISP as is commonly used is not an FP language. ML was nice but there wasn't much FP done in ML either.

The advancements to make FP practical, like good garbage collectors, laziness, monads, good persistent data structures, are newer.

Many universities teach FP to their undergraduates, some of them even use Haskell as their first programming language.

I have published at ICFP and in the JFP, and understand garbage collectors, laziness, monads, good persistent data structures very well. Yet, I prefer CBV to lazy evaluation, I prefer full unrestricted support for imperative programming, I don't think Haskell approach to effects by monads is ideal (I prefer Scala's giving you the option to tame effects by monads). There is a reason why, despite near half a century since Backus' "Can programming be liberated from the von Neumann style?", CUDA dominates HPC, C++/C (and Rust) dominate mainstream infrastructure programming, Go took the cloud world by storm, ML is dominated by Python, front-end is dominated by Javascript/Typescript, hardware design is dominated by Verilog, and business computing (for lack of a better term) is dominated by Java/C#. I really don't think the reason is that everybody is too uneducated to realise the benefits of Haskell.

I don't know, as far as I know functional programming is a standard course in computer science university curriculum. I've only been part of small dev teams so far, but of those teams always more than half were university educated, and none of them continued functional programming after university. Of all my university friends only one did Haskell outside of university that I know of (maybe there's some secret Scala/F# lovers at Java/.net firms). I've been part of the Haskell community, so it's not like I don't know Haskell programmers, but I'm saying I know a lot of formally educated programmers, and only very few of them took a liking to functional programming to an extent they'd do it professionally or even as a hobby.

I think there are quite a few closet "functional" programmers, who may not even consider themselves as such, doing their best to write mostly side-effect-free, declarative code within the confines of an OO or multi-paradigm language (in .NET land, functional-ish features like LINQ and pattern-matching bleeding into C# makes this easier). I also met more than one person trying to introduce F#/Scala in a pretty small .NET shop I used to work for.

Except every non programmer with a business degree seem to love functional programming: Microsoft Excel

Excel is at its core a declarative programming language. Entering formulas in cells that reference other cells declares the relationship of the calculated cells to its referents.

It is not an imperative language: the user does not tell the computer which order in which to carry out computations. It is not procedural: there is no notion writing of procedures within its cells. It is not functional: while there are built-in functions users cannot write their own in the same way.

> while there are built-in functions users cannot write their own in the same way.

It's been a while since I've used Excel, but I thought you could write custom methods using VBA that could be called in a given cell.

You can indeed, but VBA is of course imperative, and VBA is used in part because it is difficult to read/write and considered a poor practice to have any significant chaining of functions in the spreadsheet. The bigger reason it is used, of course, is because Excel's declarative environment does not accommodate all behaviors and users prefer to implement them imperatively. So this sort of reinforces Excel as not being a functional environment.

Being able to write functions doesn’t make a language functional. The hallmark of functional programming is closures as first-class objects, passed as arguments or returned from other functions.

The nearest Excel equivalent would be constructing a formula string for later evaluation, which is far from the same thing. If you wanted to perform lambda calculus in Excel you’d end up implementing your own functional programming language in VBA. Have fun with that :-)

I’ve heard this before, but long felt it is more like logic programming: you declare facts and relationships, then an evaluation engine finds results.

Not saying you can’t, say, pass around closures in Excel but it’s far from natural. Whilst spreadsheets always remind me, more than anything, of the Prolog I took in college, and not the Lisp or ML.

Functional programming involves using functions as a first-class objects. I never saw that kind of programming in Excel.

Umm, doesn't Excel use Visual Basic (VBA) under the hood?

No, AFAIK, VBA is just a scripting layer exposed by Excel, not what Excel uses itself.

What do you mean by "using itself"? When you write a function in an Excel cell, IIANM it's a VBA function. Excel is implemented in C++ IIRC.

> When you write a function in an Excel cell, IIANM it's a VBA function

No, its uses the Excel formula language, which isn't the same as VBA (nor is it a subset of VBA; Excel formula language expressions generally aren't valid VBA.)

Not at all, Excel can be scripted in multiple ways, VBA is just one among many.

Hated functional programming in university, now wish there was wider industry adoption. Deep diving into FP made me think more about the code, rather than just writing it in an OO-Language.