26 Jan
2012
26 Jan
'12
1:20 a.m.
On 25/01/12 5:37 PM, Liam Proven wrote:
On 6 January 2012 16:45, Robert Smith<quadricode at
gmail.com> wrote:
Google, first hit:
http://mitpress.mit.edu/sicp/
* Types and Programming Languages by Pierce
This book explains type theory and the theory of programming languages. ...
* Purely Functional Data Structure by Okasaki
Talks about data structures which are immutable and efficient, suitable for
purely functional languages. ...
* Introduction to Functional Programming using Haskell by Bird
This is a book, *not* about Haskell, but rather about functional
programming. ...
* Learn You A Haskell For Great Good by Lipovaca
Okay, now if you want to be spoonfed Haskell and functional programming,
read this. ...
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.
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).
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. 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?
No, of course not, but you insist on saying they are.
--Toby
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.