Cost of Option / Some vs null

In my opinion null isn't just against idiomatic scala it just is plain wrong and often results in non robust bug ridden code that just waits to blow up in your face.
To put it another way if it wouldn't be for Java interoperability I would hope to see scalac abandon null.
Actually it would be awesome if the compiler would actually transform any null value into Option.

And no I do not think that it is as efficient as null since null is basically the absense of any type information. (as far as I understand it) and option is an extra object that wraps a value. But unless you can proof in your case that Option is a bottleneck in your case I wouldn't worry about it and take the safety of Option over null anytime.

Just my 2cts.

2009/11/20 Maxime Lévesque <maxime.levesque@gmail.com>

 Does scalac implement some kind of magic so that
using Option[T]  is as efficient as using nulls ?
Of course Option is a wrapper so the extra cost should
be one thin object. I was just writing a tight loop
and was trying to make it lean and mean. I got tempted
to depart from idiomatic scala here and use a good old null,
it got me wondering if this kind of magic be doable by
the compiler ? (And is it doing it ?)

  Cheers

On Thu, 2009-11-19 at 23:57 -0500, Maxime Lévesque wrote:
>
> Does scalac implement some kind of magic so that
> using Option[T] is as efficient as using nulls ?

No.

This was mentioned as a possibility at some point, but some people were
upset when an assert checking for null was added to Some and there's
also the question of how to deal with List(null).headOption.

> Of course Option is a wrapper so the extra cost should
> be one thin object. I was just writing a tight loop
> and was trying to make it lean and mean. I got tempted
> to depart from idiomatic scala here and use a good old null,
> it got me wondering if this kind of magic be doable by
> the compiler ? (And is it doing it ?)

In very tight loops, the allocation cost of Option (assuming it doesn't
get elided via escape analysis) could cause a slowdown indeed.

Best,
Ismael

Allocation elision is something that will start to play a part here soon.

On Nov 20, 2009 9:51 AM, "Ismael Juma" <mlists@juma.me.uk> wrote:

On Thu, 2009-11-19 at 23:57 -0500, Maxime Lévesque wrote: > > Does scalac implement some kind of m...

No.

This was mentioned as a possibility at some point, but some people were
upset when an assert checking for null was added to Some and there's
also the question of how to deal with List(null).headOption.

> Of course Option is a wrapper so the extra cost should > be one thin object. I was just writing a...

In very tight loops, the allocation cost of Option (assuming it doesn't
get elided via escape analysis) could cause a slowdown indeed.

Best,
Ismael

On Fri, 2009-11-20 at 10:20 +0100, Viktor Klang wrote:
> Allocation elision is something that will start to play a part here
> soon.

Are you talking about HotSpot or scalac -optimise? And what do you mean
by "soon"?

Scalar replacement has been in HotSpot for some releases now, but it's
still very limited and optimisation opportunities are missed when
compared to allocation-free code (relevant for very tight loops).

Best,
Ismael

Ismael Juma wrote:
> On Fri, 2009-11-20 at 10:20 +0100, Viktor Klang wrote:
>> Allocation elision is something that will start to play a part here
>> soon.
>
> Are you talking about HotSpot or scalac -optimise? And what do you mean
> by "soon"?
>
> Scalar replacement has been in HotSpot for some releases now, but it's
> still very limited and optimisation opportunities are missed when
> compared to allocation-free code (relevant for very tight loops).
>
> Best,
> Ismael

The initial question was good: Does Scala abandon `null' in favor of
`None'? Especially if you make your classes unapply-aware, Options are
the only way to go.

I think that nullness is itself a sort of a value: absence of
information. I'd reckon that 50 % of Java code deals with the question
``null or not null," sounding Shakespearish. So yes, this `Some' and
`None' stuff may be overengineered.

---Phil

On Fri, 2009-11-20 at 10:40 +0100, Philip Köster wrote:
> The initial question was good: Does Scala abandon `null' in favor of
> `None'?

That was not the initial question. The question was:

"Does scalac implement some kind of magic so that using Option[T] is as
efficient as using nulls ?"

> I think that nullness is itself a sort of a value: absence of
> information. I'd reckon that 50 % of Java code deals with the question
> ``null or not null," sounding Shakespearish. So yes, this `Some' and
> `None' stuff may be overengineered.

I don't know how you reached that conclusion from what you said above.

Ismael

> I don't know how you reached that conclusion from what you said above.
>
> Ismael

The only thing I know is that `Option' confuses me any time I encounter
it. The following is poorly memorized, and it may be wrong: If I say
`get' on a Scala map, I might receive a `None' , but if I use
parentheses, I receive an exception. Either way it is, all of that is
hard to memorize, and a cul-de-sac.

Now this is a good example of how libraries should *not* be designed. It
places the burden on the user of a lib, who really just wants to get his
job done and not worry about subleties such as the difference between
`null' and `None'. This imposes a new kind of fuzzy logic leading to
even more if-then-else branches than we really need.

2009/11/20 Ismael Juma <mlists@juma.me.uk>

On Fri, 2009-11-20 at 10:20 +0100, Viktor Klang wrote:
> Allocation elision is something that will start to play a part here
> soon.

Are you talking about HotSpot or scalac -optimise? And what do you mean
by "soon"?

I'm talking about HotSpot,I recently read somewhere that escape analysis is going to be improved.Also, something about stack allocation when scalar replacement cannot be done, but it knows that the reference won't escape.  

Scalar replacement has been in HotSpot for some releases now, but it's
still very limited and optimisation opportunities are missed when
compared to allocation-free code (relevant for very tight loops).

Best,
Ismael

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: twitter.com/viktorklang
Code: github.com/viktorklang

On Fri, 2009-11-20 at 11:13 +0100, Philip Köster wrote:
> Now this is a good example of how libraries should *not* be designed. It
> places the burden on the user of a lib, who really just wants to get his
> job done and not worry about subleties such as the difference between
> `null' and `None'. This imposes a new kind of fuzzy logic leading to
> even more if-then-else branches than we really need.

This leads me to think that you're using it wrong. Option is meant to
help with the if/else problem that one finds with null (and also the
problem that one never knows where null is expected). You may want to
check some tutorials on Option and the various ways you can use it
without having to rely on if/else all the time.

Best,
Ismael

On Fri, 2009-11-20 at 11:21 +0100, Viktor Klang wrote:
> I'm talking about HotSpot,
> I recently read somewhere that escape analysis is going to be
> improved.

Do you have a link? I posted something about this on Twitter and I'm
curious if it's a different one.

> Also, something about stack allocation when scalar replacement cannot
> be done, but it knows that the reference won't escape.

