9) Never misuse an abstraction. An abstraction provides a certain set of tools; use them and only them.
-
-
18) Responsibilities should be clearly separated. This applies from kernel modules through network citizens.
Show this thread -
19) Dualities must be faced head-on and analyzed differently at different layers. Statically typed vs. dynamically typed, imperative vs. functional, code vs. data, and effectful vs. pure can all be a matter of perspective, and all relevant perspectives must have coherent answers
Show this thread -
20) One hundred lines of simplicity is better than twenty lines of complexity. It's not enough for an abstraction to reduce code duplication; it must actually make the code simpler.
Show this thread -
21) Prefer mechanical simplicity to mathematical simplicity. Often mechanical simplicity and mathematical simplicity go together.
Show this thread -
22) The Law of Leaky Abstractions is a lie; abstract airtightly. If your abstractions are leaking, it's not due to some law of the universe; you just suck at abstracting. Usually, you didn't specify the abstraction narrowly enough.
Show this thread -
23) Some cliches are repeated because they are true; others must be repeated because they are not.
Show this thread
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.