I learned Haskell in just 15 years

Functional programming benefits and limits

• Many see FP (and Haskell) as a way to learn better software design: modeling domains declaratively, isolating side effects, and composing small functions.
• Several argue FP can be a huge productivity boost for hard problems (powerful abstractions, less boilerplate for traversals, error handling), but may hurt productivity for “easy” tasks or when the domain fits imperative thinking better.
• Others counter that you can learn most of these lessons in imperative languages too, though progress tends to be slower without being “forced” into a new paradigm.

Purity, side effects, and “Hello World”

• Discussion distinguishes “functional” from “pure”: many FP languages allow side effects; Haskell mainly makes them explicit via types (e.g., IO), which helps reasoning and testing.
• There is debate on whether Haskell is truly “pure” given exceptions, unsafe primitives, and bottom; some prefer the more precise term “referential transparency.”
• Pure languages are praised for making side effects explicit and quarantined at boundaries, but some feel this just shifts complexity into types and abstractions.

Ease of use, syntax, and maintainability

• Some find Haskell elegant and its code easy to understand once learned; others criticize its syntax, operator proliferation, layout rules, laziness, and difficulty of debugging.
• Tension over maintainability: one side reports large, stable Haskell codebases with safe refactors; the other claims Haskell is a poor tool for typical “real‑world” teams and leads to over‑abstract code that’s hard to hand over.

Performance and domain fit

• Conflicting claims on performance: Haskell/OCaml described both as slow and memory‑heavy and as surprisingly fast (sometimes within ~50% of C) when written idiomatically.
• Pure FP is seen as awkward for certain algorithms (e.g., in‑place quicksort, histograms) that map naturally to mutable arrays.

Alternative FP languages and ecosystems

• F#, Scala, OCaml, Clojure, Elm, PureScript, Idris, Unison, Elixir and others are discussed as more approachable or pragmatic options, often with better tooling or ecosystems in certain domains (.NET, JVM, web, cloud).
• Some prefer “functional‑first” languages that allow dropping into OOP/imperative styles when convenient.

Culture, team fit, and learning paths

• Reports of excellent Haskell teams as well as serious culture clashes when FP‑oriented developers join imperative shops (over‑engineering, rewrite pressure).
• Suggested learning paths include Haskell itself, but also F#, Elm, Unison, Prolog, and project‑based materials (games, blog generators, small interpreters) plus books and blogs on domain modeling and algebraic design.