I think the costs are probably something along these lines:
When using an Option type, you cannot use methods on that type directly any
more (that's the point) so you have to understand enough about the
functional approach to use stuff like:
o.map(_.length)
or
for (s <- o) yield s.length
which will still be compile time checkable, and will turn an Option[String]
into an Option[Int] with a possible None outcome if it is missing.
It's also extra characters to type in type signatures (fortunately though
Scala is pretty good at inferring types so that overhead is reduced)
The biggest liability, as you point out, is that because Scala runs on the
JVM, references can still be null. That's a big problem, but (even though
you find the statement irksome - sorry but I can't help what you find
irksome) I have eliminated null in my code. I never set variables to null,
and anything that comes out of Java can be wrapped in an option immediately:
Option("hello") gives an Some("hello")
Option(null) gives a None
so you can take the result of any java method and immediately make it safe
using Option.
In my opinion and experience of working on a rapidly constructed, extensive
calculation engine, the result of using Option throughout has been a far
more reliable system, easier to make agile changes to quickly, and which
produces large numbers of results reliably even when some operations fail
(as they will - the one thing that is consistent in genetic science is its
inconsistency). Our scientists want all the answers that can be calculated,
and to know about the ones that can't, not simply to be told that it can't
do it.
If you work under those criteria, you will end up with a SafeString, or an
option-like construct yourself - it's the logical way to do it. The part
that makes it the most valuable is that it is implemented at the core
library level and hence used by all of the libraries. In the same way that
lambdas in a language make the library APIs tighter and more integrated, so
patterns like this when adopted by the libraries throughout have a similar
advantage.
Another way to look at it is that you say yourself, the down sides
"...which are, oddly enough, hardly ever mentioned by the people trying to
sell me on that...". Two things on this - Cedric - I never tried to sell
Scala to you at all, it seems to me that all of our conversations on the
subject have been started by you, not by me. Secondly, have you ever
stopped to ask yourself why so many people seem to like Option, or indeed
Scala. Perhaps, like me, they just find it really, really good and want to
let others know that. I don't think of the downsides of Option ever when I
use it, I am just grateful that it is there.
Sure there is no silver bullet, of course not (neither are the null safe
operators, or the @nullable annotations - Tor talked about the downsides of
the annotations already on the podcast) but mostly people see that these
improve on what went before. Nullsafe operator actually adds syntax to the
language, which I am not against, but also don't think is necessary here -
sure it saves characters, but if that is what you want Scala provides on
that front all over the place (check out case classes for an enormous win
on that front, or simply having lambdas and the loan pattern).
Dick
On Tuesday, June 5, 2012 10:28:47 PM UTC-7, Cédric Beust ♔ wrote:
>
> Hi Dick,
>
> Thanks for taking the time to jump in.
>
> A few thoughts:
>
>
>> Option is absolutely a static type solution to the problem.
>> Option[String] is not a String.
>>
>
> This was my point: if it's okay to change types, then it's hard to pretend
> that Option is a revolutionary improvement over what we have today.
> "Replace String with SafeString everywhere in your code base and your code
> will be more robust" is a simplistic way of solving problems (the same kind
> that led to the fallacy of using auto_ptr everywhere in the C++ world).
>
> First of all, I've been in this industry for long enough to know that
> there are no silver bullet solution. No technical approach comes with zero
> costs, and while I'm fully able to understand the benefit of a technical
> solution, I'm more interested in hearing the trade offs of said solution,
> which are, oddly enough, hardly ever mentioned by the people trying to sell
> me on that new hot thing. I understand the benefits of Option, now please
> tell me what the costs are? This is what I've been trying to address in my
> previous email and also the older blog post I pointed to.
>
> In particular, the "I haven't seen an NPE in months" justification irks
> me. I have no doubt it's true, by the very definition of Option, but I ask
> you (and anyone who's defending Option/Maybe): what do you think you lost?
> I have asked this question a few times and I have never received anything
> but blank stares, as if most people who jumped on the Option bandwagon
> never even considered the trade offs.
>
> Make no mistake: you *have* lost something while using Option, the
> question should really be "did you lose more than you gained?".
>
> My experience with Option within the JVM has been quite mixed, as I
> explained. I can totally see how Haskell's Maybe is a clearer win, but
> within the JVM and necessary interoperability with Java, the track record
> of Option is much more mixed.
>
>
>> Which very neatly will handle an optional person, with an optional
>> address, with an optional zipCode, and either return a Some(zipCode) or a
>> None depending on whether person,
>>
>
> Like I said earlier, I find
>
> person.?address.?zipcode
>
> much more useful and less boiler-platey than the Option approach (then
> again, you said so yourself on the podcast, so I think we're in agreement
> there).
>
> address or zipCode are actually there (any of them can be None, the result
>> will be None, if they are all there you get a zipCode). Combine that with a
>> loop and a flatten, and you get a very compact way of pulling out all of
>> the zipCodes that are available without a single null check or NPE. Cedric,
>> I invite you to come to our next training session, we have exercises that
>> really demonstrate this stuff very nicely.
>>
>
> I would love to attend one of your sessions, but my family obligations
> make this a bit difficult. Hope we can make this happen one day.
>
>
>> You say they sweep errors under the rug, but that's a pessimist's
>> viewpoint. From experience on the massive calc engines I work on now, the
>> use of Option and Either are a massive improvement on what was available
>> before. Not every calculation has a valid (or possible) answer. The Java
>> way to handle that is to bail when you get one that doesn't (throw an
>> exception) and you end up with nothing. Now in genetics, where you have
>> millions of calculations, and maybe 5% will fail, using either Option or
>> Either is a far better way to go. Instead you get 95% of the answers
>> completed as expected, and 5% of them have an exceptional outcome which can
>> be reported at the end. When I think of the exception throwing way we are
>> used to, I am pleased to have a much better option.
>>
>
> You probably already know this, but Either's default bias is currently
> under heavy discussion on the Scala list, and the community seems to be
> squarely split on the right default.
>
> In one fell swoop, it has eliminated NPEs from my runtimes
>>
>
> I believe I covered this above. The "pudding proof" is not whether it
> eliminated NPE's in your code base but whether it made your code base more
> robust. If you just traded NPE's for obscure errors that escape tests and
> are hard to track, you haven't gained much.
>
> Myself, I *love* it when I get NPE's because I know that I can fix them in
> less than a minute. I am much more interested in finding a systematic way
> to fix ConcurrentModificationException (to name just one) than
> NullPointerExceptions.
>
> NPE's are really not a huge deal in practice.
>
>
>> - fully a third of my runtime errors at a conservative estimate, not to
>> mention eliminating all of the null checks littered all over my code.
>>
>
> No argument there. I totally agree that null (or "no value") checks should
> be handled by the compiler.
>
> --
> Cédric
>
>
>
--
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/-/8RlpFa05TwUJ.
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.
