So many ways to handle errors ...

[Bruce Eckel]

I have been struggling with all the different ways that Scala seems to have for error handling, and now in 2.10 scala.util.Try has been added. I'm starting to get the impression that there's been a *lot* of experimenting around error handling in Scala. Experimenting is a good thing, but now there seem to be lots of skeletons lying about, and blogs and documentation about using things that are maybe now obsolete.

It sort of seems like scala.util.Try is supposed to be a replacement for other things, such as Either (I've read some comments to that effect). But does that mean you should also use Try instead of Some? No clue.

And I've come across a number of examples that use "catching()" which now seems to have fallen out of favor. Again, is Try supposed to replace this? And what about the conventional try-catch -- is Try for all those cases too, or are there still situations where it survives?

It feels like maybe they are still experimenting too fast to settle down and write seriously about it -- so far I've only come across rather dense and brief examples of the various approaches, and from looking at the Scala Doc it seems like there's a lot more that you can do that isn't shown in examples.

It feels like the experiment is still moving forward so quickly that no one has sat down and documented what succeeded and failed, and what you should use and what  you shouldn't use.

So I'm left to sort through the bones and try to figure out what they mean for regular programmers to use. It's a situation where you need to have enough deep knowledge that you can tell people what the simple choices are.

What I'd love to get from this question is a list of what to use and where to use it. So, "in this situation, use this approach for error handling." All help, history, explanations are appreciated. Thanks!

[Adam Shannon]

I think they all serve useful and distinct purposes, and it can be a
mis-step to assume they all are for the same purpose.

Either is a nice way to return one of two values, suppose:

def updateOrAffirm[A](thingToUpdate: A): Either[Boolean, A]

This case would be where you need to know if set of rows was updated
or already existed. You could easily fold over the result and perform
different actions based on the result.

Option[_] is very useful for optional parameters. Take for example
building messages that travel across the network. You won't always
need to specify all parts of a message (and probably won't for
performance if you don't have to)! This way you can build messages
that only need what they require.

Try is a nice way to abstract over failure, many times which is not
your fault. Yes, it basically wraps the block in a try/catch, but it
does provide a nice abstraction over it. For example, you can use its
Success/Failure case classes as the result of a function its self
(without using the object Try).

def validEmail(email: String): Try[String]

This could be very useful in GUI applications to either return the
error message back onto the screen, or further process the given email
address.

Yes, I don't doubt that its annoying how these items can seem so
interrelated, but I think these structures really shine in their own
way. Also, it only gets worse as you go on, I can easily see confusion
of Failure[_] being thought of as a "validation" (it hasn't completed,
so it's still failure), or scalaz's Validation[_], etc.. I actually
like the pace that it's moving at.

--
Adam Shannon
Developer
University of Northern Iowa
Junior -- Computer Science B.S. & Mathematics
http://ashannon.us

[Bruce Eckel]

I agree with experimentation being better than deciding early on an approach and stubbornly sticking with it (ala Java).

But for example I've read comments to the effect that Either should be replaced by try (this was by Shannon someone, one of the library maintainers, and she did go ahead and replace Either with Try in the library she was talking about). And Try has so many different variations that it does appear to be able to replace a number of the previous approaches to error handling (including catching(), it seems). I'm trying to figure out which ones. I'm pretty sure that *all* the approaches that have been introduced are not still the "best practices" based on what I've been reading.

-- Bruce Eckel

www.AtomicScala.com
www.Reinventing-Business.com
www.MindviewInc.com

[Adam Shannon]

So, if Try is taking off and becoming a de-facto standard way of
handling errors isn't that a good thing? Perhaps now Either can be
used for other (more understandable or appropriate) use cases?

I welcome new structures which can replace older ones where they seem apt to.

[Bruce Eckel]

Yes, I think it's a good thing. If it's true. Which is what I'm trying to figure out.

-- Bruce Eckel

www.AtomicScala.com
www.Reinventing-Business.com
www.MindviewInc.com

[Rex Kerr]

Either is whenever you need either of two things, including error condition or valid result.  If the error condition happens to be a thrown exception, use Try instead (it's got a bunch of convenience methods for this, and packages the exception automatically).  If you only want to catch some exceptions and let the rest pass through, use catching; Try will catch everything.

  --Rex

[martin odersky]

Indeed, the idea is that Try should be used instead of Either for error handling. 

Either is not specific in the types it handes, so using it to encapsulate a possible exception is overgeneralization. Because Either is symmetric and generic, people made different decision where the exception part of an Either should go (in its type parameters). Should it go first (because Right sounds like "Correct" and Left by analogy is "False")? Or should the regular result go first and the exception go second? People have used both conventions, which is confusing. Another problem with Either is that, because of its symmetry it lacks nice and natural composition operations such as flatMap.

So I believe if we want to have a widespread use of the new Futures, as used in Play, Akka, Finagle, and if we want them to be easily accessible also from Java programs, Try is a better choice than Either.

Either is still a fundamental type, i.e. the dual of Pair. So I see no reason to remove it. It's just that error handling is an important and more specific subject that deserves a specific type.

Cheers

 - Martin

--
Martin Odersky
Prof., EPFL and Chairman, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

[Rob Dickens]

Martin,

Regarding Either, it sounds like you're against adding the
right-biased capability then; okay, but other changes had been
suggested as well though - am I right in thinking (hoping!) these
haven't been dismissed, but will be considered for inclusion in a
later release (after 2.10 final)?

Rob

[Josh Suereth]

Also, Try and util.control.Exception should probably be unified.  I think that was an oversight.   Try is coming in from Twitter.  util.control.Exception is what we all used before its existence, and still has some nicer features.

What you're seeing could be akin to "experimentation" but I like to think of it as "progress".  I'm hoping in 2.11 to get a chance to clean up the standard library (i.e. a ton of deprecations, pointing people at the 'current best practice' way to do things.   Essentially the language has gotten better (macros, anyval, etc.) and we need to move our own standard library in that direction.   That will come, but it's going to take time for full deprecation periods and such.

SO, what you're seeing is essentially the history of 'best practice' in the library.   We should do a better job of cleaning it up and documentating (yes, that's now a word).

- Josh

[√iktor Ҡlang]

On Fri, Aug 17, 2012 at 2:49 PM, Josh Suereth <joshua....@gmail.com> wrote:

Also, Try and util.control.Exception should probably be unified.  I think that was an oversight.   Try is coming in from Twitter.  util.control.Exception is what we all used before its existence, and still has some nicer features.

What you're seeing could be akin to "experimentation" but I like to think of it as "progress".  I'm hoping in 2.11 to get a chance to clean up the standard library (i.e. a ton of deprecations, pointing people at the 'current best practice' way to do things.   Essentially the language has gotten better (macros, anyval, etc.) and we need to move our own standard library in that direction.   That will come, but it's going to take time for full deprecation periods and such.

SO, what you're seeing is essentially the history of 'best practice' in the library.   We should do a better job of cleaning it up and documentating (yes, that's now a word).

Also, don't forget the scala.util.control.NonFatal (which Try uses internally) to avoid catching things that aren't meant to be caught.

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Bruce Eckel]

I just noticed there's another point of confusion:

In 2.10 we now have

scala.util.Try

But we also have from a previous version:

scala.util.control.Exception.Try

On first glance, the latter appears to have at least a little in common with the former.

Is scala.util.Try intended to replace scala.util.control.Exception.Try?

-- Bruce Eckel

www.AtomicScala.com
www.Reinventing-Business.com
www.MindviewInc.com

[Josh Suereth]

This should be enlightening: https://github.com/scala/scala/pull/1165

Thanks for reminding us of the issue!   This (hopefully) will push with M7 today.

scala.util.Try is for composing behavior, ignoring exceptions.   scala.util.control.Exception is for composing exception handling blocks, and then feeding behavior.

Try is more likely to be used in 80% of cases, but I'm  a user of the later, and it's nice when needed.   The above patch hopefully illustrates how to blend the two.   scala.util.control.Exception is about *choosing* which exceptions can be caught and deferred.  Try attempts to do it for you.

- Josh

[Bruce Eckel]

That is helpful, thanks. Are either Try and/or Exception reasonable substitutes for handling Some/None?

Also, what about scalaz.Validation? Is this "just an alternative" way to deal with errors? Or is it, essentially, a testing ground for concepts that might eventually move into the standard Scala distribution.

Thanks.

-- Bruce Eckel

www.AtomicScala.com
www.Reinventing-Business.com
www.MindviewInc.com

[√iktor Ҡlang]

On Mon, Aug 20, 2012 at 9:18 PM, Bruce Eckel <bruce...@gmail.com> wrote:

That is helpful, thanks. Are either Try and/or Exception reasonable substitutes for handling Some/None?

Option: Some/None is for signaling presence/absence

Try: Success/Failure is for signaling success/failure

[Bruce Eckel]

My reading was that Option was for preventing null pointer exceptions by converting the result of using a potentially null pointer into Some or None. I assume Try has some way to deal with null pointers -- is it special or just another exception?

-- Bruce Eckel

www.AtomicScala.com
www.Reinventing-Business.com
www.MindviewInc.com

[Josh Suereth]

Yeah, so here's a bit from my thoughts on them:

(1) util.control.Exception is about defining *catch* blocks and composing them.

(2) util.Try is about threading a computation and worrying about NonFatal failures at the end.  Specifically, JVM exceptions.  You have to embedd lots of try-catch special logic for this.

(3) Validation is about doing a bunch of things and *aggregating the error messages*.  This is useful when doing form validation for instance.  It doesn't know/care about JVM exceptions, but you can find ways to encode them in functions or make "impure" functions "pure".

I haven't seen anything to unify the (3) design goals in a nice elegant fashion.   I personally like each enough to warrant their existence, but I'd love to find a way to unify some of these goals into a coherent interface.   

Specifically, when I use Validation (for my cases) I'm aggregating error messages and I don't want to generate stack traces that come with Exceptions.   That's why Validation shouldn't default to assuming Exceptions.

Hope that helps!

- Josh

[Josh Suereth]

Option won't deal with null pointer exceptions, they'll be thrown.  Option(null) will return a "None" instance, and if you avoid calling 'get' you can avoid most null pointer exceptions.

Try( <something that throws NPE>) will return a  "Failure(NPE)", similarlly to how Option(null) returns "None".  You get a "Null" case, but it's certainly different.  Using Option you can prevent NPE from being generated.  Using Try, the stack trace is made and thrown.

- josh

[Daniel Sobral]

On Mon, Aug 20, 2012 at 4:26 PM, Bruce Eckel <bruce...@gmail.com> wrote:
> My reading was that Option was for preventing null pointer exceptions by
> converting the result of using a potentially null pointer into Some or None.

More or less. Actually, *null* is widely used to indicate
presence/absence, though sometimes it's also used to indicate
success/failure (particularly in C). So you'd use Option if you happen
to be using null that way, and Try if you happen to be using null the
other way.

--
Daniel C. Sobral

I travel to the future all the time.

[Rodrigo Cano]

So, given this new Try class, shouldn't the Promise class use it instead of Either?

[Rodrigo Cano]

Ha!, I just realized it was actually replaced with it. Nevermind.

[Richard Wallace]

This is a falsity promoted by people that don't really understand the
Maybe/Option type. Don't let yourself be fooled by them.

[martin odersky]

On Tue, Aug 21, 2012 at 5:26 AM, Richard Wallace <rwal...@thewallacepack.net> wrote:

This is a falsity promoted by people that don't really understand the
Maybe/Option type.  Don't let yourself be fooled by them.

This comment comes across as pompous and unhelpful. Please avoid this style of debate in the future.

Thanks

 - Martin

[Tony Morris]

On 21/08/12 20:13, martin odersky wrote:
> On Tue, Aug 21, 2012 at 5:26 AM, Richard Wallace <
> rwal...@thewallacepack.net> wrote:
>
>> This is a falsity promoted by people that don't really understand the
>> Maybe/Option type. Don't let yourself be fooled by them.
>>
> This comment comes across as pompous and unhelpful. Please avoid this style
> of debate in the future.
>
> Thanks
>
> - Martin

Contrary to the belief of a few, this kind of comment has been proven to
be useful for many people in many contexts on many occasions.

It might be blunt or abrasive or what-not, but it is definitely,
unequivocally, undeniably, demonstrably very very helpful. One just has
to come to terms that not all people think the way one might and accept
that it can indeed be very helpful.

If the comment is not welcome, it might be better phrasing as, "comments
that come across to me as pompous and unhelpful should be avoided..."

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

[Rex Kerr]

To unpack Martin's comment, whose sentiment I agree with, one might say:

This style of comment is perceived by a sufficiently large fraction of readers as being pompous and unhelpful, due to its dismissive tone and lack of actionable information.  In particular, if one does not really understand the Maybe/Option type, this post will not help you become any better informed.

Those readers who benefit from such messages--seeing them as informational and an invitation to look into the topic in more depth on their own--are sufficiently rare that the benefit to them is outweighed by the negative impression made on everyone else.  These people will be equally well served by a post with a less abrasive tone, such as

"""
Maybe/Option is used for more than just null handling, though people who are less familiar with Maybe/Option can become too fixated on this aspect of their use.  For a more complete picture, see
  // Whatever it was you were thinking of
Also, for a good exposition on why and how to use Option "instead of null", see
  http://james-iry.blogspot.com/2010/08/why-scalas-and-haskells-types-will-save.html
"""

If you want to actually be helpful, a post like this is required.  If one is not posting the shorter snarkier comment to be helpful, why post it at all?

  --Rex

P.S. Keep in mind that if you say something that someone finds helpful they will contact *you* about it.  If you say something that someone finds abrasive, they are more likely to contact *a moderator/superior figure* about it or simply drop off the mailing list.  So if you count how positive posts are by positive feedback, keep in mind you may have a terrible sampling bias.

[Bruce Eckel]

Thanks for all that, including the helpful links.

As someone who has been involved in programming pre-internet, I've seen a lot of this and have somewhat thickened my skin about these things. However, I always find it a breath of fresh air to interact with the online Python community, which has tried from the beginning to discourage ... aggressive commenting ... and to encourage helpful and gentle replies. I'm still not certain just how Guido managed to do that, but it is a model of what I'd like to see in other communities and I applaud those in the Scala community who are trying to set the example. It's time for "regular adopters" (as opposed to early adopters) to join the ranks and they need a friendlier environment; the language is challenging enough without feeling like the community is hostile towards the un-initiated.

-- Bruce Eckel

www.AtomicScala.com
www.Reinventing-Business.com
www.MindviewInc.com

[Naftoli Gugenheim]

On Mon, Aug 20, 2012 at 3:26 PM, Bruce Eckel <bruce...@gmail.com> wrote:

My reading was that Option was for preventing null pointer exceptions by converting the result of using a potentially null pointer into Some or None.

To expand on what others have said:

In Java when you want to return a value of a certain type but it may not be available, you don't encode the "optionality" in the type; the type is the same as if it was mandatory, just there's a special value for "unavailable," null. The problem with that is that every part of the code has to worry about whether the variable actually holds a value.

Option does not "wrap" that situation but instead offers a different way of thinking about it, preventing those problems from occurring in the first place. Basically you put the "maybe-ness" into the type system, so the compiler does not let you pretend treat a non-existent value as if it's there (you can't call `length` on an Option[String]). Instead, the code that handles the value must be written in a way so that it's clear what happens when there is no value. For instance you can pattern match, which means there are two branches of code, one for when there is a value --- and that branch sees the "definite" type and so can deal with the value directly --- and another branch of code deals with the "unavailable" case. The branches can compute and return a new value (the type of the entire match expression is whatever type is common to both branches). There's also foreach, which is like a pattern match that has no None branch, and doesn't return a new value, and map, which does return the value but packages it in a new Option.

[Josh Suereth]

On Tue, Aug 21, 2012 at 10:52 AM, Tony Morris <tonym...@gmail.com> wrote:

Tony - 

There  are far better ways to teach people than using condescension and/or elitism.   That is the way of cults, and I think we should have more respect for other's intelligence.  One could read this comment in many different voices, but the pattern has been that of "we know better than you do".   Challenging people's beliefs can be done in a constructive/non-threatening way.   If someone is unwilling to listen to a reasoned voice, using bullying or "us vs them" to challenge their beliefs works only on a limited subset of people.   It's a sociological technique *not* welcome on this, or other scala mailing lists.

I think it's more important to have your message / ideas reach as many as possible.   If you want to use that tactic on individuals on other forums, that's fine.   Please do not do so on the public mailing list.

Note:  I learned *a lot* from you, and most of it was done without the outlined technique.   If someone is not ready to listen to what you have to say, I do not think these comments will make them ready any earlier, and will drive away others.   It is not welcome in this community.   HOWEVER, the ideas, thoughts and paradigms, teaching, learning, new ways of thinking *are* welcome.   We want everyone to be able to freely express ideas and to have the community grow.   FP has a lot to teach everyone, but this is not the way to do that.   

- Josh

[Tony Morris]

On 23/08/12 18:13, Josh Suereth wrote:
> On Tue, Aug 21, 2012 at 10:52 AM, Tony Morris <tonym...@gmail.com> wrote:
>
>> On 21/08/12 20:13, martin odersky wrote:
>>> On Tue, Aug 21, 2012 at 5:26 AM, Richard Wallace <
>>> rwal...@thewallacepack.net> wrote:
>>>
>>>> This is a falsity promoted by people that don't really understand the
>>>> Maybe/Option type. Don't let yourself be fooled by them.
>>>>
>>> This comment comes across as pompous and unhelpful. Please avoid this
>> style
>>> of debate in the future.
>>>
>>> Thanks
>>>
>>> - Martin
>> Contrary to the belief of a few, this kind of comment has been proven to
>> be useful for many people in many contexts on many occasions.
>>
>> It might be blunt or abrasive or what-not, but it is definitely,
>> unequivocally, undeniably, demonstrably very very helpful. One just has
>> to come to terms that not all people think the way one might and accept
>> that it can indeed be very helpful.
>>
>> If the comment is not welcome, it might be better phrasing as, "comments
>> that come across to me as pompous and unhelpful should be avoided..."
>>
>>
> Tony -
>
> There are far better ways to teach people than using condescension and/or
> elitism.

That's the thing, there was no condescension. That others might perceive
this is because if they had used these words, that's what they would be
intending. This is a projection bias and it gives away *an awful lot*
about a person when they do this. Richard's original words alone do not
project condescension in any way at all and you'll notice any effort to
demonstrate otherwise falls flat on its face -- go on try it -- no
handwaving or I will call bullshit.

I've had this discussion on this list way too many times. In short, the
charge here to Richard and his words is thought crime -- it is without
substance and it is extremely offensive to intellectual discourse. There
are some very narrow-minded person(s) who seem intent on failing to
figure out that Richard's comment is in fact, not condescending and in
many contexts, is very useful. I am happy to leave it at that because I
am quite convinced this will not change, but do expect that many
thinking people will take offence to this disgusting discourse either
vocally (as I do) or not (as many choose). I will defend Richard and his
words and many will, silently or not.

As for elitism, I am firmly in favour of embracing it and I harbour
resent for any suggestion that I should do anything else. There are some
great essays on how repulsive this trend of shunning elitism is. I will
leave it at that for now -- happy to help you break out of that one.

> That is the way of cults, and I think we should have more
> respect for other's intelligence. One could read this comment in many
> different voices, but the pattern has been that of "we know better than you
> do". Challenging people's beliefs can be done in a
> constructive/non-threatening way. If someone is unwilling to listen to a
> reasoned voice, using bullying or "us vs them" to challenge their beliefs
> works only on a limited subset of people. It's a sociological technique
> *not* welcome on this, or other scala mailing lists.

Bullcrap, you're off on a wild one here. It is words that have a meaning
in a language, nothing more. Again, some narrow-minded person(s) might
decide to project their ulterior motivations onto those words -- that is
*not my (or anyone else's) problem*. If these people are not able to
adjust their thinking to a more honest approach to problem-solving, then
I cannot help them. I can help others though, especially readers of
Richard's original words and Richard himself (though I am sure he gives
less of a fuck about this ongoing garbage than I do right Richard?).

>
> I think it's more important to have your message / ideas reach as many as
> possible. If you want to use that tactic on individuals on other forums,
> that's fine. Please do not do so on the public mailing list.
>
> Note: I learned *a lot* from you, and most of it was done without the
> outlined technique. If someone is not ready to listen to what you have to
> say, I do not think these comments will make them ready any earlier, and
> will drive away others. It is not welcome in this community. HOWEVER,
> the ideas, thoughts and paradigms, teaching, learning, new ways of thinking
> *are* welcome. We want everyone to be able to freely express ideas and to
> have the community grow. FP has a lot to teach everyone, but this is not
> the way to do that.
>
> - Josh
>

You genuinely think I haven't quite worked out how to teach and you
genuinely think you can provide me good advice. I appreciate it -- I
truly do. I genuinely adore your good intentions. They are just
misguided. Don't take it personally, please.

You truly think that "nobody listens" because I might say "fuck" or I
might use abrasive terms or in this case, I am defending Richard
Wallace's clear statement of fact. You just have it all wrong and that
is fine with me. This is not the place to discuss it though if you'd
like to truly understand why don't you think?

Don't fall into the trap that you have been invited to. I have long
given up on these mailing lists having any reasonable discourse, but
please at least let Richard say his words without having to put up with
this repeatedly disgusting behaviour simply because one has their head
stuck where it does not shine so bright. It is not fair to Richard and
it is not fair to any potential audience of his words.

Personally, I find this ongoing nonsense completely repulsive. Just let
it be and stop thinking you have it all worked out -- you do not, I know
this, and come to mention it, *lots* of people know this. I am sure some
of you guys think I am the nutter on my lonesome who harbours these
terrible feelings, described by four letter words. I find this thought
fucking hilarious, but also wildly wrong -- I am just more vocal than
most possibly because I just do not care. Please think. Seriously. Stop
taking offence and consider the possibility that you guys haven't got it
quite worked out as much as you think you do and that I am not as
"alone" as you think I am (again, just more vocal).

I only intended to defend Richard and his clear statement of fact
against this ongoing disgusting behaviour on these lists. I do not
intend to continue this discussion on this list if that is OK with you.
It doesn't belong here and I doubt it will be constructive.

The mailing list operators genuinely think they have it all worked out
and there is bugger-all I can do about it. Peace to strong intellectual
sentiment, elitism and making a whole load of fucking sense.

[Dennis Haupt]

any human has to accept two facts to level up:
* there are people who have a much deeper knowledge of some things
* you don't know what you don't know - but someone else might

in my opinion, knowing that there is something you don't know is as valuable as getting told something new directly . yes, that information can be presented in a nicer way than saying: "the one who said this does not fully understand the possibilities of the underlying concept". but the one hearing this could also try not to interpret it as "you are stupid" but as "take a closer look at this". i never felt offended by elitism. i accept the fact that there might be *large* differences in the quality/quantity of knowledge and skill one could acquire and one might have at the moment.

-------- Original-Nachricht --------
> Datum: Thu, 23 Aug 2012 20:23:18 +1000
> Von: Tony Morris <tonym...@gmail.com>
> An: Josh Suereth <joshua....@gmail.com>
> CC: scala-...@googlegroups.com
> Betreff: Re: [scala-debate] So many ways to handle errors ...

[Josh Berry]

On Thu, Aug 23, 2012 at 8:27 AM, Dennis Haupt <h-s...@gmx.de> wrote:
> in my opinion, knowing that there is something you don't know is as valuable as getting told something new directly . yes, that information can be presented in a nicer way than saying: "the one who said this does not fully understand the possibilities of the underlying concept". but the one hearing this could also try not to interpret it as "you are stupid" but as "take a closer look at this". i never felt offended by elitism. i accept the fact that there might be *large* differences in the quality/quantity of knowledge and skill one could acquire and one might have at the moment. of you guys think I am the nutter on my lonesome who harbours these

There is also the entirely effective and large fields of propaganda
and advertising that show delivery matters. To believe otherwise
seems just as foolhardy as the alternative. That is, the message of
"please think. Seriously, stop posting messages that are easily
construed as offensive" is just as valid as "Please stop taking
offence." More so, as the actor in the former is proclaiming (often
rightly so) superior knowledge.

Could there be an ideal world where delivery was less important? I
certainly wish it were so. If the belief is that one can browbeat
people into that world, have at it. There seems to be little evidence
of that compared to the contrary, though.

Of course, I'm writing this as an outsider, so fully expecting to get
(rightly) lambasted here. When does the term idiocy actually kick in?
:)

