Hacker News Reader

Comment by tabtab | Hacker News Reader

Functional (FP) tends to be a "personality fit" thing. Many who do just fine in procedural and/or OOP don't transition to FP well.

FP shops have tried since the early 60's to stay viable and expand, but usually fail outside of niche domains. I'm just the messenger. FP has had more than plenty of shots throughout history to prove its mettle in the real world.

I personally have found FP hard to debug. The "naked state" of imperative programming is actually helpful when debugging, because the context is laid out on a nice little e-desk to examine. With FP you mostly have to open and inspect one drawer at a time.

One FP proponent replied, "well, then make fewer bugs." No comment, other than reminding that one can't control other people's creation of bugs even if they can control their own.

View on HN

> I personally have found FP hard to debug.

I can very honestly say pure functions are the easiest thing to debug and test: Inputs, outputs. Trivial for unit testing.

I can't speak for MLs/Haskell, but debugging pure functions in any language tend to just be glancing at the stack trace, seeing the values on the stack going in, and then seeing where the unexpected wrong output came out, and being fairly confident knowing the issue is going to be in that function.

> The "naked state" of imperative programming

Are we including OO in this definition? The fundamental design pattern of OO is to encapsulate state. It's anything but naked, always being wrapped in object instances, only accessible via getters/setters, scattered into a million pieces across many instances of the system.

Conversely, Clojure has the most naked state ever. There's usually little to no state, and the current state is right there on the stack. Most simple Clojure programs with state have a singular atom aptly named "state" which is passed around, easy to inspect and modify as it's a simple data structure.

I think, ultimately, there's a common conflation of "Functional Programming" meaning "Declarative Type-Driven Functional Programming", when the reality is there are alternatives to ML/Haskell, aside from applying Functional patterns in "non-functional" languages.

If you can document how to do and think "properly" and efficiently under FP, that would be helpful. Sometimes it's really hard to convey how our mind works to other minds. Thus, "it works for me" is hard to extrapolate.

I really like the concept of "compression oriented programming" that Casey outlines here. You write an imperative program and make functions and objects as "compressions" of your original code, where suitable. That way you don't end up with a jungle of objects, and, on the other hand, don't start constructing monads or producing hundreds of tiny functions just for the ideology of it all.

Keep in mind that what may seem like "personality fit" may be more related to "learned imperative programming first".

As an analogy, depending on which spoken language a person learned first (as a child, _automatically), learning some new languages may be particularly difficult or quite natural.

If we had all learned functional programming concepts first, our minds would be trained to think that way. We all learned functional (declarative) math, and we don't even think about it as such. It's just math.

This video gives some plausible explanations as to why imperative programming is more common than functional: https://youtu.be/QyJZzq0v7Z4

That may be part of the problem, but it also may be true that some minds simply work better under one paradigm than another. Since one must show proficiency in imperative to get into the field, that's a filtering mechanism that guarantees most programmers can handle imperative already. If they change to functional, some may not handle it so well, taking much longer to learn.

Observations of various organizations that tried it seem to confirm this. They have problems after the original team leaves.

Reply on news.ycombinator.com