You say that as if FP is objectively superior to the imperative style, but as someone who's done both, I still find FP style like "swimming against the river"—if my brain thinks in steps and iterations, why do the mental gymnastics to convert that into recursion?
FP is principally about function composition, folds and zippers. I still find myself thinking in terms of iteration, it's just not expressed as a for-loop. Instead, the iteration conditions are expressed by the composed function which builds a list, and the body of the for-loop is expressed by the composed function applied to the members of the list.
for(int i = 0; i < N; ++i) { ... }
becomes
foldl (fn (i, acc) => ...) 0 (range N)
It's technically recursion, but I don't really see any of it, and I don't really think about it that way.
Fair point! Programming paradigms aren't objectively superior - they're tools, and different people's brains work differently. Many problems are naturally iterative, and forcing them into recursive patterns can feel awkward. That said, some problems become much cleaner with FP approaches - data transformations, avoiding shared state bugs, or mathematical computations. It's worth having both tools available. use imperative when you think in steps, use functional when you think in transformations. Don't force one paradigm everywhere just because it's trendy or "pure."
But do give yourself this gift - even if you end up preferring imperative style for day-to-day work, learning Haskell or Clojure can be genuinely eye-opening.
It's like learning a foreign language - even if you never become fluent, it changes how you think about your native language. You'll start seeing patterns and abstractions you missed before, even in imperative code.
upd: sorry, only after posting it I noticed your "as someone who's done both". Just wanted to point out that here my suggestion is aimed not to you directly, but to a "proverbial" programmer, I used "you" in more general sense.
Comments
You say that as if FP is objectively superior to the imperative style, but as someone who's done both, I still find FP style like "swimming against the river"—if my brain thinks in steps and iterations, why do the mental gymnastics to convert that into recursion?
FP is principally about function composition, folds and zippers. I still find myself thinking in terms of iteration, it's just not expressed as a for-loop. Instead, the iteration conditions are expressed by the composed function which builds a list, and the body of the for-loop is expressed by the composed function applied to the members of the list.
becomes It's technically recursion, but I don't really see any of it, and I don't really think about it that way.Fair point! Programming paradigms aren't objectively superior - they're tools, and different people's brains work differently. Many problems are naturally iterative, and forcing them into recursive patterns can feel awkward. That said, some problems become much cleaner with FP approaches - data transformations, avoiding shared state bugs, or mathematical computations. It's worth having both tools available. use imperative when you think in steps, use functional when you think in transformations. Don't force one paradigm everywhere just because it's trendy or "pure."
But do give yourself this gift - even if you end up preferring imperative style for day-to-day work, learning Haskell or Clojure can be genuinely eye-opening.
It's like learning a foreign language - even if you never become fluent, it changes how you think about your native language. You'll start seeing patterns and abstractions you missed before, even in imperative code.
upd: sorry, only after posting it I noticed your "as someone who's done both". Just wanted to point out that here my suggestion is aimed not to you directly, but to a "proverbial" programmer, I used "you" in more general sense.