[Chris Twiner]

Right about the time that I criticise you all for a lack of judgement
in replying, thereby showing my lack of judgement :-)

still I agree, its all about group differences here, a large
percentage respond to Tony's brevity, another likely larger segment is
"positively" turned off by it :-), many other little segments of
behaviour and perceptional differences and finally the group I belong
to, which finds it entertaining - more often than not refreshing, but
not largely affected by it one way or another.

The tone doesn't do him any favours, but at the risk of being elitist
or daring to improve myself - the underlying message still has worth,
as did Richards comments. Same token applies to all the other
replies.

I'd add however - before I duck and cover - one key phrase that Rex
mentioned: lack of actionable information, without that its going to
reach even less people.

[Bruce Eckel]

But couldn't you then say that by dealing with the representation of the result via the maybe-type rather than "an object or a null" you prevent NPEs? Or at least put up another wall against them?

-- Bruce Eckel

www.AtomicScala.com
www.Reinventing-Business.com
www.MindviewInc.com

[Daniel Sobral]

On Thu, Aug 23, 2012 at 12:11 PM, Bruce Eckel <bruce...@gmail.com> wrote:
> But couldn't you then say that by dealing with the representation of the
> result via the maybe-type rather than "an object or a null" you prevent
> NPEs? Or at least put up another wall against them?

