25 Jan
2012
25 Jan
'12
2:37 p.m.
On 6 January 2012 16:45, Robert Smith <quadricode at gmail.com> wrote:
SICP should explain closures just fine. I mean, not only are closures (and
lexical scope as a prerequisite) explained, but you also use closures in a
practical way. And there is no way SICP is poor.
I am amused that you don't even explain what that ETLA stands for.
I've added it to my Bookmooch wishlist, anyway, although I doubt I'll
get it in time to be much help.
Pretty much every source I have found says /the Little Schemer/ is a classic.
Have you ever actually /seen/ it?
It's in Greek, I swear it!
The first page starts:
?
*The First Commandment*
When recurring on a list of atoms, /lat/, ask two questions about it:
(null? lat() and *else*.
?
That's _before the Foreword._
The text itself starts:
?
Is it true that this is an atom?
atom
Yes, because *atom* is a string of characters beginning with the letter *a*.
?
I mean, really, WTF? An instructional text that starts by asking
questions about undefined terms? /Really?/
That's worth knowing, but it overall, your answer seems strange to me.
Apart from the incomprehensible examples, that is.
Are the concepts of "closure" and "lambda calculus" really /so/
recondite that they cannot be understood except by reading entire
book-length exegeses and learning a whole new skill?
I find this implausible.
I do not *understand* the Poincar? conjecture, but a mathematician
friend of mine, over the course of a 45min talk, gave me enough of the
shape of thing to get the gist of it, and to understand the general
thrust of Grigori Perelman's essentially topological proof of it - the
one that won him the Fields Medal, which he declined to accept. These
are decidedly NOT simple subjects, but they /can/ be explained to
non-technical people.
I simply cannot accept that two basic elements of a programming
language (or family thereof), which several here are maintaining is
the best one for beginners to learn, is more complex than this.
--
Liam Proven ? Profile: http://lproven.livejournal.com/profile
Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven
Tel: +44 20-8685-0498 ? Cell: +44 7939-087884
* Types and Programming Languages by Pierce
This book explains type theory and the theory of programming languages. You
write several little interpreters, like an interpreter for the core, untyped
lambda calculus. You learn about the relevance of lambda calculus as a
fundamental computer science concept, and how one builds upon that. As said,
it explains type theory too.
* Purely Functional Data Structure by Okasaki
Talks about data structures which are immutable and efficient, suitable for
purely functional languages. This is more about functional programming than
the lambda calculus.
* Introduction to Functional Programming using Haskell by Bird
This is a book, *not* about Haskell, but rather about functional
programming. That is, it's relatively language unspecific, but uses Haskell
as a vehicle for examples.
* Learn You A Haskell For Great Good by Lipovaca
Okay, now if you want to be spoonfed Haskell and functional programming,
read this. You'll start with syntax, recursion, and types; and it'll carry
you to monads, zippers, applicative functors, randomness, etc.
It does not talk about really serious stuff like unsafe IO, some of the
finer points of lazy evaluation, monad transformers
Um. Thanks for the suggestions, but I have to point out that I can't
really buy and read half a dozen textbooks in order to finish a 2 or 3
thousand word article. I mean, ideally, I'd be knocking out a couple
of such pieces a day if I were a staffer and at least a few a week as
a freelancer. This simply does not permit such a depth of research!
Closures: again, I have yet to find a readable,
comprehensible
explanation of what they are, what they are good for, why they are
powerful and what strengths they confer onto a programming language.
Readable and comprehensible explanations:
* SICP
* Programming in Scheme (Abelson & Eisenberg)
* aforementioned Henderson.
and dozens of others. There are A LOT of good functional programming
texts out there, many dating back to the 70s and 80s of course, and far
in conceptual advance of the mainstream (PHP! ASP.NET! Java! snore).
* Let Over Lambda by Hoyte
Chapter 1 of this book dives into a pragmatic explanation of what a closure
is by describing it as a "Let Over Lambda". For example
(define closure
?(let ((x 2))
? ?(lambda () (display x)))
This is an extremely simple example.
Er. It may be, but it is not simple enough for me to follow, I'm afraid.
This is why I marked these messages as read & have come back to them
to reread them once a week or so all this month. I am not getting any
closer to enlightenment.
CLOSURE is bound to a lambda
expression. But not just some pure lambda, it has extra information about
its environment. So it's a lambda (code) + environment (data). If we proceed
to call CLOSURE, we get:
Er...
(closure)
2 We can be more fancy:
(define counter
?(let ((count 0))
? ?(lambda ()
? ? ?(set! count (+ 1 count))
? ? ?count)))
Here the lambda captures COUNT. Now we call COUNTER a few times:
I'm sorry, but I don't follow at all. Code examples in a language I
don't understand - and references to another one I don't know - do not
really help, I'm afraid. Sorry for my inadequate understanding.
(counter)
1
(counter)
2
(counter)
3
Look ma! Encapsulation! COUNT is not accessible from the outside. C++ers
might call this a ~private variable~, but really it's just a variable closed
inside some execution context. Anyway, that's what Chapter 1 of said book talks
about.
* Lisp In Small Pieces by Quiennec
This talks about compiling Lisp if you're interested in how closures might
be compiled. It also talks about formal semantics and other mathy stuff.
This is /way/ too much for me, I fear.
> If the
teaching& reference materials that I have found so far are
> unable to convey these core concepts, then there would seem to be two
> possible conclusions:
>
> [a] /all/ the materials that I've been able to find are extremely
> poor, even the ones that are more or less universally agreed to be
> very good
>
> or
>
> [b] these are complex, difficult concepts and a massive amount of
> back-knowledge is necessary to understand it.
No, these are not necessarily poor nor complex just because *you* don't
understand it. > I would
*REALLY* like and hugely value any pointers, ideally web links
> but print references would do as well, as to these concepts.
>
> But are there other possible explanations that I have missed? That
> these things are easy but all the texts are rubbish?
>
The best way to go about it is to actually write some programs in Scheme or
Standard ML or Haskell or whatever. Then you actually internalize what
things mean, instead of these abstract definitions like what the semantics
of lambda is. You'll find the easy-to-understand books typically do the
programming for you by showing you code examples.
Remember, programming isn't like history, where you can just read a book and
understand what's going on. It's more like medicine and being a doctor,
where both book reading *and* practice are important, the latter being
almost surely more important.