3 ms·
Somewhat related is the Lispy approach of using generic data structures (e.g. cons lists); compared to the OOP approach of defining new (hierachies of) datastru
by chriswarbo 4y ago
Somewhat related is the Lispy approach of using generic data structures (e.g. cons lists); compared to the OOP approach of defining new (hierachies of) datastructures/types/interfaces (usually classes) for each use-case.
With the former, there's an ever-growing set of functions we call on our data; whilst the latter is incompatible with all existing code.
- convolvatron 4y agohaving a common syntax gets you a crude kind of type-generic behavior. you can can write functions that just deal with 'stuff', including functions to merge data and to serialize/unseriaze. maybe you also get a base type system. maybe include some transport functions like idempotency...write a little data viewer. you can build stuff on top of this - including additional semantics, like adding a schema with the same underlying representation in order to do validation. or transactions - nothing to say say that the body can't be another one of these generic data items wrapped up in a transaction envelope - or signed like a cert. I dislike 'narrow waist', although I understand the image. it seems to me to really be about what everything always has been - separation of concerns and low level functions that support reuse.