Cost of Option / Some vs null

Stepan Koltsov-2 wrote:
>
> I'll explain the use case better:
>

Okay, got it. I would still write this as an Option, and instead of using
.get() I would use
.getOrElse(throw new DescriptiveException("good error message")). It would
make design intent
more clear and provide better log messages, at the cost of some additional
text but no additional lines.
Intentionally throwing an NPE would make me uneasy, mostly because whenever
one shows
up in the logs someone ends up spending time to figure out why, and also
because I would be sure that
someone five years down the road would wind up swearing at me.

That said, I can't actually pull the trigger and say that your use case is
"wrong". Different, and probably
not one I would sign off on given the alternative, but still within
acceptable variation. Something to think
about, particularly in light of Erlang-ish "just crash it" error handling
practice.

--Dave Griffith

> I'll explain the use case better:
>
> ===
> class User {
> // fields are nullable, null means uninitialized
> var login: String
> var email: String
> var userpic: String
> }

I question the requirement of having those first two fields be
nullable. As null is an error case, why would you want them to
possibly ever be null?

I'd write:

case class User(login: String, email: String, userPic: Option[String])

That, to me, makes it clear that userPic can validly hold nothing.

If you're paranoid:

case class User(login: String, email: String, userPic: Option[String]) {
if (login == null || email == null)
throw null
}

On Sat, Nov 21, 2009 at 21:00, Ricky Clarkson wrote:
>> I'll explain the use case better:
>>
>> ===
>> class User {
>>  // fields are nullable, null means uninitialized
>>  var login: String
>>  var email: String
>>  var userpic: String
>> }
>
> I question the requirement of having those first two fields be
> nullable.  As null is an error case, why would you want them to
> possibly ever be null?

null fields value is not an error. Fields of class User initialized
from DB table. Different sets of fields are initialized in different
queries.

"userpic == null" means "userpic columns weren't fetched", because I
don't need it.

> I'd write:
>
> case class User(login: String, email: String, userPic: Option[String])

All fields (including login and email) may uninitialized in different
scenarios. Class user may have 30 fields, so initializing all fields
in constructor does not work.

S.

> That, to me, makes it clear that userPic can validly hold nothing.
>
> If you're paranoid:
>
> case class User(login: String, email: String, userPic: Option[String]) {
>  if (login == null || email == null)
>    throw null
> }
>
> --
> 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
>

Perhaps it would have been better to say it can't be eliminated from any language that is turing-complete.
On Sat, Nov 21, 2009 at 7:43 AM, Jesper Nordenberg <megagurka@yahoo.com> wrote:

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

--
Daniel C. Sobral

Veni, vidi, veterni.

Sure, sure. Null is the 0 of pointers. As long as you are handling pointers, null has its place.
Me, I'm with the people who say manual memory management, and, therefore, pointers, have no place in modern languages. So, out with pointers, of which null is a value.
Now, if I'm handling strings, I'm handling strings. I don't want to get a pointer instead.

On Sat, Nov 21, 2009 at 4:03 AM, Philip Köster <philip.koester@web.de> 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."

--
Daniel C. Sobral

Veni, vidi, veterni.

> null fields value is not an error.

But it is, if a certain method is called while certain fields are null.

To me, that sounds a very flaky design. I'm not sure what the right
design is as I don't have all the details.

Fields of class User initialized
> from DB table. Different sets of fields are initialized in different
> queries.
>
> "userpic == null" means "userpic columns weren't fetched", because I
> don't need it.
>
>
>> I'd write:
>>
>> case class User(login: String, email: String, userPic: Option[String])
>
> All fields (including login and email) may uninitialized in different
> scenarios. Class user may have 30 fields, so initializing all fields
> in constructor does not work.
>
> S.
>
>
>> That, to me, makes it clear that userPic can validly hold nothing.
>>
>> If you're paranoid:
>>
>> case class User(login: String, email: String, userPic: Option[String]) {
>>  if (login == null || email == null)
>>    throw null
>> }
>>
>> --
>> 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
>>
>

  C'mon François, take it eaaasy ! These days there's all this rave about
polyglot programming, can't we take it one step further ?

 Prend ça cooool Mec ! ;-)

 Cheers !

On Sat, Nov 21, 2009 at 7:01 AM, Francois <fanf42@gmail.com> wrote:

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.



