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