> it was the structural constraint of already being in an immutable context that prompted the cleaner design.
Yes! This is what I think most languages retrofitted to include functional features miss: the constraints of immutability and (customarily) no global variables force you to think about what data you actually need where, and often lead to a cleaner design.
Constraints are necessary for ingenuity and creativity too.
Also, those constraints create consistency though necessity. For example, you can write immutable code in Javascript/Python/Whatever, but because it doesn't force it on you through constraints of the language, you have no guarantees that other parts of the application follows your immutability rules, so many of the benefits are lost. Being able to make assumptions about a program, because the language enforces them to be true, is very useful.
If we're talking anecdotes, I've always been most creative when I have tight constraints to work within (technical, time, aesthetic etc). For example, some of my most imaginative code was when trying to fit some code into a teeny tiny microcontroller. Some of the most fun too (provided that time wasn't also a constraint, I find that mixing a time constraint with other constraints often turns it from a fun puzzle to a stressful task).
> force you to think about what data you actually need where, and often lead to a cleaner design.
This is key. Because you have to be explicit about what state is retained, and how it is passed, you are forced to consider it more carefully. For most software, operating on data and storing state are the most important things -- it feels right to be forced to focus on it.
Nice. Although it's not mentioned, it seems like the insight here is partially about the lingering effects on the API of one model of persistence?
A log is normally considered a stream that's too large to keep in memory and needs to be incrementally persisted to disk on the fly, in timestamp order. (Or at least, the traditional file-based way does that, which affects the API.) But each HTTP request happens in memory and its log could be kept there.
A downside might be if the server crashes in the middle of a request, the request is entirely unlogged? But maybe you could log some values to disk and merge them later.
It wouldn't make sense to log most of these events outside the context of the http request -- it makes sense to smash it all into the one log line. Otherwise you have no simple way to tie everything back together; you could make an id for each request and tie everything back to that, but that is inconvenient, slow, and mostly a way to justify a Hadoop cluster you don't actually need.
That's not the key insight though. The key insight is not to try to log the time something took -- instead, log the beginning and the end, and calculate the duration later. This makes the logging apis much simpler and enables measuring times between events in different scopes without coupling the different scopes.
Yes! This is what I think most languages retrofitted to include functional features miss: the constraints of immutability and (customarily) no global variables force you to think about what data you actually need where, and often lead to a cleaner design.
Constraints are incredibly valuable.