This I haven't heard about. Do you have a reference?

Best,
Ismael

Ismael Juma schrieb:
> On Fri, 2009-11-20 at 11:13 +0100, Philip Köster wrote:
>> Now this is a good example of how libraries should *not* be designed. It
>> places the burden on the user of a lib, who really just wants to get his
>> job done and not worry about subleties such as the difference between
>> `null' and `None'. This imposes a new kind of fuzzy logic leading to
>> even more if-then-else branches than we really need.
>
> This leads me to think that you're using it wrong. Option is meant to
> help with the if/else problem that one finds with null (and also the
> problem that one never knows where null is expected). You may want to
> check some tutorials on Option and the various ways you can use it
> without having to rely on if/else all the time.
>
> Best,
> Ismael
>
>

I read all the tutorials, so please don't talk to me like a was a child,
'cause that is something that really pisses me off and makes me
speechless. I can very well understand why beginners are confused about
the diff between `Option' and the Java-native null value, and I predict
many failures will arise from this basic misunderstanding. A user asked
what the difference was, and you gave no answer but only increased the
confusedness. QED.

On Fri, 2009-11-20 at 11:36 +0100, Philip Köster wrote:
> I read all the tutorials, so please don't talk to me like a was a child,

I did not. I simply said that if you believe that the usage of Option
leads to more if/else than using null, then maybe you're not using it in
the idiomatic way. I don't see why you'd interpret it the way you did.

> A user asked what the difference was, and you gave no answer but only increased the
> confusedness.

He did not ask that. He was interested in the performance issues of
using Option in tight loops (as I stated in the previous message
already).

Best,
Ismael

Sometimes this is frustrating hard, because the short answer "Option is a monad, using nulls is not" is no more enlightening to most Java devs.
I tend to explain it as "Option is a list constrained to size 0 or 1", this means that you can use expressions like "for every item in the list" and know that they still won't error even if the list is empty.

On Fri, Nov 20, 2009 at 10:36 AM, Philip Köster <philip.koester@web.de> wrote:

Ismael Juma schrieb:

On Fri, 2009-11-20 at 11:13 +0100, Philip Köster wrote:

Now this is a good example of how libraries should *not* be designed. It places the burden on the user of a lib, who really just wants to get his job done and not worry about subleties such as the difference between `null' and `None'. This imposes a new kind of fuzzy logic leading to even more if-then-else branches than we really need.

This leads me to think that you're using it wrong. Option is meant to
help with the if/else problem that one finds with null (and also the
problem that one never knows where null is expected). You may want to
check some tutorials on Option and the various ways you can use it
without having to rely on if/else all the time.

Best,
Ismael

I read all the tutorials, so please don't talk to me like a was a child, 'cause that is something that really pisses me off and makes me speechless. I can very well understand why beginners are confused about the diff between `Option' and the Java-native null value, and I predict many failures will arise from this basic misunderstanding. A user asked what the difference was, and you gave no answer but only increased the confusedness. QED.

I introduced Option at work in some Java code for builders; basically,
a builder would have a number of parameters, Param,
Param, etc. Option would let you have Param> to
specify an optional parameter, rather than having to write a separate
OptionalParameter class and have code duplication everywhere.

Other than that, I said it was a smarter null, as you could not
dereference it without being aware that it may contain nothing. I
ended up implementing a new Option type in our codebase, though with
what I think is an interesting addition; my Option.None contains a
String reason. Yes, Tony, this means it's now a String | T, not a
Nothing | T, so calling it Option is a little dubious. If every time
I got an NPE I could see *why* the value was null at a glance, that'd
be excellent. There are far too many return null;s in the codebase;
some of them represent errors, some of them represent that there just
was no result for some reason.

I'm not suggesting Scala's Option changes at all, just detailing an experience.

2009/11/20 Kevin Wright :
> Sometimes this is frustrating hard, because the short answer "Option is a
> monad, using nulls is not" is no more enlightening to most Java devs.
> I tend to explain it as "Option is a list constrained to size 0 or 1", this
> means that you can use expressions like "for every item in the list" and
> know that they still won't error even if the list is empty.
>
> On Fri, Nov 20, 2009 at 10:36 AM, Philip Köster
> wrote:
>>
>>
>> Ismael Juma schrieb:
>>>
>>> On Fri, 2009-11-20 at 11:13 +0100, Philip Köster wrote:
>>>>
>>>> Now this is a good example of how libraries should *not* be designed. It
>>>> places the burden on the user of a lib, who really just wants to get his job
>>>> done and not worry about subleties such as the difference between `null' and
>>>> `None'. This imposes a new kind of fuzzy logic leading to even more
>>>> if-then-else branches than we really need.
>>>
>>> This leads me to think that you're using it wrong. Option is meant to
>>> help with the if/else problem that one finds with null (and also the
>>> problem that one never knows where null is expected). You may want to
>>> check some tutorials on Option and the various ways you can use it
>>> without having to rely on if/else all the time.
>>>
>>> Best,
>>> Ismael
>>>
>>>
>>
>> I read all the tutorials, so please don't talk to me like a was a child,
>> 'cause that is something that really pisses me off and makes me speechless.
>> I can very well understand why beginners are confused about the diff between
>> `Option' and the Java-native null value, and I predict many failures will
>> arise from this basic misunderstanding. A user asked what the difference
>> was, and you gave no answer but only increased the confusedness. QED.
>
>

As Scott Meyers wrote in his unforgettable book, ``More Effective C++,"
he left no doubt about his basic point: If you want to express
something, express it in the language so anyone can understand it. For
me that was the most fundamental sentence of his books. Transferred to
Java, which has only a very poor understanding of constness, this means:
``If you want to express something as being null, then make it null and
not have it an instance of a contrived made-up class."

