> Careful. Functional is often harder to debug. The very "state" functional likes to avoid is often an excellent x-ray point(s) for debugging.

Wat. Yes, if your bug relates to a certain state, then you'll have to debug the state, but (a function or a program) being stateless means automagically avoiding all bugs relating to state; thus you don't need those "x-ray points". Also, you don't need to know whether a given function mutates it's argument or returns the result (or both), which is a pain in JavaScript, and even with Common Lisp's sort "function". If your language is immutable by default you just never have to watch out for accidental mutations. No "x-ray" needed, because functional programming (done properly) shouldn't be a leaky abstraction.

> but (a function or a program) being stateless means automagically avoiding all bugs relating to state; thus you don't need those "x-ray points".

That's not entirely true, at least the way I understand "state". You still can, and do, model state in stateless systems; the programming environment just doesn't give you mutable, named cells for free. State is modeled by, for instance, observing how the arguments change in each self-call of a recursive function, or by the value observed between stages of a functional pipeline. These are what I would consider the analogous "x-ray points".

I don't disagree with you, but I find the benefits are more about lifting state out of the steps and making it visible, rather than eliminating the concept of state.

Relatedly, "Immutability is not enough", from a couple days ago: https://news.ycombinator.com/item?id=27642263

> You still can, and do, model state in stateless systems;

Yea, in functional programming it's easier to focus on the essential state inherent to the problem, and avoid introducing accidental state.

> Relatedly, "Immutability is not enough", from a couple days ago: https://news.ycombinator.com/item?id=27642263

Okay, interesting article, but I don't agree with this bit:

> It turns out that our purely functional rendering code is sensitive to ordering in non-obvious ways. The first time I encountered this kind of bug, it felt strangely familiar – it’s something that often occurs in imperative programs. This is exactly the kind of problem that functional programming was supposed to help us avoid!

I don't think functional programming is supposed to help you with if you misunderstand the essential logic of the problem. I'd argue that declarative languages (like Prolog and SQL) can help avoid this type of ordering bug though by making variable assignment explicit.

I agree with you on the linked article ^_^ but it does at least do a good job of showing how the concerns of state still exist in the absence of mutable data.

You can still step through functional code an examine local variables, you just have the assurance that the values of any local state are purely dependent on the inputs to the function and not any other external state. So it's ultimately easier to debug - any values that affect the operation of a function are explicitly set when calling the function, and you don't have to worry about figuring out ways to ensure that runtime-generate state matches whatever it was when the error originally occurred.

In theory you wouldn't have many "local variables" if you followed functional practices.

Re: "you just have the assurance that the values of any local state are purely dependent on the inputs to the function and not any other external state."

I don't see that principle helping much in practice.

Let me show you the interactive debugger for Clojure in Emacs:

https://docs.cider.mx/cider/debugging/debugger.html

     // procedural style
     func foo01(a) {
       b = x(a);
       c = y(b);
       r = z(b,c);
       return r;
     }
     // functional style
     func foo02(a) {
       return z(x(a), y(x(a)));
     }

With foo01, one can readily study the value of "b", "c", and "r" in a debugger and/or a Write() statement. With foo02 it's harder to do the equivalent. A good debugger will let you explore the output of a given function call in foo02, but you still have to rework the code to put those into a Write() statement. A direct debugger is sometimes not sufficient, especially in big loops.

It's also easier to read the first style. It's more like a bulleted list:

    - Step 1
    - Step 2
    - Step 3

The functional style is often an awkward horizontal string of chained steps. Sure, the formatting can be adjusted, but it takes more effort, training, and/or discipline to format functional code to make it legible to ordinary code maintainers. Procedural just handles riff-raff better; functional requires ideal conditions/staff.

PS, do I really deserve a -4 score above?

Both are functional styles.

    (defn foo01 [a]
      (let [b (x a)
            c (y b)
            r (z b c)]
        r))

and

    (defn foo02 [a]
      (z (x a)
         (y (x a))))

are both valid.

I prefer the first one where I can see the intermediate steps clearly.

this is not what procedural vs. functional is. Both funcs are equivalent.

What definition of "functional" are you using?

It sounds to me as if you don’t have much real world experience developing software in a functional language. Am I right?