As soon as you have user names with an associated history, you're dealing with state. Functional programming is a style of managing state transitions, not avoiding them.
I'm not suggesting I can get a free lunch. I wasn't talking about avoiding state transitions. I wasn't even talking about pure functional programming. By talking about variables captured by closures, I'm implicitly not doing so.
In the context of server programming, by using the word 'statelessness', I meant that the request (from clicking the link) doesn't need to go back to the same server that created the link. Having an in-memory hash-table containing closures or continuations keyed by an ID in the request implies that request needs to ultimately reach back to the same machine, one way or another.
I'm talking about programming the Lisp-style multi-request process using continuations (as described by pg in his essays), except making them work in a stateless way - without the requirement for hash tables full of continuations that need periodic collecting, with the consequence that the links go stale.
A request handler generating such continuations would, of course, need to be simple and lightweight, not deep or complex. Code artifacts and stateful resources would need to be serialized using keys that contain enough information to find or recreate them. Imagine having server-side URLs for every function, for every resource, where doing a request for a function pointer or a resource could potentially open a database connection or load a library. The keys would be analogous to such URLs.
Consider an activation record. It is the storage for local variables, parameters and the function return location (aka continuation, when you twist your mind around it). The activation record for any given function has a particular signature. Let's say one of these local variables is a Customer object, mapped by an ORM from the database. That is something that can be reduced to an ID; if you know that this activation record only ever has a Customer in that slot, you can potentially serialize that object as a single number.
Keep the chain of activation records short, and they act mostly as a path through a tree to the current state of a process or interaction. Function a calls function b calls function c, which returns a result to the client, along with a continuation (or more interestingly, multiple continuations). A serialized continuation would be little more than a record of the current step in the overall process, everything needed to pick up where one left off. I think, with the right level of language abstraction, this can be made very slim.
(PS: I detect a certain amount of exasperation in your tone. I'm not sure what I did to trigger it.)
Thank you for elaborating. It appears that you're thinking about an application in the abstract (e.g. Customer objects) rather than HN in particular. Perhaps that is the source of my dissonance...I don't think it is critical for HN to serve up state in real time, but that's just me.
HN is serving up state, BTW, HATEOAS-style, because your front page is customized to you. Only problem is (was) the expiring links - the page is stateful server-side, not just client-side. This article is about making HN more HATEOAS, that IMO makes it technically serving up more state (parameters on the URLs it embeds in the page, for one). My comment was about a way of having a more HATEOAS semantics with respect to statefulness, but less programming cost server side.
As soon as you have user names with an associated history, you're dealing with state. Functional programming is a style of managing state transitions, not avoiding them.