You prevent NPEs if you do not use them, nor use any libraries that
use them. If you avoid them in your own code and firewall external
APIs against them, you reduce the chance of them happening (depending
on how complete the firewalling was).

Now, Option replaces one of the use cases for nulls, which makes it
easier to avoid nulls in your code, and, thus, prevent NPEs. But it's
not using Option that is reducing the chance of NPEs, it is not using
nulls that's doing that.

[Dennis Haupt]

once you start investing energy into the delivery itself instead of the pure content of the message, you might be more successful - but you're also no longer seeing the recipient as a being that can think for itself. you are seeing it a an automaton that you can manipulate if you just deliver the correct input.

in a way, tony's way is actually *more* respectful than packaging the message nicely to convince more people. he's saying "i give you some facts, now think or stay ignorant" instead of mixing facts while also trying to please the audience.

i never liked commercials. i tend to not buy the things they try to sell because they try to make me associate positive feelings with their products, which is a totally obvious act of de-respecting me.
-------- Original-Nachricht --------
> Datum: Thu, 23 Aug 2012 09:46:28 -0400
> Von: Josh Berry <tae...@gmail.com>
> An: scala-...@googlegroups.com

> Betreff: Re: [scala-debate] So many ways to handle errors ...

[Luke Vilnis]

I'm not really sure why it's somehow controversial to tell people to mind their manners. It's not a question of pedagogical style - if you're going to speak to other people, be polite. That's just the bare minimum expectation of civility. Knowing more about a topic (or thinking you know more) than others is not an excuse for rudeness. There is nothing "respectful" about being rude to people. Being polite is not an attempt to manipulate someone, it's just the way that people are supposed to talk to each other...

[Richard Wallace]

"p is not true." is rude? Please explain.

[Dennis Haupt]

imho, one should just state facts and back them up if necessary. that is all.

-------- Original-Nachricht --------
> Datum: Thu, 23 Aug 2012 11:47:46 -0400
> Von: Luke Vilnis <lvi...@gmail.com>
> An: Dennis Haupt <h-s...@gmx.de>
> CC: Josh Berry <tae...@gmail.com>, scala-...@googlegroups.com

[Russ P.]

On Thursday, August 23, 2012 8:49:34 AM UTC-7, Richard Wallace wrote:

"p is not true." is rude?  Please explain.

The reason it comes across as rude to some is that, simply asserted, it provides no explanation of *why* "p is not true," nor does it explain what *is* true in this particular context. The lack of any explanation implies that the original statement, "p is true," is not just wrong but is so wrong that it is not even worth discussing. Another possible interpretation is, "just believe me because I am smarter than the people who believe otherwise." Yet another is, "I don't have time for this crap." Well, if you don't have time to explain why "p is not true," then perhaps you shouldn't simply assert it.

--Russ P

http://RussP.us

 

[Tim Pigden]

There is a difference between "p is not true" and "p is a falsity promoted by people who do not understand ..."

The former is a comment on p alone, the latter is also a comment about other people and their actions.

[Rob Dickens]

Bruce,

I'm pretty sure that Option only prevents NPEs arising from
*forgetting to check* that a value (that is sometimes intentionally
null) is not null, before dereferencing it.

So if you substitute Option[T] for T, the compiler will complain if
you try to use a T. (You are confronted with the fact that the value
is optional, so there's no danger of forgetting this.)

However, what Option can't prevent are NPEs arising from *the value
being null*, since values of type Option[T] can also be null!

There was a discussion about this a long time ago, entitled 'Option
under fire', on scala...@listes.epfl.ch, whose archive doesn't
appear to be available any longer unfortunately.

Rob

[Richard Wallace]

Right, but it's only a difference between saying "p is false" and "p
is false and q is true". Unless the issue is that I am claiming
something is true second part of that statement that is false - in
which case, I am simply incorrect, not being rude - I don't see where
the problem is.

[pagoda_5b]

Totally agree.

 

On Thursday, August 23, 2012 5:47:46 PM UTC+2, Luke Vilnis wrote:

I'm not really sure why it's somehow controversial to tell people to mind their manners. It's not a question of pedagogical style - if you're going to speak to other people, be polite. That's just the bare minimum expectation of civility. Knowing more about a topic (or thinking you know more) than others is not an excuse for rudeness. There is nothing "respectful" about being rude to people. Being polite is not an attempt to manipulate someone, it's just the way that people are supposed to talk to each other...

 

This is for Tony, Richard, Dennis and all the others that are "disgusted" by people reacting badly to their "attitude" on a public mailing lists:

let's face it, you're not just being "honest", "straight to the point" or whatever you think, you're being simply antisocial and rude.

Take it for a fact that most people don't like such manners of communication, especially if you're not an acquaintance.

Since I don't know you personally, even though I have a high opinion of your expertise regarding computer science, math, scala, functional programming etc., I certainly don't have to listen to you speaking rudely or without regards for the target of your discussion. And I think that many others don't.

It's just a matter of caring for the listener, which leads to putting more effort in the way a person exposes his theories and beliefs, being attentive to the possible audience, and not just stating something matter-of-factly, simply because he believes it's true.

For what I care, Richard's comment is just his opinion, and I don't have to take his assertions for granted simply because he's so sure of his stuff.

As already stated, some explanation and reference to a convincing proof of what is asserted helps most if you want to be taken seriously. Otherwise most people will simply take you for someone who thinks he's convincing just because he shouts louder.

Tony, of course I think you've been through such discussions already, because I, just like so many others, am one of those "narrow-minded" person.

In fact I really appreciated many of your works and presentation and I'm not that annoyed by your manners in such discussions as this, but I simply wanted to share that you're totally off track on judging people's reactions, probably because you're too proud to care, and I have no intention to try to change you or any other.

And almost certainly I won't comment anymore on this.

Have a nice day

Ivano

[Matthew Pocock]

On 23 August 2012 17:38, Tim Pigden <tim.p...@optrak.com> wrote:

There is a difference between "p is not true" and "p is a falsity promoted by people who do not understand ..."

Quoted for truth

 

The former is a comment on p alone, the latter is also a comment about other people and their actions.

When writing something where it will be read in public, you are not in control of who will read it or how they will interpret your tone and attitude. They are not you. If you've been told several times that a particular way of expressing yourself is found offensive or offputting, then there's no point claiming that it is not, or using your own standards as a defence, because it has already been brought to your attention that certain styles are found offensive. It's common courtesy, in that case, to take reasonable steps not to continue to write things in this same style that you now know will be found offensive.

Matthew

 

--

Dr Matthew Pocock

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

mailto: turingate...@gmail.com

gchat: turingate...@gmail.com

msn: matthew...@yahoo.co.uk

irc.freenode.net: drdozer

skype: matthew.pocock

tel: (0191) 2566550

mob: +447535664143

[HamsterofDeath]

i apologize if i came across as rude. i did not intent to do that.

[Rob Dickens]

>> archive doesn't appear to be available any longer
>

> http://scala-programming-language.1934581.n4.nabble.com/Option-under-fire-td2315004.html

Thanks! Couldn't find this via http://www.scala-lang.org/node/199

On Thu, Aug 23, 2012 at 5:44 PM, Chris Twiner <chris....@gmail.com> wrote:
> http://scala-programming-language.1934581.n4.nabble.com/Option-under-fire-td2315004.html

[Josh Berry]

On Thu, Aug 23, 2012 at 11:43 AM, Dennis Haupt <h-s...@gmx.de> wrote:
> once you start investing energy into the delivery itself instead of the pure content of the message, you might be more successful - but you're also no longer seeing the recipient as a being that can think for itself. you are seeing it a an automaton that you can manipulate if you just deliver the correct input.

Nonsense. While I'm personally not a fan of some of Tufte's entire
message, I do think he is spot on here. Taking the time to
persuasively present information is a skill. A valuable one. Why is
it valuable? Because it is a respectful act to the people that you are
trying to persuade. Not everyone has or can be expected to have the
highest level of understanding on a topic. Even among those that
could, many likely have other areas that are more pressing for them,
so they truly do need to be persuaded, and not just presented the
facts. There was a good coding horror blog about this topic, I
believe.

> in a way, tony's way is actually *more* respectful than packaging the message nicely to convince more people. he's saying "i give you some facts, now think or stay ignorant" instead of mixing facts while also trying to please the audience.

But that is the thing, often this presentation is with an aside slight
at another crowd. It is oddly inviting, and I'm sure the people it
connects with have a "I'm in your crowd" feel and do appreciate it a
lot. Others will see "partisan programming" and get annoyed/turned
off. This is in spite of the message. Indeed, that is the point.
The emotions elicited here are entirely due to the presentation of the
message, and not the message itself.

> i never liked commercials. i tend to not buy the things they try to sell because they try to make me associate positive feelings with their products, which is a totally obvious act of de-respecting me.

Doesn't matter if you like them or not. I personally avoid them like
the plague. I also am forced to acknowledge that they work. More,
there is very deep science behind why they work. To think you can
somehow sidestep that science because you are smart and your message
is factual is, quite frankly, unscientific. :)