@font-face {
font-family: 宋体;
}
@font-face {
font-family: Verdana;
}
@font-face {
font-family: @宋体;
}
@page Section1 {size: 595.3pt 841.9pt; margin: 72.0pt 90.0pt 72.0pt 90.0pt; layout-grid: 15.6pt; }
P.MsoNormal {
TEXT-JUSTIFY: inter-ideograph; TEXT-ALIGN: justify; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; FONT-SIZE: 10.5pt
}
LI.MsoNormal {
TEXT-JUSTIFY: inter-ideograph; TEXT-ALIGN: justify; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; FONT-SIZE: 10.5pt
}
DIV.MsoNormal {
TEXT-JUSTIFY: inter-ideograph; TEXT-ALIGN: justify; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; FONT-SIZE: 10.5pt
}
A:link {
COLOR: #1c1c1c; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
COLOR: #1c1c1c; TEXT-DECORATION: underline
}
A:visited {
COLOR: #343434; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
COLOR: #343434; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
FONT-STYLE: normal; FONT-FAMILY: Verdana; COLOR: windowtext; FONT-WEIGHT: normal; TEXT-DECORATION: none; mso-style-type: personal-compose
}
DIV.Section1 {
page: Section1
}
BLOCKQUOTE {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px; MARGIN-LEFT: 2em
}
OL {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
UL {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}

add some fun: about 3500 yrs ago
chinese already had number 1-9. about 2500 yrs ago chinese invent 0. So what YOU
did was just invent how to write numbers in a simple way
 

De
Gao
2009-11-23

发件人： Philip
Köster
发送时间：
2009-11-21 23:22:08
收件人： Ishaaq
Chandy
抄送： Moez A. Abdel-Gawad;
Scala User List
主题： Re: _|_ vs null (Was
Re: [scala-user] Cost of Option / Some vs null)
 

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 <moez@cs.rice.edu <mailto: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
>      >>>
>      >>>
>      >>
>      >
> 
> 

Ok, at the risk of irritating every one else on this mailing list - I'll take the bait and continue this off-topic conversation with one last post.

Please back your claims with references. You statements may be true, but they need to be backed with documentation to be believable.

Zero has had a long and convoluted history pre-dating the Indians, but the first *documented* instance of using the decimal system (which is based on the concept of using zeroes to denote place-holders to denote magnitude) as well as treating zero as a number in its own right is of Indian origin: http://en.wikipedia.org/wiki/Zero#History

According to that wiki page the Chinese had a non-formalised concept of zero in the first century (not first by a long shot, the Babylonians win there again - 2nd millennium BCE! - followed by a number of other civilizations before the Chinese got to it), and that their first formalised documented instance of using zero as we do now was in 1247 CE. I concede that not everyone may consider wikipedia as a legitimate source, however it is not alone in making this claim, and it is the easiest one I could search and link to in an email like this. If you have documented evidence contradicting this please do share.

Ishaaq

2009/11/23 De Gao <gaode.ml@gmail.com>

add some fun: about 3500 yrs ago chinese already had number 1-9. about 2500 yrs ago chinese invent 0. So what YOU did was just invent how to write numbers in a simple way   De Gao 2009-11-23 发件人： Philip Köster 发送时间： 2009-11-21 23:22:08 收件人： Ishaaq Chandy 抄送： Moez A. Abdel-Gawad; Scala User List 主题： Re: _|_ vs null (Was Re: [scala-user] Cost of Option / Some vs null)   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 <moez@cs.rice.edu <mailto: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 >      >>> >      >>> >      >> >      > >  > 

But at the other end of the spectrum; I think that Europeans+Russians fairly got infinity, the proper formalised aleph-zero stuff, not just ∞ (Cantor was German, but born in Russia)

Or if you just want to get very-very-very close to zero then we have Newton and Leibniz to thank for infinitesimals and differential calculus

Recent research has shown that traditional African villages have been built around a fractal structure for, well, a very long time.


There's a lot to be said for the famous "standing on the shoulders of giants" quote.  Mathematics is truly global and is built from the work of a great many people scattered across the globe.



On Mon, Nov 23, 2009 at 11:02 AM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

Ok, at the risk of irritating every one else on this mailing list - I'll take the bait and continue this off-topic conversation with one last post.

Please back your claims with references. You statements may be true, but they need to be backed with documentation to be believable.

Zero has had a long and convoluted history pre-dating the Indians, but the first *documented* instance of using the decimal system (which is based on the concept of using zeroes to denote place-holders to denote magnitude) as well as treating zero as a number in its own right is of Indian origin: http://en.wikipedia.org/wiki/Zero#History

According to that wiki page the Chinese had a non-formalised concept of zero in the first century (not first by a long shot, the Babylonians win there again - 2nd millennium BCE! - followed by a number of other civilizations before the Chinese got to it), and that their first formalised documented instance of using zero as we do now was in 1247 CE. I concede that not everyone may consider wikipedia as a legitimate source, however it is not alone in making this claim, and it is the easiest one I could search and link to in an email like this. If you have documented evidence contradicting this please do share.

Ishaaq

2009/11/23 De Gao <gaode.ml@gmail.com>

add some fun: about 3500 yrs ago chinese already had number 1-9. about 2500 yrs ago chinese invent 0. So what YOU did was just invent how to write numbers in a simple way   De Gao 2009-11-23 发件人： Philip Köster 发送时间： 2009-11-21 23:22:08 收件人： Ishaaq Chandy 抄送： Moez A. Abdel-Gawad; Scala User List 主题： Re: _|_ vs null (Was Re: [scala-user] Cost of Option / Some vs null)   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 <moez@cs.rice.edu <mailto: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 >      >>> >      >>> >      >> >      > >  > 

Amen brother! No argument there. That is what I implied when I previously pointed out that the Arabs have a myriad achievements to their credit. And yes, as you point out, so do the Greeks, the Chinese, the Europeans etc. I was merely pointing out a factual error that was made about the history of zero, nothing more, nothing less.

In fact, in all this, the people that really shine out were the Babylonians - the mathematical discoveries they made 4000 years ago were unmatched for their time! The stuff they discovered still affects us today - ever wondered why there are 60 seconds to the minute? 360 degrees to form a circle?

Cheers,
Ishaaq

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

But at the other end of the spectrum; I think that Europeans+Russians fairly got infinity, the proper formalised aleph-zero stuff, not just ∞ (Cantor was German, but born in Russia)

Or if you just want to get very-very-very close to zero then we have Newton and Leibniz to thank for infinitesimals and differential calculus

Recent research has shown that traditional African villages have been built around a fractal structure for, well, a very long time.


There's a lot to be said for the famous "standing on the shoulders of giants" quote.  Mathematics is truly global and is built from the work of a great many people scattered across the globe.



On Mon, Nov 23, 2009 at 11:02 AM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

Ok, at the risk of irritating every one else on this mailing list - I'll take the bait and continue this off-topic conversation with one last post.

Please back your claims with references. You statements may be true, but they need to be backed with documentation to be believable.

Zero has had a long and convoluted history pre-dating the Indians, but the first *documented* instance of using the decimal system (which is based on the concept of using zeroes to denote place-holders to denote magnitude) as well as treating zero as a number in its own right is of Indian origin: http://en.wikipedia.org/wiki/Zero#History

According to that wiki page the Chinese had a non-formalised concept of zero in the first century (not first by a long shot, the Babylonians win there again - 2nd millennium BCE! - followed by a number of other civilizations before the Chinese got to it), and that their first formalised documented instance of using zero as we do now was in 1247 CE. I concede that not everyone may consider wikipedia as a legitimate source, however it is not alone in making this claim, and it is the easiest one I could search and link to in an email like this. If you have documented evidence contradicting this please do share.

Ishaaq

2009/11/23 De Gao <gaode.ml@gmail.com>

add some fun: about 3500 yrs ago chinese already had number 1-9. about 2500 yrs ago chinese invent 0. So what YOU did was just invent how to write numbers in a simple way   De Gao 2009-11-23 发件人： Philip Köster 发送时间： 2009-11-21 23:22:08 收件人： Ishaaq Chandy 抄送： Moez A. Abdel-Gawad; Scala User List 主题： Re: _|_ vs null (Was Re: [scala-user] Cost of Option / Some vs null)   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 <moez@cs.rice.edu <mailto: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 >      >>> >      >>> >      >> >      > >  > 

Erik Engbrecht schrieb:
> Using option, the same person might write:
> val x = 5 + foo.get().integerValue // may throw NoSuchElementException
> because foo may be None

And some would argue that you should really write something like
this to avoid all the case matches and if/else constructs:

scala> def addFive(foo: Option[Int]) = foo map (_ + 5)
addFive: (Option[Int])Option[Int]

scala> addFive(None)
res0: Option[Int] = None

scala> addFive(Some(4))
res1: Option[Int] = Some(9)

This works equally well for Tony's Optionn:

scala> def addFiveN(foo: Optionn[Int]) = foo map (_ + 5)
addFiveN: (Optionn[Int])java.lang.Object with Optionn[Int]

scala> object NoneN extends Optionn[Nothing] {
| def cata[X](ding: Nothing => X, dong: => X) = dong
| }
defined module NoneN

scala> class SomeN[T](x: T) extends Optionn[T] {
| def cata[X](ding: T => X, dong: => X) = ding(x)
| }
defined class SomeN

scala> addFiveN(NoneN) cata (x => "SomeN(" + x.toString + ")", "NoneN")
res16: java.lang.String = NoneN

scala> addFiveN(new SomeN(4)) cata (x => "SomeN(" + x.toString + ")", "NoneN")
res17: java.lang.String = SomeN(9)

- Florian

Yeah, base 60 is fun, divisible by so many other useful integers. Same
logic applies to base 12; try and easily split a meter into thirds,
then do the same with a foot.

On Monday, November 23, 2009, Ishaaq Chandy wrote:
> Amen brother! No argument there. That is what I implied when I previously pointed out that the Arabs have a myriad achievements to their credit. And yes, as you point out, so do the Greeks, the Chinese, the Europeans etc. I was merely pointing out a factual error that was made about the history of zero, nothing more, nothing less.
>
> In fact, in all this, the people that really shine out were the Babylonians - the mathematical discoveries they made 4000 years ago were unmatched for their time! The stuff they discovered still affects us today - ever wondered why there are 60 seconds to the minute? 360 degrees to form a circle?
>
> Cheers,
> Ishaaq
>
> 2009/11/23 Kevin Wright >
>
>
> But at the other end of the spectrum; I think that Europeans+Russians fairly got infinity, the proper formalised aleph-zero stuff, not just ∞ (Cantor was German, but born in Russia)
>
> Or if you just want to get very-very-very close to zero then we have Newton and Leibniz to thank for infinitesimals and differential calculus
>
> Recent research has shown that traditional African villages have been built around a fractal structure for, well, a very long time.
>
>
> There's a lot to be said for the famous "standing on the shoulders of giants" quote.  Mathematics is truly global and is built from the work of a great many people scattered across the globe.
>
>
>
>
>
> On Mon, Nov 23, 2009 at 11:02 AM, Ishaaq Chandy wrote:
>
>
>
> Ok, at the risk of irritating every one else on this mailing list - I'll take the bait and continue this off-topic conversation with one last post.
>
> Please back your claims with references. You statements may be true, but they need to be backed with documentation to be believable.
>
> Zero has had a long and convoluted history pre-dating the Indians, but the first *documented* instance of using the decimal system (which is based on the concept of using zeroes to denote place-holders to denote magnitude) as well as treating zero as a number in its own right is of Indian origin: http://en.wikipedia.org/wiki/Zero#History
>
> According to that wiki page the Chinese had a non-formalised concept of zero in the first century (not first by a long shot, the Babylonians win there again - 2nd millennium BCE! - followed by a number of other civilizations before the Chinese got to it), and that their first formalised documented instance of using zero as we do now was in 1247 CE. I concede that not everyone may consider wikipedia as a legitimate source, however it is not alone in making this claim, and it is the easiest one I could search and link to in an email like this. If you have documented evidence contradicting this please do share.
>
> Ishaaq
>
> 2009/11/23 De Gao
>
>
>
>
>
>
>
>
>
>
>
>
> add some fun: about 3500 yrs ago
> chinese already had number 1-9. about 2500 yrs ago chinese invent 0. So what YOU
> did was just invent how to write numbers in a simple way
>
>
>
>
>
> De
> Gao
> 2009-11-23
>
>
>
> 发件人： Philip
> Köster
> 发送时间：
> 2009-11-21 23:22:08
> 收件人： Ishaaq
> Chandy
> 抄送： Moez A. Abdel-Gawad;
> Scala User List
> 主题： Re: _|_ vs null (Was
> Re: [scala-user] Cost of Option / Some vs null)
>
>
> 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 inve
>

Babylonians didn't fully develop division (i.e. they didn't fully work out the idea of multiplicative inverse and come up with methods for representing such things to arbitrary precision).  So for them (1/7) was a problem.  They did create tables of exact multiplicative inverses, though, along with approximations for the ones that didn't have exact inverses (and they recognized that those were just approximations).

