http://cs.brown.edu/~sk/Publications/Papers/Published/fffk-h...
It seems to me that FP is having quite a renaissance recently, which could limit the relevance of that paper's contentions today. I'm also seeing quite a backlash against OOP and especially OOP as the One True Paradigm that it was pushed as in throughout the 00s - this can be seen not only in FP language growth but also in the design of other new languages like Go that lack many OOP features.
Honestly, I would argue for the "Never Compromise" route for undergraduate regardless of current trends. I've found firsthand that mid-to-high-achieving high school students are able to grep SICP just fine, even if they haven't been introduced to calculus as of yet. But I haven't read HtDP or PPL yet, so I can't really pass judgement on which book would be better.
It seems that FP is always having a renaissance. I distinctly recall lots of people (including me) talking in 2001-2002 about the big FP renaissance just round corner. I also recall a few old school lisper rolling their eyes at us and saying that they where saying the same thing back in the early-mid 80's.
I worked through it for a class, and I distinctly remember a moment where I thought "what the fuck - did I just write a working type inferencer?". It has a great way of simplifying things to the point where adding a complex new language feature isn't a distant theoretical proposition, it seems like a simple and straightforward next step. Of course, it helped that I had a great instructor.
I can't speak for this new book, but it seems like an interesting combo of intro to programming and programming languages. And it's in pyret, which is like the bastard child of python and plt-scheme: http://www.pyret.org/
EDIT: just skimmed through the text, you seem to be using "type-like annotations" mentioned in Pyret docs.
Another thing to note - Pyret is much more readable/enjoyable (and I guess writable :)) than the previous lisp languages you've used. Thanks!
I don't know why you say types are an afterthought. HtDP teaches a profoundly _typed_ discipline of programming. The datatype mechanism in PLAI continues this with more enforcement. And plai-typed is anything _but_ an "afterthought", right?
PAPL is written as if types work. We have an internal type-checker that I've been using off-and-on this semester (but it's still in development). As soon as it's ready, all programs in the book will pass through it and the book will be almost completely typed.
I'm not going to get into an argument here about whether it is better to start with static types. Though I somewhat share @noelwelsh's viewpoint, I think the full situation is far more complex and demands actual research — HCI research — as opposed to just matters of opinion (including mine).
I'm sure Shriram will correct me if I'm wrong.
I keep hearing your name, first because Kathi was my beloved teacher and advisor, second because Justin worked with you, and third because I made Frank Goodman take your class. Maybe we'll finally meet one day!
At any rate, I'm committed to having a full copy of the book available for free to all, as is also true of HtDP (we were one of the pioneers in this space) and PLAI (which has even more free/commercial options than HtDP).
You may assume at least a CC BY-NC-ND, which lets typical users have at it right away.
If it has no DRM but is 'all rights reserved', and I really want a copy, I wait for a chance to buy it at a deep discount.
If it is released under a CC 'non-commercial' license, I buy a copy at full price.
If it is released under a CC license which allows commercial use, I pay extra for a copy (at sites like www.leanpub.com) or buy 2 copies.
At any rate, I would gladly pay for a copy (or two) of PAPL if the option were available and a CC license declared.
BTW, thanks for this resource!
"The simplest notion of an object—pretty much the only thing everyone who talks about objects agrees about—is that an object is:
a value, that
maps names to
stuff: either other values or “methods”."
(I don't want to start a debate or anything, just thought it was a practical, minimal definition)
> If you ask Pyret for the value of this program, it will unsurprisingly tell you that it’s 3.
I am not sure how to do that. In [this tutorial](http://www.pyret.org/docs/latest/A_Tour_of_Pyret.html#%28par...) everything is a test. Is the program 3 supposed to be run as a test as well? Just running 3 in the editor does nothing. Where can I read up on Pyret syntax so i can follow this book?
> 3 3 > 1 + 2 3
We will often build up programs incrementally, just as a pair of programmers
would. We will include mistakes, not because I don’t know the answer, but
because *this is the best way for you to learn*. Including mistakes makes it
impossible for you to read passively: you must instead engage with the
material, because you can never be sure of the veracity of what you’re
reading.
I’d also agree with the author that a good book for readers to learn from does not make a good reference book (and vice-versa).
Thanks in advance. :-)