IMO the essence of programming is the definition of abstract interfaces and the composition of components within a context according to those interfaces. The e

IMO the essence of programming is the definition of abstract interfaces and the composition of components within a context according to those interfaces. The essence of functional programming is the composition of components that create their results without modifying their execution context in any way that could be detected by a failure of referential transparency. With that definition, functional programming is a style, not a class of languages. An assembly routine that computes a cosine is a functional program. I typically write C/C++ code in a functional style, constructing and returning new data structures rather than modifying arguments in place, because it's so much easier to test, use in parallel code, and reuse later. So I don't think that strong typing, higher kinds, higher order functions, algebraic types, pattern matching, anonymous closures, polymorphism, or garbage collection, e.g., are necessary to functional programming (although they're all wonderful and Haskell seems to have collected just the right mix of features together into a language that I love using whenever I can). It's about whether or not your components have interfaces that are like mathematical functions.