tag:blogger.com,1999:blog-33103854.post8700663048796923287..comments2023-05-22T14:15:21.482+02:00Comments on Karsten Wagner's Blog: Why monads are 'evil'Karsten Wagnerhttp://www.blogger.com/profile/09652404623625038743noreply@blogger.comBlogger28125tag:blogger.com,1999:blog-33103854.post-49855742388196795882013-09-27T02:44:55.173+02:002013-09-27T02:44:55.173+02:00Those that believe this is "ignorant tripe&qu...Those that believe this is "ignorant tripe" or that Karsten "completely misunderstood the definition of functional programming" are incorrect.<br /><br />Please see also: http://conal.net/blog/posts/can-functional-programming-be-liberated-from-the-von-neumann-paradigm<br /><br />Conal completely understands functional and monadic programming, yet shares an equivalent opinion Buckhttps://www.blogger.com/profile/14381479492212729903noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-53067459454205190362013-06-22T15:35:48.335+02:002013-06-22T15:35:48.335+02:00It is interesting. I must admit that at first I di...It is interesting. I must admit that at first I didn't understand what you said. I had to read your comments to see what you saw wrong with monads.<br />My understanding was that it was not hidden under the carpet, but taken care of by the compiler instead of the programmer : the programmer write mostly in the functional world, and uses bind to interact with the outside world. <br /><br />NowAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-33103854.post-74747298094285883962011-07-23T10:33:32.629+02:002011-07-23T10:33:32.629+02:00I have refined my understand, which is explained a...I have refined my understand, which is explained at the following link:<br /><br />http://goldwetrust.up-with.com/t112p180-computers#4434<br /><br />As Peyton-Jones elucidates in "Tackling the Awkward Squad", IO Monad is simply (one of) Haskell's way(s) of mixing impure, imperative code with pure, declarative code. To the extent that you can make your interface to the world shelbyhttps://www.blogger.com/profile/04192118408905938326noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-1446956819452974352011-06-24T15:35:21.706+02:002011-06-24T15:35:21.706+02:00I agree with Karsten about IO monad, and I explain...I agree with Karsten about IO monad, and I explained it in a different way in a post which followed this one:<br /><br />http://apocalisp.wordpress.com/2011/05/30/imperative-vs-functional-programming/#comment-4561<br /><br />It was censored, but I have a copy here:<br /><br />http://goldwetrust.up-with.com/t112p180-computers#4434shelbyhttps://www.blogger.com/profile/04192118408905938326noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-33629851734533393482010-12-21T05:26:14.726+01:002010-12-21T05:26:14.726+01:00I agree with the main point of this post. You see ...I agree with the main point of this post. You see many times I see clever programmers sacrificing readability for by using monads to save a few lines of code. Like the author says, monads like lisp macros can result in elegant code but at the expense of a reader who is not familiar with the given macro or monad. However, no one can deny the sheer beauty and elegance of a well designed monad and ShowPonyhttps://www.blogger.com/profile/07870841144965376439noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-31968716348562687042009-12-20T02:37:18.235+01:002009-12-20T02:37:18.235+01:00IO is no less pure than your world-passing alterna...IO is no less pure than your world-passing alternative. Bind /is/ referentially transparent. In your first example, bind simply chains the actions together. It doesn't execute anything. These actions are passed around without ever losing any purity. The second bind you mention doesn't exist. Monads are no "trick"- the runtime takes the evaluated main action and executes it, not Ruskyhttps://www.blogger.com/profile/17077098677917743715noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-33928390616937894892009-09-03T09:42:41.094+02:002009-09-03T09:42:41.094+02:00I think you will identify with Conal Eliott's ...I think you will identify with Conal Eliott's work, which shares some ideas about I/O's and Monads.<br /><br />For example, this piece trying to use satire in order to explain that using the IO type is indeed not "purely functional programming":<br /><br />http://conal.net/blog/posts/the-c-language-is-purely-functional/<br /><br />And of course, his work on FRP (http://conal.netPeakerhttps://www.blogger.com/profile/18054587706979539795noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-72428580480763282802007-12-31T16:58:00.000+01:002007-12-31T16:58:00.000+01:00Hi, Karsten,I am certainly a Haskell newbie, but I...Hi, Karsten,<BR/><BR/>I am certainly a Haskell newbie, but I've always understood the monadic IO issue in this way:<BR/><BR/>1. Impure (side-effectful) behavior is inevitable; we use computer programs because we want something to happen in the real world (e.g. my resume to be printed on my laser printer).<BR/><BR/>2. Pure functional programming (whenever possible) is good because RT allows me to uncialhttps://www.blogger.com/profile/15225671465200387626noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-38755448192494552942007-07-24T02:58:00.000+02:002007-07-24T02:58:00.000+02:00@Karsten, I don't have anything concrete to add, b...@Karsten, I don't have anything concrete to add, but want to say I appreciate you thinking out loud and questioning things. Please keep doing that, we don't need everyone to be complacent.<BR/><BR/>@Helpful others, I also appreciate you being willing to engage with Karsten to figure out what the middle ground is (apparently namely that IO is the sin bucket).<BR/><BR/>Both of you help folks like Raoul Dukehttps://www.blogger.com/profile/07354740962526930549noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-50457031096099522752007-05-06T15:31:00.000+02:002007-05-06T15:31:00.000+02:00My experience with monads is limited, but, as far ...My experience with monads is limited, but, as far as I know, the "do" transformation into >>= operator sequence and the operator transformation into standard function call notation is done at compile time, not at runtime. There is no difference in performance and lazines with pure functional notation. The code generated in fact stays functional.<BR/><BR/>In Monads, the sequencing of operations ismemetic warriorhttps://www.blogger.com/profile/11962281728014883353noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-72601468723441881152007-02-12T17:21:00.000+01:002007-02-12T17:21:00.000+01:00Karsten, I'm afraid you've mistaken STM monad with...Karsten, I'm afraid you've mistaken STM monad with ST monad in your last comment. They are different things for different purposes.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-33103854.post-6342787594817078502007-02-07T13:56:00.000+01:002007-02-07T13:56:00.000+01:00> If you keep an undo/backtrack action attached to...> If you keep an undo/backtrack action attached to information to be garbage collected, it cannot be freed.<br /><br />Like in every application which uses undo/redo. Nonetheless most applications use it. So it's obviously a solvable problem.<br /><br />> as the relevant operations could have mutated farther along. <br /><br />With r.t. there is no mutation, so this can't happen.<br /><br />> So,Karsten Wagnerhttps://www.blogger.com/profile/09652404623625038743noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-1562302111335266522007-02-07T02:57:00.000+01:002007-02-07T02:57:00.000+01:00@wellsed:
> What's not fair is that your arguemen...@wellsed:<br /><br />> What's not fair is that your arguements for such criticism are grossly incorrect.<br /><br />Then please show where they are incorrect. If I'm so obviously wrong, then this should be simple.<br /><br />And of course I know about CiteSeer. Do you want to insult me?<br /><br />Btw: Have you read Wadlers "How to Declare an Imperative" (can be found <a href='http://Karsten Wagnerhttps://www.blogger.com/profile/09652404623625038743noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-20618198588444847632007-02-06T18:01:00.000+01:002007-02-06T18:01:00.000+01:00If I make a false assertion (which is totally poss...If I make a false assertion (which is totally possible, has happened and will happen again - like with every human) I'm happy to be corrected. If somebody can't stand this, he shouldn't read <i>any</i> blog anymore.<br /><br />I'm totally convinced that functional programming is a very powerful thing with big promise in the future. But I also think that not <i>everything</i> in the area is a goodKarsten Wagnerhttps://www.blogger.com/profile/09652404623625038743noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-23808686546814710412007-02-06T17:37:00.000+01:002007-02-06T17:37:00.000+01:00Karsten,
As a separate note: you seem convinced t...Karsten,<br /><br />As a separate note: you seem convinced that all actions in the world can have undo/redo semantics. <br /><br />This is observably untrue. Some things cannot be undone.<br /><br /> High-level languages depend upon garbage collectors to free memory from unreferenced data structures. This is a destructive action that cannot be undone. If garbage collection could be undone Ed Wesley Wellshttps://www.blogger.com/profile/10475241665359459131noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-59178110514548639672007-02-06T17:30:00.000+01:002007-02-06T17:30:00.000+01:00Karsten,
Its fair enough to have your own opinion...Karsten,<br /><br />Its fair enough to have your own opinions, we all do. Its very fair to criticize language features.<br /><br />What's not fair is that your arguements for such criticism are grossly incorrect. However, I had not really taken time to understand Clean's IO system (to much to do as it is), but I'm doing so now.<br /><br />In the meantime, I've found a lovely paper detailing an Ed Wesley Wellshttps://www.blogger.com/profile/10475241665359459131noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-12919948797789773732007-02-06T09:04:00.000+01:002007-02-06T09:04:00.000+01:00Karsten, don't mind Slava too much. People are li...Karsten, don't mind Slava too much. People are likely frustrated because of the numerous <i>completely false</i> assertions you make about Haskell, so it's very difficult to take your post seriously. The most egregious is the repeated assertion that the IO monad breaks Haskell's referential transparency. This is <i>false</i>. The existence of IO doesn't break referential transparency, it in Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-33103854.post-55900817750581233232007-02-02T23:45:00.000+01:002007-02-02T23:45:00.000+01:00@wellsed:
Haskell is lazy, but of course you can a...@wellsed:<br />Haskell is lazy, but of course you can also force strictness (by using the seq-operator). And if you would write a program which returns some value the compiler would enforce that this value is really computed - or the whole program would end completely unevaluated. And of course I know about all this - if not then I wouldn't wrote about how interaction could be done by lazy Karsten Wagnerhttps://www.blogger.com/profile/09652404623625038743noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-45341285681885425662007-02-02T23:18:00.000+01:002007-02-02T23:18:00.000+01:00@Cale Gibbard:
I've just read this document writt...@Cale Gibbard:<br /><br />I've just read <a href='http://portal.acm.org/citation.cfm?id=606670&dl=ACM&coll=&CFID=15151515&CFTOKEN=6184618'>this document</a> written by two of the Clean developers. On page 26 there is a paragraph which I want to quote (typing errors and the part in [] are from me):<br /><br />"This system [monadic I/O] is simple but has the disadvantage that all objects to be Karsten Wagnerhttps://www.blogger.com/profile/09652404623625038743noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-55822609111808344062007-02-02T22:05:00.000+01:002007-02-02T22:05:00.000+01:00Karsten, I do not know your background, but it is ...Karsten, I do not know your background, but it is clear you have misunderstood a few things.<br /><br />First and foremost, it appears you do not understand evaluation in a Haskell program.<br />The non-strict (aka "lazy") semantics of Haskell mean that a program does not have an<br />a priori evaluation order. It is an undecideable problem to determine a Haskell program's <br />evaluation orderEd Wesley Wellshttps://www.blogger.com/profile/10475241665359459131noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-19024658361162456042007-02-02T21:30:00.000+01:002007-02-02T21:30:00.000+01:00@Slava Pestov: I've long held you in high esteem, ...@Slava Pestov: I've long held you in high esteem, but more and more often I see you post insulting crap.<br /><br />Just because somebody does not like some things about functional programming (and hey, it's all opinion and taste!), does not mean he's an idiot.<br /><br />I've learned and used many languages, including Common Lisp, SML, Assembler. Now I'm a Java guy who's done with FP + Lisp. Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-33103854.post-65172433466431078982007-02-02T21:03:00.000+01:002007-02-02T21:03:00.000+01:00There are some important ways in which monadic pro...There are some important ways in which monadic programming is different from imperative programming though, even in the I/O monad. Most imperative languages don't give you such ability to glue actions together in new ways. Representing actions explicitly gives you the ability to write your own control structures whose definitions are expanded at runtime. The Control.Monad module is full of such Cale Gibbardhttps://www.blogger.com/profile/02239068589033148700noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-13731500512943032522007-02-02T13:45:00.000+01:002007-02-02T13:45:00.000+01:00@Arthur:
The question is what we want: A language ...@Arthur:<br />The question is what we want: A language which supports a certain paradigm or a multi-paradigm language with a certain core-paradigm. It's not a problem that we can program imperatively in every language as we can program functional in every language. The question is always how much work we need to do to switch paradigms. By using monads this switching isn't just easy, it even Karsten Wagnerhttps://www.blogger.com/profile/09652404623625038743noreply@blogger.comtag:blogger.com,1999:blog-33103854.post-52359754298368567422007-02-02T10:43:00.000+01:002007-02-02T10:43:00.000+01:00Dear Karsten,
I'm quite new to Haskell so maybe ...Dear Karsten, <br /> I'm quite new to Haskell so maybe I'm really missing your point. As far as I understand in the early days IO in Haskell was approached via two (equivalent) techniques (which I could consider "more" functional): streams and continuations. For example Stream IO would mean that the main function would have type main::[Responses]->[Requests] where the program would <i>lazily</i> Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-33103854.post-71525855256039002242007-02-02T09:48:00.000+01:002007-02-02T09:48:00.000+01:00Karsten, you seem to have completely misunderstood...Karsten, you seem to have completely misunderstood the definition of functional programming. Yes, you can do functional programming in an imperative language (given enough rope to hang yourself with). Yes, you can do imperative programming in a functional language. This is not news: denotational semantics already provided a functional interpretation of imperative languages. And denotational Arthur van Leeuwenhttps://www.blogger.com/profile/02659194414320690064noreply@blogger.com