[Richard Wallace]

Don't worry, you didn't.

[Richard Wallace]

> the people that you are trying to persuade.

This is the fundamental disconnect. I can't speak for Tony or anyone
else, but I was not, and am not, trying to "persuade" or "convince"
anyone. I was inviting the to investigate and discover the truth of
things for themselves. I am not trying to "win" or do any other such
nonsense.

[Peter Pnin]

Let me try to summarize the problem:

"p is pompous" AND "p is unhelpful"

in longer form:

"p has the property of being pompous" and "p has the property of being unhelpful"

pomposity and unhelpfulness, when joined together, is the specific "problem" alluded to earlier in the thread.

[Rex Kerr]

On Thu, Aug 23, 2012 at 11:43 AM, Dennis Haupt <h-s...@gmx.de> wrote:

in a way, tony's way is actually *more* respectful than packaging the message nicely to convince more people. he's saying "i give you some facts, now think or stay ignorant" instead of mixing facts while also trying to please the audience.

That doesn't make any sense.  Almost everyone can--in addition to accurately parsing the literal truth of a message--infer many things about tone and attitude based upon choice of words.  Pretending that your readers are unable to understand implication and tone is quite condescending given that most people can.

Now, it is true that some people have genuine difficulty parsing tone out of text or even body language, and it is probably true that such people are overrepresented among programmers since our main job is to tell computers what to do, not other people.  However, if you are capable of doing so and do so poorly it is just as wrong as if you choose unpleasant or ugly color combinations "because" some people are color blind.

i never liked commercials. i tend to not buy the things they try to sell because they try to make me associate positive feelings with their products, which is a totally obvious act of de-respecting me.

Of course, people will use every channel available to try to get you to do things.  They'll show appealing images, say words with appealing literal meaning, phrase them with appealing tone, deliver appealing odors if possible, etc..  Closing information channels because people try to use them to get you to do stuff is not a winning proposition.

One thing you can say is that some inputs are higher reliability than others.  For example, it is easier to detect a line of equals symbols:
   =========================================
than it is to detect a subtle insult (omitted for brevity this time).

This doesn't mean that you should avoid considering the tone, but it does mean that when someone chooses the wrong tone you might want to give them the benefit of the doubt about whether they meant exactly what you thought they did.  However, the corollary is not that you can use whatever arrogant or dismissive or hostile tone you want and people should deal, but that you should put a little extra effort into making your tone clear because it is a slightly lower-fidelity signal that people will be interpreting.

Plus, paying a little attention to tone spares us all from conversations like this one that distract from learning something interesting, writing some useful code, etc..

  --Rex

[Richard Wallace]

On Thu, Aug 23, 2012 at 11:51 AM, Rex Kerr <ich...@gmail.com> wrote:
> That doesn't make any sense. Almost everyone can--in addition to accurately
> parsing the literal truth of a message--infer many things about tone and
> attitude based upon choice of words. Pretending that your readers are
> unable to understand implication and tone is quite condescending given that
> most people can.
>

Oh good. So I get a free pass? Because the only indication that
there was anything rude or offensive in my original statement is
everyone telling me so. No matter how many times I read it, I cannot
find anything that could be misconstrued as insulting to the reader -
unless you are one of the people holding onto the false belief, but I
was not addressing those people.

We can stop talking about this now, right?

Please can we stop talking about this now and talk about useful things?

Please?

[Rex Kerr]

On Thu, Aug 23, 2012 at 2:57 PM, Richard Wallace <rwal...@thewallacepack.net> wrote:

On Thu, Aug 23, 2012 at 11:51 AM, Rex Kerr <ich...@gmail.com> wrote:
> That doesn't make any sense.  Almost everyone can--in addition to accurately
> parsing the literal truth of a message--infer many things about tone and
> attitude based upon choice of words.  Pretending that your readers are
> unable to understand implication and tone is quite condescending given that
> most people can.
>

Oh good.  So I get a free pass?  Because the only indication that
there was anything rude or offensive in my original statement is
everyone telling me so.  No matter how many times I read it, I cannot
find anything that could be misconstrued as insulting to the reader -
unless you are one of the people holding onto the false belief, but I
was not addressing those people.

Well, actually, I can find something without looking very hard:

On Mon, Aug 20, 2012 at 12:26 PM, Bruce Eckel <bruce...@gmail.com> wrote:
> My reading was that Option was for preventing null pointer exceptions by
> converting the result of using a potentially null pointer into Some or None.

On Tue, Aug 21, 2012 at 5:26 AM, Richard Wallace <rwal...@thewallacepack.net> wrote:

This is a falsity promoted by people that don't really understand the
Maybe/Option type.  Don't let yourself be fooled by them.

Is it good to be fooled, or bad?  Especially by something "promoted by people that don't really understand"?  The discerning reader would presumably not be fooled, and would notice that the writer doen't understand what he or she is saying.  Therefore, this is mildly disparaging of whoever you're talking to, given that they were apparently already fooled.

But it is also hostile phrasing in general: one can infer that the clueless are trying to fool people with falsities, which is a rather unkind thing to do, and that you're in a defensive posture against them, rather than trying to work through their misunderstandings, or trying to make it so clear to everyone else what the right thing is that one need not worry about the few who are still babbling about their mistaken impression.  This makes it seem like to agree with you is to step into the middle of something contentious: which side are you on, the falsity-promoting foolers, or my side?  One then has to wonder: wait, if it's a simple matter of correctness, why are there even sides?  What am I getting into here?  If there are "sides", maybe the other side has something good to say in its defense?

There are plenty of other ways to phrase things even if you have decided that you don't want to be so helpful as to include a link to a good treatment of Option-as-more-than-a-null-converter.  For example:

"It's far more useful than that!  You hear this a lot, maybe because it's one obvious way to use it (and some never look deeper than that before writing blogs)."

It's got all the same information--even down to warning about inaccurate posts of others--but phrased in a non-confrontational and positive way.  Better yet,

"They're for much more than that!  Check out http://URL"

or even

"Actually, they're to let types, rather than data, tell you whether a value might not exist, so the compiler can help you remember to deal with the no-data case.  And it provides utility methods that assist you in dealing with each case in a sensible and generic manner--including when a value might be null."

Now not only is there no contention, the reader knows what the right answer is (a less-wrong answer, anyway).  That beats both condescension-aimed-at-third-parties and positive-but-mostly-empty-messages almost every time (when it comes to transforming people from less informed to more informed).

  --Rex

[Alex Cruise]

Let me preface this by saying that I don't feel you've done anything substantially wrong here! :)

 

"This is a falsity promoted by people that don't really understand the Maybe/Option type.  Don't let yourself be fooled by them."

On Thu, Aug 23, 2012 at 11:57 AM, Richard Wallace <rwal...@thewallacepack.net> wrote:
> Oh good.  So I get a free pass?  Because the only indication that
> there was anything rude or offensive in my original statement is
> everyone telling me so.  No matter how many times I read it, I cannot
> find anything that could be misconstrued as insulting to the reader -

What are the odds that your reader might consider herself not to "really understand the Maybe/Option type"?  How could anyone feel neutral about being accused of promoting falsity?

> unless you are one of the people holding onto the false belief, but I
> was not addressing those people.

No, but "those people" are reading.  And they might not agree that their beliefs are false.  When you put things in such black-and-white terms, you erect social barriers against conversation.  You might not care, but a lot of us are concerned that people feel welcome, and comfortable, and free to ask dumb questions, here.  I've asked a lot of dumb questions on the Scala mailing lists, and the answers have almost always been patient, helpful and encouraging.  Jumping into a community with preexisting cultural norms can be frightening.

> We can stop talking about this now, right?
>
> Please can we stop talking about this now and talk about useful things?

We would love to, but these little efflorescences of attitude keep happening, and substantial numbers of us would like them to stop.  Please don't misunderstand me to say that I want you, or Tony, or anyone else, to stop posting.  We just want everyone to moderate their tone, so that hopefully no one will ever have to moderate the lists.

-0xe1a

[Naftoli Gugenheim]

Hmm, how about this: Option prevents NPE (or some of them); Try puts up a wall around them (meaning to say, it wraps them and safely preserves them as data rather than control flow).

[Richard Wallace]

On Thu, Aug 23, 2012 at 12:43 PM, Naftoli Gugenheim
<nafto...@gmail.com> wrote:
> Hmm, how about this: Option prevents NPE (or some of them);

Option is orthogonal to NPEs. Look at a language like Haskell, it
does not have nulls or NPEs, but it does have the Maybe type. It
doesn't have to have the Maybe type, it is just the most generic
solution to the problem.

[Naftoli Gugenheim]

On Thu, Aug 23, 2012 at 6:23 AM, Tony Morris <tonym...@gmail.com> wrote:

That's the thing, there was no condescension. That others might perceive
this is because if they had used these words, that's what they would be
intending. This is a projection bias

Stop right there! Let me try to undertand your argument:

1. Josh S. and everyone else's complaints assume that the speaker (in any of the many instances that spark such discussions) intends or feeld condescension. (implied)

2. However this is a fallacy since in fact there was no condescension.

The counterargument, in a nutshell, is that it's not about what the speaker's actual intention was, but about the feelings he knowingly caused. It doesn't matter if those feelings are due to projection bias. If the speaker is aware that his words will trigger certain feelings, and a lot of people are uncomfortable in a forum where such feelings are triggered, and the forum's policy is that people should feel comfortable --- then it's every poster's job to do his best to prevent that from occurring.

and it gives away *an awful lot*
about a person when they do this.

