Cost of Option / Some vs null

It's pervasive in Java (and Scala) because pretty much every single reference has the possibility of being null.  The type system does nothing to prevent it.  The same goes for most other imperative languages, whether then call it null, Nil, None, or something else.

In Scala I think it's considered bad style to use null in public ways, and ok to use it as an optimization so long as it is restricted to the private parts of your class.  In Java null is used all the time, usually to mean either None or to mean "not yet initialized."  So with pure Scala code written by a trusted genious you can safely assume that null isn't going to bite you, while with Java you have to be prepared for it all the time.

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

On Sat, Nov 21, 2009 at 03:16, Erik Engbrecht <erik.engbrecht@gmail.com> 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 <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.

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

Actaully, I was making a dumb point that you could avoid null entirely if you choose.

You could make an option that has two states:  Unitialized and Initialized(value)e instead....  Especially if you're not using an ORM.


- Josh

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

On Sat, Nov 21, 2009 at 03:01, Josh Suereth <joshua.suereth@gmail.com> 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 <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.
>
>

Stepan Koltsov-2 wrote:
>
> Blaming null is a common misconception. Bad programmers always make
> bugs, not depending of whether null exists.
>

All programmers, good and bad, create bugs. Weirdly enough, whether you are
a good programmer
or bad doesn't even have much effect on your rate of bug creation. The
(somewhat disturbing) rule of
thumb is that whenever you write 10 lines of code you have, on average,
coded a bug. This is
independent of both programmer skill and language used. (It's also
independent of just how hard
you try to code in a bug-free manner. Discipline doesn't get you very far,
can't be trusted, can't
be maintained, and absolutely, positively does not scale.)

This matters. Because of this reality, just about the only way to decrease
bugs created per feature is to decrease the number of lines of code
necessary to implement an average feature. Both Scala and the various
dynamic languages that have become popular of late are examples of languages
that attempt to allow greater density of features per line. They've been
quite successful at it, with usual density increases reported at about 3-10x
over Java/C#, clustering around 5x. That said, it's uncertain how much
denser functionality can get.

But if we can't decrease bug densities anymore, we can decrease bug costs.
The best way of doing that is to realize that not all bugs are created
equal. Some classes of bugs are easier and cheaper to find, and can be
found sooner than others. Bugs that manifest as static type errors
(ignoring casts) in typeful languages show up at compile time (or preferably
at edit time, as IDEs get more powerful). This makes them particularly
cheap to fix. Off-by-one errors and language-barrier errors (e.g.
misspelling fields for reflective access) tend to show up the first time a
program is run, making them annoying but
manageable. Null pointer errors and type cast errors are probably the
worst. They can lie dormant
in code until it gets to production and then manifest intermittently. At
that point things can get very
expensive indeed. Option moves null pointers from being production-time
nightmares to compile-time annoyances. That's nothing but upside. I'll
trade CPU cycles for that all day long.

Back when I was starting out in this industry, the worst sorts of bugs were
wild pointers and buffer overruns, which make null pointer exceptions look
positively tame in comparison. We as an industry annihilated wild pointer
bugs and buffer overruns for large classes of programming through a
combination of faster hardware and better language design. We can do the
same for null pointer bugs. Option (or something essentially the same as
Option) is pretty much the way to go for that. It's not perfect, but it's
pretty damn good, and the alternatives are all immeasurably worse.

--Dave Griffith

On Sat, Nov 21, 2009 at 04:16, Dave Griffith wrote:
> Stepan Koltsov-2 wrote:
>>
>> Blaming null is a common misconception. Bad programmers always make
>> bugs, not depending of whether null exists.
>>
>
> All programmers, good and bad, create bugs.  Weirdly enough, whether you are
> a good programmer
> or bad doesn't even have much effect on your rate of bug creation.  The
> (somewhat disturbing) rule of
> thumb is that whenever you write 10 lines of code you have, on average,
> coded a bug.   This is
> independent of both programmer skill and language used.  (It's also
> independent of just how hard
> you try to code in a bug-free manner.   Discipline doesn't get you very far,
> can't be trusted, can't
> be maintained, and absolutely, positively does not scale.)
>
> This matters.  Because of this reality, just about the only way to decrease
> bugs created per feature is to decrease the number of lines of code
> necessary to implement an average feature.  Both Scala and the various
> dynamic languages that have become popular of late are examples of languages
> that attempt to allow greater density of features per line.  They've been
> quite successful at it, with usual density increases reported at about 3-10x
> over Java/C#, clustering around 5x. That said, it's uncertain how much
> denser functionality can get.
>
> But if we can't decrease bug densities anymore, we can decrease bug costs.
> The best way of doing that is to realize that not all bugs are created
> equal.  Some classes of bugs are easier and cheaper to find, and can be
> found sooner than others.   Bugs that manifest as static type errors
> (ignoring casts) in typeful languages show up at compile time (or preferably
> at edit time, as IDEs get more powerful).  This makes them particularly
> cheap to fix.   Off-by-one errors and language-barrier errors (e.g.
> misspelling fields for reflective access) tend to show up the first time a
> program is run, making them annoying but
> manageable.   Null pointer errors and type cast errors are probably the
> worst.  They can lie dormant
> in code until it gets to production and then manifest intermittently.  At
> that point things can get very
> expensive indeed.   Option moves null pointers from being production-time
> nightmares to compile-time annoyances.  That's nothing but upside.  I'll
> trade CPU cycles for that all day long.
>
> Back when I was starting out in this industry, the worst sorts of bugs were
> wild pointers and buffer overruns, which make null pointer exceptions look
> positively tame in comparison.  We as an industry annihilated wild pointer
> bugs and buffer overruns for large classes of programming through a
> combination of faster hardware and better language design.   We can do the
> same for null pointer bugs.   Option (or something essentially the same as
> Option) is pretty much the way to go for that.  It's not perfect, but it's
> pretty damn good, and the alternatives are all immeasurably worse.

You probably missed parts of the discussion where explained how Option
changes NullPointerException to NoSuchElementException.

S.

> 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.

I need some time to get used to this. From my experience, I envision
noisy code like this, in pseudocode:

