
Clever Functional Design - gsempe
https://ferd.ca/clever-functional-design.html
======
macintux
> 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 incredibly valuable.

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

~~~
voxl
Constraints are not necessary for creativity.

~~~
tlb
What would you point to as the most creative thing done with zero constraints?

~~~
stonesixone
Speaking personally, I would say I'm most creative when dreaming (where there
are no constraints).

~~~
dkersten
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).

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

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

