4 ms·

Careful. Functional is often harder to debug. The very "state" functional likes to avoid is often an excellent x-ray point(s) for debugging. It's one of the rea

by tabtab 5y ago

Careful. Functional is often harder to debug. The very "state" functional likes to avoid is often an excellent x-ray point(s) for debugging. It's one of the reasons functional fails to take off in the mainstream despite being around 60 odd years. Service-ability often trumps parsimony in team code. I'm just the observant messenger. There are exceptions, but they tend to be transient.

hjek 5y ago
> 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.
- Twisol 5y ago
  > 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 https://news.ycombinator.com/item?id=27642263
  - hjek 5y ago
    > 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 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.
    - Twisol 5y ago
      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.
rhines 5y ago
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.
- tabtab 5y ago
  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.
divs1210 5y ago
Let me show you the interactive debugger for Clojure in Emacs: https://docs.cider.mx/cider/debugging/debugger.html https://docs.cider.mx/cider/debugging/debugger.html
- tabtab 5y ago
  // 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?
  - rmetzler 5y ago
    this is not what procedural vs. functional is. Both funcs are equivalent.
    - tabtab 5y ago
      What definition of "functional" are you using?
  - divs1210 5y ago
    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.
mbrodersen 5y ago
It sounds to me as if you don’t have much real world experience developing software in a functional language. Am I right?

by tabtab 5y ago

hjek 5y ago

> 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.

Twisol 5y ago
> 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 https://news.ycombinator.com/item?id=27642263
- hjek 5y ago
  > 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 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.
  - Twisol 5y ago
    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.

rhines 5y ago

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.

tabtab 5y ago
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.

divs1210 5y ago

Let me show you the interactive debugger for Clojure in Emacs: https://docs.cider.mx/cider/debugging/debugger.html https://docs.cider.mx/cider/debugging/debugger.html

tabtab 5y ago
// 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?
- rmetzler 5y ago
  this is not what procedural vs. functional is. Both funcs are equivalent.
  - tabtab 5y ago
    What definition of "functional" are you using?
- divs1210 5y ago
  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.

mbrodersen 5y ago

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