Option under fire

the blog is complete crap, i think he comes from the java/c world and is not capable thinking in other language. you can easily diminish every argument he makes. he doesn't understand exhaustive matching, he doesn't seem to know that you will in many case use foreach ... getOrElse etc.

best, -sciss-

Am 05.08.2010 um 16:17 schrieb Rob Dickens:

> A prominent blogger is claiming that Option 'doesn't save you from NPEs'[1].
>
> To my knowledge, that isn't actually what it claims to do. Rather, it
> claims (does it not) to save you from forgetting to check, before
> attempting to use it, that the value isn't null, where null is
> allowed[2]. Thus, the compiler will pick you up if you try to
> dereference without using a match (or whatever), but it won't prevent
> you from assigning null to your reference (since Null is a subclass of
> every reference class).
>
> If this blogger does have a point, please could somebody explain it.
>
> Thanks,
>
> Rob
>
> 1 http://beust.com/weblog/2010/07/28/why-scalas-option-and-haskells-maybe-...
> http://www.dzone.com/links/scalas_option_and_haskells_maybe_types_wont_s...
> 2 Prog'ing in Scala, p 313.
> 3 ditto, p 243

It is not he intention of Option to save you from NPEs but if you use
it the likelyhood of NPEs drops rapidly as every reference you want to
use has to be checked against Option. As you already stated nobody is
preventing you from putting null into Option as Null is legal in
Scala. Same goes for all places you interact with existing Java code.

The blog post is a complete waste if you ask me except for the
comments. What the blogger doesn't understand is that the monadic
properties of Option actually turn it into the powerful companion it
is.

Just my 2cts.

-Stefan

2010/8/5 Rob Dickens :
> A prominent blogger is claiming that Option 'doesn't save you from NPEs'[1].
>
> To my knowledge, that isn't actually what it claims to do. Rather, it
> claims (does it not) to save you from forgetting to check, before
> attempting to use it, that the value isn't null, where null is
> allowed[2]. Thus, the compiler will pick you up if you try to
> dereference without using a match (or whatever), but it won't prevent
> you from assigning null to your reference (since Null is a subclass of
> every reference class).
>
> If this blogger does have a point, please could somebody explain it.
>
> Thanks,
>
> Rob
>
> 1 http://beust.com/weblog/2010/07/28/why-scalas-option-and-haskells-maybe-...
>   http://www.dzone.com/links/scalas_option_and_haskells_maybe_types_wont_s...
> 2 Prog'ing in Scala, p 313.
> 3 ditto, p 243
>

Option DOES get touted as "the solution to NPEs" or "the way to avoid null checks", but using this to "sell" Scala is a bit disingenuous.  It only works if you use it everywhere and never touch Java libraries.  None of that is Scala or Option's "fault".
So, Option gets straw-maned into being something that it's not; it's really a way to say "this value is optional" and to deal with such values cleanly.
I will say that ignoring Cedric's complaints and blowing him is a mistake; he is a skilled and prominent Java programmer who probably takes more time than most on understanding new languages; that he came to the conclusions he did is just as much on the community as it is on him.  Being inclusive and nice is a better long-term strategy than exclusive and superior.
My feelings on this particular subject are here: http://www.naildrivin5.com/blog/2010/07/30/in-offense-of-scala-option.html and a motivator for why I want to work on improving the documentation.
Dave

---
My Blog: http://www.naildrivin5.com/blog
Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
Fork me on Github: http://davetron5000.github.com



On Thu, Aug 5, 2010 at 11:17 AM, Rob Dickens <robcdickens@gmail.com> wrote:

A prominent blogger is claiming that Option 'doesn't save you from NPEs'[1].

To my knowledge, that isn't actually what it claims to do. Rather, it
claims (does it not) to save you from forgetting to check, before
attempting to use it, that the value isn't null, where null is
allowed[2]. Thus, the compiler will pick you up if you try to
dereference without using a match (or whatever), but it won't prevent
you from assigning null to your reference (since Null is a subclass of
every reference class).

If this blogger does have a point, please could somebody explain it.

Thanks,

Rob

