luc taesch | 28 Mar 17:21 2013
Picon

introducing Maybe at managing level

I was looking for some link introducing the way FP/ Haskell handles 
errors and Exceptions.

This is for a non FP Guy, and ideally withought scaring them with 
Monads and category theory :-).

for the background :

the guy said : As I mentioned in another thread in banking (in 
particular) it is the exception processing that often dominates the 
functionality of a system - as the core concept is generally very 
straightforward. Developing for "exception handling" (not in a Java/C++ 
sense) is a tricky thing - as the exception don't necessarily shout 
themselves out - and are often why we have large misunderstood legacy 
systems which are hard to replace.
John Lato | 29 Mar 06:47 2013
Picon

Re: introducing Maybe at managing level

In FP, I think this sort of problem is generally handled via algebraic data types rather than exceptions.  In particular this directly addresses the issue of "exceptions don't necessarily shout themselves out", since the compiler warns you if you've missed a case.

They sound mathy, but algebraic data types are actually a pretty simple concept.  I think the "Learn You a Haskell" explanation is decent: http://learnyouahaskell.com/making-our-own-types-and-typeclasses

Provided I understand the context properly, actually using exceptions for this sort of issue would be extremely rare practice.


On Fri, Mar 29, 2013 at 12:21 AM, luc taesch <luc.taesch <at> gmail.com> wrote:
I was looking for some link introducing the way FP/ Haskell handles errors and Exceptions.

This is for a non FP Guy, and ideally withought scaring them with Monads and category theory :-).

for the background :

the guy said : As I mentioned in another thread in banking (in particular) it is the exception processing that often dominates the functionality of a system - as the core concept is generally very straightforward. Developing for "exception handling" (not in a Java/C++ sense) is a tricky thing - as the exception don't necessarily shout themselves out - and are often why we have large misunderstood legacy systems which are hard to replace.



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Luc TAESCH | 29 Mar 10:02 2013
Picon

Re: introducing Maybe at managing level

Thanks John.

I was indeed thinking to Maybe and the monad bindings, 
and  LYAH, or http://book.realworldhaskell.org/read/error-handling.html

the problems is I cannot uses these links in isolation ( to a Non haskellers) because they mention Monads, Lazyness, Algebric types, all this vocabularies that side track a beginner, ( or a manager ;-)

then all I want to show is the generic concept ( powerpoint level) 
of how a forest of (non core) case can be streamlined in one major case ( the good outcome) , and all the rest ( exceptions in a non technical sense) are catched by the maybe monad, without sidetracking the readability of the code .

I saw this somewhere on the blogosphere, but cannot remember where..

this is management level, and this is even worse than beginners techies, because they derails very quickly when talking "details"


--------------
Luc
Envoyé avec Sparrow

Le vendredi 29 mars 2013 à 06:47, John Lato a écrit :

In FP, I think this sort of problem is generally handled via algebraic data types rather than exceptions.  In particular this directly addresses the issue of "exceptions don't necessarily shout themselves out", since the compiler warns you if you've missed a case.

They sound mathy, but algebraic data types are actually a pretty simple concept.  I think the "Learn You a Haskell" explanation is decent: http://learnyouahaskell.com/making-our-own-types-and-typeclasses

Provided I understand the context properly, actually using exceptions for this sort of issue would be extremely rare practice.


On Fri, Mar 29, 2013 at 12:21 AM, luc taesch <luc.taesch <at> gmail.com> wrote:
I was looking for some link introducing the way FP/ Haskell handles errors and Exceptions.

This is for a non FP Guy, and ideally withought scaring them with Monads and category theory :-).

for the background :

the guy said : As I mentioned in another thread in banking (in particular) it is the exception processing that often dominates the functionality of a system - as the core concept is generally very straightforward. Developing for "exception handling" (not in a Java/C++ sense) is a tricky thing - as the exception don't necessarily shout themselves out - and are often why we have large misunderstood legacy systems which are hard to replace.



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
David Virebayre | 29 Mar 10:14 2013
Picon

Re: introducing Maybe at managing level

The link to LYAH that John provided,
http://learnyouahaskell.com/making-our-own-types-and-typeclasses ,
doesn't mention monad at all.

Laziness is mentionned only once while explaining recursive types, but
you could omit that line.

Now Algebraic is mentionned 6 times, but if you're afraid it might
scare someone, why not replace it by 'Haskell' ( thus, Algebraic data
type becomes Haskell data type, for the purpose of your introduction )

2013/3/29 Luc TAESCH <luc.taesch <at> gmail.com>:
> Thanks John.
>
> I was indeed thinking to Maybe and the monad bindings,
> and  LYAH, or http://book.realworldhaskell.org/read/error-handling.html
>
> the problems is I cannot uses these links in isolation ( to a Non
> haskellers) because they mention Monads, Lazyness, Algebric types, all this
> vocabularies that side track a beginner, ( or a manager ;-)
>
> then all I want to show is the generic concept ( powerpoint level)
> of how a forest of (non core) case can be streamlined in one major case (
> the good outcome) , and all the rest ( exceptions in a non technical sense)
> are catched by the maybe monad, without sidetracking the readability of the
> code .
>
> I saw this somewhere on the blogosphere, but cannot remember where..
>
> this is management level, and this is even worse than beginners techies,
> because they derails very quickly when talking "details"
>
>
> --------------
> Luc
> be.linkedin.com/in/luctaesch/
> Envoyé avec Sparrow
>
> Le vendredi 29 mars 2013 à 06:47, John Lato a écrit :
>
> In FP, I think this sort of problem is generally handled via algebraic data
> types rather than exceptions.  In particular this directly addresses the
> issue of "exceptions don't necessarily shout themselves out", since the
> compiler warns you if you've missed a case.
>
> They sound mathy, but algebraic data types are actually a pretty simple
> concept.  I think the "Learn You a Haskell" explanation is decent:
> http://learnyouahaskell.com/making-our-own-types-and-typeclasses
>
> Provided I understand the context properly, actually using exceptions for
> this sort of issue would be extremely rare practice.
>
>
> On Fri, Mar 29, 2013 at 12:21 AM, luc taesch <luc.taesch <at> gmail.com> wrote:
>
> I was looking for some link introducing the way FP/ Haskell handles errors
> and Exceptions.
>
> This is for a non FP Guy, and ideally withought scaring them with Monads and
> category theory :-).
>
> for the background :
>
> the guy said : As I mentioned in another thread in banking (in particular)
> it is the exception processing that often dominates the functionality of a
> system - as the core concept is generally very straightforward. Developing
> for "exception handling" (not in a Java/C++ sense) is a tricky thing - as
> the exception don't necessarily shout themselves out - and are often why we
> have large misunderstood legacy systems which are hard to replace.
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Gmane