Ricky Clarkson schrieb:
> I introduced Option at work in some Java code for builders; basically,
> a builder would have a number of parameters, Param,
> Param, etc. Option would let you have Param> to
> specify an optional parameter, rather than having to write a separate
> OptionalParameter class and have code duplication everywhere.
>
> Other than that, I said it was a smarter null, as you could not
> dereference it without being aware that it may contain nothing. I
> ended up implementing a new Option type in our codebase, though with
> what I think is an interesting addition; my Option.None contains a
> String reason. Yes, Tony, this means it's now a String | T, not a
> Nothing | T, so calling it Option is a little dubious. If every time
> I got an NPE I could see *why* the value was null at a glance, that'd
> be excellent. There are far too many return null;s in the codebase;
> some of them represent errors, some of them represent that there just
> was no result for some reason.
>
> I'm not suggesting Scala's Option changes at all, just detailing an experience.
>
> 2009/11/20 Kevin Wright :
>> Sometimes this is frustrating hard, because the short answer "Option is a
>> monad, using nulls is not" is no more enlightening to most Java devs.
>> I tend to explain it as "Option is a list constrained to size 0 or 1", this
>> means that you can use expressions like "for every item in the list" and
>> know that they still won't error even if the list is empty.
>>
>> On Fri, Nov 20, 2009 at 10:36 AM, Philip Köster
>> wrote:
>>>
>>> Ismael Juma schrieb:
>>>> On Fri, 2009-11-20 at 11:13 +0100, Philip Köster wrote:
>>>>> Now this is a good example of how libraries should *not* be designed. It
>>>>> places the burden on the user of a lib, who really just wants to get his job
>>>>> done and not worry about subleties such as the difference between `null' and
>>>>> `None'. This imposes a new kind of fuzzy logic leading to even more
>>>>> if-then-else branches than we really need.
>>>> This leads me to think that you're using it wrong. Option is meant to
>>>> help with the if/else problem that one finds with null (and also the
>>>> problem that one never knows where null is expected). You may want to
>>>> check some tutorials on Option and the various ways you can use it
>>>> without having to rely on if/else all the time.
>>>>
>>>> Best,
>>>> Ismael
>>>>
>>>>
>>> I read all the tutorials, so please don't talk to me like a was a child,
>>> 'cause that is something that really pisses me off and makes me speechless.
>>> I can very well understand why beginners are confused about the diff between
>>> `Option' and the Java-native null value, and I predict many failures will
>>> arise from this basic misunderstanding. A user asked what the difference
>>> was, and you gave no answer but only increased the confusedness. QED.
>>
>
>
>

Buckley says John Rose is working on stack allocation. So I guess we need an audience with mr Rose!

On Nov 20, 2009 11:52 AM, "Ricky Clarkson" <ricky.clarkson@gmail.com> wrote:

I introduced Option at work in some Java code for builders; basically,
a builder would have a number of parameters, Param<Long>,
Param<Boolean>, etc.  Option would let you have Param<Option<Long>> to
specify an optional parameter, rather than having to write a separate
OptionalParameter class and have code duplication everywhere.

Other than that, I said it was a smarter null, as you could not
dereference it without being aware that it may contain nothing.  I
ended up implementing a new Option type in our codebase, though with
what I think is an interesting addition; my Option.None contains a
String reason.  Yes, Tony, this means it's now a String | T, not a
Nothing | T, so calling it Option is a little dubious.  If every time
I got an NPE I could see *why* the value was null at a glance, that'd
be excellent.  There are far too many return null;s in the codebase;
some of them represent errors, some of them represent that there just
was no result for some reason.

I'm not suggesting Scala's Option changes at all, just detailing an experience.

2009/11/20 Kevin Wright <kev.lee.wright@googlemail.com>:

> Sometimes this is frustrating hard, because the short answer "Option is a > monad, using nulls is ...

-- Ricky Clarkson Java and Scala Programmer, AD Holdings +44 1565 770804 Skype: ricky_clarkson Goog...

On Fri, 2009-11-20 at 12:00 +0100, Viktor Klang wrote:
> Buckley says John Rose is working on stack allocation. So I guess we
> need an audience with mr Rose!

As far as I know, John Rose is working on invokedynamic. I just asked
Christian Thalinger (a HotSpot engineer) on IRC and he said:

"No, we don't plan to support stack allocation as TLAB allocations are
nearly as fast."

Best,
Ismael

I will not choose to duplicate code for the hypothetical developer who
will not understand Option.

2009/11/20 Philip Köster :
> As Scott Meyers wrote in his unforgettable book, ``More Effective C++," he
> left no doubt about his basic point: If you want to express something,
> express it in the language so anyone can understand it. For me that was the
> most fundamental sentence of his books. Transferred to Java, which has only
> a very poor understanding of constness, this means: ``If you want to express
> something as being null, then make it null and not have it an instance of a
> contrived made-up class."
>
> Ricky Clarkson schrieb:
>>
>> I introduced Option at work in some Java code for builders; basically,
>> a builder would have a number of parameters, Param,
>> Param, etc.  Option would let you have Param> to
>> specify an optional parameter, rather than having to write a separate
>> OptionalParameter class and have code duplication everywhere.
>>
>> Other than that, I said it was a smarter null, as you could not
>> dereference it without being aware that it may contain nothing.  I
>> ended up implementing a new Option type in our codebase, though with
>> what I think is an interesting addition; my Option.None contains a
>> String reason.  Yes, Tony, this means it's now a String | T, not a
>> Nothing | T, so calling it Option is a little dubious.  If every time
>> I got an NPE I could see *why* the value was null at a glance, that'd
>> be excellent.  There are far too many return null;s in the codebase;
>> some of them represent errors, some of them represent that there just
>> was no result for some reason.
>>
>> I'm not suggesting Scala's Option changes at all, just detailing an
>> experience.
>>
>> 2009/11/20 Kevin Wright :
>>>
>>> Sometimes this is frustrating hard, because the short answer "Option is a
>>> monad, using nulls is not" is no more enlightening to most Java devs.
>>> I tend to explain it as "Option is a list constrained to size 0 or 1",
>>> this
>>> means that you can use expressions like "for every item in the list" and
>>> know that they still won't error even if the list is empty.
>>>
>>> On Fri, Nov 20, 2009 at 10:36 AM, Philip Köster
>>> wrote:
>>>>
>>>> Ismael Juma schrieb:
>>>>>
>>>>> On Fri, 2009-11-20 at 11:13 +0100, Philip Köster wrote:
>>>>>>
>>>>>> Now this is a good example of how libraries should *not* be designed.
>>>>>> It
>>>>>> places the burden on the user of a lib, who really just wants to get
>>>>>> his job
>>>>>> done and not worry about subleties such as the difference between
>>>>>> `null' and
>>>>>> `None'. This imposes a new kind of fuzzy logic leading to even more
>>>>>> if-then-else branches than we really need.
>>>>>
>>>>> This leads me to think that you're using it wrong. Option is meant to
>>>>> help with the if/else problem that one finds with null (and also the
>>>>> problem that one never knows where null is expected). You may want to
>>>>> check some tutorials on Option and the various ways you can use it
>>>>> without having to rely on if/else all the time.
>>>>>
>>>>> Best,
>>>>> Ismael
>>>>>
>>>>>
>>>> I read all the tutorials, so please don't talk to me like a was a child,
>>>> 'cause that is something that really pisses me off and makes me
>>>> speechless.
>>>> I can very well understand why beginners are confused about the diff
>>>> between
>>>> `Option' and the Java-native null value, and I predict many failures
>>>> will
>>>> arise from this basic misunderstanding. A user asked what the difference
>>>> was, and you gave no answer but only increased the confusedness. QED.
>>>
>>
>>
>>
>

