5 ms·

But it doesn't encode Maybe/Option in a composable way. Say you have a Map<T,Option<U>> and you look up a key. If the key is present but maps to None, you get S

But it doesn't encode Maybe/Option in a composable way. Say you have a Map<T,Option<U>> and you look up a key. If the key is present but maps to None, you get Some None, but if the key is not present, you get None. A plain untyped null/nil results in a lossy encoding of the two distinct cases. Lispy maps tend to paper this over by returning multiple values or returning a tuple (e.g. using Clojure's `find` instead of `get`), but I almost never see a codebase maintained with enough discipline to handle these situations consistently. If you have multiple developers working on different parts of a record-munging pipeline, you will typically have to deal with endless bug regressions involving the silent disappearance of key-value pairs that come and go depending on the order in which you compose the transformations.

3pt14159 8y ago
I think it fundamentally boils down to how you see the data. People that think in RDMS terms see the existence of the record as an implicit existence of the mapping key, since every record of a table has every attribute. If the record is not there, then it truly is None as in non-existence (no key present) but that operates at a different layer in our applications because the missing object doesn't have the methods or attributes of the class. It's a different class entirely! So in that sense the conflation issue with key => null vs no key at all is itself a mishandling, since it's operating on different classes of objects. This is what you call "paper overing" but I don't think it is fundamentally wrong, I think it's just a different way of reasoning about the data. It's also why I think the functional programming community prizes maybe monads more than the object orientated community. Functional programming is fundamentally about managing streams of data with functions that match up types, so the distinction between none and null matters because the data doesn't drag along it's methods from place to place.

3pt14159 8y ago

I think it fundamentally boils down to how you see the data. People that think in RDMS terms see the existence of the record as an implicit existence of the mapping key, since every record of a table has every attribute. If the record is not there, then it truly is None as in non-existence (no key present) but that operates at a different layer in our applications because the missing object doesn't have the methods or attributes of the class. It's a different class entirely! So in that sense the conflation issue with key => null vs no key at all is itself a mishandling, since it's operating on different classes of objects. This is what you call "paper overing" but I don't think it is fundamentally wrong, I think it's just a different way of reasoning about the data. It's also why I think the functional programming community prizes maybe monads more than the object orientated community. Functional programming is fundamentally about managing streams of data with functions that match up types, so the distinction between none and null matters because the data doesn't drag along it's methods from place to place.