Yin wang[]
https://web.archive.org/web/20140118083122/https://yinwang0.wordpress.com/2013/11/09/oop-fp/
It is not their fault. Many years ago I was exactly like them. I was a big fan of Haskell. I argued with my Cornell professors about pureness. I told them purely functional languages and monads are going to save the world. They told me not to believe those marketing hypes and there is no silver bullet. I didn’t listen to them, and I left Cornell. They didn’t try to convince me because I just needed several more years of research to understand what they told me. After that I learned from some of the world’s best and most humble functional programming language researchers: Dan Friedman, Kent Dybvig, Amr Sabry. To be honest, they have much deeper knowledge about functional programming than the creators of Haskell. For a simple example, few Haskell people know that lazy evaluation was invented by Dan Friedman in his 1976 paper CONS should not Evaluate its Arguments. He also knows more about type systems than most people. He showed us how easy the HM is to implement. Why doesn’t he put laziness and a type system into Scheme? Because although he understand them well, he didn’t really like them. At this age, he even made his own logic programming language and started to make a theorem prover.
wiki c2[]
http://wiki.c2.com/?TheEvolutionOfaHaskellProgrammer Somebody in OnMonads pointed out that the above document doesn't have a monadic factorial, so I will provide one. One imagines that this would be written by someone who came from an asm background...
http://wiki.c2.com/?OnMonads Simply, monads are wrappers around function invocations. They're a lot like like C++ ->() operators. They're also a lot like interceptors in AspectOrientedProgramming. Since their semantics remain constant no matter how many times you push function invocations through them, they're also a bit like SingletonPatterns. And since they carry around their own guts consistently from one invocation to another they're a bit like closures. If closures could be composited formally ...
There are a bunch of different Monads with identical syntax but different semantics. Wrappers that do IO, Exceptions, Nullability, ACID State, Logging, Messaging, ... all these types of wrappers can be easily composed and transformed to achieve combinations of effects. The rest is implementation details.
stackoverflow[]
"... @Jonathan Sterling: The terms are often used ambiguously or misleadingly, particularly when arcane-but-precise academic jargon starts getting mixed with descriptive-but-fuzzy industry jargon, so it's easy to get the wrong idea. The same thing happens with formal mathematical concepts vs. their hand-wavy use in Haskell, which has led to me embarrassing myself in front of a couple mathematicians! – C. A. McCann Apr 25 '11 at 15:48 .... https://stackoverflow.com/questions/3124511/how-to-model-class-hierarchies-in-haskell/3124870#3124870
Instead of classes and objects, Haskell uses abstract data types. These are really two compatible views on the problem of organizing ways of constructing and observing information. The best help I know of on this subject is William Cook's essay Object-Oriented Programming Versus Abstract Data Types. See https://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf
links[]
http://winestockwebdesign.com/Essays/Lisp_Curse.html
https://wiki.c2.com/?ChallengeSixVersusFpDiscussion
https://wiki.c2.com/?ChallengeSixVersusFpDiscussion
https://syndicode.com/blog/pros-and-cons-of-functional-programming/
https://www.quora.com/How-would-you-explain-a-concept-of-monads-to-a-non-CS-person/answer/Panicz-Godek