I guess Rose is mainly working on invokedynamic, but there wasn't really room for me to misunderstand Buckley.

You seem much more versed in this thing than I am so I'll yield here.

On Nov 20, 2009 12:15 PM, "Ismael Juma" <mlists@juma.me.uk> wrote:

On Fri, 2009-11-20 at 12:00 +0100, Viktor Klang wrote: > Buckley says John Rose is working on stack ...

As far as I know, John Rose is working on invokedynamic. I just asked
Christian Thalinger (a HotSpot engineer) on IRC and he said:

"No, we don't plan to support stack allocation as TLAB allocations are
nearly as fast."

Best,
Ismael

Just throwing this out there, but if you want a "reason" type
functionality then take a look at Lifts Box type. It's states are:

Empty
Failure
Full

Essentially failure gives you proper handling of a "reason" for the
error or cause of the box being empty (if one exisits)

Might be worth a look at least.

Cheers, Tim

Sent from my iPhone

On 20 Nov 2009, at 11:51, Ricky Clarkson
wrote:

> I introduced Option at work in some Java code for builders; basically,
> a builder would have a number of parameters, Param,
> Param, etc. Option would let you have Param> to
> specify an optional parameter, rather than having to write a separate
> OptionalParameter class and have code duplication everywhere.
>
> Other than that, I said it was a smarter null, as you could not
> dereference it without being aware that it may contain nothing. I
> ended up implementing a new Option type in our codebase, though with
> what I think is an interesting addition; my Option.None contains a
> String reason. Yes, Tony, this means it's now a String | T, not a
> Nothing | T, so calling it Option is a little dubious. If every time
> I got an NPE I could see *why* the value was null at a glance, that'd
> be excellent. There are far too many return null;s in the codebase;
> some of them represent errors, some of them represent that there just
> was no result for some reason.
>
> I'm not suggesting Scala's Option changes at all, just detailing an
> experience.
>
> 2009/11/20 Kevin Wright :
>> Sometimes this is frustrating hard, because the short answer
>> "Option is a
>> monad, using nulls is not" is no more enlightening to most Java devs.
>> I tend to explain it as "Option is a list constrained to size 0 or
>> 1", this
>> means that you can use expressions like "for every item in the
>> list" and
>> know that they still won't error even if the list is empty.
>>
>> On Fri, Nov 20, 2009 at 10:36 AM, Philip Köster > e>
>> wrote:
>>>
>>>
>>> Ismael Juma schrieb:
>>>>
>>>> On Fri, 2009-11-20 at 11:13 +0100, Philip Köster wrote:
>>>>>
>>>>> Now this is a good example of how libraries should *not* be
>>>>> designed. It
>>>>> places the burden on the user of a lib, who really just wants to
>>>>> get his job
>>>>> done and not worry about subleties such as the difference
>>>>> between `null' and
>>>>> `None'. This imposes a new kind of fuzzy logic leading to even
>>>>> more
>>>>> if-then-else branches than we really need.
>>>>
>>>> This leads me to think that you're using it wrong. Option is
>>>> meant to
>>>> help with the if/else problem that one finds with null (and also
>>>> the
>>>> problem that one never knows where null is expected). You may
>>>> want to
>>>> check some tutorials on Option and the various ways you can use it
>>>> without having to rely on if/else all the time.
>>>>
>>>> Best,
>>>> Ismael
>>>>
>>>>
>>>
>>> I read all the tutorials, so please don't talk to me like a was a
>>> child,
>>> 'cause that is something that really pisses me off and makes me
>>> speechless.
>>> I can very well understand why beginners are confused about the
>>> diff between
>>> `Option' and the Java-native null value, and I predict many
>>> failures will
>>> arise from this basic misunderstanding. A user asked what the
>>> difference
>>> was, and you gave no answer but only increased the confusedness.
>>> QED.
>>
>>
>
>
>

> I will not choose to duplicate code for the hypothetical developer who
> will not understand Option.

And I would not want to switch with a developer confronting me with such
Blödsinn ...

Welcome to the new scala-user Ricky :)

Want to lament over a beer?

Philip Köster wrote:
>
>> I will not choose to duplicate code for the hypothetical developer who
>> will not understand Option.
>
> And I would not want to switch with a developer confronting me with
> such Blödsinn ...
>

> -----Original Message-----
> From: philip.koester@web.de [mailto:philip.koester@web.de]
> Sent: Friday, November 20, 2009 12:15 PM
> As Scott Meyers wrote in his unforgettable book, ``More
> Effective C++,"
> he left no doubt about his basic point: If you want to
> express something, express it in the language so anyone can
> understand it. For me that was the most fundamental sentence
> of his books. Transferred to Java, which has only a very poor
> understanding of constness, this means:
> ``If you want to express something as being null, then make
> it null and not have it an instance of a contrived made-up class."

Be careful: The premise that a programmer wants "to express something
as being null" may be wrong right to begin with.
I at least would rather want to express something as being an optionally
empty result. This is explicitly expressed in the language when seeing
Option[T] as a result type, and anyone can understand it.
This is NOT expressed when the result type is T and may _implicitly_ be
null or not, what one only detects when looking at the javadoc (just NOT the
language, but an additional textual description!) or my implementation (only
possible for open source).

Beside that:

> > I will not choose to duplicate code for the hypothetical
> developer who will not understand Option.
>
> And I would not want to switch with a developer confronting
> me with such Blödsinn ...
>

I want to state that I am repelled by the tone of the posts of yours
I read in the last time.
Please be so kind to watch your words and keep an adult attitude.

KR
Det

Tony Morris schrieb:
> Welcome to the new scala-user Ricky :)
>
> Want to lament over a beer?
>
> Philip Köster wrote:
>>> I will not choose to duplicate code for the hypothetical developer who
>>> will not understand Option.
>> And I would not want to switch with a developer confronting me with
>> such Blödsinn ...
>>
>

No problem on my side. I like Ricky. No insult intended. Drinking a beer
w/ some1 from another continent might broaden my perspective and make my
life more colorful. No hard feelings about Ricky, by no means. I enjoy
his postings, only sometimes I disagree.

The differences between Map.get() and Map.apply() are indeed confusing to
newcomers, particularly since the Map.apply() gets to use the special ()
syntax even though it has notably worse failure characteristics. That
doesn't have much to do with Option, however, just a minor confusion in
library design that looks like it was created for no better reason than to
leverage the special () syntax. I essentially never use Map.apply() for
just that reason, unless I'm absolutely sure the element is in the map (and
thus want the exception, if I turn out to be wrong).

(And yes, Ismael was being rude, albeit unintentionally. If all you have to
add is "You're doing it wrong, go read some tutorials" then you are better
off not saying anything. There's no way you aren't going to end up sounding
like an ass.)

--Dave Griffith

On Fri, Nov 20, 2009 at 04:48:20AM -0800, Dave Griffith wrote:
> (And yes, Ismael was being rude, albeit unintentionally. If all you
> have to add is "You're doing it wrong, go read some tutorials" then
> you are better off not saying anything. There's no way you aren't
> going to end up sounding like an ass.)

I object. ijuma goes to what I consider superhuman lengths to avoid
offending people. If you find a way to take offense from an email of
his, the smart money is on you being oversensitive and insecure. You
are the one who would have been better off saying nothing (and it's not
too late to start.)

I still think null is a mistake as it is not type checked nor does it make clear the intentions of  use: Is it null because somebody forgot to allocate it, is it null because of the absence of a result or is it null because somebody made a mistake?

Option forces you to think and handle the null value as a type and can be checked by the compiler to be there so no unintended null values.
This is from a library designers view as well as from a users view.

And if it bothers you so much that the user has to unpack the Option then provide a method that does this for him and make it return null and see how your users will run into unintended NPEs all the time.
 

On Fri, 2009-11-20 at 04:48 -0800, Dave Griffith wrote:
>
> The differences between Map.get() and Map.apply() are indeed confusing to
> newcomers, particularly since the Map.apply() gets to use the special ()
> syntax even though it has notably worse failure characteristics. That
> doesn't have much to do with Option, however, just a minor confusion in
> library design that looks like it was created for no better reason than to
> leverage the special () syntax.

It's there because Map inherits from Function which has an apply method.

Ismael

On Fri, 2009-11-20 at 05:13 -0800, Paul Phillips wrote:
> On Fri, Nov 20, 2009 at 04:48:20AM -0800, Dave Griffith wrote:
> > (And yes, Ismael was being rude, albeit unintentionally. If all you
> > have to add is "You're doing it wrong, go read some tutorials"

It may help to read my message again. I did not say it like that. It was
a comment based on one of the issues Philip identified in the way he
uses Option.

And if you think I was rude there, then your definition of rude differs
from mine.

> > then
> > you are better off not saying anything. There's no way you aren't
> > going to end up sounding like an ass.)
>
> I object. ijuma goes to what I consider superhuman lengths to avoid
> offending people. If you find a way to take offense from an email of
> his, the smart money is on you being oversensitive and insecure. You
> are the one who would have been better off saying nothing (and it's not
> too late to start.)

Thanks, Paul.

Ismael

> (And yes, Ismael was being rude, albeit unintentionally. If
> all you have to add is "You're doing it wrong, go read some
> tutorials" then you are better off not saying anything.
> There's no way you aren't going to end up sounding like an ass.)

He did not say it this way.
Read again:
"This leads me to think that you're using it wrong. Option is meant
to help with the if/else problem that one finds with null
(and also the problem that one never knows where null is expected).
You may want to check some tutorials on Option and the various ways
you can use it without having to rely on if/else all the time."

From what I know of Option and what I read from Philips mail,
the thought arose in me too, that perhaps a misunderstanding
or misapplication of Option was the problem.
Beside writing long introductory material in a mail, a hint
to already elaborated stuff is valid (although a specific link
would have done no bad).

If that misses the point, that can be clarified.

I have been target of such advising here before, but a simple
"no I understood the basics, but you haven't grokked my
specific problems with it, so look ..." helped to lift further
discussions to a higher level and gave me the opportunity to
gain a deeper understanding, of Scala's solution as well as my
own problem.

I experienced this list before as a place where questions are
welcomed and answered with patience.
Let us keep that communicative and de-escalating level.

(BTW: I still haven't understood the reason for the statement
that Option/None be more of a burden for a lib user than null and
imposes even more if-else branches)

KR
Det

No, Paul, your mails are always enlightening and humorous in a way, and
I have come to enjoy them. But the way you outnumber others that don't
share your sort of genious appears best arrogantly to me.

Paul Phillips schrieb:
> On Fri, Nov 20, 2009 at 04:48:20AM -0800, Dave Griffith wrote:
>> (And yes, Ismael was being rude, albeit unintentionally. If all you
>> have to add is "You're doing it wrong, go read some tutorials" then
>> you are better off not saying anything. There's no way you aren't
>> going to end up sounding like an ass.)
>
> I object. ijuma goes to what I consider superhuman lengths to avoid
> offending people. If you find a way to take offense from an email of
> his, the smart money is on you being oversensitive and insecure. You
> are the one who would have been better off saying nothing (and it's not
> too late to start.)
>

On Fri, Nov 20, 2009 at 04:14:42PM +0100, Philip Köster wrote:
> No, Paul, your mails are always enlightening and humorous in a way,
> and I have come to enjoy them. But the way you outnumber others that
> don't share your sort of genious appears best arrogantly to me.

Can I get "outnumber" in the original German? That's a serious question,
I'm endlessly fascinated by the way concepts take different expressions
in different languages, and how that alters the way (and whether) people
think about them. In the US we have no shame about filling in gaps when
we spot a good one elsewhere. Which reminds me, thanks for
"schadenfreude", I don't know how we got along before that one.

2009/11/19 Maxime Lévesque <maxime.levesque@gmail.com>

 Does scalac implement some kind of magic so that
using Option[T]  is as efficient as using nulls ?
Of course Option is a wrapper so the extra cost should
be one thin object. I was just writing a tight loop
and was trying to make it lean and mean. I got tempted
to depart from idiomatic scala here and use a good old null,
it got me wondering if this kind of magic be doable by
the compiler ? (And is it doing it ?)

  Cheers

Most of my Scala code performs just fine using Scala idioms.  The occational bit of code that needs additional tuning (e.g., converting a String to JavaScript escaping), my code looks more like C than anything else (pre-allocation of buffers, no memory allocation inside the inner-most loop, etc.)  So, in this very narrow case, I think using null is okay, but I'd document the code heavily (including the justification).  Also, the null constructs shouldn't escape a set of private methods in a given class.

My 2 cents.



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

Philip Köster wrote:
> As Scott Meyers wrote in his unforgettable book, ``More Effective C++,"
> he left no doubt about his basic point: If you want to express
> something, express it in the language so anyone can understand it. For
> me that was the most fundamental sentence of his books. Transferred to
> Java, which has only a very poor understanding of constness, this means:
> ``If you want to express something as being null, then make it null and
> not have it an instance of a contrived made-up class."

Philip,

just to provide you with some more context...

http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mi...

Ciao
Paolo

2009/11/19 Maxime Lévesque <maxime.levesque@gmail.com>

I was just writing a tight loop
and was trying to make it lean and mean. I got tempted
to depart from idiomatic scala here and use a good old null

If you need performance inside a tight loop, don't feel bad about using null, just because it's not "idiomatic Scala".
Just don't let the null escape.

> Can I get "outnumber" in the original German?

It's hard to find a German to English translation. (That's why my
English is so bad.) You know you are intelligent, you won the WSOP
series, and you ``rule out" others that don't have your talents. You're
a given programmer, but you have a hard time to get into a beginner's mind.

His question, rephrased:

"What was the German word that you translated to "outnumber"?". I.e.,
don't translate it, just type the word, in German.

2009/11/20 Philip Köster :
>> Can I get "outnumber" in the original German?
>
> It's hard to find a German to English translation. (That's why my English is
> so bad.) You know you are intelligent, you won the WSOP series, and you
> ``rule out" others that don't have your talents. You're a given programmer,
> but you have a hard time to get into a beginner's mind.
>

> Date: Fri, 20 Nov 2009 04:48:20 -0800
> From: dave.l.griffith@gmail.com
> To: scala-user@listes.epfl.ch
> Subject: Re: [scala-user] Cost of Option / Some vs null
>
>
>
> The differences between Map.get() and Map.apply() are indeed confusing to
> newcomers, particularly since the Map.apply() gets to use the special ()
> syntax even though it has notably worse failure characteristics.

I think it's really useful to have both syntaxes; it means I can do (in the case where it represents a programming error to not have a key defined):

    doSomethingWith( map(key) )

As opposed to:

    assume(map.isDefinedAt(key))
    doSomethingWith( map.get(key).get )

Or the alternative using match (4 lines of code). This means that I can do an assert and lookup at the same time; much clearer!




Have more than one Hotmail account? Link them together to easily access both.

Regarding object creation costs, I find that creating and disposing of a small, transient object takes about 4-8 ns/object on decent modern processors (3 GHz Core 2, for example) with the 1.6 JVM.

Although I've not specifically tested it with Option, I'd expect a similar time taken there.

Note that you only pay this cost when you return a Some.  None is a singleton object and is passed essentially for free.

Another interesting question that I have not investigated is how much time is taken by handling/unwrapping Some(x) vs. None.  My intuition is that pattern matches would be the slowest and would take something close to object creation time, while (y eq None) would be the fastest (probably under a clock cycle in optimized JIT code).  But given the complexity of modern CPU architecture and all the wizardry performed by the JVM, I would test rather than assume if I used it for anything important.

  --Rex

On Fri, Nov 20, 2009 at 12:05 PM, christopher marshall <oxbow_lakes@hotmail.com> wrote:

> Date: Fri, 20 Nov 2009 04:48:20 -0800
> From: dave.l.griffith@gmail.com
> To: scala-user@listes.epfl.ch
> Subject: Re: [scala-user] Cost of Option / Some vs null
>
>
>
> The differences between Map.get() and Map.apply() are indeed confusing to
> newcomers, particularly since the Map.apply() gets to use the special ()
> syntax even though it has notably worse failure characteristics.

I think it's really useful to have both syntaxes; it means I can do (in the case where it represents a programming error to not have a key defined):

    doSomethingWith( map(key) )

As opposed to:

    assume(map.isDefinedAt(key))
    doSomethingWith( map.get(key).get )

Or the alternative using match (4 lines of code). This means that I can do an assert and lookup at the same time; much clearer!




Have more than one Hotmail account? Link them together to easily access both.

By the way, data provenance ("where did this piece of data come from?") is a quite hot topic in databases right now. In your trick, you basically answer "where did this null came from?". I think it's likely in the future such techniques to be more common, both in databases and software, though it's tricky. But in some cases it's immensely useful for some kind of values to be able to ask "how/why this particular value was computed", and get back something like "because this operation was applied with this and that inputs", perhaps recursively.
Dimitris

2009/11/20 Ricky Clarkson <ricky.clarkson@gmail.com>

I introduced Option at work in some Java code for builders; basically,
a builder would have a number of parameters, Param<Long>,
Param<Boolean>, etc.  Option would let you have Param<Option<Long>> to
specify an optional parameter, rather than having to write a separate
OptionalParameter class and have code duplication everywhere.

Other than that, I said it was a smarter null, as you could not
dereference it without being aware that it may contain nothing.  I
ended up implementing a new Option type in our codebase, though with
what I think is an interesting addition; my Option.None contains a
String reason.  Yes, Tony, this means it's now a String | T, not a
Nothing | T, so calling it Option is a little dubious.  If every time
I got an NPE I could see *why* the value was null at a glance, that'd
be excellent.  There are far too many return null;s in the codebase;
some of them represent errors, some of them represent that there just
was no result for some reason.

I'm not suggesting Scala's Option changes at all, just detailing an experience.

2009/11/20 Kevin Wright <kev.lee.wright@googlemail.com>:
> Sometimes this is frustrating hard, because the short answer "Option is a
> monad, using nulls is not" is no more enlightening to most Java devs.
> I tend to explain it as "Option is a list constrained to size 0 or 1", this
> means that you can use expressions like "for every item in the list" and
> know that they still won't error even if the list is empty.
>
> On Fri, Nov 20, 2009 at 10:36 AM, Philip Köster <philip.koester@web.de>
> wrote:
>>
>>
>> Ismael Juma schrieb:
>>>
>>> On Fri, 2009-11-20 at 11:13 +0100, Philip Köster wrote:
>>>>
>>>> Now this is a good example of how libraries should *not* be designed. It
>>>> places the burden on the user of a lib, who really just wants to get his job
>>>> done and not worry about subleties such as the difference between `null' and
>>>> `None'. This imposes a new kind of fuzzy logic leading to even more
>>>> if-then-else branches than we really need.
>>>
>>> This leads me to think that you're using it wrong. Option is meant to
>>> help with the if/else problem that one finds with null (and also the
>>> problem that one never knows where null is expected). You may want to
>>> check some tutorials on Option and the various ways you can use it
>>> without having to rely on if/else all the time.
>>>
>>> Best,
>>> Ismael
>>>
>>>
>>
>> I read all the tutorials, so please don't talk to me like a was a child,
>> 'cause that is something that really pisses me off and makes me speechless.
>> I can very well understand why beginners are confused about the diff between
>> `Option' and the Java-native null value, and I predict many failures will
>> arise from this basic misunderstanding. A user asked what the difference
>> was, and you gave no answer but only increased the confusedness. QED.
>
>