I'm not sure what you're trying to imply, but it does sound like something that is unwanted on this list.

[Naftoli Gugenheim]

On Thu, Aug 23, 2012 at 3:47 PM, Richard Wallace <rwal...@thewallacepack.net> wrote:

On Thu, Aug 23, 2012 at 12:43 PM, Naftoli Gugenheim
<nafto...@gmail.com> wrote:
> Hmm, how about this: Option prevents NPE (or some of them);

Option is orthogonal to NPEs.  Look at a language like Haskell, it
does not have nulls or NPEs, but it does have the Maybe type.  It
doesn't have to have the Maybe type, it is just the most generic
solution to the problem.

Sure. But in practice it ends up preventing NPEs from happening, since it gives you an alternative way to represent "unavailable" that does not involve null, so you use null less, so the NPEs that hypothetically might have occurred had you used null never happened.

No?

[Naftoli Gugenheim]

You might also say, "Using Haskell instead of Java prevents NPEs." :)

[HamsterofDeath]

hm, that doesn't sound right to me. i would explain it like this:
"option" is a tool for documenting the fact that an object may not exist and for handling that fact - on a level accessible to the compiler and the developer.
if you have a simple type T, you cannot say if a value/var of T can be null or not. you have no guarantee.
if you use Option<T> instead of T, not only does that explicitly state "T might not exist", you also get a lot of methods for handling this case without the usual if != null condition.
*insert some examples using map, foreach and so on here*
"Null" no longer has to be a special case. both cases can be handled without splitting up the control flow.
you can also no longer accidently access a value that might not exist. you have to explicitly extract it by using pattern matching or by calling "get".

the NPE problem vanishes by itself if you simply never use null, you don't need option for that. but option takes away the need for "null replacement objects", so it certainly helps here.

[Richard Wallace]

On Thu, Aug 23, 2012 at 12:54 PM, Naftoli Gugenheim
<nafto...@gmail.com> wrote:
> On Thu, Aug 23, 2012 at 3:47 PM, Richard Wallace
> <rwal...@thewallacepack.net> wrote:
>>
>> On Thu, Aug 23, 2012 at 12:43 PM, Naftoli Gugenheim
>> <nafto...@gmail.com> wrote:
>> > Hmm, how about this: Option prevents NPE (or some of them);
>>
>> Option is orthogonal to NPEs. Look at a language like Haskell, it
>> does not have nulls or NPEs, but it does have the Maybe type. It
>> doesn't have to have the Maybe type, it is just the most generic
>> solution to the problem.
>
>
> Sure. But in practice it ends up preventing NPEs from happening, since it
> gives you an alternative way to represent "unavailable" that does not
> involve null, so you use null less, so the NPEs that hypothetically might
> have occurred had you used null never happened.
> No?
>

Correct, but saying that Option is intended to prevent NPEs is
misleading. This is a nice side-effect, but it is not the intent.
Better to say that it, "Encodes the possible presence or absence of a
value in the type system. If used in where `null` might have been
used in other languages, this prevents you from running into NPEs in
your own code."

But it's important to emphasize that this is not the primary purpose
of Option because that is misleading.

[HamsterofDeath]

Am 23.08.2012 21:54, schrieb Naftoli Gugenheim:

On Thu, Aug 23, 2012 at 3:47 PM, Richard Wallace <rwal...@thewallacepack.net> wrote:

On Thu, Aug 23, 2012 at 12:43 PM, Naftoli Gugenheim
<nafto...@gmail.com> wrote:
> Hmm, how about this: Option prevents NPE (or some of them);

Option is orthogonal to NPEs.  Look at a language like Haskell, it
does not have nulls or NPEs, but it does have the Maybe type.  It
doesn't have to have the Maybe type, it is just the most generic
solution to the problem.

Sure. But in practice it ends up preventing NPEs from happening, since it gives you an alternative way to represent "unavailable" that does not involve null, so you use null less, so the NPEs that hypothetically might have occurred had you used null never happened.

No?

using options instead of null, but leaving everything else as it is, just replaces NPEs by some other exception that is thrown if you call get on None.

[Richard Wallace]

On Thu, Aug 23, 2012 at 12:52 PM, Naftoli Gugenheim
<nafto...@gmail.com> wrote:
> On Thu, Aug 23, 2012 at 6:23 AM, Tony Morris <tonym...@gmail.com> wrote:
>>
>> That's the thing, there was no condescension. That others might perceive
>> this is because if they had used these words, that's what they would be
>> intending. This is a projection bias
>
>
> Stop right there! Let me try to undertand your argument:
> 1. Josh S. and everyone else's complaints assume that the speaker (in any of
> the many instances that spark such discussions) intends or feeld
> condescension. (implied)
> 2. However this is a fallacy since in fact there was no condescension.
>
> The counterargument, in a nutshell, is that it's not about what the
> speaker's actual intention was, but about the feelings he knowingly caused.
> It doesn't matter if those feelings are due to projection bias. If the
> speaker is aware that his words will trigger certain feelings, and a lot of
> people are uncomfortable in a forum where such feelings are triggered, and
> the forum's policy is that people should feel comfortable --- then it's
> every poster's job to do his best to prevent that from occurring.

What if the speaker didn't knowingly cause these feelings. These
feelings are purely a byproduct of the readers mental state? I think
this is where I become most confused as I can't possibly know what
will cause these feelings in anyone, much less _everyone_.

[Richard Wallace]

On Thu, Aug 23, 2012 at 1:05 PM, HamsterofDeath <h-s...@gmx.de> wrote:
>
> using options instead of null, but leaving everything else as it is, just
> replaces NPEs by some other exception that is thrown if you call get on
> None.
>

Sure, I didn't stipulate that you need to use Option correctly, but it
was assumed you wouldn't use `get`.

[Tony Morris]

You guys genuinely fail to realise how many people (of very high quality intellectual discussion) refuse to use the scala mailing lists because of these ridiculous, offensive, disgusting, soft attitudes toward intellectualism. The funny part comes when I am bombarded with lectures on how to "stop scaring people away" or rewording so that "your audience would be more receptive." What a joke. Seriously, you have no idea how fucking hilarious that is, to me anyway.

Richard just happened to pop his head out of a hole; many others are not so brave. Heads back in the sand now.

On Aug 24, 2012 1:49 AM, "Richard Wallace" <rwal...@thewallacepack.net> wrote:

"p is not true." is rude?  Please explain.

On Thu, Aug 23, 2012 at 8:47 AM, Luke Vilnis <lvi...@gmail.com> wrote:
> I'm not really sure why it's somehow controversial to tell people to mind
> their manners. It's not a question of pedagogical style - if you're going to
> speak to other people, be polite. That's just the bare minimum expectation
> of civility. Knowing more about a topic (or thinking you know more) than
> others is not an excuse for rudeness. There is nothing "respectful" about
> being rude to people. Being polite is not an attempt to manipulate someone,
> it's just the way that people are supposed to talk to each other...
>

> On Thu, Aug 23, 2012 at 11:43 AM, Dennis Haupt <h-s...@gmx.de> wrote:
>>

>> once you start investing energy into the delivery itself instead of the
>> pure content of the message, you might be more successful - but you're also
>> no longer seeing the recipient as a being that can think for itself. you are
>> seeing it a an automaton that you can manipulate if you just deliver the
>> correct input.
>>

>> in a way, tony's way is actually *more* respectful than packaging the
>> message nicely to convince more people. he's saying "i give you some facts,
>> now think or stay ignorant" instead of mixing facts while also trying to
>> please the audience.
>>

>> i never liked commercials. i tend to not buy the things they try to sell
>> because they try to make me associate positive feelings with their products,
>> which is a totally obvious act of de-respecting me.

>> -------- Original-Nachricht --------
>> > Datum: Thu, 23 Aug 2012 09:46:28 -0400
>> > Von: Josh Berry <tae...@gmail.com>
>> > An: scala-...@googlegroups.com
>> > Betreff: Re: [scala-debate] So many ways to handle errors ...
>>
>> > On Thu, Aug 23, 2012 at 8:27 AM, Dennis Haupt <h-s...@gmx.de> wrote:
>> > > in my opinion, knowing that there is something you don't know is as
>> > valuable as getting told something new directly . yes, that information
>> > can be
>> > presented in a nicer way than saying: "the one who said this does not
>> > fully
>> > understand the possibilities of the underlying concept". but the one
>> > hearing this could also try not to interpret it as "you are stupid" but
>> > as "take
>> > a closer look at this". i never felt offended by elitism. i accept the
>> > fact that there might be *large* differences in the quality/quantity of
>> > knowledge and skill one could acquire and one might have at the moment.
>> > of you
>> > guys think I am the nutter on my lonesome who harbours these
>> >
>> > There is also the entirely effective and large fields of propaganda
>> > and advertising that show delivery matters.  To believe otherwise
>> > seems just as foolhardy as the alternative.  That is, the message of
>> > "please think.  Seriously, stop posting messages that are easily
>> > construed as offensive" is just as valid as "Please stop taking
>> > offence."  More so, as the actor in the former is proclaiming (often
>> > rightly so) superior knowledge.
>> >
>> > Could there be an ideal world where delivery was less important?  I
>> > certainly wish it were so.  If the belief is that one can browbeat
>> > people into that world, have at it.  There seems to be little evidence
>> > of that compared to the contrary, though.
>> >
>> > Of course, I'm writing this as an outsider, so fully expecting to get
>> > (rightly) lambasted here.  When does the term idiocy actually kick in?
>> >  :)
>
>

[Bruce Eckel]

I found Dan Kang's comment on 

http://scala-programming-language.1934581.n4.nabble.com/Option-under-fire-td2315004.html

to be illuminating:

"Yes, this isn't about invalid operations on certain runtime values - which everyone knows can happen with or without null, but about mutability, null having multiple meanings and null values being allowed to propagate through call chains, because it never violates any static type constraints, yet doesn't support any operations.  For comparison, consider scala where every type is implicitly an option and every val is actually a var.  The real benefit of Option is that not everything is an Option.  In Java, everything is an Option and you cannot - as far as the type system is concerned - peel anything of its optionality.  If you checked for null in some value in one place, there's no static way to communicate this fact to another method.

"Those problems make it difficult to figure out why you're getting an NPE, which is the real problem behind nulls.  ..."

-- Bruce Eckel

www.AtomicScala.com
www.Reinventing-Business.com
www.MindviewInc.com

[Naftoli Gugenheim]

