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 post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