--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@gmail.com
Google Wave: ricky.clarkson@googlewave.com

On Fri, Nov 20, 2009 at 5:51 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

I ended up implementing a new Option type in our codebase, though with
what I think is an interesting addition; my Option.None contains a
String reason.

I imagine that Ricky already knows this, but in case others don't:

This is what Either is often used for, although it is admittedly a little more awkward and can be a little less efficient than a customized Option ("Left" basically means "Wrong" when used this way):

def getFileName(args:Array[String]) = {
  if (args.length!=1) Left("A single file name was not supplied.")
  else Right(new java.io.File(args(0)))
}

val fileResult = getFileName(myArgs)
if (fileResult.isRight) {
  // Blah blah blah with fileResult.right.get
}
else {
  // Handle error using fileResult.left.get
}

alternative:

fileResult.fold(errorString => {
  // handle error case
} ,
goodFile => {
  // handle case where file is okay
})

The nice thing about Either is that you're not restricted to returning a String in case something goes wrong.  You could pass back an exception or, well, anything else.

The not-so-nice thing about Either is that it's sealed (probably to make pattern matching safer) so you can't extend it with your own domain-specific methods; instead, you'd need to write wrapper class(es) with implicit conversion functions.  Given the Left/Right/Either inheritance tree (necessary for the functionality), subclassing would be perilous anyway, though, so the sealed annotation isn't that much of a loss.

  --Rex