100%, if one didn't know better then what can you do. But it behooves us to do our best to learn how people's "mental states" work. Therefore the best response (not comparing to your response, which I don't recall) to criticism, is along the lines of "I didn't intend to make that happen, sorry about that. Can you help me understand how I can improve," (that's what I try to do when I make such mistakes) --- in other words, (a) express that it was unintended, and (b) try to become smarter.

Clearly, some people have a knack for these things, while others have to struggle to learn it. It's similar to many other things, like musicality, etc. The main thing is to try.

[Richard Wallace]

On Thu, Aug 23, 2012 at 1:03 PM, Richard Wallace

To be perfectly honest, I wouldn't mention Option and null together
*unless* my target audience was coming from a language that depended
on using `null` or something similar for to indicate the possible
presence or absence of value. In fact, you might go the other way and
explain it as, "In Java, all values are Option[T]. If seen that way,
then trying to use that value causes an implicit call to `get` and `v
!= null` is just `v.isDefined`. But wait, there is a whole host of
other combinators for Option that make such things unnecessary!"

[Kevin Wright]

That sounds a lot like you find it funny when you know you've caused offence, or only appealed to a select, elite audience.  Either way, it's a strong indicator of psychopathy.

Actually, I don't believe you to be a psychopath.  Yet the above statement is entirely factually accurate.  If you read it as casting doubt upon your sanity then was the belief uniquely in your own head, or was it implied in my choice of phrasing?

Just by way of analogy...

[Tony Morris]

Bruce
A better way to think of Option is as a list with a maximum length of one. To think of Option in the context of "what we already know", in this case, null pointer exceptions, is perilous. I sincerely advise against it and I think others have already.

Just a list, no more than one element. Notice that its map/flatMap/filter methods work just like List. No need to talk about null or pointers or exceptions.

It also gets *way* more attention than is deserved. It is just an algebraic data type, like hundreds of others. Algebraically, it stands for "adding one/unit to a value." This is another useful way to think of Option.

[Naftoli Gugenheim]

I agree. My point was not to define Option. The train of thought was that Bruce was comparing how Option fits in with relation to Try, as far as how they affect dealing with NPEs.
At least that's how I understood the issue:

That is helpful, thanks. Are either Try and/or Exception reasonable substitutes for handling Some/None?

...

My reading was that Option was for preventing null pointer exceptions by converting the result of using a potentially null pointer into Some or None. I assume Try has some way to deal with null pointers -- is it special or just another exception?

So my comments, taken as a description of Option, are indeed very misleading. My point was rather, given the context of "what to do about NPEs," how does Try fit in, and how does Option fit in.

Does that make sense?

[ARKBAN]

> You guys genuinely fail to realise how many people (of normal intellectual

> discussion) refuse to use the scala mailing lists because of these ridiculous,

> offensive, disgusting, soft^H^H^H attitudes by intellectuals. The funny part

> comes when I am bombarded with lectures on how to "stop scaring people
> away" or rewording so that "your audience would be more receptive." What a
> joke. Seriously, you have no idea how fucking hilarious that is, to me anyway.

I'd say "fixed that for you" but that's not accurate either. The reality is that my rewording is equally true. There are 886 members on this mailing list, and probably around 50 actually post.

Personally, I've learned my lesson and I rarely if ever post here. I know from there are just as many people willing to push me off the mountain as help me climb it. (Just by writing this post I know I'm in for a few more lumps.)

ARKBAN

[Richard Wallace]

This whole debacle is going to have the opposite effect on me. If the
truth cannot be plainly stated without offense being taken, and I must
find a way to make it palatable to a large group of unknown people
whose mind set is impossible to determine at any given time, then I
probably just won't bother. I have little time or energy for such
things.

[Bruce Eckel]

Regarding the issue of maintaining friendly discussions on the web -- which I think is especially important for the Scala community -- I'll observe that in this conversation, someone said that (paraphrasing here):

1. He hadn't said anything wrong.

2. If someone took it badly, it was their own problem and not his.

and then, later in the conversation:

3. Looking at his original comment, he couldn't possibly understand how anyone could misinterpret it.

There may be a deeper problem here in that the person saying these things may be trying to (unknowingly) communicate that they are actually incapable of detecting verbal cues about what they or other people are saying. Which means that all the attempts to patiently explain why the original statements didn't convey a friendly environment are simply confusing (and probably frustrating) to the person.

I don't know the answer to this problem, but it seems like the parties are trying to communicate two different issues, which is why no one is making progress.

-- Bruce Eckel

www.AtomicScala.com
www.Reinventing-Business.com
www.MindviewInc.com

[Bruce Eckel]

Yes, and I'm being more ambitious here, trying to grok the bigger picture of how Scala is approaching error handling/error prevention.

One of the issues is that it's still evolving, as we see in the new Try stuff, and the code that was just added to unify Try and catching().

I'm trying to find the simple and clear explanation, but I have usually found that I have to take a deep dive into the complicated stuff in order to understand what the simple approach should be.

-- Bruce Eckel

www.AtomicScala.com
www.Reinventing-Business.com
www.MindviewInc.com

[Richard Wallace]

On Thu, Aug 23, 2012 at 1:41 PM, Bruce Eckel <bruce...@gmail.com> wrote:
> Yes, and I'm being more ambitious here, trying to grok the bigger picture of
> how Scala is approaching error handling/error prevention.
>
> One of the issues is that it's still evolving, as we see in the new Try
> stuff, and the code that was just added to unify Try and catching().
>
> I'm trying to find the simple and clear explanation, but I have usually
> found that I have to take a deep dive into the complicated stuff in order to
> understand what the simple approach should be.
>

In that case, I think the important thing to take away from all this
is that Option has nothing to do with NPEs, null or error handling.
It is just another ADT, with useful combinators defined. Pure and
simple.

[Tony Morris]

It's just an ongoing issue with a vocal minority believing they have it all worked out, but are completely incapable of analytical thinking on the matter. Welcome.

[Rex Kerr]

On Thu, Aug 23, 2012 at 4:33 PM, Richard Wallace <rwal...@thewallacepack.net> wrote:

This whole debacle is going to have the opposite effect on me.  If the
truth cannot be plainly stated without offense being taken, and I must
find a way to make it palatable to a large group of unknown people
whose mind set is impossible to determine at any given time, then I
probably just won't bother.  I have little time or energy for such
things.

Since you didn't say much of use the first time--a simple "No" would have been slightly less insulting, and way faster for you to type, and conveyed the same critical information--it's a bit hard to bemoan the loss of such sage advice.

Anyway, the key is that mind set _is not unknowable_.  Most people manage to predict it with a fair degree of accuracy almost all of the time.  Some people are really good at doing it intuitively; others have to rely upon bitter experience to build intuition; others have to do it intellectually.  Still, once you build up the appropriate intuition and/or knowledge, it's just not that hard to execute it.  (In fact, it's easier overall, because your communications are more effective; you cease distracting people with your tone.)

It's not that it doesn't work to use a brusque or arrogant tone, or even to be insensitive to tone.  It does work some of the time, just not as reliably.  You have more errors of communication; you reach fewer people who are otherwise happy to learn.  (The camp of "I am happy to learn, but not if you're going to be an ass about it" is a large one.)  It's kind of like using null to represent a value that isn't present...yes, it works, sorta, and your code runs faster (and there's less to type, sometimes, if you're willing to do it unsafely).

But it's not the best way to develop robust software (or engage in robust interpersonal communication).

  --Rex

P.S. Arrogant tone is extremely effective at getting the insecure off your back when they look like they're going to cause you problems.  When one knows what one is doing and is surrounded by people who are not, one can get in the habit of adopting this tone so that one can get something done.

P.P.S. What is considered arrogant varies a bit by culture and country.  Australia, as Tony has mentioned in the past (and I concur) tolerates an awful lot of plainness/non-nicety.  In South Korea, my impression (perhaps incorrect) is that anything not crafted in such a mild way that it's only barely possible to interpret what is said is nearly intolerable at least when it comes to a "subordinate" talking to a "superior".  (I understand that South Korean airlines have instituted an English-only rule for pilots during flight, not just for international communication in order to encourage plain statement of problems during flight.)  In international forums, one may have to adjust ones estimate of mind-set a little to hit the international average.  Again, it's not so hard; people will forgive a few errors if you're nice about it, and it's an important skill to develop to communicate with maximum reach.

[Josh Suereth]

This is true.   Option is about optionally values.   A simple truism.

You can handle failures using option, but you can also use validation or now Try.    Try is more about avoiding error handling in a 'staged computation' until later.   Validation is about collecting error messages (well, it can be more generic), and Option is about return values that may or may not exist.   Like "what value is stored at this key in a map."

Now, as to the rest of the discussions -

Teaching requires successful communication.   I do not want to moderate the list, but will do so if required for successful communication.   messages that throw up emotional barriers to learning are unhelpful.   I realize, tony, that it is arrogant of me to make judgment calls he.   I am an imperfect being.   However it is my responsibility and I do so to the best of my ability.  I will make mistakes.

Emotions can be used to block a message, or to ram one home.   I want scala ml to be free of this so we have a free exchange of ideas, and people are willing to ask "dumb" questions and receive patient guidance.

The truth will stand up in the end.   Weigh my actions as you see fit.  Judge me as you will.   I'm one of those responsible for this ML so if you don't like my judgment, find another place to communicate.

However if this thread continues not to discuss option I will shut it down and force conversation to occur on something that won't show when googling for "scala error handling".

This has gone far too long.   Tony/Richard, we can take this up privately if you want.

[Richard Wallace]

On Thu, Aug 23, 2012 at 2:05 PM, Rex Kerr <ich...@gmail.com> wrote:
> On Thu, Aug 23, 2012 at 4:33 PM, Richard Wallace
> <rwal...@thewallacepack.net> wrote:
>>
>>
>> This whole debacle is going to have the opposite effect on me. If the
>> truth cannot be plainly stated without offense being taken, and I must
>> find a way to make it palatable to a large group of unknown people
>> whose mind set is impossible to determine at any given time, then I
>> probably just won't bother. I have little time or energy for such
>> things.
>
>
> Since you didn't say much of use the first time--a simple "No" would have
> been slightly less insulting, and way faster for you to type, and conveyed
> the same critical information--it's a bit hard to bemoan the loss of such
> sage advice.
>

I tried to warn him off the vocal, but incorrect, crowd. That was the
main intent of my response. "No" does not indicate the same thing. I
could have said, "Don't listen to those idiots they have nfi what they
are talking about." and it would have been equally correct. I feel
like I showed considerable restraint.

> Anyway, the key is that mind set _is not unknowable_. Most people manage to
> predict it with a fair degree of accuracy almost all of the time. Some
> people are really good at doing it intuitively; others have to rely upon
> bitter experience to build intuition; others have to do it intellectually.
> Still, once you build up the appropriate intuition and/or knowledge, it's
> just not that hard to execute it. (In fact, it's easier overall, because
> your communications are more effective; you cease distracting people with
> your tone.)
>
> It's not that it doesn't work to use a brusque or arrogant tone,

I used no such tone, despite your insistence that I did.

> or even to
> be insensitive to tone. It does work some of the time, just not as
> reliably. You have more errors of communication; you reach fewer people who
> are otherwise happy to learn. (The camp of "I am happy to learn, but not if
> you're going to be an ass about it" is a large one.) It's kind of like
> using null to represent a value that isn't present...yes, it works, sorta,
> and your code runs faster (and there's less to type, sometimes, if you're
> willing to do it unsafely).
>
> But it's not the best way to develop robust software (or engage in robust
> interpersonal communication).
>

The best discussions I've had with colleagues all started with,
"That's the dumbest idea I've ever heard." Either I was saying it or
it was being said to me. No one was interested in pandering to the
emotional sensitivities of the other, we were simply interested in the
technical merit of the thing under discussion.

