5 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. Wat. Yes, if you

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

by hjek 5y ago

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.