Michael Vanier writes about programming language theory, covering the Y combinator, monads, and the choice of foundational languages.
HN commenters point to his Y combinator explanation and monad tutorial as clear, and cite his critical view of Ruby.
If it helps, I'm rather fond of this explanation: https://mvanier.livejournal.com/2897.html
Especially this part, from toward the beginning:
> Before I get into the details of what Y actually is, I'd like to address the question of why you, as a programmer, should bother to learn about it. To be honest, there aren't a lot of good nuts-and-bolts practical reasons for learning about Y. Even though it does have a few practical applications, for the most part it's mainly of interest to computer language theorists.
The article goes on to explain why you should learn it, anyway, but, still, it's not like monads and Haskell. Despite the concept's intellectual cachet, you don't need to understand it to be an effective lisper. That said, this opinion is mine and mine alone, and stands in direct contradiction to the sentiment expressed in the following paragraph.
Well, they're both foundational languages, pretty much, not in the sense of this blog, i.e. most instructional language
http://mvanier.livejournal.com/998.html
but in the sense of can you put up a significant web app in 2 or 3 days, do lots of companies use it (along with C, java, C#, javascript).
r vs. p can't be reduced to 15 bullet points, but one of the best things i remember is Alex Martelli in 2003, so he was talking about ruby 1.6 and python 2.3, i believe, but still valid
http://groups.google.com/group/comp.lang.python/msg/28422d707512283
and here's the last thread from May.
http://news.ycombinator.com/item?id=157269
There's the other killer apps: Python: twisted, zope, SQLalchemy, mercurial. Ruby: rake, capistrano, rspec, adhearsion, merb, puppet, metasploit. I'm sure python has a bunch more, but i've been living in rails-land.
TXR Lisp:
(defun y (f)
[(op @1 @1)
(op f (op [@@1 @@1]))])
It looks like the Haskell one is calling itself by name: (y f) appears in the right hand side. That's against the spirit of the exercise. The Y combinator is a way of boostrapping the ability to have functions be able to call themselves in a language which doesn't have named functions as a primitive.
See here: https://mvanier.livejournal.com/2897.html starting at "Deriving the Y combinator" where it presents a lazy version of Y in Scheme, similar to the Haskell one and argues that it's not valid.
Regarding the Scheme version, there is a shorter form:
(define (Y f)
((lambda (x) (x x))
(lambda (x) (f (lambda (y) ((x x) y))))))
This is analogous to the TXR Lisp one above which rewrites the lambda terms using op syntax.
Fun to try with code (mildly). Here's the geekiest I could do that's worth sharing :-) http://i.imgur.com/IBaLCn4.png - based on the first stanza from the following:
Tiger got to hunt,
Bird got to fly;
Lisper got to sit and wonder, (Y (Y Y))?
Tiger got to sleep,
Bird got to land;
Lisper got to tell himself he understand.
— Kurt Vonnegut, modified by Darius Bacon,
(as quoted on this blog entry http://mvanier.livejournal.com/2897.html about y-combinators)
In Haskell and PureScript, Monad is a typeclass just like any other.
They are an abstraction, effectful computation is not inherent to them, they represent computational contexts, e.g. the list monad is used to model non-determinism, the maybe monad represents computations that can fail, both of these are pure.
This is an excellent set of posts for building an intuition about monads: http://mvanier.livejournal.com/3917.html
afaik it's pretty academic. The only practical application is to allow recursion in languages that don't do recursion which is pretty much none.
This is a good description if you're into that sort of thing: http://mvanier.livejournal.com/2897.html
The meat of it is that you can 'do' recursion by building up functions that call other functions :/ meh