3 ms·

I think this is a long term investment that goes beyond engineer / language /etc. preferences. It's a matter of abstraction 'stability'. There's a cost for eac

I think this is a long term investment that goes beyond engineer / language /etc. preferences. It's a matter of abstraction 'stability'. There's a cost for each abstraction, so modeling without fully understanding what you try to model or something that changes wrt the abstraction model will yield incomplete abstractions, be hard to read, etc. Many things are being remodeled over an over (incomplete, with bugs, etc.) when in fact they don't change much. These are good candidates for good abstractions. I don't think you'd want to do 3d graphics without a system that understand the algebraic aspects (e.g. orthogonality) behind rotations, translations, etc. Categories generalize this all the way so optimizations would be possible at a whole different level (makes me think about what Tensorflow enables). I also think you only need one category (just like you only need one group / semigroup concept) for a model and it could be language agnostic.

codygman 6y ago
> 95% of Go programs could be replaced with a single traverse This is a rather abrasive way of putting it that tries to communicate this point. I would have found it difficult to even entertain when my Gopher squishee on my desk and I came across it as someone very in love with Go at the time. The point though is that for loops in Go are unstructured, but very flexible. That lack of structure lets you have any organization you have, probably influenced by previous languages you've used. Structured recursion like folds and maps enforce a certain pattern to this, the same goes for traverse. That idea isn't specific to traverse though, it generalizes to all of the Haskell abstractions. The reason people talk about composability so much is because composable code means re-usable, concise as in KISS , and elegant code.

3 ms·

I think this is a long term investment that goes beyond engineer / language /etc. preferences. It's a matter of abstraction 'stability'. There's a cost for eac

by random3 6y ago

codygman 6y ago
> 95% of Go programs could be replaced with a single traverse This is a rather abrasive way of putting it that tries to communicate this point. I would have found it difficult to even entertain when my Gopher squishee on my desk and I came across it as someone very in love with Go at the time. The point though is that for loops in Go are unstructured, but very flexible. That lack of structure lets you have any organization you have, probably influenced by previous languages you've used. Structured recursion like folds and maps enforce a certain pattern to this, the same goes for traverse. That idea isn't specific to traverse though, it generalizes to all of the Haskell abstractions. The reason people talk about composability so much is because composable code means re-usable, concise as in KISS , and elegant code.