1 http://beust.com/weblog/2010/07/28/why-scalas-option-and-haskells-maybe-types-wont-save-you-from-null
  http://www.dzone.com/links/scalas_option_and_haskells_maybe_types_wont_save.html
2 Prog'ing in Scala, p 313.
3 ditto, p 243

On Thu, Aug 05, 2010 at 04:17:02PM +0100, Rob Dickens wrote:
> A prominent blogger is claiming that Option 'doesn't save you from
> NPEs'[1].

I'll take your word for it about prominent. What I can't believe is
that someone would write a post claiming Option does not protect you
from null and fail to use as ammunition that a) the Option can be null
and b) the Option could be Some(null). Given his likely audience I am
sure this would have made for a quick game set and match. Instead he
brought a butter knife to shoot monkeys in a barrel.

(If that's not an aphorism-in-waiting THERE ARE NO APHORISMS.)

There are even more misconceptions here. This is all about contracts where an Option tells the client of the API that a value is.... optional. For Java you'd either invent your own Option type or you'd use Javadoc to indicate that a parameter does accept null. 
The client code to something nullable / optional is... the same. There are two cases to handle and if you pick the Some/non-null side and assume that the other side will never occur, then you're susceptible to NPE:s / NoSuchElementExceptions.
I am not directing this to you Paul.
I don't get why this subject is so debated. Even in Java, you are not really that susceptible to NPE:s. Use a programming-style where you always initialise things to valid state, don't keep / pass around half-constructed objects etc. And this is not to "protect" against NPE:s as such, this is just plain old... programming on purpose.
Option is a really tool though because it makes it clear that something is just that. Optional. It is also simliar to the other aggregates / monads so you can get away form the if-then-act style and into a more functional setting. reduceLeft, foreach, map, getOrElse etc often produce much less cruft and boilderplate.

On Thu, Aug 5, 2010 at 5:29 PM, Paul Phillips <paulp@improving.org> wrote:

On Thu, Aug 05, 2010 at 04:17:02PM +0100, Rob Dickens wrote:
> A prominent blogger is claiming that Option 'doesn't save you from
> NPEs'[1].

I'll take your word for it about prominent.  What I can't believe is
that someone would write a post claiming Option does not protect you
from null and fail to use as ammunition that a) the Option can be null
and b) the Option could be Some(null).  Given his likely audience I am
sure this would have made for a quick game set and match.  Instead he
brought a butter knife to shoot monkeys in a barrel.

