Re: [Haskell-cafe] introducing Maybe at managing level

[David Virebayre]

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 :
> 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  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@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] introducing Maybe at managing level

[Luc TAESCH]

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/ (http://be.linkedin.com/in/luctaesch/)
Envoyé avec Sparrow (http://www.sparrowmailapp.com/?sig)


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  (mailto:luc.tae...@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@haskell.org (mailto:Haskell-Cafe@haskell.org)
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>  

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] introducing Maybe at managing level

[John Lato]

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  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@haskell.org
> http://www.haskell.org/**mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] introducing Maybe at managing level

[luc taesch]

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@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe