Functional programming languages have alway been somewhat dismissed by most. Even though every once in a while functional programming becomes somewhat of a hot topic, only few programmers actually take it up as their main or favourite programming style. I'd say Ritchie's attitude there is and was kind of mainstream. I suppose just as C (or C style languages) have been mainstream for the past 40 years.
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.
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.
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.
> 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.)
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.