These days, to split a meter into thirds, it's (1/3) meters--just leave it as a rational number!  Convert (1/3) or whatever you end up with into decimal to the desired number of significant figures as the last step.  Not so hard!

Of course, it would be easier still to divide by 3 if we used base 6 or 12 for counting.  (60 is too much of a hassle, since your addition table has ~900 entries in it, which is hard to memorize.)

  --Rex

On Mon, Nov 23, 2009 at 1:40 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

Yeah, base 60 is fun, divisible by so many other useful integers. Same
logic applies to base 12; try and easily split a meter into thirds,
then do the same with a foot.

On Monday, November 23, 2009, Ishaaq Chandy <ishaaq@gmail.com> wrote:

> In fact, in all this, the people that really shine out were the Babylonians - the mathematical discoveries they made 4000 years ago were unmatched for their time! The stuff they discovered still affects us today - ever wondered why there are 60 seconds to the minute? 360 degrees to form a circle?
>

Sorry for scala mail list, but it is really an  interesting topic.
  60 is very meaningfull in Chinese culture. Traditional Chinese also think 60 is the realy cycle.   You could find some introduce in wiki: http://en.wikipedia.org/wiki/Sexagenary_cycle And it  is used at  calendar  on 2697 BC.   Ancestor muse know something that we didn't understand.
  On Mon, Nov 23, 2009 at 10:40 AM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