> --Rex
>
> P.S. Arrogant tone is extremely effective at getting the insecure off your
> back when they look like they're going to cause you problems. When one
> knows what one is doing and is surrounded by people who are not, one can get
> in the habit of adopting this tone so that one can get something done.
>
> P.P.S. What is considered arrogant varies a bit by culture and country.
> Australia, as Tony has mentioned in the past (and I concur) tolerates an
> awful lot of plainness/non-nicety. In South Korea, my impression (perhaps
> incorrect) is that anything not crafted in such a mild way that it's only
> barely possible to interpret what is said is nearly intolerable at least
> when it comes to a "subordinate" talking to a "superior". (I understand
> that South Korean airlines have instituted an English-only rule for pilots
> during flight, not just for international communication in order to
> encourage plain statement of problems during flight.) In international
> forums, one may have to adjust ones estimate of mind-set a little to hit the
> international average. Again, it's not so hard; people will forgive a few
> errors if you're nice about it, and it's an important skill to develop to
> communicate with maximum reach.
>

It is not really worth that effort. If you cannot take what is being
said at face value without it becoming a personal issue, then you will
not learn much. If you value always feeling good about yourself,
you're welcome to it. I welcome the opportunity to learn when I've
gone wrong and appreciate being told straight forwardly. If you do
not, then you can ignore me. I know there are others who feel the
same as I do.

[Tony Morris]

On 24/08/12 07:19, Richard Wallace wrote:
> If you cannot take what is being
> said at face value without it becoming a personal issue, then you will
> not learn much.

There is the gold right there.

It's not that one insists on taking a helpful comment personally, out of
context and with invented projected meaning (although that alone is
indeed ridiculous), but it's the disastrous consequences of doing so.
You will not learn anything while you do this and we all regularly
witness the consequences of having learned poorly on this list *all the
time*. Don't be sucked into this trap!


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

[Matthew Pocock]

On 23 August 2012 21:06, Richard Wallace <rwal...@thewallacepack.net> wrote:

What if the speaker didn't knowingly cause these feelings.  These
feelings are purely a byproduct of the readers mental state?  I think
this is where I become most confused as I can't possibly know what
will cause these feelings in anyone, much less _everyone_.

I sympathise. The only way I can play pictionary is to treat it as a Turing test. What pictures would I draw to fool the other person into thinking I was drawing things that they could understand and interpret as 'X'? If I just draw the things that should be interpreted as 'X', everyone just looks confused. When they draw things, there's no point me saying to myself 'what have they drawn?' - I have to ask 'what would I say they'd drawn if I was trying to fool them into thinking I understood what they where drawing?'. That way I consciously and deliberately make some sort of approximation to their mental state rather than mine, and then we win. Otherwise, we're still on the first stretch by the time everyone else is about ready to win.

So, for these kind of discussions, you can have Turing cheat-sheet with things like:

It's fine to say someone is wrong, but don't use words that would be used by somebody else telling them that they are

1. stupid

2. ignorant

3. deceptive

There may be things they don't know. In which case, rather than saying, "you are ignorant", think about what it is they don't know and:

4. try to summarise the lack of knowledge in a sentence or two

5. try to state the extra knowledge they need

Now I read back trough this, it sounds like a potted aspie's guide to mailing list etiquette, but what the hell.

Matthew

--

Dr Matthew Pocock

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

mailto: turingate...@gmail.com

gchat: turingate...@gmail.com

msn: matthew...@yahoo.co.uk

irc.freenode.net: drdozer

skype: matthew.pocock

tel: (0191) 2566550

mob: +447535664143

[Rex Kerr]

Well, I'll do what I can to give a longer overview.

The JVM has one inbuild error-handling mechanism: when something goes so wrong that you cannot continue, throw an exception.  You can use this low-level control flow, or any "normal" control flow, to implement all sorts of error handling.

Scala can use the JVM's exception mechanism.  It also has two generic container classes that are particularly useful for error handling (though not only for error handling): Option and Either.  And it has one new specific container class designed exclusively for error handling: Try.  And it has a set of utility classes and methods that give you additional options for handling exceptions beyond the low-level try/catch: util.control.Exceptions.

Which one you want to use depends on what the nature of the "error" is.  If you can predict that something is not going to result in a desired value, you probably don't want to throw an exception and catch it.  It's expensive, and that takes the control flow arbitrarily far away from the site of the problem.  If that's what you want, great--but otherwise, it's better to detect in advance.

If you detect in advance, what can you do?  If you can simply supply a default value and leave it at that, you can, of course.  But often you will not have a value where you actually wanted one.  This is where Option comes in: it is a general-purpose container that either contains one thing or does not.  It's a great fit for error handling, when that often happens: you have what you want (e.g. the head of a list), or you do not (e.g. there was no head).  It's best when you know why you didn't get what you asked for; then you don't need a reason, just an absence of anything.

Of course, now that you have something-or-nothing, there are a bunch of things you might want to do: only call a function if there is something, convert the nothing into a default value, etc. etc.; Option provides these as methods.  null can be used (for classes, not primitives) to signal no-value-present also, but it doesn't have the handy utility methods, nor will your types distinguish certainly-a-value from maybe-a-value.  If you know a null is used to represent no-value, you can wrap in Option to convert the null to a None, and take advantage of the handy features Option provides.

Now, you might detect in advance and find that you don't simply want to say that _something_ went wrong, but _what_ went wrong.  And this is where Either is useful: Either is a generic construct that, as the name implies, contains either (but not both) of two different things.  One way to use this is to have what you really want as one of the types (typically Right, as the name is suggestive that it is what you want), and if something went wrong to put whatever information you have as the other type (typically Left).  Again, Either has a bunch of handy methods for handling this situation where you have either of two things.  This can be useful for returning error messages that specify the invalid input, saving context relevant for understanding the failure, or packaging up thrown exceptions so they can be collected or otherwise dealt with.

If you can predict where things will go wrong, but the code is going to throw a particular exception at you instead of using Option or Either like it should (in Scala), possibly because it's a Java library, then you can use util.control.Exceptions to specify which exception will be thrown and to package it into an Option or Either.  Then you get all your nice functionality with a minimum of fuss (and without writing over and over again  try { Some(blah) } catch { case e: IHopeISpelledThisExceptionNameRight => None}).  Unfortunately, the minimum of fuss is still a fair bit of fuss--enough so that the try/catch is not drastically worse.

Finally, if you can't predict where things will go wrong, or you can but all you really want is your exception packaged in an Either for later handling, falling back on try/catch is more awkward than ideal, and Either has a problem--you can catch the original exception, but if you throw another exception while dealing with the first one, you have to use Exceptions.catching again, and it's just awkward.  What you very often want when dealing with exceptions is to make every failure case end up as an exception, no matter when or where it went wrong, collect the success as something else, and be able to operate on the thing using your utility methods without messing up the property that either you have a wrapped exception, or your wrapped value, and nothing else will happen.  This is what Try does (or will, when the last uncaught exception bug is fixed): when you deal with a try, all your Either-like utility methods will firstly do the sensible thing (which is to act on the correct value, not on the exception), and second, if anything goes wrong while you're working on it, it'll give you a wrapped exception instead of bailing out of your exception-handling code with an exception.

So, in summary:
  Use Option when a value may or may not exist.
  Use Either when either you have the value you want or some data related to what went wrong
  Use Try when you want your value, or to collect any exceptions if they arise
  Use methods from Exceptions when you want to convert particular exceptions to Option or Either

--Rex

[virtualeyes]

I did not find your original reply to be particularly out of line, not all really, but in the context of:
scala is complex
scala is for elite programmers
if you're a beginner and ask an inane (to an advanced scala user)  question, you might get harshly shot down

Martin stepped in to make an example of what proper mailing list etiquette should be.

Those at the core of the language have a vested interest in seeing Scala thrive, and so do those who have grown to love the language and rely on it for the bulk of their projects.

The last thing anyone (who cares about the language) wants to see is for Scala to become known as the language for thought provoking a$$holes ;-)

Cheers

[Eric Kolotyluk]

Thank-you Rex.

I was praying someone would end my misery of suspense waiting for a useful summary.

Cheers, Eric

[Som Snytt]

An amazing and vibrant thread, and all on-topic ("So many ways to handle errors!").

I just got hooked on Try (via Future), and now I'll use it for dirty scripty things like
Try(args.head.toInt) filter (_ > 0) recover { ... } foreach (...)

Is that venial?  Wikipedia says a mortal sin must be a grave matter and also committed with full knowledge and complete consent.  So with Scala, I'm safe, because I'll never possess full knowledge, which is one of its pleasures.

I'm not sure I'm as safe using catchingPromiscuously, because you never know what you might catch.

Thanks to the teachers and evangelists for spreading the goodness (if I'm not mixing metaphors).

[Linas]

On Fri, 2012-08-24 at 06:09 +1000, Tony Morris wrote:
> You guys genuinely fail to realise how many people (of very high
> quality intellectual discussion) refuse to use the scala mailing lists
> because of these ridiculous, offensive, disgusting, soft attitudes
> toward intellectualism.

Really? Do provide the relevant statistics, please. Who are these many?
How have they been counted?

Linas.

[Matthew Pocock]

Hiya. 

On 24 August 2012 00:15, Som Snytt <som....@gmail.com> wrote:

 

I just got hooked on Try (via Future), and now I'll use it for dirty scripty things like
Try(args.head.toInt) filter (_ > 0) recover { ... } foreach (...)

Is that venial?  Wikipedia says a mortal sin must be a grave matter and also committed with full knowledge and complete consent.  So with Scala, I'm safe, because I'll never possess full knowledge, which is one of its pleasures.

Lol! Hum ... in the politest possible way, eugh! Exceptions aren't really intended for control flow. I can see how what you've written may make sense in a throw-away script, but in production (or anything anybody else would ever see), it would be much better to use the types to explicitly handle the empty-args case. I'd probably have written that as something along the lines of:

val arg0Val: Int = args.headOption match {

  case Some(ParsedInt(x)) if x > 0 => x

  case Some(ParsedInt(x)) => warn_the_user_about_out_of_range_value; some_default_value

  case None => warn_the_user_about_missing_value; some_default_value

  case Some(badString) => show_the_user_an_error_message

}

where ParsedInt is:

object ParsedInt {

  unapply(str: String): Option[Int] = Try(str.toInt).opt

}

I know it's longer, but it is very, very explicit about what's going on and each different error condition is handled. Note - I did use Try in the implementation of ParsedInt - Sun in their infinite wisdom decided to use exceptions here to indicate parse failure, which is not really an exceptional circumstance, so Try seems like an entirely legitimate and natural way to unbreak that API choice.

I've not compiled this, so it may contain mistakes.

Matthew

[pagoda_5b]

I guess the issue arises just because scala is inevitably (and I would say intentionally) a language that attracts huge attention from the java developer community. So the Option type is quite naturally used very often in blogs and presentations _for java devs_, to introduce a language and type feature that helps solving some NPE cases and null objects inconsistently used as empty results in that language.

It's so simple to explain and the gains are so clear that it's a natural choice.

For the same audience it's harder to grasp what the Option type could exactly represent as an ADT, and its use in a monadic context.

Instead for people having functional/haskell experience it's just another useful ADT with monadic behaviour on top of that.

Maybe the issue is if, from an "intellectual integrity" point of view, it's correct and useful to present this ADT without clearly stating all that it represents and implies. From a pragmatic standpoint I find that presenting Option as an alternative to null-as-missing-value and as a way to avoid NPE is quite useful as an introduction for people _with java background_, even if it sounds incorrect to who's used to it from a functional background.

Bye,

Ivano

[pagoda_5b]

In this I think you're totally off-track.

Stating that Option, "is just another ADT, with useful combinators defined", would imply that Option and Either are the same things (just another ADT, with useful combinators defined, just like so many others).

You've reduced the context of the argument so much that it becomes useless from a practical viewpoint.

I guess that Bruce is trying to best tackle the practical advantages and implications of using this type, in the most useful and unambiguous manner, in the most useful and clearly identified context (like error-handling, possibly-missing value, single-element list...)

To say that it has nothing to do with NPE or nulls, while possibly true from an "intellectual" approach (and here we could argue), it's sterile and altogether false from the perspective of a java developer, for whom using the Option could be actually related to a problem he usually approaches using null references and for whom it can prevent situations where he had to battle with unwanted NPEs.

For this java developer these aspects are practically and actually related.

The purely logical and theoretic approach is very useful to define and correctly identify data types and their properties.

But it becomes useless if it can't be applied to real case problems, where the abstraction must be usually put aside a little, to be replaced by analogies and conceptual models that can be easily adapted to the situation at hand (like tackling problems like "error-handling", "computations that might have no defined outcome" and so on...)

It's like abstract math, which is intriguing, delightful and enticing, but actually useless if you can't find no practical application to it (like CS or physics or whatever)

[Tony Morris]

I'm not sure who you are addressing, since many of the points you seem
to refute are quite well known to be true. However, you're making an
error when it comes to instruction so hopefully something useful can
come of this.

On 24/08/12 18:27, pagoda_5b wrote:
> In this I think you're totally off-track.
> Stating that Option, "is just another ADT, with useful combinators
> defined", would imply that Option and Either are the same things (just
> another ADT, with useful combinators defined, just like so many others).

