4 of your 15 paragraphs start with "Anyway,". I thought that was interesting.
--Dave On May 2, 2013, at 9:08 PM, Levi Pearson wrote: > That's an interesting article, and it's not entirely wrong, but the > premise is flawed. JQuery is not actually a monad in any reasonable > sense of the term. Let me give a bit of background on monads, but I > will not pretend that anyone is likely to suddenly understand them > just from my explanation. Like a lot of things, especially abstract > things, you have to develop an intuition for them through study and > practice. > > Like the article said, Monads come from Category Theory. Some > mathematicians used to call it the 'theory of abstract nonsense' or > something like that (and some of them may still call it that) but it's > really just a continuation of the basic trajectory of mathematics. > Mathematicians can be compared to programmers. For a programmer, the > basic unit of work is a program, by which we'll mean a set of > instructions that encode an algorithm for execution on a computer. > For a mathematician, the basic unit of work is a proof, by which we'll > mean a series of arguments that describe (primarily to other > mathematicians) why some statement about some feature of a > mathematical system must be true. > > Mathematicians, it has been said (as has been said of programmers), > are fundamentally lazy, and would like to do as little actual work as > possible to get their results. There are a lot of areas of > mathematical research, and most of them started by someone thinking, > "What would happen if I changed this thing we tend to assume does not > change?" Exploration of these kinds of ideas can open new fields of > mathematics, and eventually physics and engineering. But the result is > that there's a lot of stuff in common between different fields of > mathematics. So, in the interest of laziness (or economy, if you want > to be nice) mathematicians have been looking for ways to prove things > about whole groups of mathematical systems based on the properties > that they have in common. When you prove something in a framework > like that, you can use the proof in any new (or established) field of > mathematics just by showing that your field adheres to the properties > that were assumed by your proof. > > This process has led (over hundreds of years) to increasingly abstract > ways of looking at mathematics and proof. If you start with basic > counting and arithmetic, you can abstract over that by forming > algebra, in which you can replace concrete numbers with abstract > variables and show that equations hold for whole patterns of > mathematical expressions. If you look at the concept of a number, it > turns out that it can refer to several differen things of increasing > complexity: the positive integers, the natural numbers, the rational > numbers, the real numbers, the complex numbers, etc. It turns out > that we can refer to all of these distinct things as simply 'numbers' > because they all obey the same set of arithmetic properties. This > form of abstraction developed into set theory, group theory, etc. > > Category theory is sort of the next step in the abstraction ladder. > The idea is to do proofs in a very abstract domain that show how > potentially very different fields of mathematics can map to one > another, so that proofs in this abstract domain can apply to huge > areas of mathematics. Because it's so abstract and removed from > everyday arithmetic, there's no common vocabulary for describing these > abstract objects. Their value to mathematics is in the fact that they > are so abstract, so attempting to explain them in more concrete terms > is necessarliy a weakening of what they are. Like any specialized > field, the vocabulary is unique and it takes time to develop a feel > for what the terms mean. I'm still not all that great at it, so I > won't attempt to dive into a deep explanation. > > Computer scientists and programmers do a similar thing with programs. > You can create languages that abstract over different properties of > programs. I think you're all somewhat familiar with this idea, so I > won't get into it too deeply, but you can probably see a bit of a > correspondence between this method of forming abstractions and the > method of forming abstractions that mathematicians use. It turns out > that when you are a computer scientist studying programming languages, > it's helpful to be a bit of a mathematician as well, because > mathematics is very useful for describing the properties of things and > providing a context for proving things about them. > > Anyway, a programming language can be described in terms of three > basic families of characteristics: syntax, which is the form of the > langauge, or set of symbols and their combinations that make valid > statements in the language; semantics, which is how you can tell what > the valid statements of the languages *mean*; and pragmatics, which > includes all the messy details about the mapping between the meaning > of the language and the machine it's going to run on. Of all these, > the semantic family of characteristics are most interesting to > langauge researchers, because these contain the real power of the > language to carry meaning. So, if you want to say something very > precisely about the meanings of programs in your language, you need to > formally define the semantics of the language, and by "formally > define" I mean capture the meaning of the language in some sort of > system of symbols that can be mechanically manipulated (by human or > computer) to deduce properties of the program. > > There are a number of ways to do this, but the primary ones are > operational semantics, denotational semantics, and axiomatic > semantics. They are by no means exclusive; it can be useful to define > some features of the language via one semantic model and some in > another, or to apply different models to the same features in order to > explore different properties of the features. Operational semantics > basically describe the what the language means with respect to some > sort of an "abstract machine" and the way the language maps onto > operations in that machine, or sometimes by direct syntactic > manipulation and rewriting of the language according to a set of > transformation rules. Denotational semantics maps statements in the > language into some sort of direct mathematical statement, generally in > a specific field of mathematics such as a flavor of set theory, type > theory, or domain theory. Axiomatic semantics say that a statement in > the language means precisely what can be logically proved about it. > > Anyway, computer scientists have been working on the formal semantics > of programming languages for about as long as programming languages > have existed, which means that they've had to map languages like > Fortran directly to mathematical statements or operations on a > mathematically-defined abstract machine. Although statements in > Fortran look a lot like mathematics and share a lot of similarities, > the fact that variables can be assigned to is a foreign concept to > mathematics and has to be mapped to something else, which is generally > called the 'store'. I won't get into all the details, but the general > idea is that statements are mapped into their semantic definition as > operations that occur in sequence and which take the current state of > the store as an input, returning a modified store as an output. > > Anyway, this had been the standard way of doing things for a while, > and all the management of the store and the way that statements > interacted with it had to be carried around in the way you described > the operational semantics. This was a bit awkward, and eventually a > guy named Eugenio Moggi discovered that the Category theorists had > come up with an abstract bit of mathematical structure that was a very > close fit for the work you need to do in programming language > semantics of stateful languages. He showed in a paper how you could > use a categorical thing called a Monad to represent the state of a > program, and the structure of the Monad could be made to describe the > sequencing of statements and modification of state from statement to > statement. This let you apply all the ways of manipulating > categorical structures that the category theorists had been working on > to the proofs you were trying to make in your semantics as well as > giving a clearer notation for describing things. This technique > eventually got adopted on a wider scale into the CS field of > operational semantics. > > Some time later, programming language researchers who were working on > purely functional programming languages decided that it would be in > their best interest to take all the many languages that they'd been > working with as the field developed and combine what they'd learned > from them into a single language that would be a sort of 'lingua > franca' for functional programming research. This had been done > previously with languages like Algol, and to a lesser extent Scheme, > but new developments in the mathematics of programming language theory > demanded a language that played to the strengths of those > developments. So, Haskell was born as a research collaboration > language. It didn't have to worry much about pragmatics like how to > do I/O, because the primary purpose of the language was to examine and > develop the semantics. But eventually people wanted to do real > programming with it, partially to validate all the work they'd been > doing on developing a sophisitcated language. What use is a > sophisticated language if you can't make any flashy programs with it? > So Haskell developed a few different ways of doing I/O that were > mostly rather awkward and embarrasing, though you can actually find > research papers describing how cool they were. > > Anyway, at some point Simon Peyton Jones, an employee of Microsoft > Research and one of the driving forces behind the development of > Haskell, realized that Moggi's work on describing the operational > semantics of programming languages via Monads could be implemented > pretty directly in Haskell, thanks to the fact that the meaning of > Haskell programs maps fairly cleanly to mathematical statements, and > vice versa. So he could write the operational semantics for an > embedded DSL describing the meaning of I/O operations directly in > Haskell, making the Haskell implementation the abstract machine. This > let him take advantage of the notational clarity Moggi had developed > to make a pretty clear description of the I/O operations and their > sequencing in a Haskell program. Although this was a big improvement > by itself, he realized that he could take one more step and make a bit > of syntactic sugar that mapped the Monadic expressions back to > statements in a simple concrete statement-based language. This gave a > very friendly way to write I/O operations in Haskell. > > This was very cool in itself, but the fact that it was done via the > mapping capabilities of operational semantics and category theory > meant that he hadn't just introduced an I/O system; he'd introduced an > abstract DSL syntax that could have its operational semantics > reprogrammed within Haskell! The I/O Monad defined one meaning for the > basic operations, but because of the way the Type Class mechanism > works in Haskell, you could provide an entirely different set of > operations for your own Monad type (Monad itself is a Type Class, not > a single type) providing they met the required interface and followed > the Monad Laws (which let you use the category theory theorems to > reason about how the operations combine with other structures in > category theory, and are what make them actually a Monad instead of > just some ad-hoc collection of operations). Once you define a new > Monad, the way in which a do expression is interpreted depends on the > operational semantics you defined with that Monad. > > I hope you can see that while this is a pretty abstract thing and a > bit difficult to take in all at once, it's a very powerful thing to > have in a language. It basically changed the course of Haskell > development for the next decade or so as people delved into Monads and > category theory and discovered how many basic types in Haskell could > be mapped into Monads and thus gain access to the 'do' syntax and all > the mechanisms and logic that had been built up around the Monad Type > Class. It turns out that Monads are a fairly specialized form of > structure in category theory, and more abstract structures could be > expressed in Haskell as well. When you wrote programs in terms of > these abstract structures, you could re-use the same implementations > of operations whenever a type you defined happened to map cleanly to > one of the structures. And, just like the way that natural numbers > and real numbers both adhere to the same kinds of rules for combining > things arithmetically, it turns out that many structures in programs > adhere to some basic kinds of rules for combining things. A lot of > these groups of rules for operating on things have been collected and > given funny names, and they can help you organize programs and take > advantage of work that's already been done in defining how those rules > for operating on things have been implemented. > > By now, I will be surprised if anyone is still reading, but if you > have got this far I hope that you see a bit of the idea behind the > motivation for all the weirdly named bits in Haskell, and how they're > really general concepts that actually show up all the time in > languages, since they were originally developed in the context of > computer science to describe how normal stateful procedural languages > work! If anyone has specific questions or would like pointers for > further avenues of study, let me know and I'll be happy to try to > provide answers or references. > > --Levi > > On Thu, May 2, 2013 at 8:30 AM, justin <[email protected]> wrote: >> This is probably the most useful article on monads I've seen: >> >> http://importantshock.wordpress.com/2009/01/18/jquery-is-a-monad/ >> >> --j >> >> >> On Thu, May 2, 2013 at 7:06 AM, justin <[email protected]> wrote: >> >>> A monad is a monoid in the category of endofunctors, what's the problem? >>> >>> >>> On Thu, May 2, 2013 at 5:36 AM, S. Dale Morrey <[email protected]>wrote: >>> >>>> I just read that Java 8 will include Monads. I tried to google the term >>>> and came up with mind blowing complex stuff which may have stripped a gear >>>> in my brain. >>>> >>>> Can someone please explain in terms so simple a Java programmer can >>>> explain, what the heck is a monad or more importantly what would be a >>>> valid >>>> use case for one? In fact I'm not sure what they are is as important as >>>> why, when or how I would use one (or several) since of course I tend to >>>> learn by example. >>>> >>>> If there is anything similar in Perl, PHP or Python, those examples would >>>> be helpful too. >>>> Car analogies appreciated as well. >>>> >>>> Thanks! >>>> >>>> /* >>>> PLUG: http://plug.org, #utah on irc.freenode.net >>>> Unsubscribe: http://plug.org/mailman/options/plug >>>> Don't fear the penguin. >>>> */ >>>> >>> >>> >>> >>> -- >>> http://justinhileman.com >>> >> >> >> >> -- >> http://justinhileman.com >> >> /* >> PLUG: http://plug.org, #utah on irc.freenode.net >> Unsubscribe: http://plug.org/mailman/options/plug >> Don't fear the penguin. >> */ > > /* > PLUG: http://plug.org, #utah on irc.freenode.net > Unsubscribe: http://plug.org/mailman/options/plug > Don't fear the penguin. > */ > /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