Yeah, base 60 is fun, divisible by so many other useful integers. Same
logic applies to base 12; try and easily split a meter into thirds,
then do the same with a foot.

On Monday, November 23, 2009, Ishaaq Chandy <ishaaq@gmail.com> wrote:
> Amen brother! No argument there. That is what I implied when I previously pointed out that the Arabs have a myriad achievements to their credit. And yes, as you point out, so do the Greeks, the Chinese, the Europeans etc. I was merely pointing out a factual error that was made about the history of zero, nothing more, nothing less.
>
> In fact, in all this, the people that really shine out were the Babylonians - the mathematical discoveries they made 4000 years ago were unmatched for their time! The stuff they discovered still affects us today - ever wondered why there are 60 seconds to the minute? 360 degrees to form a circle?
>
> Cheers,
> Ishaaq
>
> 2009/11/23 Kevin Wright <kev.lee.wright@googlemail.com <javascript:_e({}, 'cvml', 'kev.lee.wright@googlemail.com');>>
>
>
> But at the other end of the spectrum; I think that Europeans+Russians fairly got infinity, the proper formalised aleph-zero stuff, not just ∞ (Cantor was German, but born in Russia)
>
> Or if you just want to get very-very-very close to zero then we have Newton and Leibniz to thank for infinitesimals and differential calculus
>
> Recent research has shown that traditional African villages have been built around a fractal structure for, well, a very long time.
>
>
> There's a lot to be said for the famous "standing on the shoulders of giants" quote.  Mathematics is truly global and is built from the work of a great many people scattered across the globe.
>
>
>
>
>
> On Mon, Nov 23, 2009 at 11:02 AM, Ishaaq Chandy <ishaaq@gmail.com> wrote:
>
>
>
> Ok, at the risk of irritating every one else on this mailing list - I'll take the bait and continue this off-topic conversation with one last post.
>
> Please back your claims with references. You statements may be true, but they need to be backed with documentation to be believable.
>
> Zero has had a long and convoluted history pre-dating the Indians, but the first *documented* instance of using the decimal system (which is based on the concept of using zeroes to denote place-holders to denote magnitude) as well as treating zero as a number in its own right is of Indian origin: http://en.wikipedia.org/wiki/Zero#History
>
> According to that wiki page the Chinese had a non-formalised concept of zero in the first century (not first by a long shot, the Babylonians win there again - 2nd millennium BCE! - followed by a number of other civilizations before the Chinese got to it), and that their first formalised documented instance of using zero as we do now was in 1247 CE. I concede that not everyone may consider wikipedia as a legitimate source, however it is not alone in making this claim, and it is the easiest one I could search and link to in an email like this. If you have documented evidence contradicting this please do share.
>
> Ishaaq
>
> 2009/11/23 De Gao <gaode.ml@gmail.com>
>
>
>
>
>
>
>
>
>
>
>
>
> add some fun: about 3500 yrs ago
> chinese already had number 1-9. about 2500 yrs ago chinese invent 0. So what YOU
> did was just invent how to write numbers in a simple way
>
>
>
>
>
> De
> Gao
> 2009-11-23
>
>
>
> 发件人： Philip
> Köster
> 发送时间：
> 2009-11-21 23:22:08
> 收件人： Ishaaq
> Chandy
> 抄送： Moez A. Abdel-Gawad;
> Scala User List
> 主题： Re: _|_ vs null (Was
> Re: [scala-user] Cost of Option / Some vs null)
>
>
> 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 inve
>

