> They start mandating restrictions on input/output, what functions should be used for Like what? You've thrown out a ton of generalisations, but nothing here

> They start mandating restrictions on input/output, what functions should be used for Like what? You've thrown out a ton of generalisations, but nothing here is concrete. > When you take all the stupidity, assumptions, and restrictions away functions are most universally a bag of instructions, as are classes and various other things. If you group all things together as a 'bag of instructions' then there's no point in teaching functional concepts or any paradigm's concepts for that matter. I am reading between the lines here, but I am assuming by 'restrictions' you're referring to functions taking immutable values and returning immutable values. There are sensible reasons for this (along with referential transparency in general) that enable function composition, which is the 'super power' of functional programming. It isn't a requirement, it's just good practice, and so I can understand why FP advocates would promote it (I certainly do). A class can have those powers too if it is immutable, because ultimately any class is just a set of functions with an implicit 'this' argument, but it's often understood differently. It doesn't seem unreasonable to promote and talk about the differences in approach, especially in languages that allow you to 'cheat'. Yes, the narrow definition of a functional language is that it has first class functions. Clearly though there's techniques for success within the paradigm. Again, it's quite hard to latch onto exactly what you're saying here, but I don't think functions as structure is the argument for FP (as such), it's functions that work like mathematical functions, to leverage the centuries of knowledge of mathematical expressions, proofs, etc. Personally, I find my functional code much easier to understand, compose, test, and generally have confidence in. When I compose two functions I don't have to 'go and look inside' to see what it does first, because they're pure and declarative. The declarative nature of the functions is an artefact of following the good practice of immutable values, referential transparency, and total functions which lead to 'honest' type-signatures, it just happens on its own. I spent a reasonable part of my career in imperative-land, and honestly I wish I'd found functional programming much earlier. I write fewer bugs and I have more confidence in my code. And yes, it adds constraints that are annoying sometimes, but those constraints ultimately stop the code becoming a cognitively difficult mass of mutation or hidden complexity.