[ux266478]

I see this misconception a lot. Functional programming has nothing to do with mutability or immutability. Just like product types (or associative arrays) don't make for object oriented programming, the paradigm is about the patterns you use and the total structure of the program. In the case of functional programming, it's that your entire program is built around function composition and folds. This changes how you build your program on a fundamental level.

Additionally, functional programming does have a strong theory behind it. That of the lambda calculus. Everything is formalization and constructions built on top of that. We don't have a "hard line" to detect if a language is "functional" because it's not a language paradigm, but a property of the code itself. Grammar is orthogonal to this stuff. You can, however, make a pretty good guess by looking at the standard library of a language. There is no ambiguity that Idris or Haskell are a languages designed for functional programming, for example.

I think this stems from a problem that there are a lot of programmers, who through no fault of their own, have engaged with tools for functional programming, but skipped building things using the alien and weird stuff so in the end there's no actual learning of functional programming itself. Every new programming paradigm is a shift of your core perspective, they require you to relearn programming from the ground up. It shouldn't feel like "this is just ABC with XYZ", you are only truly beginning to learn when you are put back into your shoes as a middle schooler unlocking the power of nested conditionals. If you don't get that feeling, you're just learning a different language and not a programming paradigm.

> And even the best example of purity, SQL

Purity is not a claim of functional programming. Also SQL is not anywhere close to being a functional language, it's not only a non-programming language, but even if it were (and it can be with extensions) its paradigm is far more in line with logic programming.

[motorest]

> This changes how you build your program on a fundamental level.

I think this manifestation of cargo cult mentality should be put to rest. For each paradigm we heard the same story, but we still see programs in ${LANGUAGE_A} not even following idiomatic styles and looking instead like programs transcoded from ${LANGUAGE_B}. You do not change the way you build programs by rewriting projects in a specific language or even style. You just get the same people implementing the same programs according to the same mental model. The key factor is experience and familiarity, and you don't build any of that by marketing a particular programming style. Moreso when which framework of library was adopted by a project. The hard truth is that experience and familiarity derive from problems a developer faced and the solutions that worked, and quite bluntly after all these decades functional programming isn't living up to the hype created by it's fans. It's the curse of LISP all over again.

[ux266478]

I'm not sure that your objection puts anything to rest, least of all a "cargo cult mentality". You re-assert exactly what I say just to disagree and miss the rest of the post. Codebases which are not written in a functional style are not functional programming, no matter the language being used. The overwhelming majority of programmers did not learn to program in a functional style, and without the long haul learning process of thinking about program construction in terms of function composition and application, they will program according to whatever they've always used. They can't program or use a mental framework that they don't know. Languages are languages. The syntax and grammar of a language has (virtually) no effect on a programming paradigm. There's nothing in the grammar stopping you from using Haskell as an imperative language. That's a knock-on effect of being a turing complete grammar, no more, no less.

Given these facts which are absolutely not up for debate, some statistical sample of codebases which are just some unstructured hodge-podge mudball in any given language isn't particularly meaningful. Somebody who spent 2 weeks reading Haskell tutorials in their off-time isn't going to be writing functional programs in Haskell. Hell, somebody who has been writing mudball Haskell programs for years isn't going to be writing functional programs.

> and quite bluntly after all these decades functional programming isn't living up to the hype created by it's fans

Perhaps your problem is that you are looking through such a lens that "hype" even registers on your radar. And that's why I'm sure you can't name a single weakpoint of functional programming off the top of your head besides the ever popular, ever erroneous complaint about "performance" by people who think functional programming is immutability, purity and function pointers. If all you care about is the social baggage with a working discipline and its tools, how can you possibly have anything but the most trivial, surface-level and, to put it bluntly, ignorant view of things? There is no substance to that nonsense, don't kid yourself. Until you change that you will never receive any signal, just noise. The heterogeneity of programming as a discipline will continue to frustrate you to no end.

"All over again"

Lisp is a tool explicitly designed for functional programming ;-)

[layer8]

To chime in to this discussion, I suppose there is a disagreement of what functional programming means exactly. For some it means Haskell or equivalent, for you it seems to be much laxer. Functional-programming evangelists tend to be on the stricter side, though.

When programming with “functional core with imperative shell”, is that functional programming overall? In the projects I work, functional-style parts are commonly bookended by imperative parts both outwards and inwards. The inward parts are things like database calls, file I/O, OS state, or other remote service calls. The art lies in keeping as much code free from side-effects as possible, but it’s rarely only the “shell” that is imperative.

Regarding functional (de)composition and proper structuring, that was very much a thing in imperative programming from fairly early on. That’s not specific to a functional style.

I suspect that it depends on the context in which people first learn about it whether they associate it with functional programming or not.

And I think that a lot of the aversion to functional programming advocacy comes from advocates demonizing anything imperative, while in reality a mix of both is appropriate.

[ux266478]

> Functional-programming evangelists tend to be on the stricter side, though.

> I think that a lot of the aversion to functional programming advocacy comes from advocates demonizing anything imperative

I find these types to often be more motivated by things like nicely designed grammars and powerful type systems more than functional programming itself. A convenient test is give someone over to a J codebase. If they principally learned in a functional environment, or otherwise mastered functional programming, they'll love it. If they just like having language features that aren't 50 years old, they'll want to tear their hair out.

I have seen academic-types that abhor the idea of a flip-flop. I'm not programming a blackboard, so I pay this no mind.

> When programming with “functional core with imperative shell”, is that functional programming overall?

The functional parts surely are. The imperative parts are probably not (since they have to be very granular). Why reduce it to a binary overall? A complex codebase is a highly entropic thing. How much does the functional core influence the non-functional shell? It probably varies, and would require a high dimensional manifold to accurately graph.

> Regarding functional (de)composition and proper structuring, that was very much a thing in imperative programming from fairly early on.

Imperative and functional aren't generally mutually exclusive in my eyes. You can use statements to structure programs in a functional manner. No problem.

Threaded code is relatively similar to functional programming, but it's also very dead unfortunately. Most people's introduction and exposure to it is exclusively through Forth toys. It was (and maybe still is?) a real assembly technique. You need better control over the callstack than you get out of most imperative languages these days.

Point-free style is a critical component of functional programming in my eyes. Far more important than purity. It's not exclusive to functional programming, but it's pretty much holding up half the sky. Without it, you get crap like recursively descending a list of function pointers and void* args. Not ergonomic.

I should also note that I would consider ENIAC's programming paradigm to be rather close to functional:

https://www.cs.drexel.edu/~bls96/eniac/simulator.html

[motorest]

> I'm not sure that your objection puts anything to rest, least of all a "cargo cult mentality". You re-assert exactly what I say just to disagree and miss the rest of the post.

Not quite. I'm pointing out how your argument is based on a cargo cult mentality where throwing "functional programming" labels at practices is all that's needed to fix any and all problems. It is not. Functional programming has been a thing for decades and you still get software with the same rate of bugs and failures than your average codebase.

> Codebases which are not written in a functional style are not functional programming, no matter the language being used.

This is another predictable way on how the cargo cult mentality copes with the failures to live up to the extraordinary claims. You're pinning the blame of the bug-free cargo planes not landing on your makeshift functional programming airport because of how the cult of functional programming is being practiced wrong.

The truth of the matter is that programming paradigms are not panaceas, and developers still need to be mindful of software engineering best practices to minimize the risk of introducing problems.