--
Scala中文社区:  http://groups.google.com/group/scalacn

Stepan Koltsov
writes:

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

I'm late to the party here, but I want to throw this in: In Java,
there's no good way to distinguish between a function that always
returns a valid reference and one that sometimes does and sometimes
returns null.

C has this problem, and C++ fixed it by way of idiom: a function that
returns a reference (or, of course, by value) promises to to not return
null, while a function that returns a pointer hints that it might return
null.¹ Scala's Option is most valuable as a threat, like the returned
pointer in C++.

When reviewing my team's Java code, I often have to dive down through
all the new function invocations they've introduced to see first whether
the function's documentation threatens to return null, and then whether
the implementation does anyway -- despite an unmentioned threat.

In Java, the following expressions are not "safe":

object.method().field
object.method().method()

just as in C or C++ the following expressions are not "safe":

func()->member
func()->memberfunc()

By "safe", I mean trustworthy to not dereference null pointers without
code inspection. Scala's Option -- like C++ references -- use the type
system to make this distinction.

It's unfortunate that Scala functions declared to return some type can
still return null.

Footnotes:
¹ It takes strange or just irresponsible code to work around this,
creating an undefined program, and the blame rightly lays with the
function that built up the null reference, not with the invoker of the
function consuming its return value.

On Fri, Nov 27, 2009 at 17:52, Steven E. Harris wrote:
> Stepan Koltsov
> writes:
>
>> Blaming null is a common misconception. Bad programmers always make
>> bugs, not depending of whether null exists.
>
> I'm late to the party here, but I want to throw this in: In Java,
> there's no good way to distinguish between a function that always
> returns a valid reference and one that sometimes does and sometimes
> returns null.

Just add a convention in your team: null is allowed only if it is
explicitly mentioned.

> C has this problem, and C++ fixed it by way of idiom: a function that
> returns a reference (or, of course, by value) promises to to not return
> null, while a function that returns a pointer hints that it might return
> null.

C++ has various coventions for &.

For example, reference may be used to indicate object ownership changes.

If object passed by reference to a function, then function does not
store the reference.

If object passed by pointer to a function, then either
— function may store pointer somewhere and pointer may be used after
function returns
— or pointer is used to indicate out parameter.

If object is passed by auto_ptr, then function takes object ownership

> Scala's Option is most valuable as a threat, like the returned
> pointer in C++.
>
> When reviewing my team's Java code, I often have to dive down through
> all the new function invocations they've introduced to see first whether
> the function's documentation threatens to return null, and then whether
> the implementation does anyway -- despite an unmentioned threat.
>
> In Java, the following expressions are not "safe":
>
>  object.method().field
>  object.method().method()
>
> just as in C or C++ the following expressions are not "safe":
>
>  func()->member
>  func()->memberfunc()
>
> By "safe", I mean trustworthy to not dereference null pointers without
> code inspection. Scala's Option -- like C++ references -- use the type
> system to make this distinction.

Add Option to C++ and Java (I did), and do not use null unless it is
explicitly mentioned.

> It's unfortunate that Scala functions declared to return some type can
> still return null.

It is unfortunate that function is declared to return Int, and it can
sill return negative value.

S.

> Just add a convention in your team: null is allowed only if it is
> explicitly mentioned.

Which would only be a team convention. In the Java world, what seems
agreeable is that lists and arrays should never be `null' but empty
rather. But noone can promise you the libs you are using hold on to this
unwritten contract. I believe it should be the language to enforce this.

And yes, although this has nothing to do with constness at first sight:
Declared constness offers a wide range of possible optimizations, not
just only for the compiler but also for CPU opcodes at runtime. And
maybe future hardware layouts will make a big difference between
read-only and read-and-write memory areas. I still don't know whether it
was a good idea to make mutability and immutablity a matter of different
class implementations. Only time will tell, and it hasn't done yet. I
believe this belongs to the field of optimizations we all agree is less
important than commonly assumed. I believe a vector or whatever should
not know whether it is immutable or not, but users of a vector should
tell whether they want to use it as a mutable or immutable vector.

---Phil

Based upon experience of C++, I can't agree more about how useful const is.One thing I would do differently though:  const should be the default, make mutability explicit

On Sun, Nov 29, 2009 at 11:01 PM, Philip Köster <philip.koester@web.de> wrote:

Just add a convention in your team: null is allowed only if it is
explicitly mentioned.

Which would only be a team convention. In the Java world, what seems agreeable is that lists and arrays should never be `null' but empty rather. But noone can promise you the libs you are using hold on to this unwritten contract. I believe it should be the language to enforce this.