No it wouldn't. It would mean they are related and indeed they are.

type Option[A] = Either[Unit, A]

There are some pretty interesting lessons on this point, but leave it
aside for now.

> You've reduced the context of the argument so much that it becomes useless
> from a practical viewpoint.
> I guess that Bruce is trying to best tackle the practical advantages and
> implications of using this type, in the most useful and unambiguous manner,
> in the most useful and clearly identified context (like error-handling,
> possibly-missing value, single-element list...)
>
> To say that it has nothing to do with NPE or nulls, while possibly true
> from an "intellectual" approach (and here we could argue), it's sterile and
> altogether false from the perspective of a java developer, for whom using
> the Option could be actually related to a problem he usually approaches
> using null references and for whom it can prevent situations where he had
> to battle with unwanted NPEs.
> For this java developer these aspects are practically and actually related.

No, to say it has nothing to do with null pointer exceptions is to make:
a) a statement of fact
b) a statement that guides a student more appropriately to discover and
understand the subject matter appropriately
c) guides the student away from some of the hyperbolic garbage that is
available on the internet (which I am assuming Richard originally refers
to) that misconstrues facts wildly but subtly, so that someone like
Bruce, who deserves a decent explanation, may inadvertently fall into a
trap. Bruce does not deserve the misguidance that is evident in that
material, of which the author has the same chronic misunderstanding --
one of which we all have a duty to ensure that Bruce, a genuinely
curious mind, does not also acquire.

This is one of many great battles in teaching by the way -- it's not as
simple as stating the facts and then letting go of the student's hand.
It is far more complex than that and especially so given some of the
comments on this thread and on the internet that serve only to misguide
(or provide laughs for those who can see straight through it).

As Richard has already pointed out quite spectacularly, no the Option
data type has nothing to do nulls or pointers or exceptions. If you
disagree, please debunk his argument -- it is solid and it is rather
jaw-dropping that it might be suggested otherwise. Prepending adverbs
like, "theoretically" or "intellectually" does not sway any of these
facts -- it just looks like squirming.

However, if you are going to argue that we should "bend that truth" a
little (and by a little, I mean a lot) for the purpose of instruction,
then you are doing a serious disservice to any potential student of the
subject matter in a rather catastrophic way. If you are indeed arguing
this, I urge you to suspend disbelief and gain more experience here
first, then also join others who have strong experience in teaching this
subject -- for the potential student's sake, please do this. I think you
have a lot to learn about how to learn and teach if this is the case.

> The purely logical and theoretic approach is very useful to define and
> correctly identify data types and their properties.
> But it becomes useless if it can't be applied to real case problems, where
> the abstraction must be usually put aside a little, to be replaced by
> analogies and conceptual models that can be easily adapted to the situation
> at hand (like tackling problems like "error-handling", "computations that
> might have no defined outcome" and so on...)
>
> It's like abstract math, which is intriguing, delightful and enticing, but
> actually useless if you can't find no practical application to it (like CS
> or physics or whatever)

This is incoherent and I am to assume that it written this way to
support whatever mistake you are making. Otherwise, please clarify.

> In that case, I think the important thing to take away from all this
>> is that Option has nothing to do with NPEs, null or error handling.
>> It is just another ADT, with useful combinators defined. Pure and
>> simple.
>>
>>
>>

[Rob Dickens]

> ...to say it has nothing to do with null pointer exceptions is to make:
> a) a statement of fact...
> ...hyperbolic garbage that is available on the internet

How about page 329 of Programming in Scala (2nd Ed).

[Kevin Wright]

type Option[A] = Either[Unit, A]

Why is this definition preferable to Either[Nothing, A] ?

My concern here is that attempting to .get from a None will thrown an exception, whereas attempting to .get from the left projection of an Either[Unit, A] will return a Unit - so the behaviour isn't consistent.

Admittedly, it would be far nicer if .get simply didn't exist in the first place, or exceptions, or other side-effects.  But these things do exist in Scala and on the JVM, so shouldn't they be accounted for? 

Option is used to indicate (as a static type) that a something might not be present.

null is used (as a runtime value) to indicate that something is absent

The two concepts are different, very different - values and types simply aren't the same thing.

That doesn't mean to say that they're totally unrelated.  I actually find null/Option to be a good candidate for explaining the differences between type-level and value-level thinking.

[Tony Morris]

On 24/08/12 20:06, Rob Dickens wrote:
>> ...to say it has nothing to do with null pointer exceptions is to make:
>> a) a statement of fact...
>> ...hyperbolic garbage that is available on the internet
> How about page 329 of Programming in Scala (2nd Ed).

I don't have that book handy so I don't know what you refer to.
Certainly, I didn't have any book in mind when I wrote it.

The hyperbolic garbage on the internet may make the mistake of
overstepping the relationship of a mundane ADT, but this is not what
makes it hyperbolic garbage. I was hoping not to get into that -- if you
do not know what I refer to, then leave it aside -- I was just expecting
most people would.

[Tony Morris]

On 24/08/12 20:12, Kevin Wright wrote:
>>
>> type Option[A] = Either[Unit, A]
>>
>>
> Why is this definition preferable to Either[Nothing, A] ?
>
> My concern here is that attempting to .get from a None will thrown an
> exception, whereas attempting to .get from the left projection of an
> Either[Unit, A] will return a Unit - so the behaviour isn't consistent.
>
>
> Admittedly, it would be far nicer if .get simply didn't exist in the first
> place, or exceptions, or other side-effects. But these things do exist in
> Scala and on the JVM, so shouldn't they be accounted for?

This definition is not so much "preferred" as it is "correct."
Either[Nothing, A] is isomorphic to A and so it is incorrect.

Let's do some algebra. Start with some basics:

* Option[A] = Unit + A
* Either = addition (aka sum type)
* Nothing = 0 (aka uninhabited)
* Unit = 1

Therefore, Option[A] = Either[Unit, A]. You can write the bijection (not
type-checked):

* def inject[A](o: Option[A]): Either[Unit, A] = o map (Right(_))
getOrElse (Left())
* def surject[A](x: Either[Unit, A]): Option[A] = x.fold(_ => None, Some(_))

Reader's exercise: write a proof of this isomorphism.

Notice that there is no possible bijection Option[A] <=> Either[Nothing,
A]. Try it if you like.

I didn't follow your last paragraph, but perhaps it is the source of the
confusion.

[Tony Morris]

To add to the algebra exercise.

Since Either[A, B] corresponds to A+B and Nothing=0, then
Either[Nothing, A] = 0+A = A.

[Rob Dickens]

> I don't have that book handy

http://www.artima.com/pins1ed/case-classes-and-pattern-matching.html#15.6

See third paragraph.

[Tony Morris]

On 24/08/12 20:54, Rob Dickens wrote:
>> I don't have that book handy
> http://www.artima.com/pins1ed/case-classes-and-pattern-matching.html#15.6
>
> See third paragraph.

I don't see a problem with that paragraph. It is indeed true that where
one might have used null, one instead uses the Option data type, but
this kind of thinking is very limited and not really helpful for gaining
a good handle on the subject of algebraic data types and the specific
one under discussion.

It is the excess emphasis that detracts from helping a student come to
an understanding or worse, the aforementioned hyperbolic garbage that
deserves no attention at all.

[Kevin Wright]

I now feel sorry for our erstwhile new joiner to the mailing list, who has just read that...

No, to say it has nothing to do with null pointer exceptions is to make: a) a statement of fact

then 

It is indeed true that where one might have used null, one instead uses the Option data type

and whose head is now reeling in confusion.

Option is a very different beast from nulls, yet it *is* related through being used in places where people would otherwise use nulls in Java.  and if you're not using nulls then you won't be exposed to NullPointerExceptions.

So to say that "Option has nothing to do with null pointer exceptions" is a statement of falsehood.  It's true that they are in no way equivalent, but non-equivalence and "having nothing to do with" don't mean the same thing at all.

Perhaps we should just use the phrasing:

Option has `None` to "do with" NullPointerExceptions

[Tony Morris]

It is an arbitrary relationship. You could similarly argue that there is
a relationship between giraffes and cauliflower because they are both
things. Put the goal posts in place, then let's talk. I understand it is
confusing, which is why this should be avoided in any introduction.

The phrase "has nothing to do with" does not commute at least when I use
it. The English language sucks balls.

[Kevin Wright]

On 24 August 2012 12:20, Tony Morris <tonym...@gmail.com> wrote:

It is an arbitrary relationship. You could similarly argue that there is
a relationship between giraffes and cauliflower because they are both
things.

They're both multi-cellular eukaryotic organisms. They're also both edible.  So the relationship goes far beyond mere existence.

 

Put the goal posts in place, then let's talk. I understand it is
confusing, which is why this should be avoided in any introduction.

I personally see no confusion here.  If two "solutions" are commonly used to tackle the same design problem, then it's fair to discuss them in a "compare and contrast" fashion.

 

The phrase "has nothing to do with" does not commute at least when I use
it. The English language sucks balls.

 

http://xkcd.com/191/