(If that's not an aphorism-in-waiting THERE ARE NO APHORISMS.)

--
Paul Phillips      | It's better to have gloved and tossed than never to
Vivid              | have played baseball.
Empiricist         |
i'll ship a pulp   |----------* http://www.improving.org/paulp/ *----------

On Thu, Aug 05, 2010 at 11:36:05AM -0400, David Copeland wrote:
> My feelings on this particular subject are here:
> http://www.naildrivin5.com/blog/2010/07/30/in-offense-of-scala-option.ht...
> a motivator for why I want to work on improving the documentation.

In case anyone else finds that as difficult to read as I do, you may
want to know about this godsend. It's a bookmarklet which instantly
transforms any page into simple text using your choice of font, size,
and so on.

http://readable-app.appspot.com/setup.html

I offer this not intending to be exclusive and/or superior, but because
I genuinely cannot read the page and think clearly at the same time.
It's possible there's something wrong with my browser. Or with me.
Probable even.

While the blog displays a certain amount of ignorance, I think it is a flavor of ignorance that is often encouraged by glossing over certain subtleties with regards what Option does and does not accomplish.  It wouldn't surprise me if some of the displayed ignorance was intentional.   And I don't think there's anything wrong with that.  Explanations of Option often either gloss over the subtleties or dive into type system arcana, and neither of these approaches does much good for the newbie.  So I think it's helpful for someone to occasionally poke the community for more useful explanations.

On Thu, Aug 5, 2010 at 11:22 AM, Stefan Langer <mailtolanger@googlemail.com> wrote:

It is not he intention of Option to save you from NPEs but if you use
it the likelyhood of NPEs drops rapidly as every reference you want to
use has to be checked against Option. As you already stated nobody is
preventing you from putting null into Option as Null is legal in
Scala. Same goes for all places you interact with existing Java code.

The blog post is a complete waste if you ask me except for the
comments. What the blogger doesn't understand is that the monadic
properties of Option actually turn it into the powerful companion it
is.

Just my 2cts.

-Stefan

2010/8/5 Rob Dickens <robcdickens@gmail.com>:
> A prominent blogger is claiming that Option 'doesn't save you from NPEs'[1].
>
> To my knowledge, that isn't actually what it claims to do. Rather, it
> claims (does it not) to save you from forgetting to check, before
> attempting to use it, that the value isn't null, where null is
> allowed[2]. Thus, the compiler will pick you up if you try to
> dereference without using a match (or whatever), but it won't prevent
> you from assigning null to your reference (since Null is a subclass of
> every reference class).
>
> If this blogger does have a point, please could somebody explain it.
>
> Thanks,
>
> Rob
>
> 1 http://beust.com/weblog/2010/07/28/why-scalas-option-and-haskells-maybe-types-wont-save-you-from-null
>   http://www.dzone.com/links/scalas_option_and_haskells_maybe_types_wont_save.html
> 2 Prog'ing in Scala, p 313.
> 3 ditto, p 243
>

--
http://erikengbrecht.blogspot.com/

I wondered before: would it be possible to eliminate null from a language
and always use Option if a var, val, parameter etc could be undefined?

Sure, it would be a problem interfacing with existing languages, although
conversions could make up for that. I'm not asking about that, but about
a language that wouldn't have null as a possible value for any type.

Job

Thing is. The problem is not nullability but rather ignoring optionality. If a field may be null, then blindly dereferencing it will produce an NPE. The same goes for blindly calling get on an Option. So that blogger is right in that Option does not remove NPE because they are the symptom for another cause. Blind assumptions.
That said, Option offers a much better model for dealing with optionality than regular null-checks. For instance: chain all the Some/if (!null) code using map / flatMap on the Option and finish off with getOrElse (defaultValue). That way you get away from handling all the intermediate if-not-successful cases - lumping all of them into the final / global default case.

On Thu, Aug 5, 2010 at 6:05 PM, Job Honig <joho@xs4all.nl> wrote:

I wondered before: would it be possible to eliminate null from a language
and always use Option if a var, val, parameter etc could be undefined?

Sure, it would be a problem interfacing with existing languages, although
conversions could make up for that.  I'm not asking about that, but about
a language that wouldn't have null as a possible value for any type.

Job

On Thu, Aug 5, 2010 at 8:58 AM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

While the blog displays a certain amount of ignorance, I think it is a flavor of ignorance that is often encouraged by glossing over certain subtleties with regards what Option does and does not accomplish.  It wouldn't surprise me if some of the displayed ignorance was intentional.

I read the blog post and my first reaction was "this guy is pretty clueless."  Then I saw that he wrote TestNG and my next reaction was "if he can't spend 20 minutes trying to view things from a different perspective, his code must be wicked rigid and I would not trust it."  Okay... enough with the ad hominem comments.
Different languages have different styles.  Successful patterns in one language do not always translate to success in another language.  Having followed the Java -> Ruby -> Scala path, I have some sympathy for using the same patterns in Scala that one uses in Java.  On the other hand, spending a little time looking around the net, one can find nice examples of Option and more generally of monads (or think of them as collections) in Scala and other languages:

• http://blog.lostlake.org/index.php?/archives/50-The-Scala-Option-class-and-how-lift-uses-it.html as well as the updated version http://lift.la/scala-option-lift-box-and-how-to-make-your-co 
• http://blog.lostlake.org/index.php?/archives/41-Scala-Idioms,-Step-1,-Lists-and-Maps.html
• http://notes-on-haskell.blogspot.com/2007/02/whats-wrong-with-for-loop.html

The fact that the author of the blog post didn't do some basic research and is actively battling with folks who are trying to guide him in the right direction indicates to me that he has little of actual value to share.
In terms of Option reducing the NPE issue:

• The Option type documents when the logic of a method may not have a valid result (e.g., converting a String to an Int... it is not "exceptional" that this cannot be calculated or a hashtable lookup).  Documentation in the type system rather than in documentation text (especially when there are many different idioms in Java, even in the standard Java libraries)
• Using Option and for comprehensions push the developer to think about isolating the business logic (if all of these things are legal, then what logic is applied) from the assemblage of the values that go into the logic.  Put another way, you get a much lower McCabe number (cyclomatic complexity) using for comprehensions than with nested if/else statements and low McCabe numbers translates directly to low bug counts.
• Option does not, in Scala, *eliminate* NPEs, but as a tool on its own, it is powerful and the way it prods the developer into coding further reduces defects (NPE and others).

So, there is no silver bullet (especially in a Java-compatible language) for common Java problems, but there are tools that help the developer do a better job of focusing on getting the business logic right and Option is one of those tools.  

  And I don't think there's anything wrong with that.  Explanations of Option often either gloss over the subtleties or dive into type system arcana, and neither of these approaches does much good for the newbie.  So I think it's helpful for someone to occasionally poke the community for more useful explanations.

On Thu, Aug 5, 2010 at 11:22 AM, Stefan Langer <mailtolanger@googlemail.com> wrote:

It is not he intention of Option to save you from NPEs but if you use
it the likelyhood of NPEs drops rapidly as every reference you want to
use has to be checked against Option. As you already stated nobody is
preventing you from putting null into Option as Null is legal in
Scala. Same goes for all places you interact with existing Java code.

The blog post is a complete waste if you ask me except for the
comments. What the blogger doesn't understand is that the monadic
properties of Option actually turn it into the powerful companion it
is.

Just my 2cts.

-Stefan

2010/8/5 Rob Dickens <robcdickens@gmail.com>:
> A prominent blogger is claiming that Option 'doesn't save you from NPEs'[1].
>
> To my knowledge, that isn't actually what it claims to do. Rather, it
> claims (does it not) to save you from forgetting to check, before
> attempting to use it, that the value isn't null, where null is
> allowed[2]. Thus, the compiler will pick you up if you try to
> dereference without using a match (or whatever), but it won't prevent
> you from assigning null to your reference (since Null is a subclass of
> every reference class).
>
> If this blogger does have a point, please could somebody explain it.
>
> Thanks,
>
> Rob
>
> 1 http://beust.com/weblog/2010/07/28/why-scalas-option-and-haskells-maybe-types-wont-save-you-from-null
>   http://www.dzone.com/links/scalas_option_and_haskells_maybe_types_wont_save.html
> 2 Prog'ing in Scala, p 313.
> 3 ditto, p 243
>

--
http://erikengbrecht.blogspot.com/

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics

 I'd say that the blogger misses the point that with a decent type system available
such as Scala's, there are plenty of opportunities of static validation that can
be exploited, it doesn't mean that they will be, but that they can be.
Option[] says something to the type system, and with the proper patterns
understood are utilized, managing NPEs, becomes managing optionality,
with less verbosity more readability, self documenttion, predictability etc...

 Max

On Thu, Aug 5, 2010 at 12:29 PM, Patrik Andersson <pandersson@gmail.com> wrote:

Thing is. The problem is not nullability but rather ignoring optionality. If a field may be null, then blindly dereferencing it will produce an NPE. The same goes for blindly calling get on an Option. So that blogger is right in that Option does not remove NPE because they are the symptom for another cause. Blind assumptions.
That said, Option offers a much better model for dealing with optionality than regular null-checks. For instance: chain all the Some/if (!null) code using map / flatMap on the Option and finish off with getOrElse (defaultValue). That way you get away from handling all the intermediate if-not-successful cases - lumping all of them into the final / global default case.

On Thu, Aug 5, 2010 at 6:05 PM, Job Honig <joho@xs4all.nl> wrote:

I wondered before: would it be possible to eliminate null from a language
and always use Option if a var, val, parameter etc could be undefined?

Sure, it would be a problem interfacing with existing languages, although
conversions could make up for that.  I'm not asking about that, but about
a language that wouldn't have null as a possible value for any type.

Job

About this topic:http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare

2010/8/5 Job Honig <joho@xs4all.nl>

I wondered before: would it be possible to eliminate null from a language
and always use Option if a var, val, parameter etc could be undefined?

Sure, it would be a problem interfacing with existing languages, although
conversions could make up for that.  I'm not asking about that, but about
a language that wouldn't have null as a possible value for any type.

Job

Just on a side note: to eliminate NPEs one has to eliminate null !
Which btw haskell did. So the author is also wrong in bringing in the
Maybe monad in his talk as haskell does not know null values.

-Stefan

2010/8/5 Sylvain HENRY :
> About this topic:
> http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mi...
>
> 2010/8/5 Job Honig
>>
>> I wondered before: would it be possible to eliminate null from a language
>> and always use Option if a var, val, parameter etc could be undefined?
>>
>> Sure, it would be a problem interfacing with existing languages, although
>> conversions could make up for that.  I'm not asking about that, but about
>> a language that wouldn't have null as a possible value for any type.
>>
>> Job
>
>

This really isn't about null though. It's about making assumptions that are not safe to be made. foo.bar() assumes that foo is non-null. anOption.get assumes that anOption matches Some(_). head aList in Haskell is the same thing. It requires that aList is not []. Removing null does... nothing to remedy this.
Default initialization of fields and values make null creep in unless the programmer either always initializes or always uses final (in Java) or val in Scala for instance.
null is being punished for things it is not the cause of.
On Fri, Aug 6, 2010 at 10:34 AM, Stefan Langer <mailtolanger@googlemail.com> wrote:

Just on a side note: to eliminate NPEs one has to eliminate null !
Which btw haskell did. So the author is also wrong in bringing in the
Maybe monad in his talk as haskell does not know null values.

-Stefan

2010/8/5 Sylvain HENRY <hsyl20@gmail.com>:
> About this topic:
> http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare
>
> 2010/8/5 Job Honig <joho@xs4all.nl>
>>
>> I wondered before: would it be possible to eliminate null from a language
>> and always use Option if a var, val, parameter etc could be undefined?
>>
>> Sure, it would be a problem interfacing with existing languages, although
>> conversions could make up for that.  I'm not asking about that, but about
>> a language that wouldn't have null as a possible value for any type.
>>
>> Job
>
>

(I believe we basically agree, I just wanted to elaborate)

But the problem is that null can impersonate any type, so you can never know where it pops up. I don't think uninitialzed fields causes most problems, but rather ill-specified contracts between callers and callees. Especially return values are problematic - should they always be checked for null?

It is true that removing null does not prevent you from making assumptions that are not safe to be made, but it reduces the number of places where this kind of assumption has to be made, and allows the type system to remind you in the remaining ones.


On Fri, Aug 6, 2010 at 10:51 AM, Patrik Andersson <pandersson@gmail.com> wrote:

This really isn't about null though. It's about making assumptions that are not safe to be made. foo.bar() assumes that foo is non-null. anOption.get assumes that anOption matches Some(_). head aList in Haskell is the same thing. It requires that aList is not []. Removing null does... nothing to remedy this.
Default initialization of fields and values make null creep in unless the programmer either always initializes or always uses final (in Java) or val in Scala for instance.
null is being punished for things it is not the cause of.

2010/8/6 Patrik Andersson :
> [...] This really isn't about null though. It's about making assumptions that are
> not safe to be made. foo.bar() assumes that foo is non-null. anOption.get
> assumes that anOption matches Some(_). head aList in Haskell is the same
> thing. It requires that aList is not []. Removing null does... nothing to
> remedy this. [...]
Actually it does as in this case the error is obviouse as it states
you are not allowed to use head on an empty list. First of it tells
you that you are calling head and second that you are doing it on a
list which is empty.
A NPE simply tells you that the reference is null...

-Stefan

val list: List[String] = ...
val h = list.head // does that give you NPE, NoSuchElementException or an actual element ?
You cannot know at that point. Why do people single out null in this case when it should be obvious that it has absolutely nothing to do with it? Calling on null references it not allowed and neither is invoking head on empty lists.
null and None are also very close. None can be assigned to any Option type just as null can every reference. They're very similar in that regard. That said: Option is of course better because of all the reason that've already been enumerated here. 
On Fri, Aug 6, 2010 at 1:28 PM, Stefan Langer <mailtolanger@googlemail.com> wrote:

2010/8/6 Patrik Andersson <pandersson@gmail.com>:
> [...] This really isn't about null though. It's about making assumptions that are
> not safe to be made. foo.bar() assumes that foo is non-null. anOption.get
> assumes that anOption matches Some(_). head aList in Haskell is the same
> thing. It requires that aList is not []. Removing null does... nothing to
> remedy this. [...]
Actually it does as in this case the error is obviouse as it states
you are not allowed to use head on an empty list. First of it tells
you that you are calling head and second that you are doing it on a
list which is empty.
A NPE simply tells you that the reference is null...

-Stefan

Yes, this isn't about invalid operations on certain runtime values - which everyone knows can happen with or without null, but about mutability, null having multiple meanings and null values being allowed to propagate through call chains, because it never violates any static type constraints, yet doesn't support any operations.  For comparison, consider scala where every type is implicitly an option and every val is actually a var.  The real benefit of Option is that not everything is an Option.  In Java, everything is an Option and you cannot - as far as the type system is concerned - peel anything of its optionality.  If you checked for null in some value in one place, there's no static way to communicate this fact to another method.
Those problems make it difficult to figure out why you're getting an NPE, which is the real problem behind nulls.  The debate here is analogous to static versus dynamic typing.  Option is simply one way to use statically typed optionality.  Obviously you can't have a type system that catches every run time error, but being able to specify whether some value is optional or not is important.
On Fri, Aug 6, 2010 at 8:02 AM, Patrik Andersson <pandersson@gmail.com> wrote:

val list: List[String] = ...
val h = list.head // does that give you NPE, NoSuchElementException or an actual element ?
You cannot know at that point. Why do people single out null in this case when it should be obvious that it has absolutely nothing to do with it? Calling on null references it not allowed and neither is invoking head on empty lists.

When I first saw a link to this blog, I noticed it was from Cedric Beust and moved on. Whatever the actual truth of the deeper content of his posts, it seems he is keen on dressing them in a way to ensure controversy.

On Thu, Aug 5, 2010 at 2:01 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

On Thu, Aug 5, 2010 at 8:58 AM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

While the blog displays a certain amount of ignorance, I think it is a flavor of ignorance that is often encouraged by glossing over certain subtleties with regards what Option does and does not accomplish.  It wouldn't surprise me if some of the displayed ignorance was intentional.

I read the blog post and my first reaction was "this guy is pretty clueless."  Then I saw that he wrote TestNG and my next reaction was "if he can't spend 20 minutes trying to view things from a different perspective, his code must be wicked rigid and I would not trust it."  Okay... enough with the ad hominem comments.
Different languages have different styles.  Successful patterns in one language do not always translate to success in another language.  Having followed the Java -> Ruby -> Scala path, I have some sympathy for using the same patterns in Scala that one uses in Java.  On the other hand, spending a little time looking around the net, one can find nice examples of Option and more generally of monads (or think of them as collections) in Scala and other languages:

• http://blog.lostlake.org/index.php?/archives/50-The-Scala-Option-class-and-how-lift-uses-it.html as well as the updated version http://lift.la/scala-option-lift-box-and-how-to-make-your-co 
• http://blog.lostlake.org/index.php?/archives/41-Scala-Idioms,-Step-1,-Lists-and-Maps.html
• http://notes-on-haskell.blogspot.com/2007/02/whats-wrong-with-for-loop.html

The fact that the author of the blog post didn't do some basic research and is actively battling with folks who are trying to guide him in the right direction indicates to me that he has little of actual value to share.
In terms of Option reducing the NPE issue:

• The Option type documents when the logic of a method may not have a valid result (e.g., converting a String to an Int... it is not "exceptional" that this cannot be calculated or a hashtable lookup).  Documentation in the type system rather than in documentation text (especially when there are many different idioms in Java, even in the standard Java libraries)
• Using Option and for comprehensions push the developer to think about isolating the business logic (if all of these things are legal, then what logic is applied) from the assemblage of the values that go into the logic.  Put another way, you get a much lower McCabe number (cyclomatic complexity) using for comprehensions than with nested if/else statements and low McCabe numbers translates directly to low bug counts.
• Option does not, in Scala, *eliminate* NPEs, but as a tool on its own, it is powerful and the way it prods the developer into coding further reduces defects (NPE and others).

So, there is no silver bullet (especially in a Java-compatible language) for common Java problems, but there are tools that help the developer do a better job of focusing on getting the business logic right and Option is one of those tools.  

  And I don't think there's anything wrong with that.  Explanations of Option often either gloss over the subtleties or dive into type system arcana, and neither of these approaches does much good for the newbie.  So I think it's helpful for someone to occasionally poke the community for more useful explanations.

On Thu, Aug 5, 2010 at 11:22 AM, Stefan Langer <mailtolanger@googlemail.com> wrote:

It is not he intention of Option to save you from NPEs but if you use
it the likelyhood of NPEs drops rapidly as every reference you want to
use has to be checked against Option. As you already stated nobody is
preventing you from putting null into Option as Null is legal in
Scala. Same goes for all places you interact with existing Java code.

The blog post is a complete waste if you ask me except for the
comments. What the blogger doesn't understand is that the monadic
properties of Option actually turn it into the powerful companion it
is.

Just my 2cts.

-Stefan

2010/8/5 Rob Dickens <robcdickens@gmail.com>:
> A prominent blogger is claiming that Option 'doesn't save you from NPEs'[1].
>
> To my knowledge, that isn't actually what it claims to do. Rather, it
> claims (does it not) to save you from forgetting to check, before
> attempting to use it, that the value isn't null, where null is
> allowed[2]. Thus, the compiler will pick you up if you try to
> dereference without using a match (or whatever), but it won't prevent
> you from assigning null to your reference (since Null is a subclass of
> every reference class).
>
> If this blogger does have a point, please could somebody explain it.
>
> Thanks,
>
> Rob
>
> 1 http://beust.com/weblog/2010/07/28/why-scalas-option-and-haskells-maybe-types-wont-save-you-from-null
>   http://www.dzone.com/links/scalas_option_and_haskells_maybe_types_wont_save.html
> 2 Prog'ing in Scala, p 313.
> 3 ditto, p 243
>

--
http://erikengbrecht.blogspot.com/

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics

--
Daniel C. Sobral

I travel to the future all the time.

Daniel Sobral wrote:
> When I first saw a link to this blog, I noticed it was from Cedric
> Beust and moved on. Whatever the actual truth of the deeper content of
> his posts, it seems he is keen on dressing them in a way to ensure
> controversy.

This may be so but I don't think it's blatantly intentional. I think he
is way out of his depth, completely unaware of it and unwilling to
change it, for whatever reason (which are likely to be fascinating).
Some people are of this persuasion *shrug*.

I suggest that the only constructive thing to be done in this situation
(even if it is intentional) is to make an effort to educate and abort if
the ROI diminishes below a threshold and ensure that others do not fall
prey to such gross misinformation and misunderstanding.

Just wanted to say thanks for all the responses. It's good to have a
small army to turn to occasionally.

Rob

On Wed, Aug 11, 2010 at 1:54 AM, Tony Morris wrote:
> Daniel Sobral wrote:
>> When I first saw a link to this blog, I noticed it was from Cedric
>> Beust and moved on. Whatever the actual truth of the deeper content of
>> his posts, it seems he is keen on dressing them in a way to ensure
>> controversy.
>
> This may be so but I don't think it's blatantly intentional. I think he
> is way out of his depth, completely unaware of it and unwilling to
> change it, for whatever reason (which are likely to be fascinating).
> Some people are of this persuasion *shrug*.
>
> I suggest that the only constructive thing to be done in this situation
> (even if it is intentional) is to make an effort to educate and abort if
> the ROI diminishes below a threshold and ensure that others do not fall
> prey to such gross misinformation and misunderstanding.
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>

When someone is struggling with their two times table, it's not always helpful to sit them down and introduce advanced number-theory :-)

> Date: Wed, 11 Aug 2010 10:54:37 +1000
> From: tonymorris@gmail.com
>
> I suggest that the only constructive thing to be done in this situation
> (even if it is intentional) is to make an effort to educate>
> --
> Tony Morris
> http://tmorris.net/
>
>

I disagree.  Sometimes principles/theory are exactly what a person struggling with rote memorization needs.

On Thu, Aug 12, 2010 at 11:27 AM, christopher marshall <oxbow_lakes@hotmail.com> wrote:

When someone is struggling with their two times table, it's not always helpful to sit them down and introduce advanced number-theory :-)

> Date: Wed, 11 Aug 2010 10:54:37 +1000
> From: tonymorris@gmail.com
>
> I suggest that the only constructive thing to be done in this situation
> (even if it is intentional) is to make an effort to educate >
> --
> Tony Morris
> http://tmorris.net/
>
>

--
http://erikengbrecht.blogspot.com/

Using group/ring theory to explain addition and multiplication:) I actually thing that's how fundamental mathematics should be taught via representations and abstractions then implementation, and this would lead to much easier communication and arguments in participations... Seeing scala now fundamentally rested on FP and generally, functional calculus, without it scala programs will emulate java and no one will notice a thing:) or pose questions such as "why this construct" in java its just NULL etc etc:)

