Re: [Haskell-cafe] 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 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 luc.tae...@gmail.com (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
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.tae...@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.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 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
[Haskell-cafe] 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.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 http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