Discovering the `0' was what separated the Arabians from the Romans.

Of course, different than null, 0 is also a number. What the Romans and many others had was the "absence" of a number. You had 1, 2, 3, etc, and, if none of them applied, you had a space representing its absence.   Which was quite unfortunate, as you can't really do anything with the absence of a number. Much like how null works, or doesn't, in fact.

On Fri, Nov 20, 2009 at 5:11 PM, Philip Köster <philip.koester@web.de> wrote:

Discovering the `0' was what separated the Arabians from the Romans.

--
Daniel C. Sobral

Veni, vidi, veterni.

map.getOrElse(x, throw new DescriptiveException())

Not saying it's good, mind you, but it is clear and concise.

--Dave Griffith

christopher marshall-2 wrote:
>
> Or the alternative using match (4 lines of code). This means that I can do
> an assert and lookup at the same time; much clearer!
>

0 exists. null represents "that which does not exist." In computational
theory, what null represents is more commonly called bottom, _|_,
undefined, non-terminating computation, logical absurdity. In philosophy
it is sometimes called "not even false."

I recommend:
* Try a turing-complete language without null, such as a pure functional
one. Ask, why does this pure functional language not have null?
* Try a language without null and without absurdity (i.e.
non-termination) such as Coq where you will learn about types as
theorems (warning: you will learn about once-inhabited types,, which has
implications for discourse with others).

