3 ms·
As I see it, being declarative and limiting depth of function calls go hand-in-hand. Also very, very closely related is locality. It's really hard to give a g
by sodapopcan 4y ago
As I see it, being declarative and limiting depth of function calls go hand-in-hand. Also very, very closely related is locality.
It's really hard to give a good example (because it's not an easy problem), but I really want to see a high-level procedure that describes (declares) every important thing that is going on (from a business standpoint). Then ideally, I only have to dive into each function once to get enough context on the main procedure. Any further dives are library/util-type calls (again, I'm talking super ideally here).
And even though I used the term "procedure" twice there, I'm talking about either FP or OO styles.
And of course (oh boy) the context can change everything.
- pramodbiligiri 4y agoI agree so much with this. I prefer that all lines in a function are at the same level of abstraction w.r.t your problem domain. One line can't be about customer accounts and the very next one about the file system! I also feel that Local Reasoning is a very powerful capability in code. In fact, Martin Odersky the creator of Scala pointed to an article that headlined Local Reasoning as one of the clearest explanation of Why FP matters (https://twitter.com/odersky/status/1271182333467602945?lang=en https://twitter.com/odersky/status/1271182333467602945?lang=...). Any abstraction (here I include complex types) is a trade-off against local reasoning. Anything that makes the reader of the code drift far away from what they're currently reading on the screen is a hit against local reasoning. So they've to be introduced judiciously.