And yes, although this has nothing to do with constness at first sight: Declared constness offers a wide range of possible optimizations, not just only for the compiler but also for CPU opcodes at runtime. And maybe future hardware layouts will make a big difference between read-only and read-and-write memory areas. I still don't know whether it was a good idea to make mutability and immutablity a matter of different class implementations. Only time will tell, and it hasn't done yet. I believe this belongs to the field of optimizations we all agree is less important than commonly assumed. I believe a vector or whatever should not know whether it is immutable or not, but users of a vector should tell whether they want to use it as a mutable or immutable vector.

---Phil

I thought you could always cast away the 'constness' of a variable in
C++? So it's not safer than returning some read-only interface exposed
by mutable structure, where the user would still be allowed to cast
and mutate. If you trust the code not to do such a cast, then you
could as well trust the code not perform any update and pass in the
mutable as-is. So I don't see "const" buying you anything substantial.

2009/11/30 Kevin Wright :
> Based upon experience of C++, I can't agree more about how useful const is.
> One thing I would do differently though:  const should be the default, make
> mutability explicit
>
> On Sun, Nov 29, 2009 at 11:01 PM, Philip Köster
> wrote:
>>>
>>> Just add a convention in your team: null is allowed only if it is
>>> explicitly mentioned.
>>
>> Which would only be a team convention. In the Java world, what seems
>> agreeable is that lists and arrays should never be `null' but empty rather.
>> But noone can promise you the libs you are using hold on to this unwritten
>> contract. I believe it should be the language to enforce this.
>>
>> And yes, although this has nothing to do with constness at first sight:
>> Declared constness offers a wide range of possible optimizations, not just
>> only for the compiler but also for CPU opcodes at runtime. And maybe future
>> hardware layouts will make a big difference between read-only and
>> read-and-write memory areas. I still don't know whether it was a good idea
>> to make mutability and immutablity a matter of different class
>> implementations. Only time will tell, and it hasn't done yet. I believe this
>> belongs to the field of optimizations we all agree is less important than
>> commonly assumed. I believe a vector or whatever should not know whether it
>> is immutable or not, but users of a vector should tell whether they want to
>> use it as a mutable or immutable vector.
>>
>> ---Phil
>
>

Just because C++ allowed the casting-away of const doesn't mean that scala should.
It's true that this would probably be impossible via bytecode, on the JVM(indeed, it's already impossible to truly enforce access modifiers and final fields)
But it could be defined within Scala that    "const = not changeable, under any circumstances, ever"This might even be possible within Scala reflection, though I suspect Java reflection could offer a back door.
Of course, as with any other technique - if you go out of your way to subvert the system, then you deserve to have it crash.



On Sun, Nov 29, 2009 at 11:40 PM, Dimitris Andreou <jim.andreou@gmail.com> wrote:

I thought you could always cast away the 'constness' of a variable in
C++? So it's not safer than returning some read-only interface exposed
by mutable structure, where the user would still be allowed to cast
and mutate. If you trust the code not to do such a cast, then you
could as well trust the code not perform any update and pass in the
mutable as-is. So I don't see "const" buying you anything substantial.

2009/11/30 Kevin Wright <kev.lee.wright@googlemail.com>:
> Based upon experience of C++, I can't agree more about how useful const is.
> One thing I would do differently though:  const should be the default, make
> mutability explicit
>
> On Sun, Nov 29, 2009 at 11:01 PM, Philip Köster <philip.koester@web.de>
> wrote:
>>>
>>> Just add a convention in your team: null is allowed only if it is
>>> explicitly mentioned.
>>
>> Which would only be a team convention. In the Java world, what seems
>> agreeable is that lists and arrays should never be `null' but empty rather.
>> But noone can promise you the libs you are using hold on to this unwritten
>> contract. I believe it should be the language to enforce this.
>>
>> And yes, although this has nothing to do with constness at first sight:
>> Declared constness offers a wide range of possible optimizations, not just
>> only for the compiler but also for CPU opcodes at runtime. And maybe future
>> hardware layouts will make a big difference between read-only and
>> read-and-write memory areas. I still don't know whether it was a good idea
>> to make mutability and immutablity a matter of different class
>> implementations. Only time will tell, and it hasn't done yet. I believe this
>> belongs to the field of optimizations we all agree is less important than
>> commonly assumed. I believe a vector or whatever should not know whether it
>> is immutable or not, but users of a vector should tell whether they want to
>> use it as a mutable or immutable vector.
>>
>> ---Phil
>
>

> I thought you could always cast away the 'constness' of a variable in
> C++? So it's not safer than returning some read-only interface exposed
> by mutable structure, where the user would still be allowed to cast
> and mutate. If you trust the code not to do such a cast, then you
> could as well trust the code not perform any update and pass in the
> mutable as-is. So I don't see "const" buying you anything substantial.