To "want to represent null" is a false premise of the most blatant kind.
Option is merely a list with a maximum length of one. That's really what
you want to represent. Use the types.

Philip Köster wrote:
> Discovering the `0' was what separated the Arabians from the Romans.
>

On Fri, Nov 20, 2009 at 18:58, Paolo Losi wrote:
> Philip Köster wrote:
>>
>> As Scott Meyers wrote in his unforgettable book, ``More Effective C++," he
>> left no doubt about his basic point: If you want to express something,
>> express it in the language so anyone can understand it. For me that was the
>> most fundamental sentence of his books. Transferred to Java, which has only
>> a very poor understanding of constness, this means: ``If you want to express
>> something as being null, then make it null and not have it an instance of a
>> contrived made-up class."
>
> Philip,
>
> just to provide you with some more context...
>
> http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mi...

Blaming null is a common misconception. Bad programmers always make
bugs, not depending of whether null exists.

I'm confortable with null. In most cases I use Option, but in rare
cases nulls are necessary.

Example, when class maps database table with tens of columns:

===
class User {
// null means "uninitialized"
var field1: String = null
var field2: String = null
var field3: String = null
var field4: String = null
// ...
}
===

Different subsets of fields are initialized in different queries.

===
def findLoginAndEmail(id: Long): User
def findBasicFields(id: Long): User
def findAllFields(id: Long): User
===

Making all fields Options makes access to these fields verbose:
"user.field3.get" instead of just "user.field3", "user.field3 =
Some(...)" instead of "user.field3 = ...".

This design is not perfect, but sometime it is necessary.

The main reason why people blame null is bad performance of Option.
But if Option is slow (it is), then JVM should be fixed (by
introducing value types), not Scala language.

S.

Your class is still "wrong".  You've chosen the wrong database ORM mapper.... (If I wanted to make a dumb point).

You should include values in your constructor.  I believe you can even use immutable classes with hibernate.  In fact, I've debated with myself over whether this would help resolve NPE bugs in my codebase.  Some developers are too comfortable with null....


- Josh

On Fri, Nov 20, 2009 at 3:50 PM, Stepan Koltsov <stepan.koltsov@gmail.com> wrote:

[snip/]

Blaming null is a common misconception. Bad programmers always make
bugs, not depending of whether null exists.

I'm confortable with null. In most cases I use Option, but in rare
cases nulls are necessary.

Example, when class maps database table with tens of columns:

===
class User {
 // null means "uninitialized"
 var field1: String = null
 var field2: String = null
 var field3: String = null
 var field4: String = null
 // ...
}
===

Different subsets of fields are initialized in different queries.

===
def findLoginAndEmail(id: Long): User
def findBasicFields(id: Long): User
def findAllFields(id: Long): User
===

Making all fields Options makes access to these fields verbose:
"user.field3.get" instead of just "user.field3", "user.field3 =
Some(...)" instead of "user.field3 = ...".

This design is not perfect, but sometime it is necessary.


The main reason why people blame null is bad performance of Option.
But if Option is slow (it is), then JVM should be fixed (by
introducing value types), not Scala language.

S.

In my opinion null has two big problems:
1. It's pervasive in most imperative languages because it's not encoded in types
2. It's semantically ambiguous

#2 is the more interesting one, because it can apply to Option as well, depending on how Option is used.  I think of Option as a collection that can contain 0..1 objects, with either being completely valid.  However there's nothing to stop people from using the None side to mean "not initialized yet," "unknown," or "an error occurred."  I personally think such usage is wrong, and instead types that reflect the intended semantics should be used.

I think arguments about avoiding NPEs by using Option instead of null are red herrings, because you can just as easily call get() on Option and receive a NoSuchElementException (I think that's what it throws).

On Fri, Nov 20, 2009 at 3:50 PM, Stepan Koltsov <stepan.koltsov@gmail.com> wrote:

On Fri, Nov 20, 2009 at 18:58, Paolo Losi <paolo.losi@gmail.com> wrote:
> Philip Köster wrote:
>>
>> As Scott Meyers wrote in his unforgettable book, ``More Effective C++," he
>> left no doubt about his basic point: If you want to express something,
>> express it in the language so anyone can understand it. For me that was the
>> most fundamental sentence of his books. Transferred to Java, which has only
>> a very poor understanding of constness, this means: ``If you want to express
>> something as being null, then make it null and not have it an instance of a
>> contrived made-up class."
>
> Philip,
>
> just to provide you with some more context...
>
> http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare

Blaming null is a common misconception. Bad programmers always make
bugs, not depending of whether null exists.

I'm confortable with null. In most cases I use Option, but in rare
cases nulls are necessary.

Example, when class maps database table with tens of columns:

===
class User {
 // null means "uninitialized"
 var field1: String = null
 var field2: String = null
 var field3: String = null
 var field4: String = null
 // ...
}
===

Different subsets of fields are initialized in different queries.

===
def findLoginAndEmail(id: Long): User
def findBasicFields(id: Long): User
def findAllFields(id: Long): User
===

Making all fields Options makes access to these fields verbose:
"user.field3.get" instead of just "user.field3", "user.field3 =
Some(...)" instead of "user.field3 = ...".

This design is not perfect, but sometime it is necessary.


The main reason why people blame null is bad performance of Option.
But if Option is slow (it is), then JVM should be fixed (by
introducing value types), not Scala language.

S.

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

On Sat, Nov 21, 2009 at 03:01, Josh Suereth wrote:
> Your class is still "wrong".

It solved given task well. So I don't think it is wrong.

>  You've chosen the wrong database ORM
> mapper.... (If I wanted to make a dumb point).

You definitely know all my project requirements.

> You should include values in your constructor.

Maybe. But still some fields must remain uninitialized (== null).

>  I believe you can even use
> immutable classes with hibernate.

We do not use ORM for number of reasons.

>  In fact, I've debated with myself over
> whether this would help resolve NPE bugs in my codebase.  Some developers
> are too comfortable with null....

Some people think, that Option is a silver bullet, but actually there
is no difference. If you change null to None, your NPEs get changed to
NoSuchElementException. NPEs weren't problems in our project at all.
Code should just be clear, where nulls are possible.

S.

> - Josh
>
> On Fri, Nov 20, 2009 at 3:50 PM, Stepan Koltsov
> wrote:
>>
>> [snip/]
>>
>> Blaming null is a common misconception. Bad programmers always make
>> bugs, not depending of whether null exists.
>>
>> I'm confortable with null. In most cases I use Option, but in rare
>> cases nulls are necessary.
>>
>> Example, when class maps database table with tens of columns:
>>
>> ===
>> class User {
>>  // null means "uninitialized"
>>  var field1: String = null
>>  var field2: String = null
>>  var field3: String = null
>>  var field4: String = null
>>  // ...
>> }
>> ===
>>
>> Different subsets of fields are initialized in different queries.
>>
>> ===
>> def findLoginAndEmail(id: Long): User
>> def findBasicFields(id: Long): User
>> def findAllFields(id: Long): User
>> ===
>>
>> Making all fields Options makes access to these fields verbose:
>> "user.field3.get" instead of just "user.field3", "user.field3 =
>> Some(...)" instead of "user.field3 = ...".
>>
>> This design is not perfect, but sometime it is necessary.
>>
>>
>> The main reason why people blame null is bad performance of Option.
>> But if Option is slow (it is), then JVM should be fixed (by
>> introducing value types), not Scala language.
>>
>> S.
>
>

On Sat, Nov 21, 2009 at 03:16, Erik Engbrecht wrote:
> In my opinion null has two big problems:
> 1. It's pervasive in most imperative languages because it's not encoded in
> types

Explain, please.

> 2. It's semantically ambiguous
>
> #2 is the more interesting one, because it can apply to Option as well,
> depending on how Option is used.  I think of Option as a collection that can
> contain 0..1 objects, with either being completely valid.  However there's
> nothing to stop people from using the None side to mean "not initialized
> yet," "unknown," or "an error occurred."  I personally think such usage is
> wrong, and instead types that reflect the intended semantics should be used.

Your comment is great, but I don't think it is a problem.

> I think arguments about avoiding NPEs by using Option instead of null are
> red herrings, because you can just as easily call get() on Option and
> receive a NoSuchElementException (I think that's what it throws).

Yes!

S.

> On Fri, Nov 20, 2009 at 3:50 PM, Stepan Koltsov
> wrote:
>>
>> On Fri, Nov 20, 2009 at 18:58, Paolo Losi wrote:
>> > Philip Köster wrote:
>> >>
>> >> As Scott Meyers wrote in his unforgettable book, ``More Effective C++,"
>> >> he
>> >> left no doubt about his basic point: If you want to express something,
>> >> express it in the language so anyone can understand it. For me that was
>> >> the
>> >> most fundamental sentence of his books. Transferred to Java, which has
>> >> only
>> >> a very poor understanding of constness, this means: ``If you want to
>> >> express
>> >> something as being null, then make it null and not have it an instance
>> >> of a
>> >> contrived made-up class."
>> >
>> > Philip,
>> >
>> > just to provide you with some more context...
>> >
>> >
>> > http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mi...
>>
>> Blaming null is a common misconception. Bad programmers always make
>> bugs, not depending of whether null exists.
>>
>> I'm confortable with null. In most cases I use Option, but in rare
>> cases nulls are necessary.
>>
>> Example, when class maps database table with tens of columns:
>>
>> ===
>> class User {
>>  // null means "uninitialized"
>>  var field1: String = null
>>  var field2: String = null
>>  var field3: String = null
>>  var field4: String = null
>>  // ...
>> }
>> ===
>>
>> Different subsets of fields are initialized in different queries.
>>
>> ===
>> def findLoginAndEmail(id: Long): User
>> def findBasicFields(id: Long): User
>> def findAllFields(id: Long): User
>> ===
>>
>> Making all fields Options makes access to these fields verbose:
>> "user.field3.get" instead of just "user.field3", "user.field3 =
>> Some(...)" instead of "user.field3 = ...".
>>
>> This design is not perfect, but sometime it is necessary.
>>
>>
>> The main reason why people blame null is bad performance of Option.
>> But if Option is slow (it is), then JVM should be fixed (by
>> introducing value types), not Scala language.