Sent from my Verizon Wireless BlackBerry

From: christopher marshall <oxbow_lakes@hotmail.com> Date: Thu, 12 Aug 2010 15:27:35 +0000To: <tonymorris@gmail.com>; <dcsobral@gmail.com>Cc: <feeder.of.the.bears@gmail.com>; <erik.engbrecht@gmail.com>; Scala Users<scala-user@listes.epfl.ch>Subject: RE: [scala-user] Option under fire
When someone is struggling with their two times table, it's not always helpful to sit them down and introduce advanced number-theory :-)

> Date: Wed, 11 Aug 2010 10:54:37 +1000
> From: tonymorris@gmail.com
>
> I suggest that the only constructive thing to be done in this situation
> (even if it is intentional) is to make an effort to educate>
> --
> Tony Morris
> http://tmorris.net/
>
>

Re Fantom's concise syntax, is it comparable to the experimental compiler plugin someone--I think Johannes Rudolph--posted recently, that lets you apply an operator to a monad's contents by appending a ^ to it?

On Wed, Aug 11, 2010 at 6:30 AM, Rob Dickens <robcdickens@gmail.com> wrote:

Just wanted to say thanks for all the responses. It's good to have a
small army to turn to occasionally.

Rob

On Wed, Aug 11, 2010 at 1:54 AM, Tony Morris <tonymorris@gmail.com> wrote:
> Daniel Sobral wrote:
>> When I first saw a link to this blog, I noticed it was from Cedric
>> Beust and moved on. Whatever the actual truth of the deeper content of
>> his posts, it seems he is keen on dressing them in a way to ensure
>> controversy.
>
> This may be so but I don't think it's blatantly intentional. I think he
> is way out of his depth, completely unaware of it and unwilling to
> change it, for whatever reason (which are likely to be fascinating).
> Some people are of this persuasion *shrug*.
>
> I suggest that the only constructive thing to be done in this situation
> (even if it is intentional) is to make an effort to educate and abort if
> the ROI diminishes below a threshold and ensure that others do not fall
> prey to such gross misinformation and misunderstanding.
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>

It's always a tough call. Advancing an educational pursuit, especially
among programmers, is often more challenging than programming itself.
Challenges are great.

christopher marshall wrote:
> When someone is struggling with their two times table, it's not always
> helpful to sit them down and introduce advanced number-theory :-)
>
> > Date: Wed, 11 Aug 2010 10:54:37 +1000
> > From: tonymorris@gmail.com
> >
> > I suggest that the only constructive thing to be done in this situation
> > (even if it is intentional) is to make an effort to educate
> >
> > --
> > Tony Morris
> > http://tmorris.net/
> >
> >