Yes you can cast away constness in C++. I don't remember the syntax, but
it is possible. The point is, it needs some criminal energy to do that.
It is comparable with using Java reflection and declaring a field as
accessible. But at this point, future compilers might emight a warning
or, better, an error, that your code will segfault on modern CPUs. If
you ask for trouble, then you must be willing to take the trouble. But
this whole gossip about mutability and immutablity that has been going
on for a decade or more in the JVM world really makes me frown because
that's all due to the poor meaning of `final'.

Dimitris Andreou
writes:

> I thought you could always cast away the 'constness' of a variable in
> C++?

Yes and no. If the original object declaration was not const, you can
cast away constness via const_cast, and the program is still
well-formed. However, if the original object declaration was not const,
you're now into undefined behavior. In other words, it's generally not
safe to use, especially if you're not sure from where the object in
question came from.

It used to be necessary to distinguish between "physical and logical
constness" in classes, but the "mutable" keyword came along to remove
that justification.

In addition, `const_cast' and `setAccessible' (or, in Scalanese,
`accessible') are easy to grep, while a simple usage of an object is not.

---Phil.

Steven E. Harris schrieb:
> Dimitris Andreou
> writes:
>
>> I thought you could always cast away the 'constness' of a variable in
>> C++?
>
> Yes and no. If the original object declaration was not const, you can
> cast away constness via const_cast, and the program is still
> well-formed. However, if the original object declaration was not const,
> you're now into undefined behavior. In other words, it's generally not
> safe to use, especially if you're not sure from where the object in
> question came from.
>
> It used to be necessary to distinguish between "physical and logical
> constness" in classes, but the "mutable" keyword came along to remove
> that justification.
>

> Yes and no. If the original object declaration was not const, you can
> cast away constness via const_cast, and the program is still
> well-formed. However, if the original object declaration was not const,
> you're now into undefined behavior. In other words, it's generally not
> safe to use, especially if you're not sure from where the object in
> question came from.

I believe why C++ has jumped the shark is that it is, while being
potentially powerful, too complicated. In C++, you have to differentiate
between three flavors: pointers, references, and aggregates. I believe
why Java has jumped the shark is that it is, while being potentially
powerful, too simple. In Java, you only have references you don't know
who they belong to, so you stick your head into the earth like Vogel
Strauß. I'd prefer some strategy in the middle ... Alas, Scala doesn't
point a way out.
>
> It used to be necessary to distinguish between "physical and logical
> constness" in classes, but the "mutable" keyword came along to remove
> that justification.
>

On Sun, 2009-11-29 at 23:51 +0000, Kevin Wright wrote:
>
> It's true that this would probably be impossible via bytecode, on the
> JVM
> (indeed, it's already impossible to truly enforce access modifiers and
> final fields)

You can enforce it with a security manager.

Ismael

On Mon, Nov 30, 2009 at 8:05 AM, Ismael Juma <mlists@juma.me.uk> wrote:

On Sun, 2009-11-29 at 23:51 +0000, Kevin Wright wrote:
>
> It's true that this would probably be impossible via bytecode, on the
> JVM
> (indeed, it's already impossible to truly enforce access modifiers and
> final fields)

You can enforce it with a security manager.

Granted :)
But that's a serious amount of overhead, and I'd still argue that the JVM is only helping enforce the security policy and not constness. Anything on the right side of the security manager could still cause harm.
 

Ismael

My dislike of const semantics is not in preference to a free-for-all,
but in preference for immutability.

One cannot rely on the values in a const object remaining the same,
unless one knows the code that has the object available without const.

I would rather have the object immutable than have it world-readable
and owner-writeable. I don't want objects to have the concept of an
owner. That makes them harder to reuse, and encourages crap like
clone.

2009/11/30 Kevin Wright :
>
>
> On Mon, Nov 30, 2009 at 8:05 AM, Ismael Juma wrote:
>>
>> On Sun, 2009-11-29 at 23:51 +0000, Kevin Wright wrote:
>> >
>> > It's true that this would probably be impossible via bytecode, on the
>> > JVM
>> > (indeed, it's already impossible to truly enforce access modifiers and
>> > final fields)
>>
>> You can enforce it with a security manager.
>
> Granted :)
> But that's a serious amount of overhead, and I'd still argue that the JVM is
> only helping enforce the security policy and not constness.
> Anything on the right side of the security manager could still cause harm.
>
>>
>> Ismael
>>
>>
>
>

On Mon, 2009-11-30 at 08:35 +0000, Kevin Wright wrote:
>
> On Mon, Nov 30, 2009 at 8:05 AM, Ismael Juma
> wrote:
> On Sun, 2009-11-29 at 23:51 +0000, Kevin Wright wrote:
> >
> > It's true that this would probably be impossible via
> bytecode, on the
> > JVM
> > (indeed, it's already impossible to truly enforce access
> modifiers and
> > final fields)
>
> You can enforce it with a security manager.
>
> Granted :)
>
> But that's a serious amount of overhead, and I'd still argue that the
> JVM is only helping enforce the security policy and not constness.

Sure, I never said anything about constness.

Just correcting the statement that access modifiers and final fields
can't be enforced in the JVM. They can.

Best,
Ismael

Yeah, I never really did like the idea of mutably-const :)As in C++ when you temporarily grant constness to a reference when passing it to a const function.
We need a two-pronged approach: - declare that functions are pure, and WILL NOT mutate any arguments supplied- declare members as const, which would act as final but also prevent transitive mutation.
by "const", I mean something closer to the idea of 'immutable' in D: http://www.digitalmars.com/d/2.0/const3.html
Constness/Purity becomes part of the type signature for that member/function, so it's a const Foo, not just a Foo(out of curiousity, does anyone know a good alternative to "variable" for something that can't vary? Member doesn't feel quite right)
const members can then only be passed to pure methods/functions


On Mon, Nov 30, 2009 at 8:41 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

My dislike of const semantics is not in preference to a free-for-all,
but in preference for immutability.

One cannot rely on the values in a const object remaining the same,
unless one knows the code that has the object available without const.

I would rather have the object immutable than have it world-readable
and owner-writeable.  I don't want objects to have the concept of an
owner.  That makes them harder to reuse, and encourages crap like
clone.

2009/11/30 Kevin Wright <kev.lee.wright@googlemail.com>:
>
>
> On Mon, Nov 30, 2009 at 8:05 AM, Ismael Juma <mlists@juma.me.uk> wrote:
>>
>> On Sun, 2009-11-29 at 23:51 +0000, Kevin Wright wrote:
>> >
>> > It's true that this would probably be impossible via bytecode, on the
>> > JVM
>> > (indeed, it's already impossible to truly enforce access modifiers and
>> > final fields)
>>
>> You can enforce it with a security manager.
>
> Granted :)
> But that's a serious amount of overhead, and I'd still argue that the JVM is
> only helping enforce the security policy and not constness.
> Anything on the right side of the security manager could still cause harm.
>
>>
>> Ismael
>>
>>
>
>



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

If you have ever tracked references to a reference to an immutable list
in C++, then you're digging it deep. This can no longer be handled by
humans. I do not appreciate the concept of ``ownership" either, which
is why I appreciate garbage collection.

Ricky Clarkson schrieb:
> My dislike of const semantics is not in preference to a free-for-all,
> but in preference for immutability.
>
> One cannot rely on the values in a const object remaining the same,
> unless one knows the code that has the object available without const.
>
> I would rather have the object immutable than have it world-readable
> and owner-writeable. I don't want objects to have the concept of an
> owner. That makes them harder to reuse, and encourages crap like
> clone.
>
> 2009/11/30 Kevin Wright :
>>
>> On Mon, Nov 30, 2009 at 8:05 AM, Ismael Juma wrote:
>>> On Sun, 2009-11-29 at 23:51 +0000, Kevin Wright wrote:
>>>> It's true that this would probably be impossible via bytecode, on the
>>>> JVM
>>>> (indeed, it's already impossible to truly enforce access modifiers and
>>>> final fields)
>>> You can enforce it with a security manager.
>> Granted :)
>> But that's a serious amount of overhead, and I'd still argue that the JVM is
>> only helping enforce the security policy and not constness.
>> Anything on the right side of the security manager could still cause harm.
>>
>>> Ismael
>>>
>>>
>>
>
>
>

On Mon, Nov 30, 2009 at 8:55 AM, Ismael Juma <mlists@juma.me.uk> wrote:

On Mon, 2009-11-30 at 08:35 +0000, Kevin Wright wrote:
>
> On Mon, Nov 30, 2009 at 8:05 AM, Ismael Juma <mlists@juma.me.uk>
> wrote:
>         On Sun, 2009-11-29 at 23:51 +0000, Kevin Wright wrote:
>         >
>         > It's true that this would probably be impossible via
>         bytecode, on the
>         > JVM
>         > (indeed, it's already impossible to truly enforce access
>         modifiers and
>         > final fields)
>
>         You can enforce it with a security manager.
>
> Granted :)
>
> But that's a serious amount of overhead, and I'd still argue that the
> JVM is only helping enforce the security policy and not constness.

Sure, I never said anything about constness.

Just correcting the statement that access modifiers and final fields
can't be enforced in the JVM. They can.

Yes, the JVM will enforce the manager which will in turn enforce modifiers. But I've torn my hair out over the security manager far too many times, and I'm not entirely sure that I trust it to be doing what I think it's doing.


 

Best,
Ismael

On Mon, 2009-11-30 at 09:03 +0000, Kevin Wright wrote:
> (out of curiousity, does anyone know a good alternative to "variable"
> for something that can't vary? Member doesn't feel quite right)

Value?

Ismael

Kevin Wright wrote:
>
> Constness/Purity becomes part of the type signature for that
> member/function, so it's a const Foo, not just a Foo
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#...

Carry on :)

On Mon, Nov 30, 2009 at 9:19 AM, Ismael Juma <mlists@juma.me.uk> wrote:

On Mon, 2009-11-30 at 09:03 +0000, Kevin Wright wrote:
> (out of curiousity, does anyone know a good alternative to "variable"
> for something that can't vary? Member doesn't feel quite right)

Value?

Value would be perfect if it didn't also carry the meaning "not a reference" (as in AnyVal / AnyRef)
Still, it's the best we've got :)
 

Ismael