DEV Community

Discussion on: Is Haskell bad for FP?

Collapse
 
eljayadobe profile image
Eljay-Adobe

Languages are tools. Some tools are more (or less) suitable for a particular problem domain.

Pure functional programming languages, like Haskell or the rapidly evolving Elm, have an appeal as a viable alternative to OO languages. Because they are pure, they disallow the option of backsliding to OO ways.

The FP benefits I expect in an FP language:

  • first-class functions
  • referential transparency
  • immutability
  • strong typing
  • recursion
  • pattern matching
  • higher-order functions
  • code-as-data
  • separation of behavior from data
  • side-effect free functions
  • curried functions
  • partial function application
  • concise FP-centric syntax

Pragmatic functional programming languages, like OCaml or F#, compromise on the FP-ness in order to "get work done". FP purists might find them distasteful.

Hybrid languages, like Clojure (Lisp, with some FP constructs), or Scala (primarily OO, with some FP constructs), can be a good way to get some FP on their respective platforms.

And then there are folks that try to promote Lisp, C++, or Swift as functional programming languages, merely because they have some FP-isms or FP-ishness. Which just makes me want to tell them, "Please use F# for a couple months. Then you'll understand what a FP language is, and why (non-FP language X) is not an FP language."

I've programmed in Lisp for about 3 years. I've programmed in F# for a year. I can't imagine that anyone that has programmed in any of the ML family of languages would describe Lisp as an FP language. Lisp is more powerful than that; I'd describe Lisp as a programmer's programming language, and any other language falls into The Blub Paradox.

But that doesn't make Lisp the most suitable language for all problem domains.

I think... the future of programming languages will be FP and DSL. It will take years before FP and DSL overshadow OO languages, but that is how I read the tea leaves.

I’ll wind down with a lie that OO people who are learning FP tell one another: “Learning FP will make you a better OO programmer.” It rings true, and in the short run it may even be true, but as you internalize immutability, recursion, pattern matching, higher-order functions, code as data, separation of behavior from data, and referential transparency, you will begin to despise OO. Personally, I went from being a Microsoft C# MVP to feeling guilt every time I created a new class file. Once you understand the defects that can be avoided, it stops being a technical choice and becomes an ethical one.
— Bryan Hunter, CTO, Firefly Logic
The Book of F# (in the Preface)