On Tuesday, October 30, 2012 6:41:31 PM UTC-7, Cédric Beust ♔ wrote:
>
>
> On a related note, I find it funny when people advocate Option because "it
> forces you to deal with null pointers instead of ignoring them" and then
> rant against checked exceptions because they force you to do exactly the
> same thing. I was also a bit surprised that the whole discussion on
> Optional in the podcast never mentioned a single time the main benefit of
> Options (composability) while casually discussing practices that are sure
> to lead to pain (calling get() or pattern matching on the content of an
> option), and by extension, discourage people from using Option altogether.
>
> --
> Cédric
>
>
Hi Cedric
I could have sworn that my whole point on the podcast *was* to talk about
what you call the "composability" of the option type, which is due to the
monadic nature of it if you want to be technical, but that was certainly
the point of the discussion - I will try again in the next podcast to make
sure it is super clear.
I am pretty sure I remember saying something along the lines of: sure you
can use pattern matching or if (x == None) to use options, but to do so is
missing the point, far better is this form:
val zips = for (person <- people; address <- person.addressOption; zip <-
address.zipOption) yield zip
Ok - that's a coarse example, but it shows the point, which is that you
start with some people, and get a list of the existing zips from that list
assuming that the person has an address, and the address has a zip. If not,
the for expression gets short circuited and you don't get the zip. It's
very understandable code with a high signal to noise ratio especially
compared with (I would write Java, but I would probably make a mistake
writing it after 3 years not using it, so I will write Java style Scala
with the null checks):
val zipsMut = mutable.ListBuffer.empty[String]
for (person <- people) {
if (person.address != null && person.address.zip != null) zipsMut +=
person.address.zip
}
val zips = zipsMut.toList
I think that's fair code - I even put the two null checks in the same
predicate knowing that it won't run the second if the first fails (fair,
but you need to know that lore about the language too in order to know
there can't be an NPE in that second dereference).
I even remember saying that the real value of Option in Scala, Haskell and
other languages that offer it is that it is integrated into the core
libraries for doing stuff like this. That's the real value and I remember
saying on the podcast that I can understand the position of the folks doing
Optional in Java - even if the flatMap was there, it would only really be
useful if the core libraries were retro-fitted to use options over nulls,
and if there was language support for options in the form of a for
expression or similar.
Did anyone else get that I was trying to say this? Certainly I will clear
it up in the next podcast.
I know you have a thing about me saying Option has eliminated a whole class
of runtime errors - namely NullPointerExceptions - from my code and fair
enough, I won't say that. I will say instead that Option has
enabled/encouraged/caused me to write natural looking code easily with less
bugs in it, period. Is that better?
On the other point - I get what Java was trying to do with checked
exceptions, but the problem is I have rarely (if ever) seen them used well.
The problem is that they are a pain, all that re-throwing or catching, so
people abuse them or subvert them or just plain avoid them. Just like
Option (when you get into the mindset) makes a nice, easy, readable
alternative to nulls and null checks, so Either when you get into the
mindset makes a nice, readable, easy alternative to checked exceptions.
It's convenient to use them and pass them along, which it almost never
seems to be with checked exceptions and which is why most code I have seen
either logs them and forgets them, re-throws them as runtime exceptions, or
just ignores them altogether (IOException on file close...?). Ultimately
the real judge of checked exceptions is that (as far as I know) there are
no new main-stream languages that adhere to them, even Kotlin or Fanton
(which are aiming at being the Java++ languages).
Dick
--
You received this message because you are subscribed to the Google Groups "Java
Posse" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/javaposse/-/LzXZ7yKgRnsJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
