5 ms·

Do people generally agree that Java Optional == Scala Maybe / Haskell's Maybe? Java's Optional seems fundamentally flawed in that Java allows any reference to

by AJRF 8y ago

Do people generally agree that Java Optional == Scala Maybe / Haskell's Maybe? Java's Optional seems fundamentally flawed in that Java allows any reference to hold a null value and Optional can still throw a NPE when calling isPresent on it so it still gives people a footgun.

based2 8y ago
Maybe Not - Rich Hickey (clojure), 29 nov. 2018 https://www.youtube.com/watch?v=YR5WdGrpoug https://www.youtube.com/watch?v=YR5WdGrpoug https://dotty.epfl.ch/docs/reference/intersection-types.html https://dotty.epfl.ch/docs/reference/intersection-types.html
- fmjrey 8y ago
  Yes I was going to mention that video in which Rich makes an important point in my opinion: database tables, or objects, or structs, still live within the Place Oriented Programming (PLOP) mindset. That mindset was born in a time where disk and RAM were the expensive resource therefore update-in-place was the default. I insist on the "in-place": you need to know where something is so you can update it. The downside of PLOP is that if you have no value for one of the slot in your generic form (be it a table, object or struct) then what can you put there? The alternative is to use data shapes that do not require something to be in a certain place. Hence the use of maps as the most basic data shape: you either have an entry in it, or you don't, no need to have a null entry. Expanding that thinking to databases, and you realise tables is not the right aggregate, instead you need to go one level down to something that datomic calls datom, or RDF calls a fact. To summarise, PLOP forms that package together a set of slots to be filled magnify the issue of NULL/null/nil. Instead make the slot your primary unit of composition and make sure you use aggregation of slots that does not force you to have slots filled with a null value when there is no value in the first place.
- kybernetikos 8y ago
  Yes, 'maybe not' is very relevant to this discussion, but few people seem to agree with my understanding of what he says about the right solution: Optionality doesn't fit in the type system / schema, because it's context dependent. For some functions, one subset of the data is needed, for others a different subset. Trying to mash it into the type system / schema is just fundamentally misguided.
  - gambler 8y ago
    That's exactly what he says. People might disagree that this is the right approach, but I'm not sure what other ways anyone could interpret that talk.
  - fmjrey 8y ago
    Yes, he's rather explicit in saying Maybe is a poor tool. I'll have to watch the talk a second time to be sure, but I'm not sure he proposes any solution at the level of type systems. Not using Maybe or using Union is not what he is advocating. For him (and me too) types are the wrong thing to put data in because, among other things, it forces you back into PLOP. His point is to remove entirely the need to fill slots with nothing. Obviously the talk is more about specs than types. While tactfully avoiding the debate around types, he's still starting the talk with types to help those that are only there to decomplect their thinking.
lmm 8y ago
> Java's Optional seems fundamentally flawed in that Java allows any reference to hold a null value and Optional can still throw a NPE when calling isPresent on it so it still gives people a footgun. The existence of Optional makes it possible to migrate away from using "null". E.g. Map#get could be replaced with a method that returns Optional. Calling isPresent is the wrong way to use an Optional. But yes, it's an ordinary Java value, it can be null as long as Java-the-language permits null. That's not a problem with Optional, it's a problem with Java, and introducing Optional as a plain old normal Java class is the first step to fixing it.

by AJRF 8y ago

based2 8y ago

Maybe Not - Rich Hickey (clojure), 29 nov. 2018 https://www.youtube.com/watch?v=YR5WdGrpoug https://www.youtube.com/watch?v=YR5WdGrpoug https://dotty.epfl.ch/docs/reference/intersection-types.html https://dotty.epfl.ch/docs/reference/intersection-types.html

fmjrey 8y ago
Yes I was going to mention that video in which Rich makes an important point in my opinion: database tables, or objects, or structs, still live within the Place Oriented Programming (PLOP) mindset. That mindset was born in a time where disk and RAM were the expensive resource therefore update-in-place was the default. I insist on the "in-place": you need to know where something is so you can update it. The downside of PLOP is that if you have no value for one of the slot in your generic form (be it a table, object or struct) then what can you put there? The alternative is to use data shapes that do not require something to be in a certain place. Hence the use of maps as the most basic data shape: you either have an entry in it, or you don't, no need to have a null entry. Expanding that thinking to databases, and you realise tables is not the right aggregate, instead you need to go one level down to something that datomic calls datom, or RDF calls a fact. To summarise, PLOP forms that package together a set of slots to be filled magnify the issue of NULL/null/nil. Instead make the slot your primary unit of composition and make sure you use aggregation of slots that does not force you to have slots filled with a null value when there is no value in the first place.
kybernetikos 8y ago
Yes, 'maybe not' is very relevant to this discussion, but few people seem to agree with my understanding of what he says about the right solution: Optionality doesn't fit in the type system / schema, because it's context dependent. For some functions, one subset of the data is needed, for others a different subset. Trying to mash it into the type system / schema is just fundamentally misguided.
- gambler 8y ago
  That's exactly what he says. People might disagree that this is the right approach, but I'm not sure what other ways anyone could interpret that talk.
- fmjrey 8y ago
  Yes, he's rather explicit in saying Maybe is a poor tool. I'll have to watch the talk a second time to be sure, but I'm not sure he proposes any solution at the level of type systems. Not using Maybe or using Union is not what he is advocating. For him (and me too) types are the wrong thing to put data in because, among other things, it forces you back into PLOP. His point is to remove entirely the need to fill slots with nothing. Obviously the talk is more about specs than types. While tactfully avoiding the debate around types, he's still starting the talk with types to help those that are only there to decomplect their thinking.

lmm 8y ago

> Java's Optional seems fundamentally flawed in that Java allows any reference to hold a null value and Optional can still throw a NPE when calling isPresent on it so it still gives people a footgun. The existence of Optional makes it possible to migrate away from using "null". E.g. Map#get could be replaced with a method that returns Optional. Calling isPresent is the wrong way to use an Optional. But yes, it's an ordinary Java value, it can be null as long as Java-the-language permits null. That's not a problem with Optional, it's a problem with Java, and introducing Optional as a plain old normal Java class is the first step to fixing it.