The C syntax really makes this simple feature look terribly complicated. It's a while since I watched them, but in the SICP video lectures, as I recall, the no

The C syntax really makes this simple feature look terribly complicated. It's a while since I watched them, but in the SICP video lectures, as I recall, the notion of storing functions in variables - as introduced in, like, lecture 1 or 2 - took about 0.1% of the time - if indeed that. And that's because while the principles are actually more complicated than the C example (due to the lexically-scoped variable capture), the syntax is simplicity itself. Consider the issue of making a variable, which goes something like this: (let ((x 1)) (set! x (1+ x))) You have your "let", then the list of names and values, and then the stuff that makes use of them. Now consider the issue of making a function: (let ((x (lambda () (message "stuff")))) (x)) (Well... maybe they called it define. I don't remember.) The parallels are obvious, and indeed I suppose they deliberately chose this notation to emphasise the similarity between one type of value (e.g., an int) and any other (e.g., a closure). And so once you've got the hang of making a function that takes one type of value (e.g., an int), it's a small step from there to making a function that takes another type of value (e.g., a closure). This is a dig at C and its ilk rather than the article. It's ridiculous that such a fundamental, basic primitive is given such a baroque syntax. But then C strikes me as designed for people who already know how to program so maybe the assumption is that most users will already know what function pointers are when they come to it, probably from being familiar with indirect jumps in assembly language. This post is apropos of very little, I guess. I was just moved to comment after seeing six pages of stuff that still never got to the meat of the matter. So I suppose I should finish it like this: "</rant>"