def foo(map: Map) {
val o = map[foo]
if (o == null) return
if (o instanceof None) return
if (o.get.equals("foo") { println "bingo" }
}

So I'm really not sure whether this new `Option' class is a blessing or
a curse.

It is easier to miss a variable that may be null than to ignore the possibility of an empty Option. The few times I sticked to the old habits of using null I got bitten by it so now I stick to Option, I'll worry about performance later. Using Option becomes natural once you get used to it.

Sébastien

2009/11/21 Stepan Koltsov <stepan.koltsov@gmail.com>

You probably missed parts of the discussion where explained how Option
changes NullPointerException to NoSuchElementException.


S.

On Fri, Nov 20, 2009 at 8:36 PM, Philip Köster wrote:
>> 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.
>
> I need some time to get used to this. From my experience, I envision noisy
> code like this, in pseudocode:
>
> def foo(map: Map) {
>        val o = map[foo]
>        if (o == null) return
>        if (o instanceof None) return
>        if (o.get.equals("foo") { println "bingo" }
> }

The idea is that code does not use null. So you'd write this in idiomatic scala:

def foo(map: Map) { // I assume you want some kind of type params here
for( msg <- map.get(foo) if msg != "foo") {
println("bingo");
}
}

If you're checking for null, then I guess you're going to have a
little more mess, but as others have pointed out, idiomatic scala
doesn't have nulls in user-facing code.

> If you're checking for null, then I guess you're going to have a
> little more mess, but as others have pointed out, idiomatic scala
> doesn't have nulls in user-facing code.

Okay. There's really not a lot I miss from C++, because that language is
a beast to handle, but its concepts of nonnullness and constness are
superior IMHO. In C++, I can make ``nonnullness" part of a function
contract, sparing me all those ifs checking preconditions. Of course I
can, in theory, dereference NULL to satisfy the compiler, but thas has
never been a problem in practice,

---Phil

Stepan Koltsov wrote:
> You probably missed parts of the discussion where explained how Option
> changes NullPointerException to NoSuchElementException.
>
Except it doesn't.

Tony Morris schrieb:
> Stepan Koltsov wrote:
>> You probably missed parts of the discussion where explained how Option
>> changes NullPointerException to NoSuchElementException.
>>
> Except it doesn't.
>

I'm just--thanks to Paolo Losi!--listening to Tony Hoare, some CS guy I
hadn't known before. He's a real British gentleman, one of a kind I
presumed extinct already. It is really a pleasure to listen to him. But
I don't think I agree with his basic point: Null pointers are bad. A
German guy posed the right question, and maybe because he asked it in
broken English, not a lot attention was paid. This German guy asked:
``If you make 0 a class, then you only defer the necessary runtime
checks." Mr. Hoare gave no answer on this.

---Ph.

Tony Hoare is exceptional . You should listen to him more often. Try not
to disagree so hastily.

Philip Köster wrote:
>
>
> Tony Morris schrieb:
>> Stepan Koltsov wrote:
>>> You probably missed parts of the discussion where explained how Option
>>> changes NullPointerException to NoSuchElementException.
>>>
>> Except it doesn't.
>>
>
> I'm just--thanks to Paolo Losi!--listening to Tony Hoare, some CS guy
> I hadn't known before. He's a real British gentleman, one of a kind I
> presumed extinct already. It is really a pleasure to listen to him.
> But I don't think I agree with his basic point: Null pointers are bad.
> A German guy posed the right question, and maybe because he asked it
> in broken English, not a lot attention was paid. This German guy
> asked: ``If you make 0 a class, then you only defer the necessary
> runtime checks." Mr. Hoare gave no answer on this.
>
> ---Ph.
>

> Tony Hoare is exceptional . You should listen to him more often. Try not
> to disagree so hastily.

I do not claim to be right, but I know that we should use the tools
Mother Nature gave us, and 0 is at the very heart of our nature. We
don't need a class modeling 0, because the 0 is there, waiting, ready to
be used. It needs no model, just as 1, 2, 3 ... don't need a model.
Programming languages should enable me to declare a method so that I can
say whether or not I'm ready to receive a 0 value or not. There's
nothing special about the 0, except that it is ``to be or not to be."

Look up "Church Numeral Encoding."

Philip Köster wrote:
>> Tony Hoare is exceptional . You should listen to him more often. Try not
>> to disagree so hastily.
>
> I do not claim to be right, but I know that we should use the tools
> Mother Nature gave us, and 0 is at the very heart of our nature. We
> don't need a class modeling 0, because the 0 is there, waiting, ready
> to be used. It needs no model, just as 1, 2, 3 ... don't need a model.
> Programming languages should enable me to declare a method so that I
> can say whether or not I'm ready to receive a 0 value or not. There's
> nothing special about the 0, except that it is ``to be or not to be."
>

This is the sort of mails that I, frankly, don't like: "Look up this."
Mails like these free you from saying anything, from expressing your own
opinion. I could, Tony, say in the same way ``Go read Hemingway and
Foster and get a life," or say "Go read Niklaus Wirth and get real."
This would not help anyone. What is Church Numeral Encoding? That rings
a bell, I heard about it, but I'm not interested in that unless you tell
me what you find interesting about that, in your own words. Why would I
need Church Numeral Encoding, and how does it make my life easier?

Tony Morris schrieb:
> Look up "Church Numeral Encoding."
>
> Philip Köster wrote:
>>> Tony Hoare is exceptional . You should listen to him more often. Try not
>>> to disagree so hastily.
>> I do not claim to be right, but I know that we should use the tools
>> Mother Nature gave us, and 0 is at the very heart of our nature. We
>> don't need a class modeling 0, because the 0 is there, waiting, ready
>> to be used. It needs no model, just as 1, 2, 3 ... don't need a model.
>> Programming languages should enable me to declare a method so that I
>> can say whether or not I'm ready to receive a 0 value or not. There's
>> nothing special about the 0, except that it is ``to be or not to be."
>>
>

Don't look up "Church Numeral Encoding."

Philip Köster wrote:
> This is the sort of mails that I, frankly, don't like: "Look up this."
> Mails like these free you from saying anything, from expressing your
> own opinion. I could, Tony, say in the same way ``Go read Hemingway
> and Foster and get a life," or say "Go read Niklaus Wirth and get
> real." This would not help anyone. What is Church Numeral Encoding?
> That rings a bell, I heard about it, but I'm not interested in that
> unless you tell me what you find interesting about that, in your own
> words. Why would I need Church Numeral Encoding, and how does it make
> my life easier?
>
> Tony Morris schrieb:
>> Look up "Church Numeral Encoding."
>>
>> Philip Köster wrote:
>>>> Tony Hoare is exceptional . You should listen to him more often.
>>>> Try not
>>>> to disagree so hastily.
>>> I do not claim to be right, but I know that we should use the tools
>>> Mother Nature gave us, and 0 is at the very heart of our nature. We
>>> don't need a class modeling 0, because the 0 is there, waiting, ready
>>> to be used. It needs no model, just as 1, 2, 3 ... don't need a model.
>>> Programming languages should enable me to declare a method so that I
>>> can say whether or not I'm ready to receive a 0 value or not. There's
>>> nothing special about the 0, except that it is ``to be or not to be."
>>>
>>
>

Option replacing null distinguishes possibly-null values from
never-null values. Calling .get is deliberate; you know it can fail.
Calling foo.bar(baz), where foo may be null in some circumstances,
encodes failure implicitly.

Unless your goal is to fail, you probably want code that may fail to
look different to code that may not.

Also, Option.get is only a convenience method; try to use its other
methods more; the ones that don't fail.

I suggest you read Dave's email more closely, rather than reacting to it.

2009/11/21 Stepan Koltsov :
> On Sat, Nov 21, 2009 at 04:16, Dave  Griffith wrote:
>> Stepan Koltsov-2 wrote:
>>>
>>> Blaming null is a common misconception. Bad programmers always make
>>> bugs, not depending of whether null exists.
>>>
>>
>> All programmers, good and bad, create bugs.  Weirdly enough, whether you are
>> a good programmer
>> or bad doesn't even have much effect on your rate of bug creation.  The
>> (somewhat disturbing) rule of
>> thumb is that whenever you write 10 lines of code you have, on average,
>> coded a bug.   This is
>> independent of both programmer skill and language used.  (It's also
>> independent of just how hard
>> you try to code in a bug-free manner.   Discipline doesn't get you very far,
>> can't be trusted, can't
>> be maintained, and absolutely, positively does not scale.)
>>
>> This matters.  Because of this reality, just about the only way to decrease
>> bugs created per feature is to decrease the number of lines of code
>> necessary to implement an average feature.  Both Scala and the various
>> dynamic languages that have become popular of late are examples of languages
>> that attempt to allow greater density of features per line.  They've been
>> quite successful at it, with usual density increases reported at about 3-10x
>> over Java/C#, clustering around 5x. That said, it's uncertain how much
>> denser functionality can get.
>>
>> But if we can't decrease bug densities anymore, we can decrease bug costs.
>> The best way of doing that is to realize that not all bugs are created
>> equal.  Some classes of bugs are easier and cheaper to find, and can be
>> found sooner than others.   Bugs that manifest as static type errors
>> (ignoring casts) in typeful languages show up at compile time (or preferably
>> at edit time, as IDEs get more powerful).  This makes them particularly
>> cheap to fix.   Off-by-one errors and language-barrier errors (e.g.
>> misspelling fields for reflective access) tend to show up the first time a
>> program is run, making them annoying but
>> manageable.   Null pointer errors and type cast errors are probably the
>> worst.  They can lie dormant
>> in code until it gets to production and then manifest intermittently.  At
>> that point things can get very
>> expensive indeed.   Option moves null pointers from being production-time
>> nightmares to compile-time annoyances.  That's nothing but upside.  I'll
>> trade CPU cycles for that all day long.
>>
>> Back when I was starting out in this industry, the worst sorts of bugs were
>> wild pointers and buffer overruns, which make null pointer exceptions look
>> positively tame in comparison.  We as an industry annihilated wild pointer
>> bugs and buffer overruns for large classes of programming through a
>> combination of faster hardware and better language design.   We can do the
>> same for null pointer bugs.   Option (or something essentially the same as
>> Option) is pretty much the way to go for that.  It's not perfect, but it's
>> pretty damn good, and the alternatives are all immeasurably worse.
>
> You probably missed parts of the discussion where explained how Option
> changes NullPointerException to NoSuchElementException.
>
>
> S.
>

More specifically, there exist functions that are undefined for some
elements of the codomain. If you have an issue with this, take it up
with a guy called Alan Turing. This is not an excuse to circumvent the
type system. Option doesn't "replace null" any more than medical science
replaces homeopathy. It's bunk to begin with.

Ricky Clarkson wrote:
> Option replacing null distinguishes possibly-null values from
> never-null values. Calling .get is deliberate; you know it can fail.
> Calling foo.bar(baz), where foo may be null in some circumstances,
> encodes failure implicitly.
>
> Unless your goal is to fail, you probably want code that may fail to
> look different to code that may not.
>
> Also, Option.get is only a convenience method; try to use its other
> methods more; the ones that don't fail.
>
> I suggest you read Dave's email more closely, rather than reacting to it.
>
> 2009/11/21 Stepan Koltsov :
>
>> On Sat, Nov 21, 2009 at 04:16, Dave Griffith wrote:
>>
>>> Stepan Koltsov-2 wrote:
>>>
>>>> Blaming null is a common misconception. Bad programmers always make
>>>> bugs, not depending of whether null exists.
>>>>
>>>>
>>> All programmers, good and bad, create bugs. Weirdly enough, whether you are
>>> a good programmer
>>> or bad doesn't even have much effect on your rate of bug creation. The
>>> (somewhat disturbing) rule of
>>> thumb is that whenever you write 10 lines of code you have, on average,
>>> coded a bug. This is
>>> independent of both programmer skill and language used. (It's also
>>> independent of just how hard
>>> you try to code in a bug-free manner. Discipline doesn't get you very far,
>>> can't be trusted, can't
>>> be maintained, and absolutely, positively does not scale.)
>>>
>>> This matters. Because of this reality, just about the only way to decrease
>>> bugs created per feature is to decrease the number of lines of code
>>> necessary to implement an average feature. Both Scala and the various
>>> dynamic languages that have become popular of late are examples of languages
>>> that attempt to allow greater density of features per line. They've been
>>> quite successful at it, with usual density increases reported at about 3-10x
>>> over Java/C#, clustering around 5x. That said, it's uncertain how much
>>> denser functionality can get.
>>>
>>> But if we can't decrease bug densities anymore, we can decrease bug costs.
>>> The best way of doing that is to realize that not all bugs are created
>>> equal. Some classes of bugs are easier and cheaper to find, and can be
>>> found sooner than others. Bugs that manifest as static type errors
>>> (ignoring casts) in typeful languages show up at compile time (or preferably
>>> at edit time, as IDEs get more powerful). This makes them particularly
>>> cheap to fix. Off-by-one errors and language-barrier errors (e.g.
>>> misspelling fields for reflective access) tend to show up the first time a
>>> program is run, making them annoying but
>>> manageable. Null pointer errors and type cast errors are probably the
>>> worst. They can lie dormant
>>> in code until it gets to production and then manifest intermittently. At
>>> that point things can get very
>>> expensive indeed. Option moves null pointers from being production-time
>>> nightmares to compile-time annoyances. That's nothing but upside. I'll
>>> trade CPU cycles for that all day long.
>>>
>>> Back when I was starting out in this industry, the worst sorts of bugs were
>>> wild pointers and buffer overruns, which make null pointer exceptions look
>>> positively tame in comparison. We as an industry annihilated wild pointer
>>> bugs and buffer overruns for large classes of programming through a
>>> combination of faster hardware and better language design. We can do the
>>> same for null pointer bugs. Option (or something essentially the same as
>>> Option) is pretty much the way to go for that. It's not perfect, but it's
>>> pretty damn good, and the alternatives are all immeasurably worse.
>>>
>> You probably missed parts of the discussion where explained how Option
>> changes NullPointerException to NoSuchElementException.
>>
>>
>> S.
>>
>>
>
>
>
>

This is the sort of email I dislike, the one where someone takes a
suggestion to learn something and reacts with a closed mind.

It's turning these lists to shit.

2009/11/21 Philip Köster :
> This is the sort of mails that I, frankly, don't like: "Look up this." Mails
> like these free you from saying anything, from expressing your own opinion.
> I could, Tony, say in the same way ``Go read Hemingway and Foster and get a
> life," or say "Go read Niklaus Wirth and get real." This would not help
> anyone. What is Church Numeral Encoding? That rings a bell, I heard about
> it, but I'm not interested in that unless you tell me what you find
> interesting about that, in your own words. Why would I need Church Numeral
> Encoding, and how does it make my life easier?
>
> Tony Morris schrieb:
>>
>> Look up "Church Numeral Encoding."
>>
>> Philip Köster wrote:
>>>>
>>>> Tony Hoare is exceptional . You should listen to him more often. Try not
>>>> to disagree so hastily.
>>>
>>> I do not claim to be right, but I know that we should use the tools
>>> Mother Nature gave us, and 0 is at the very heart of our nature. We
>>> don't need a class modeling 0, because the 0 is there, waiting, ready
>>> to be used. It needs no model, just as 1, 2, 3 ... don't need a model.
>>> Programming languages should enable me to declare a method so that I
>>> can say whether or not I'm ready to receive a 0 value or not. There's
>>> nothing special about the 0, except that it is ``to be or not to be."
>>>
>>
>

> This is the sort of email I dislike, the one where someone takes a
> suggestion to learn something and reacts with a closed mind.
>
> It's turning these lists to shit.

This wasn't my intention. I worship your posts, as well as Tony's, but
it appears that I sometimes have a hard time to carry out a conflict
without getting insulting. This is the way my mouth grew (in German we
say ``So ist mir der Schnabel gewachsen"), and I really didn't mean to
insult anyone. We all share the love of computer programming, so we
shouldn't hack on each other.

Please take my apologies
---Phil

PS: The inition of this discussion was whether 0 should be made a class.
There are contradictory opionions here, and this should not end in a
fight. I'm awfully sorry should I have been a flamer.

Accepted. This list has had its recent good dose of... non-thinking.

Instead, let's have some fun. Announcing the new scala.Option without
any case classes or objects!

trait Optionn[+A] {
// Church Encoding (abstract method)
def cata[X](ding: A => X, dong: => X): X

// Look ma, no case classes!
def map[B](f: A => B) = new Optionn[B] {
def cata[X](ding: B => X, dong: => X) = Optionn.this.cata(ding
compose f, dong)
}

def flatMap[B](f: A => Optionn[B]) = new Optionn[B] {
def cata[X](ding: B => X, dong: => X) =
Optionn.this.cata(f(_).cata(ding, dong), dong)
}
}

Philip Köster wrote:
>> This is the sort of email I dislike, the one where someone takes a
>> suggestion to learn something and reacts with a closed mind.
>>
>> It's turning these lists to shit.
>
> This wasn't my intention. I worship your posts, as well as Tony's, but
> it appears that I sometimes have a hard time to carry out a conflict
> without getting insulting. This is the way my mouth grew (in German we
> say ``So ist mir der Schnabel gewachsen"), and I really didn't mean to
> insult anyone. We all share the love of computer programming, so we
> shouldn't hack on each other.
>
> Please take my apologies
> ---Phil
>
> PS: The inition of this discussion was whether 0 should be made a
> class. There are contradictory opionions here, and this should not end
> in a fight. I'm awfully sorry should I have been a flamer.
>

I should have also pointed out that the 'cata' method below has the same
signature as Option's map + getOrElse.

Tony Morris wrote:
> Accepted. This list has had its recent good dose of... non-thinking.
>
> Instead, let's have some fun. Announcing the new scala.Option without
> any case classes or objects!
>
>
> trait Optionn[+A] {
> // Church Encoding (abstract method)
> def cata[X](ding: A => X, dong: => X): X
>
> // Look ma, no case classes!
> def map[B](f: A => B) = new Optionn[B] {
> def cata[X](ding: B => X, dong: => X) = Optionn.this.cata(ding
> compose f, dong)
> }
>
> def flatMap[B](f: A => Optionn[B]) = new Optionn[B] {
> def cata[X](ding: B => X, dong: => X) =
> Optionn.this.cata(f(_).cata(ding, dong), dong)
> }
> }
>
>
> Philip Köster wrote:
>
>>> This is the sort of email I dislike, the one where someone takes a
>>> suggestion to learn something and reacts with a closed mind.
>>>
>>> It's turning these lists to shit.
>>>
>> This wasn't my intention. I worship your posts, as well as Tony's, but
>> it appears that I sometimes have a hard time to carry out a conflict
>> without getting insulting. This is the way my mouth grew (in German we
>> say ``So ist mir der Schnabel gewachsen"), and I really didn't mean to
>> insult anyone. We all share the love of computer programming, so we
>> shouldn't hack on each other.
>>
>> Please take my apologies
>> ---Phil
>>
>> PS: The inition of this discussion was whether 0 should be made a
>> class. There are contradictory opionions here, and this should not end
>> in a fight. I'm awfully sorry should I have been a flamer.
>>
>>
>
>

I have no clue what this is about. No fun for me. :)

May I remind the dear audience of J. R. R. Tolkien? The Ents said,
```mountain' is too short a word for something that's been there all the
time." Likewise, ``Boolean" is too long a word representing a flag. I
find it a pity that the designers of Scala did not make that a `bool',
or `Bool', meinetwegen.

Tony Morris schrieb:
> I should have also pointed out that the 'cata' method below has the same
> signature as Option's map + getOrElse.
>
> Tony Morris wrote:
>> Accepted. This list has had its recent good dose of... non-thinking.
>>
>> Instead, let's have some fun. Announcing the new scala.Option without
>> any case classes or objects!
>>
>>
>> trait Optionn[+A] {
>> // Church Encoding (abstract method)
>> def cata[X](ding: A => X, dong: => X): X
>>
>> // Look ma, no case classes!
>> def map[B](f: A => B) = new Optionn[B] {
>> def cata[X](ding: B => X, dong: => X) = Optionn.this.cata(ding
>> compose f, dong)
>> }
>>
>> def flatMap[B](f: A => Optionn[B]) = new Optionn[B] {
>> def cata[X](ding: B => X, dong: => X) =
>> Optionn.this.cata(f(_).cata(ding, dong), dong)
>> }
>> }
>>
>>
>> Philip Köster wrote:
>>
>>>> This is the sort of email I dislike, the one where someone takes a
>>>> suggestion to learn something and reacts with a closed mind.
>>>>
>>>> It's turning these lists to shit.
>>>>
>>> This wasn't my intention. I worship your posts, as well as Tony's, but
>>> it appears that I sometimes have a hard time to carry out a conflict
>>> without getting insulting. This is the way my mouth grew (in German we
>>> say ``So ist mir der Schnabel gewachsen"), and I really didn't mean to
>>> insult anyone. We all share the love of computer programming, so we
>>> shouldn't hack on each other.
>>>
>>> Please take my apologies
>>> ---Phil
>>>
>>> PS: The inition of this discussion was whether 0 should be made a
>>> class. There are contradictory opionions here, and this should not end
>>> in a fight. I'm awfully sorry should I have been a flamer.
>>>
>>>
>>
>

Philip Köster wrote:
> I have no clue what this is about. No fun for me. :)
It's not that hard. It's Scala. Read it. Compile it. Observe certain
properties about it, such as providing exactly the same interface as
scala.Option, but without the case object/class and a single abstract
method. How does it work? Why does it work? Does this have a name? Is it
exactly the same interface i.e. I see map and flatMap but what about
others? Can I write my own Option methods on it?

Think, try it, it's fun.

>
> May I remind the dear audience of J. R. R. Tolkien? The Ents said,
> ```mountain' is too short a word for something that's been there all
> the time." Likewise, ``Boolean" is too long a word representing a
> flag. I find it a pity that the designers of Scala did not make that a
> `bool', or `Bool', meinetwegen.
>
>
>
> Tony Morris schrieb:
>> I should have also pointed out that the 'cata' method below has the same
>> signature as Option's map + getOrElse.
>>
>> Tony Morris wrote:
>>> Accepted. This list has had its recent good dose of... non-thinking.
>>>
>>> Instead, let's have some fun. Announcing the new scala.Option without
>>> any case classes or objects!
>>>
>>>
>>> trait Optionn[+A] {
>>> // Church Encoding (abstract method)
>>> def cata[X](ding: A => X, dong: => X): X
>>>
>>> // Look ma, no case classes!
>>> def map[B](f: A => B) = new Optionn[B] {
>>> def cata[X](ding: B => X, dong: => X) = Optionn.this.cata(ding
>>> compose f, dong)
>>> }
>>>
>>> def flatMap[B](f: A => Optionn[B]) = new Optionn[B] {
>>> def cata[X](ding: B => X, dong: => X) =
>>> Optionn.this.cata(f(_).cata(ding, dong), dong)
>>> }
>>> }
>>>
>>>
>>> Philip Köster wrote:
>>>
>>>>> This is the sort of email I dislike, the one where someone takes a
>>>>> suggestion to learn something and reacts with a closed mind.
>>>>>
>>>>> It's turning these lists to shit.
>>>>>
>>>> This wasn't my intention. I worship your posts, as well as Tony's, but
>>>> it appears that I sometimes have a hard time to carry out a conflict
>>>> without getting insulting. This is the way my mouth grew (in German we
>>>> say ``So ist mir der Schnabel gewachsen"), and I really didn't mean to
>>>> insult anyone. We all share the love of computer programming, so we
>>>> shouldn't hack on each other.
>>>>
>>>> Please take my apologies
>>>> ---Phil
>>>>
>>>> PS: The inition of this discussion was whether 0 should be made a
>>>> class. There are contradictory opionions here, and this should not end
>>>> in a fight. I'm awfully sorry should I have been a flamer.
>>>>
>>>>
>>>
>>
>

Tony Morris wrote:
> 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."
>

That's not true.

Me and Corky (Prof. Robert Cartwright, my PhD advisor) discussed this
once while discussing Domain Theory (the "Math of Computing", upon which
my PhD thesis is based). We reached the conclusion that non-termination
is just, well, non-termination. It can NOT be eliminated from
computation. Null, on the other hand *exists*, as a genuine real but
unusual/ exceptional/ unexpected value. It should, formally speaking,
be added to each type that needs one such value (some don't), or forced
on them by belonging to a (non-expressible-in-Java) 'NullType' that is a
subtype (based on a subclass) of all types (classes). 'null' - just like
all regular values - can be got ridden of (is not absolutely essential).
_|_ (bottom)/non-termination is absolutely essential to the nature of
computation, and cannot be got ridden of.

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

'Arabs', you mean.

One day we used to teach the world. We hope one day soon we would
again! :)

-Moez

Moez A. Abdel-Gawad wrote:
> Me and Corky (Prof. Robert Cartwright, my PhD advisor) discussed this
> once while discussing Domain Theory (the "Math of Computing", upon which
> my PhD thesis is based). We reached the conclusion that non-termination
> is just, well, non-termination. It can NOT be eliminated from
> computation.

Can you please explain how _|_ can be returned from this function:

def fn(i : Int) = i * 2

Or is that not a "computation"?

/Jesper Nordenberg

Moez A. Abdel-Gawad wrote:
> Tony Morris wrote:
> > 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."
> >
>
> That's not true.
>
> Me and Corky (Prof. Robert Cartwright, my PhD advisor) discussed this
> once while discussing Domain Theory (the "Math of Computing", upon
> which my PhD thesis is based). We reached the conclusion that
> non-termination is just, well, non-termination. It can NOT be
> eliminated from computation. Null, on the other hand *exists*, as a
> genuine real but unusual/ exceptional/ unexpected value. It should,
> formally speaking, be added to each type that needs one such value
> (some don't), or forced on them by belonging to a
> (non-expressible-in-Java) 'NullType' that is a subtype (based on a
> subclass) of all types (classes). 'null' - just like all regular
> values - can be got ridden of (is not absolutely essential). _|_
> (bottom)/non-termination is absolutely essential to the nature of
> computation, and cannot be got ridden of.
It's true. You may not realise it but you contradicted yourself.
Non-termination must exist in Scala, therefore, it must be represented.
You said this yourself.

Pattern matching will never be exhaustive, the error function is of type
forall A. A (which is a LIE!), and (wait for it) null exists. Null
represents that which does not exist and that is the extent of its
existence. In a language with different syntax, you might consider
calling it _|_. The null value is a value has the type forall A. A. This
is not a theorem. It represents bottom, non-termination, undefinedness,
logical absurdity. That is what null is. I recommend you try again with
Corky. You buggered up.

>
> >
> >
> > Philip Köster wrote:
> >> Discovering the `0' was what separated the Arabians from the Romans.
> >>
> >
>
> 'Arabs', you mean.
>
> One day we used to teach the world. We hope one day soon we would
> again! :)
>
> -Moez
>

I strongly recommend Types and Programming Languages by Benjamin Pierce.

Tony Morris wrote:
> Moez A. Abdel-Gawad wrote:
>
>> Tony Morris wrote:
>>
>>> 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."
>>>
>>>
>> That's not true.
>>
>> Me and Corky (Prof. Robert Cartwright, my PhD advisor) discussed this
>> once while discussing Domain Theory (the "Math of Computing", upon
>> which my PhD thesis is based). We reached the conclusion that
>> non-termination is just, well, non-termination. It can NOT be
>> eliminated from computation. Null, on the other hand *exists*, as a
>> genuine real but unusual/ exceptional/ unexpected value. It should,
>> formally speaking, be added to each type that needs one such value
>> (some don't), or forced on them by belonging to a
>> (non-expressible-in-Java) 'NullType' that is a subtype (based on a
>> subclass) of all types (classes). 'null' - just like all regular
>> values - can be got ridden of (is not absolutely essential). _|_
>> (bottom)/non-termination is absolutely essential to the nature of
>> computation, and cannot be got ridden of.
>>
> It's true. You may not realise it but you contradicted yourself.
> Non-termination must exist in Scala, therefore, it must be represented.
> You said this yourself.
>
> Pattern matching will never be exhaustive, the error function is of type
> forall A. A (which is a LIE!), and (wait for it) null exists. Null
> represents that which does not exist and that is the extent of its
> existence. In a language with different syntax, you might consider
> calling it _|_. The null value is a value has the type forall A. A. This
> is not a theorem. It represents bottom, non-termination, undefinedness,
> logical absurdity. That is what null is. I recommend you try again with
> Corky. You buggered up.
>
>
>>> Philip Köster wrote:
>>>
>>>> Discovering the `0' was what separated the Arabians from the Romans.
>>>>
>>>>
>> 'Arabs', you mean.
>>
>> One day we used to teach the world. We hope one day soon we would
>> again! :)
>>
>> -Moez
>>
>>
>
>

I'm a pragmatic person, not a philosopher. And I oberve, as I already
wrote, that 50 % of Java code consists of if clauses testing against
null. And all of this stems from Java's inability to define a method
param as ``nonnull." What makes matters worse, is that Java has no
understanding of ``const". ``final" is nothing but a bad joke. So
millions and gazillions of books are written about how to make a class
final, ``immutable," where it was the language that should help in the
first place.

Moez A. Abdel-Gawad schrieb:
> Tony Morris wrote:
> > 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."
> >
>
> That's not true.
>
> Me and Corky (Prof. Robert Cartwright, my PhD advisor) discussed this
> once while discussing Domain Theory (the "Math of Computing", upon which
> my PhD thesis is based). We reached the conclusion that non-termination
> is just, well, non-termination. It can NOT be eliminated from
> computation. Null, on the other hand *exists*, as a genuine real but
> unusual/ exceptional/ unexpected value. It should, formally speaking,
> be added to each type that needs one such value (some don't), or forced
> on them by belonging to a (non-expressible-in-Java) 'NullType' that is a
> subtype (based on a subclass) of all types (classes). 'null' - just like
> all regular values - can be got ridden of (is not absolutely essential).
> _|_ (bottom)/non-termination is absolutely essential to the nature of
> computation, and cannot be got ridden of.
>
> >
> >
> > Philip Köster wrote:
> >> Discovering the `0' was what separated the Arabians from the Romans.
> >>
> >
>
> 'Arabs', you mean.
>
> One day we used to teach the world. We hope one day soon we would
> again! :)
>
> -Moez
>

Slightly off topic, but the Arabs got the concept of zero from the Indians - the Arabs then introduced it to the western world.

Ishaaq

2009/11/21 Moez A. Abdel-Gawad <moez@cs.rice.edu>

Tony Morris wrote:
> 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."
>

That's not true.

Me and Corky (Prof. Robert Cartwright, my PhD advisor) discussed this once while discussing Domain Theory (the "Math of Computing", upon which my PhD thesis is based).  We reached the conclusion that non-termination is just, well, non-termination. It can NOT be eliminated from computation.  Null, on the other hand *exists*, as a genuine real but unusual/ exceptional/ unexpected value.  It should, formally speaking, be added to each type that needs one such value (some don't), or forced on them by belonging to a (non-expressible-in-Java) 'NullType' that is a subtype (based on a subclass) of all types (classes). 'null' - just like all regular values - can be got ridden of (is not absolutely essential).  _|_ (bottom)/non-termination is absolutely essential to the nature of computation, and cannot be got ridden of.

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

'Arabs', you mean.

One day we used to teach the world.  We hope one day soon we would again!  :)

-Moez

> 'Arabs', you mean

Sorry, I never used that word before, but yes, ``Arabians" was probably
wrong.

>> Me and Corky (Prof. Robert Cartwright, my PhD advisor) discussed this
>> once while discussing Domain Theory (the "Math of Computing", upon
>> which my PhD thesis is based). We reached the conclusion that
>> non-termination is just, well, non-termination. It can NOT be
>> eliminated from computation. Null, on the other hand *exists*, as a
>> genuine real but unusual/ exceptional/ unexpected value. It should,
>> formally speaking, be added to each type that needs one such value
>> (some don't), or forced on them by belonging to a
>> (non-expressible-in-Java) 'NullType' that is a subtype (based on a
>> subclass) of all types (classes). 'null' - just like all regular
>> values - can be got ridden of (is not absolutely essential). _|_
>> (bottom)/non-termination is absolutely essential to the nature of
>> computation, and cannot be got ridden of.

That is what you and your Prof agreed upon? I admit that I once started
a CS study when studying CS in Germany was hardly recognized and hardly
known about, but I still don't get it. If you want to test against 0,
what is more natural than to say just `if v == 0'? Java is a bit
schizophrenic about this: Java literature seems to agree that ``pointer"
is a no-go word, something forbidden, stemming from the ancient C++
times, no, no, it would have to be ``reference." And then, someday you
receive a `NullPointerException' and ask yourself: Wouldn't that have to
be a `NullReferenceException'?

The Java Language Specification defines a reference and a pointer as
being the same thing as each other, so NullPointerException is
certainly correct.

2009/11/21 Philip Köster :
>>> Me and Corky (Prof. Robert Cartwright, my PhD advisor) discussed this
>>> once while discussing Domain Theory (the "Math of Computing", upon which my
>>> PhD thesis is based). We reached the conclusion that non-termination is
>>> just, well, non-termination. It can NOT be eliminated from computation.
>>> Null, on the other hand *exists*, as a genuine real but unusual/
>>> exceptional/ unexpected value. It should, formally speaking, be added to
>>> each type that needs one such value (some don't), or forced on them by
>>> belonging to a (non-expressible-in-Java) 'NullType' that is a subtype (based
>>> on a subclass) of all types (classes). 'null' - just like all regular values
>>> - can be got ridden of (is not absolutely essential). _|_
>>> (bottom)/non-termination is absolutely essential to the nature of
>>> computation, and cannot be got ridden of.
>
> That is what you and your Prof agreed upon? I admit that I once started a CS
> study when studying CS in Germany was hardly recognized and hardly known
> about, but I still don't get it. If you want to test against 0, what is more
> natural than to say just `if v == 0'? Java is a bit schizophrenic about
> this: Java literature seems to agree that ``pointer" is a no-go word,
> something forbidden, stemming from the ancient C++ times, no, no, it would
> have to be ``reference." And then, someday you receive a
> `NullPointerException' and ask yourself: Wouldn't that have to be a
> `NullReferenceException'?
>

Const in the manner you speak, is where you can have a mutable object
but pass it around in an immutable form, as far as I can tell. I'd
rather have immutable objects than that.

2009/11/21 Philip Köster :
> I'm a pragmatic person, not a philosopher. And I oberve, as I already wrote,
> that 50 % of Java code consists of if clauses testing against null. And all
> of this stems from Java's inability to define a method param as ``nonnull."
> What makes matters worse, is that Java has no understanding of ``const".
> ``final" is nothing but a bad joke. So millions and gazillions of books are
> written about how to make a class final, ``immutable," where it was the
> language that should help in the first place.
>
>
> Moez A. Abdel-Gawad schrieb:
>>
>> Tony Morris wrote:
>> > 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."
>> >
>>
>> That's not true.
>>
>> Me and Corky (Prof. Robert Cartwright, my PhD advisor) discussed this once
>> while discussing Domain Theory (the "Math of Computing", upon which my PhD
>> thesis is based). We reached the conclusion that non-termination is just,
>> well, non-termination. It can NOT be eliminated from computation. Null, on
>> the other hand *exists*, as a genuine real but unusual/ exceptional/
>> unexpected value. It should, formally speaking, be added to each type that
>> needs one such value (some don't), or forced on them by belonging to a
>> (non-expressible-in-Java) 'NullType' that is a subtype (based on a subclass)
>> of all types (classes). 'null' - just like all regular values - can be got
>> ridden of (is not absolutely essential). _|_ (bottom)/non-termination is
>> absolutely essential to the nature of computation, and cannot be got ridden
>> of.
>>
>> >
>> >
>> > Philip Köster wrote:
>> >> Discovering the `0' was what separated the Arabians from the Romans.
>> >>
>> >
>>
>> 'Arabs', you mean.
>>
>> One day we used to teach the world. We hope one day soon we would again!
>> :)
>>
>> -Moez
>>
>

Coming back to Mr Köster's original dilemma, I tend to explain it to
my coworkers in our Java shop as "pretty much like null, except that
the compiler forces you to handle it".

Am I off the crease on this? It seems relatively straight-forward to
me, and I'm a very junior dev, but Option combined with Scala's match
construct, and the cleaner and more robust code you get as a result is
what made me overlook the syntax in the early Scala code examples I
saw that looked like a game of Hangman.

On 11/21/09, Tony Morris wrote:
> Philip Köster wrote:
>> I have no clue what this is about. No fun for me. :)
> It's not that hard. It's Scala. Read it. Compile it. Observe certain
> properties about it, such as providing exactly the same interface as
> scala.Option, but without the case object/class and a single abstract
> method. How does it work? Why does it work? Does this have a name? Is it
> exactly the same interface i.e. I see map and flatMap but what about
> others? Can I write my own Option methods on it?
>
> Think, try it, it's fun.
>
>>
>> May I remind the dear audience of J. R. R. Tolkien? The Ents said,
>> ```mountain' is too short a word for something that's been there all
>> the time." Likewise, ``Boolean" is too long a word representing a
>> flag. I find it a pity that the designers of Scala did not make that a
>> `bool', or `Bool', meinetwegen.
>>
>>
>>
>> Tony Morris schrieb:
>>> I should have also pointed out that the 'cata' method below has the same
>>> signature as Option's map + getOrElse.
>>>
>>> Tony Morris wrote:
>>>> Accepted. This list has had its recent good dose of... non-thinking.
>>>>
>>>> Instead, let's have some fun. Announcing the new scala.Option without
>>>> any case classes or objects!
>>>>
>>>>
>>>> trait Optionn[+A] {
>>>> // Church Encoding (abstract method)
>>>> def cata[X](ding: A => X, dong: => X): X
>>>>
>>>> // Look ma, no case classes!
>>>> def map[B](f: A => B) = new Optionn[B] {
>>>> def cata[X](ding: B => X, dong: => X) = Optionn.this.cata(ding
>>>> compose f, dong)
>>>> }
>>>>
>>>> def flatMap[B](f: A => Optionn[B]) = new Optionn[B] {
>>>> def cata[X](ding: B => X, dong: => X) =
>>>> Optionn.this.cata(f(_).cata(ding, dong), dong)
>>>> }
>>>> }
>>>>
>>>>
>>>> Philip Köster wrote:
>>>>
>>>>>> This is the sort of email I dislike, the one where someone takes a
>>>>>> suggestion to learn something and reacts with a closed mind.
>>>>>>
>>>>>> It's turning these lists to shit.
>>>>>>
>>>>> This wasn't my intention. I worship your posts, as well as Tony's, but
>>>>> it appears that I sometimes have a hard time to carry out a conflict
>>>>> without getting insulting. This is the way my mouth grew (in German we
>>>>> say ``So ist mir der Schnabel gewachsen"), and I really didn't mean to
>>>>> insult anyone. We all share the love of computer programming, so we
>>>>> shouldn't hack on each other.
>>>>>
>>>>> Please take my apologies
>>>>> ---Phil
>>>>>
>>>>> PS: The inition of this discussion was whether 0 should be made a
>>>>> class. There are contradictory opionions here, and this should not end
>>>>> in a fight. I'm awfully sorry should I have been a flamer.
>>>>>
>>>>>
>>>>
>>>
>>
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>

Thankfully we have Google and Wikipedia so that basic references are free and only a few keystrokes away.
http://en.wikipedia.org/wiki/Church_encoding

On Sat, Nov 21, 2009 at 1:25 AM, Philip Köster <philip.koester@web.de> wrote:

This is the sort of mails that I, frankly, don't like: "Look up this." Mails like these free you from saying anything, from expressing your own opinion. I could, Tony, say in the same way ``Go read Hemingway and Foster and get a life," or say "Go read Niklaus Wirth and get real." This would not help anyone. What is Church Numeral Encoding? That rings a bell, I heard about it, but I'm not interested in that unless you tell me what you find interesting about that, in your own words. Why would I need Church Numeral Encoding, and how does it make my life easier?

Tony Morris schrieb:

Look up "Church Numeral Encoding."

Philip Köster wrote:

Tony Hoare is exceptional . You should listen to him more often. Try not
to disagree so hastily.

I do not claim to be right, but I know that we should use the tools
Mother Nature gave us, and 0 is at the very heart of our nature. We
don't need a class modeling 0, because the 0 is there, waiting, ready
to be used. It needs no model, just as 1, 2, 3 ... don't need a model.
Programming languages should enable me to declare a method so that I
can say whether or not I'm ready to receive a 0 value or not. There's
nothing special about the 0, except that it is ``to be or not to be."

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

> Thankfully we have Google and Wikipedia so that basic references are
> free and only a few keystrokes away.

Ihr nervt mich gerade mit Euerm Church-Encoding, aber das ist schon okay ...

http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/Option.scala
Look at the bottom of the file.

On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris <tonymorris@gmail.com> wrote:

Stepan Koltsov wrote:
> You probably missed parts of the discussion where explained how Option
> changes NullPointerException to NoSuchElementException.
>
Except it doesn't.

--
Tony Morris
http://tmorris.net/

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

What am I looking for exactly? I see no evidence for "Option changes
NullPointerException to NoSuchElementException." Is it there?

Erik Engbrecht wrote:
> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/...
>
>
> Look at the bottom of the file.
>
> On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris > wrote:
>
> Stepan Koltsov wrote:
> > You probably missed parts of the discussion where explained how
> Option
> > changes NullPointerException to NoSuchElementException.
> >
> Except it doesn't.
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
>
>

> Const in the manner you speak, is where you can have a mutable object
> but pass it around in an immutable form, as far as I can tell. I'd
> rather have immutable objects than that.

I think I would not. So much fuzz has been created about immutable
objects. In Java, being mutable or not, is a matter of classes and
implementations. Martin Odersky even invented different packages for
those. I think it is up to a library designer, to the callee site, if it
wants to see an object as immutable or not:

def foo(map: +Map) { /* `+' meaning: cannot be `null' }

is, in my opinion, better than

def foo(map: Map) {
if map != null {
doSomething()
}
}

On 21/11/2009 12:55, Philip Köster wrote:
>> Thankfully we have Google and Wikipedia so that basic references are
>> free and only a few keystrokes away.
>
> Ihr nervt mich gerade mit Euerm Church-Encoding, aber das ist schon okay
> ...

Please respect the lang policy of the list. This mailing list is English
only, try to respect other readers, even if it seems hard.

Someone naively using references that may be null might write:  val x = 5 + foo.integerValue  // may throw NPE because foo may be null
Using option, the same person might write:  val x = 5 + foo.get().integerValue // may throw NoSuchElementException because foo may be None

On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris <tonymorris@gmail.com> wrote:

What am I looking for exactly? I see no evidence for "Option changes
NullPointerException to NoSuchElementException." Is it there?

Erik Engbrecht wrote:
> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/Option.scala
>
>
> Look at the bottom of the file.
>
> On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris <tonymorris@gmail.com
> <mailto:tonymorris@gmail.com>> wrote:
>
>     Stepan Koltsov wrote:
>     > You probably missed parts of the discussion where explained how
>     Option
>     > changes NullPointerException to NoSuchElementException.
>     >
>     Except it doesn't.
>
>     --
>     Tony Morris
>     http://tmorris.net/
>
>
>
>
>
> --
> http://erikengbrecht.blogspot.com/

--
Tony Morris
http://tmorris.net/

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

What on earth does mutability have to do with null?

2009/11/21 Philip Köster :
>> Const in the manner you speak, is where you can have a mutable object
>> but pass it around in an immutable form, as far as I can tell. I'd
>> rather have immutable objects than that.
>
> I think I would not. So much fuzz has been created about immutable objects.
> In Java, being mutable or not, is a matter of classes and implementations.
> Martin Odersky even invented different packages for those. I think it is up
> to a library designer, to the callee site, if it wants to see an object as
> immutable or not:
>
> def foo(map: +Map) { /* `+' meaning: cannot be `null' }
>
> is, in my opinion, better than
>
> def foo(map: Map) {
> if map != null {
> doSomething()
> }
> }
>

> What on earth does mutability have to do with null?

Nothing much. Yeah, sorry, I confused two topics in the heat of the night,

>
> 2009/11/21 Philip Köster :
>>> Const in the manner you speak, is where you can have a mutable object
>>> but pass it around in an immutable form, as far as I can tell. I'd
>>> rather have immutable objects than that.
>> I think I would not. So much fuzz has been created about immutable objects.
>> In Java, being mutable or not, is a matter of classes and implementations.
>> Martin Odersky even invented different packages for those. I think it is up
>> to a library designer, to the callee site, if it wants to see an object as
>> immutable or not:
>>
>> def foo(map: +Map) { /* `+' meaning: cannot be `null' }
>>
>> is, in my opinion, better than
>>
>> def foo(map: Map) {
>> if map != null {
>> doSomething()
>> }
>> }
>>
>
>
>

Ishaaq,

You wrote:
> Slightly off topic, but the Arabs got the concept of zero from the
> Indians - the Arabs then introduced it to the western world.
>

That is a myth that is trying - by some well-intentioned people? - to be
created/spread.

Arabs may have borrowed other digits (ie, their shapes) from India (not
a 100% sure fact either) but they have NOT borrowed 0. They invented
it, because they were the center of scientific research then, and they
simply needed it. Without it, math - as they had (possibly) borrowed it
from the Indians - would make much less sense. That's to the best of my
knowledge/research on this off-topic historical point.

Also, note that even *Indians* of today do call numerals we use 'Arabic
numerals', because they - digits we/Arabs - use/used *look different*
from ones they have/had (check TUG India and their TeX Tutorial, for
example).

Finally, you may also like to check the 'Islamic Mathematics' article,
on Encyclopedia Britannica (despite some of its misinformation about
Islam), for getting more info about the numerous contributions made by
Arabs and Muslims to the fundamentals of Mathematics (should I mention
where the word 'Algebra' came from?).

Now...

Tony,

Are your responses an attempt to let ignorance - or misinformation -
reign, among Scala users?? I hope not.

I've *studied* Peirce's TAPL (as it is commonly abbreviated), years ago!
It is not The Qur'an, or a Bible, that has to believed in its totality,
and without questioning. TAPL has some fundamental criticisms against it.

Relevant to our discussion is the fact/criticism that TAPL is too
syntactic, and rarely discusses (mathematical) semantics. Saying this, I
also recognize it is VERY HARD for people who are not familiar much with
PL semantics (particularly Domain Theory, and denotational semantics) to
realize TAPL's "syntactic-ness".

I thus suggest YOU first read more, in PL semantics, particularly Dana
Scott seminal work (for which he was awarded the Turing Award [the
"Nobel Prize" of CS], and Gordon Plotkin and Cardelli's important work
on PL semantics, before talking about _|_ (and wrongly associating it
with 'null').

And please remember: I was once - at the time of that discussion I had
with Corky - in your shoes. Corky then helped me, a lot, to realize the
distinction you are now still unable to make.

So, finally, please be careful before you talk, specially on a mailing
list with so many members. It is only because I am sure of my main
premises, backed by Corky's opinion, that I sent to this mailing list (I
usually do not follow it/send to it much). I - and you? - should not
want to MISGUIDE the nice people on this list who are looking for sure
and true information, right?

-Moez

PS: For the one who asked how can the (simple) program that squares its
input non-terminate, I think you missed my point (I also suggest, if
possible, studying semantics). My point is a GENERAL one, about all
possible computations, not a (your) specific one. My point is that if
you want ANY programming language to be *useful* it HAS to allow the
possibility of non-termination. That is a consequence of the
halting-problem & the Church-Turing thesis, if I recall correctly and
properly understand them. Non-termination ("giving an answer, but at
time infinity!") ALWAYS has to be in our (programmers') minds if we want
to write any useful general software (as defined by Church's lambda
calculus and Turing's Turing machines). My point is, thus, sort of a
"meta"-statement, about all useful programs we can write, not a
statement/point about a specific program.

PS2: Even though I find it exciting, I apologize if I may not continue
this discussion further. I have too much other stuff on my plate that
needs my immediate attention and time.

Tony Morris wrote:
> I strongly recommend Types and Programming Languages by Benjamin Pierce.
>
> Tony Morris wrote:
>> Moez A. Abdel-Gawad wrote:
>>
>>> Tony Morris wrote:
>>>
>>>> 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."
>>>>
>>>>
>>> That's not true.
>>>
>>> Me and Corky (Prof. Robert Cartwright, my PhD advisor) discussed this
>>> once while discussing Domain Theory (the "Math of Computing", upon
>>> which my PhD thesis is based). We reached the conclusion that
>>> non-termination is just, well, non-termination. It can NOT be
>>> eliminated from computation. Null, on the other hand *exists*, as a
>>> genuine real but unusual/ exceptional/ unexpected value. It should,
>>> formally speaking, be added to each type that needs one such value
>>> (some don't), or forced on them by belonging to a
>>> (non-expressible-in-Java) 'NullType' that is a subtype (based on a
>>> subclass) of all types (classes). 'null' - just like all regular
>>> values - can be got ridden of (is not absolutely essential). _|_
>>> (bottom)/non-termination is absolutely essential to the nature of
>>> computation, and cannot be got ridden of.
>>>
>> It's true. You may not realise it but you contradicted yourself.
>> Non-termination must exist in Scala, therefore, it must be represented.
>> You said this yourself.
>>
>> Pattern matching will never be exhaustive, the error function is of type
>> forall A. A (which is a LIE!), and (wait for it) null exists. Null
>> represents that which does not exist and that is the extent of its
>> existence. In a language with different syntax, you might consider
>> calling it _|_. The null value is a value has the type forall A. A. This
>> is not a theorem. It represents bottom, non-termination, undefinedness,
>> logical absurdity. That is what null is. I recommend you try again with
>> Corky. You buggered up.
>>
>>
>>>> Philip Köster wrote:
>>>>
>>>>> Discovering the `0' was what separated the Arabians from the Romans.
>>>>>
>>>>>
>>> 'Arabs', you mean.
>>>
>>> One day we used to teach the world. We hope one day soon we would
>>> again! :)
>>>
>>> -Moez
>>>
>>>
>>
>

As a man trying to read subtexts, I feel some sort of pain that the
Islamic culture is widely underestimated. And I agree. Modern
mathematics are unimageable without Islamic mathematicians. But Islam
folks have recently generated bad press, so it is good to see your
articles, teaching us that we should not over-simplify.

Moez A. Abdel-Gawad schrieb:
> Ishaaq,
>
> You wrote:
> > Slightly off topic, but the Arabs got the concept of zero from the
> > Indians - the Arabs then introduced it to the western world.
> >
>
> That is a myth that is trying - by some well-intentioned people? - to be
> created/spread.
>
> Arabs may have borrowed other digits (ie, their shapes) from India (not
> a 100% sure fact either) but they have NOT borrowed 0. They invented
> it, because they were the center of scientific research then, and they
> simply needed it. Without it, math - as they had (possibly) borrowed it
> from the Indians - would make much less sense. That's to the best of my
> knowledge/research on this off-topic historical point.
>
> Also, note that even *Indians* of today do call numerals we use 'Arabic
> numerals', because they - digits we/Arabs - use/used *look different*
> from ones they have/had (check TUG India and their TeX Tutorial, for
> example).
>
> Finally, you may also like to check the 'Islamic Mathematics' article,
> on Encyclopedia Britannica (despite some of its misinformation about
> Islam), for getting more info about the numerous contributions made by
> Arabs and Muslims to the fundamentals of Mathematics (should I mention
> where the word 'Algebra' came from?).
>
> Now...
>
> Tony,
>
> Are your responses an attempt to let ignorance - or misinformation -
> reign, among Scala users?? I hope not.
>
> I've *studied* Peirce's TAPL (as it is commonly abbreviated), years ago!
> It is not The Qur'an, or a Bible, that has to believed in its totality,
> and without questioning. TAPL has some fundamental criticisms against it.
>
> Relevant to our discussion is the fact/criticism that TAPL is too
> syntactic, and rarely discusses (mathematical) semantics. Saying this, I
> also recognize it is VERY HARD for people who are not familiar much with
> PL semantics (particularly Domain Theory, and denotational semantics) to
> realize TAPL's "syntactic-ness".
>
> I thus suggest YOU first read more, in PL semantics, particularly Dana
> Scott seminal work (for which he was awarded the Turing Award [the
> "Nobel Prize" of CS], and Gordon Plotkin and Cardelli's important work
> on PL semantics, before talking about _|_ (and wrongly associating it
> with 'null').
>
> And please remember: I was once - at the time of that discussion I had
> with Corky - in your shoes. Corky then helped me, a lot, to realize the
> distinction you are now still unable to make.
>
> So, finally, please be careful before you talk, specially on a mailing
> list with so many members. It is only because I am sure of my main
> premises, backed by Corky's opinion, that I sent to this mailing list (I
> usually do not follow it/send to it much). I - and you? - should not
> want to MISGUIDE the nice people on this list who are looking for sure
> and true information, right?
>
> -Moez
>
> PS: For the one who asked how can the (simple) program that squares its
> input non-terminate, I think you missed my point (I also suggest, if
> possible, studying semantics). My point is a GENERAL one, about all
> possible computations, not a (your) specific one. My point is that if
> you want ANY programming language to be *useful* it HAS to allow the
> possibility of non-termination. That is a consequence of the
> halting-problem & the Church-Turing thesis, if I recall correctly and
> properly understand them. Non-termination ("giving an answer, but at
> time infinity!") ALWAYS has to be in our (programmers') minds if we want
> to write any useful general software (as defined by Church's lambda
> calculus and Turing's Turing machines). My point is, thus, sort of a
> "meta"-statement, about all useful programs we can write, not a
> statement/point about a specific program.
>
> PS2: Even though I find it exciting, I apologize if I may not continue
> this discussion further. I have too much other stuff on my plate that
> needs my immediate attention and time.
>
> Tony Morris wrote:
> > I strongly recommend Types and Programming Languages by Benjamin Pierce.
> >
> > Tony Morris wrote:
> >> Moez A. Abdel-Gawad wrote:
> >>
> >>> Tony Morris wrote:
> >>>
> >>>> 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."
> >>>>
> >>>>
> >>> That's not true.
> >>>
> >>> Me and Corky (Prof. Robert Cartwright, my PhD advisor) discussed this
> >>> once while discussing Domain Theory (the "Math of Computing", upon
> >>> which my PhD thesis is based). We reached the conclusion that
> >>> non-termination is just, well, non-termination. It can NOT be
> >>> eliminated from computation. Null, on the other hand *exists*, as a
> >>> genuine real but unusual/ exceptional/ unexpected value. It should,
> >>> formally speaking, be added to each type that needs one such value
> >>> (some don't), or forced on them by belonging to a
> >>> (non-expressible-in-Java) 'NullType' that is a subtype (based on a
> >>> subclass) of all types (classes). 'null' - just like all regular
> >>> values - can be got ridden of (is not absolutely essential). _|_
> >>> (bottom)/non-termination is absolutely essential to the nature of
> >>> computation, and cannot be got ridden of.
> >>>
> >> It's true. You may not realise it but you contradicted yourself.
> >> Non-termination must exist in Scala, therefore, it must be represented.
> >> You said this yourself.
> >>
> >> Pattern matching will never be exhaustive, the error function is of
> type
> >> forall A. A (which is a LIE!), and (wait for it) null exists. Null
> >> represents that which does not exist and that is the extent of its
> >> existence. In a language with different syntax, you might consider
> >> calling it _|_. The null value is a value has the type forall A. A.
> This
> >> is not a theorem. It represents bottom, non-termination, undefinedness,
> >> logical absurdity. That is what null is. I recommend you try again with
> >> Corky. You buggered up.
> >>
> >>
> >>>> Philip Köster wrote:
> >>>>
> >>>>> Discovering the `0' was what separated the Arabians from the Romans.
> >>>>>
> >>>>>
> >>> 'Arabs', you mean.
> >>>
> >>> One day we used to teach the world. We hope one day soon we would
> >>> again! :)
> >>>
> >>> -Moez
> >>>
> >>>
> >>
> >
>
>

We'll just have to agree to disagree - even though the vast majority of literature on the topic (including the Encyclopaedia Britannica - which you were so quick to quote) agree with what I said: i.e. the decimal number system, with zero as a place-holder denoting magnitude was an Indian invention.

... and yes I already knew the word "Algebra" is rooted from an Arab word - that does not mean they invented the discipline - that honour belongs to the ancient Babylonians (almost 4000 years ago!) - refined by the Greeks and the Indians before the Arabs got hold of it. (http://en.wikipedia.org/wiki/Timeline_of_algebra)

I'm not belittling the myriad achievements of the Arabs - far from it, they were essential to the history of Mathematics, but please don't miss-attribute stuff.

Ishaaq

PS - and no, modern Indians do not call their numerals "Arab numerals", I know, because I am one of them :)  - "Arab numerals" is western nomenclature.

2009/11/22 Moez A. Abdel-Gawad <moez@cs.rice.edu>

Ishaaq,

You wrote:
> Slightly off topic, but the Arabs got the concept of zero from the
> Indians - the Arabs then introduced it to the western world.
>

That is a myth that is trying - by some well-intentioned people? - to be created/spread.

Arabs may have borrowed other digits (ie, their shapes) from India (not a 100% sure fact either) but they have NOT borrowed 0.  They invented it, because they were the center of scientific research then, and they simply needed it. Without it, math - as they had (possibly) borrowed it from the Indians - would make much less sense.  That's to the best of my knowledge/research on this off-topic historical point.

Also, note that even *Indians* of today do call numerals we use 'Arabic numerals', because they - digits we/Arabs - use/used *look different* from ones they have/had (check TUG India and their TeX Tutorial, for example).

Finally, you may also like to check the 'Islamic Mathematics' article, on Encyclopedia Britannica (despite some of its misinformation about Islam), for getting more info about the numerous contributions made by Arabs and Muslims to the fundamentals of Mathematics (should I mention where the word 'Algebra' came from?).

Now...

Tony,

Are your responses an attempt to let ignorance - or misinformation - reign, among Scala users??  I hope not.

I've *studied* Peirce's TAPL (as it is commonly abbreviated), years ago! It is not The Qur'an, or a Bible, that has to believed in its totality, and without questioning.  TAPL has some fundamental criticisms against it.

Relevant to our discussion is the fact/criticism that TAPL is too syntactic, and rarely discusses (mathematical) semantics. Saying this, I also recognize it is VERY HARD for people who are not familiar much with PL semantics (particularly Domain Theory, and denotational semantics) to realize TAPL's "syntactic-ness".

I thus suggest YOU first read more, in PL semantics, particularly Dana Scott seminal work (for which he was awarded the Turing Award [the "Nobel Prize" of CS], and Gordon Plotkin and Cardelli's important work on PL semantics, before talking about _|_ (and wrongly associating it with 'null').

And please remember: I was once - at the time of that discussion I had with Corky - in your shoes.  Corky then helped me, a lot, to realize the distinction you are now still unable to make.

So, finally, please be careful before you talk, specially on a mailing list with so many members.  It is only because I am sure of my main premises, backed by Corky's opinion, that I sent to this mailing list (I usually do not follow it/send to it much).  I - and you? - should not want to MISGUIDE the nice people on this list who are looking for sure and true information, right?

-Moez

PS: For the one who asked how can the (simple) program that squares its input non-terminate, I think you missed my point (I also suggest, if possible, studying semantics). My point is a GENERAL one, about all possible computations, not a (your) specific one. My point is that if you want ANY programming language to be *useful* it HAS to allow the possibility of non-termination.  That is a consequence of the halting-problem & the Church-Turing thesis, if I recall correctly and properly understand them.  Non-termination ("giving an answer, but at time infinity!") ALWAYS has to be in our (programmers') minds if we want to write any useful general software (as defined by Church's lambda calculus and Turing's Turing machines).  My point is, thus, sort of a "meta"-statement, about all useful programs we can write, not a statement/point about a specific program.

PS2: Even though I find it exciting, I apologize if I may not continue this discussion further. I have too much other stuff on my plate that needs my immediate attention and time.

Tony Morris wrote:
> I strongly recommend Types and Programming Languages by Benjamin Pierce.
>
> Tony Morris wrote:
>> Moez A. Abdel-Gawad wrote:
>>
>>> Tony Morris wrote:
>>>
>>>> 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."
>>>>
>>>>
>>> That's not true.
>>>
>>> Me and Corky (Prof. Robert Cartwright, my PhD advisor) discussed this
>>> once while discussing Domain Theory (the "Math of Computing", upon
>>> which my PhD thesis is based).  We reached the conclusion that
>>> non-termination is just, well, non-termination. It can NOT be
>>> eliminated from computation.  Null, on the other hand *exists*, as a
>>> genuine real but unusual/ exceptional/ unexpected value.  It should,
>>> formally speaking, be added to each type that needs one such value
>>> (some don't), or forced on them by belonging to a
>>> (non-expressible-in-Java) 'NullType' that is a subtype (based on a
>>> subclass) of all types (classes). 'null' - just like all regular
>>> values - can be got ridden of (is not absolutely essential).  _|_
>>> (bottom)/non-termination is absolutely essential to the nature of
>>> computation, and cannot be got ridden of.
>>>
>> It's true. You may not realise it but you contradicted yourself.
>> Non-termination must exist in Scala, therefore, it must be represented.
>> You said this yourself.
>>
>> Pattern matching will never be exhaustive, the error function is of type
>> forall A. A (which is a LIE!), and (wait for it) null exists. Null
>> represents that which does not exist and that is the extent of its
>> existence. In a language with different syntax, you might consider
>> calling it _|_. The null value is a value has the type forall A. A. This
>> is not a theorem. It represents bottom, non-termination, undefinedness,
>> logical absurdity. That is what null is. I recommend you try again with
>> Corky. You buggered up.
>>
>>
>>>> Philip Köster wrote:
>>>>
>>>>> Discovering the `0' was what separated the Arabians from the Romans.
>>>>>
>>>>>
>>> 'Arabs', you mean.
>>>
>>> One day we used to teach the world.  We hope one day soon we would
>>> again!  :)
>>>
>>> -Moez
>>>
>>>
>>
>

To possibly take some strength out of this discussion---none of us lived
4000 yrs ago, so we really don't know---, I'm always surprised to see
that even the Chinese and Japanese and Hindu folks adopted ``our"
numbers. They must have been a good invention. :)

Ishaaq Chandy schrieb:
> We'll just have to agree to disagree - even though the vast majority of
> literature on the topic (including the Encyclopaedia Britannica - which
> you were so quick to quote) agree with what I said: i.e. the decimal
> number system, with zero as a place-holder denoting magnitude was an
> Indian invention.
>
> ... and yes I already knew the word "Algebra" is rooted from an Arab
> word - that does not mean they invented the discipline - that honour
> belongs to the ancient Babylonians (almost 4000 years ago!) - refined by
> the Greeks and the Indians before the Arabs got hold of it.
> (http://en.wikipedia.org/wiki/Timeline_of_algebra)
>
> I'm not belittling the myriad achievements of the Arabs - far from it,
> they were essential to the history of Mathematics, but please don't
> miss-attribute stuff.
>
> Ishaaq
>
> PS - and no, modern Indians do not call their numerals "Arab numerals",
> I know, because I am one of them :) - "Arab numerals" is western
> nomenclature.
>
> 2009/11/22 Moez A. Abdel-Gawad >
>
> Ishaaq,
>
>
> You wrote:
> > Slightly off topic, but the Arabs got the concept of zero from the
> > Indians - the Arabs then introduced it to the western world.
> >
>
> That is a myth that is trying - by some well-intentioned people? -
> to be created/spread.
>
> Arabs may have borrowed other digits (ie, their shapes) from India
> (not a 100% sure fact either) but they have NOT borrowed 0. They
> invented it, because they were the center of scientific research
> then, and they simply needed it. Without it, math - as they had
> (possibly) borrowed it from the Indians - would make much less
> sense. That's to the best of my knowledge/research on this
> off-topic historical point.
>
> Also, note that even *Indians* of today do call numerals we use
> 'Arabic numerals', because they - digits we/Arabs - use/used *look
> different* from ones they have/had (check TUG India and their TeX
> Tutorial, for example).
>
> Finally, you may also like to check the 'Islamic Mathematics'
> article, on Encyclopedia Britannica (despite some of its
> misinformation about Islam), for getting more info about the
> numerous contributions made by Arabs and Muslims to the fundamentals
> of Mathematics (should I mention where the word 'Algebra' came from?).
>
> Now...
>
> Tony,
>
> Are your responses an attempt to let ignorance - or misinformation -
> reign, among Scala users?? I hope not.
>
> I've *studied* Peirce's TAPL (as it is commonly abbreviated), years
> ago! It is not The Qur'an, or a Bible, that has to believed in its
> totality, and without questioning. TAPL has some fundamental
> criticisms against it.
>
> Relevant to our discussion is the fact/criticism that TAPL is too
> syntactic, and rarely discusses (mathematical) semantics. Saying
> this, I also recognize it is VERY HARD for people who are not
> familiar much with PL semantics (particularly Domain Theory, and
> denotational semantics) to realize TAPL's "syntactic-ness".
>
> I thus suggest YOU first read more, in PL semantics, particularly
> Dana Scott seminal work (for which he was awarded the Turing Award
> [the "Nobel Prize" of CS], and Gordon Plotkin and Cardelli's
> important work on PL semantics, before talking about _|_ (and
> wrongly associating it with 'null').
>
> And please remember: I was once - at the time of that discussion I
> had with Corky - in your shoes. Corky then helped me, a lot, to
> realize the distinction you are now still unable to make.
>
> So, finally, please be careful before you talk, specially on a
> mailing list with so many members. It is only because I am sure of
> my main premises, backed by Corky's opinion, that I sent to this
> mailing list (I usually do not follow it/send to it much). I - and
> you? - should not want to MISGUIDE the nice people on this list who
> are looking for sure and true information, right?
>
> -Moez
>
> PS: For the one who asked how can the (simple) program that squares
> its input non-terminate, I think you missed my point (I also
> suggest, if possible, studying semantics). My point is a GENERAL
> one, about all possible computations, not a (your) specific one. My
> point is that if you want ANY programming language to be *useful* it
> HAS to allow the possibility of non-termination. That is a
> consequence of the halting-problem & the Church-Turing thesis, if I
> recall correctly and properly understand them. Non-termination
> ("giving an answer, but at time infinity!") ALWAYS has to be in our
> (programmers') minds if we want to write any useful general software
> (as defined by Church's lambda calculus and Turing's Turing
> machines). My point is, thus, sort of a "meta"-statement, about all
> useful programs we can write, not a statement/point about a specific
> program.
>
> PS2: Even though I find it exciting, I apologize if I may not
> continue this discussion further. I have too much other stuff on my
> plate that needs my immediate attention and time.
>
>
> Tony Morris wrote:
> > I strongly recommend Types and Programming Languages by Benjamin
> Pierce.
> >
> > Tony Morris wrote:
> >> Moez A. Abdel-Gawad wrote:
> >>
> >>> Tony Morris wrote:
> >>>
> >>>> 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."
> >>>>
> >>>>
> >>> That's not true.
> >>>
> >>> Me and Corky (Prof. Robert Cartwright, my PhD advisor)
> discussed this
> >>> once while discussing Domain Theory (the "Math of Computing", upon
> >>> which my PhD thesis is based). We reached the conclusion that
> >>> non-termination is just, well, non-termination. It can NOT be
> >>> eliminated from computation. Null, on the other hand *exists*,
> as a
> >>> genuine real but unusual/ exceptional/ unexpected value. It
> should,
> >>> formally speaking, be added to each type that needs one such value
> >>> (some don't), or forced on them by belonging to a
> >>> (non-expressible-in-Java) 'NullType' that is a subtype (based on a
> >>> subclass) of all types (classes). 'null' - just like all regular
> >>> values - can be got ridden of (is not absolutely essential). _|_
> >>> (bottom)/non-termination is absolutely essential to the nature of
> >>> computation, and cannot be got ridden of.
> >>>
> >> It's true. You may not realise it but you contradicted yourself.
> >> Non-termination must exist in Scala, therefore, it must be
> represented.
> >> You said this yourself.
> >>
> >> Pattern matching will never be exhaustive, the error function is
> of type
> >> forall A. A (which is a LIE!), and (wait for it) null exists. Null
> >> represents that which does not exist and that is the extent of its
> >> existence. In a language with different syntax, you might consider
> >> calling it _|_. The null value is a value has the type forall A.
> A. This
> >> is not a theorem. It represents bottom, non-termination,
> undefinedness,
> >> logical absurdity. That is what null is. I recommend you try
> again with
> >> Corky. You buggered up.
> >>
> >>
> >>>> Philip Köster wrote:
> >>>>
> >>>>> Discovering the `0' was what separated the Arabians from the
> Romans.
> >>>>>
> >>>>>
> >>> 'Arabs', you mean.
> >>>
> >>> One day we used to teach the world. We hope one day soon we would
> >>> again! :)
> >>>
> >>> -Moez
> >>>
> >>>
> >>
> >
>
>

On Sat, Nov 21, 2009 at 07:39, Sébastien Bocq wrote:
> It is easier to miss a variable that may be null than to ignore the
> possibility of an empty Option.

There is a simple rule to not forget about nulls ever (we used it successfully):

No variable is allowed to be null unless that is explicitly documented
in code (with comment or annotation).

Like this:

class User {
// all fields are nullable, null means uninitialized
var field1
var field2
var field3
...
}

S.

> The few times I sticked to the old habits of
> using null I got bitten by it so now I stick to Option, I'll worry about
> performance later. Using Option becomes natural once you get used to it.
>
> Sébastien
>
> 2009/11/21 Stepan Koltsov
>>
>> You probably missed parts of the discussion where explained how Option
>> changes NullPointerException to NoSuchElementException.
>>
>>
>> S.
>
>

On Sat, Nov 21, 2009 at 10:04, Ricky Clarkson wrote:
> Option replacing null distinguishes possibly-null values from
> never-null values.  Calling .get is deliberate; you know it can fail.
> Calling foo.bar(baz), where foo may be null in some circumstances,
> encodes failure implicitly.
>
> Unless your goal is to fail, you probably want code that may fail to
> look different to code that may not.
>
> Also, Option.get is only a convenience method; try to use its other
> methods more; the ones that don't fail.

I'll explain the use case better:

===
class User {
// fields are nullable, null means uninitialized
var login: String
var email: String
var userpic: String
}

def findLoginAndEmail(id: Long): User = return user with userpic field unset

def serializerLoginAndEmailForSomeApi(xmlWriter: XmlWriter, user: User) = {
xmlWriter.startElement("user")
xmlWriter.writeAttribute("login", user.login)
xmlWriter.writeAttribute("email", user.email)
xmlWriter.endElement("user")
}
===

I get NPE here if login or email fields are uninitialized. And this is
what I expect, because fields must be initialized if method is called
properly. If I change fields to options, code will be changed to:

===
def serializerUserLoginAndEmail(xmlWriter: XmlWriter, user: User) = {
xmlWriter.startElement("user")
xmlWriter.writeAttribute("login", user.login.get)
xmlWriter.writeAttribute("email", user.email.get)
xmlWriter.endElement("user")
}
===

Instead of getting NPE I get NoSuchElementException. I do not need any
other Option methods except get, because login and email fields _must_
be set according to method specification. In this case Option gives no
advantage.

S.

> I suggest you read Dave's email more closely, rather than reacting to it.
>
> 2009/11/21 Stepan Koltsov :
>> On Sat, Nov 21, 2009 at 04:16, Dave  Griffith wrote:
>>> Stepan Koltsov-2 wrote:
>>>>
>>>> Blaming null is a common misconception. Bad programmers always make
>>>> bugs, not depending of whether null exists.
>>>>
>>>
>>> All programmers, good and bad, create bugs.  Weirdly enough, whether you are
>>> a good programmer
>>> or bad doesn't even have much effect on your rate of bug creation.  The
>>> (somewhat disturbing) rule of
>>> thumb is that whenever you write 10 lines of code you have, on average,
>>> coded a bug.   This is
>>> independent of both programmer skill and language used.  (It's also
>>> independent of just how hard
>>> you try to code in a bug-free manner.   Discipline doesn't get you very far,
>>> can't be trusted, can't
>>> be maintained, and absolutely, positively does not scale.)
>>>
>>> This matters.  Because of this reality, just about the only way to decrease
>>> bugs created per feature is to decrease the number of lines of code
>>> necessary to implement an average feature.  Both Scala and the various
>>> dynamic languages that have become popular of late are examples of languages
>>> that attempt to allow greater density of features per line.  They've been
>>> quite successful at it, with usual density increases reported at about 3-10x
>>> over Java/C#, clustering around 5x. That said, it's uncertain how much
>>> denser functionality can get.
>>>
>>> But if we can't decrease bug densities anymore, we can decrease bug costs.
>>> The best way of doing that is to realize that not all bugs are created
>>> equal.  Some classes of bugs are easier and cheaper to find, and can be
>>> found sooner than others.   Bugs that manifest as static type errors
>>> (ignoring casts) in typeful languages show up at compile time (or preferably
>>> at edit time, as IDEs get more powerful).  This makes them particularly
>>> cheap to fix.   Off-by-one errors and language-barrier errors (e.g.
>>> misspelling fields for reflective access) tend to show up the first time a
>>> program is run, making them annoying but
>>> manageable.   Null pointer errors and type cast errors are probably the
>>> worst.  They can lie dormant
>>> in code until it gets to production and then manifest intermittently.  At
>>> that point things can get very
>>> expensive indeed.   Option moves null pointers from being production-time
>>> nightmares to compile-time annoyances.  That's nothing but upside.  I'll
>>> trade CPU cycles for that all day long.
>>>
>>> Back when I was starting out in this industry, the worst sorts of bugs were
>>> wild pointers and buffer overruns, which make null pointer exceptions look
>>> positively tame in comparison.  We as an industry annihilated wild pointer
>>> bugs and buffer overruns for large classes of programming through a
>>> combination of faster hardware and better language design.   We can do the
>>> same for null pointer bugs.   Option (or something essentially the same as
>>> Option) is pretty much the way to go for that.  It's not perfect, but it's
>>> pretty damn good, and the alternatives are all immeasurably worse.
>>
>> You probably missed parts of the discussion where explained how Option
>> changes NullPointerException to NoSuchElementException.
>>
>>
>> S.
>>
>
>
>
> --
> 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
>

In Java, your best chance to declare that param `p' may not be null is
to write it in doc comments. But as it turns out, ppl are very reluctant
to write Javadocs, for one good reason: Everytime their strategy
changes, they need refactoring and don't want to write all doc comments
all over, so they just don't write them because they know they are
moving targets. This is why I follow Scott Meyers's paradigm: ``If you
want to express something, express it in the language." Unfortunately,
Java would not le me be specific about nullness and constness, which is
why I believe that language has jumped the shark. It was a pleasant
time, but I will not miss you, Java. Alas, Scala makes no improving on
this vital matter.