The inverted review bell curve on Abelson's seminal book on Lisp and functional programming (Structure and Interpretation of Computer Programs, Second Edition) shows either love or hate, and little in between! Those who love it say it is a life changing experience for mathematicians, engineers and physicists as well as programmers, and indeed Abelson does border on the mystical when describing nested recursive functions with "hundreds" of parentheticals preceding quantum-level differential equations, all running on numerics, beneath which are (self defining recursive quantum states) and....
The problem, especially with those who hate it, is that lambda calculus, recursion, and multiple paradigm (imperative, functional, logical, etc.) models mean that each sentence is an adventure in study, not reading. IOW, I stopped highlighting when I realized I was highlighting the whole page!
This awesome new Racket gem makes Abelson an unprecedented one-two punch if you REALLY want to understand some of the hottest new concepts in programming-- at a 30,000 foot level, yet with a TON of fun, down to earth exercises. Lisp has evolved as the second oldest (months after FORTRAN) language that is not only still in use, but still producing new dialects, as this book demonstrates! I mean, a data structure not of hashes and trees but of LISTS??? You'll learn to your amazement how lists can even handle multiprocessor and concurrent computing nightmares with recursion that would defy the most agile trees. Talk about ancient and up to date at the same time!
The coolest thing about Racket, and even Scheme and Common Lisp, is that you can create your own "complete" programming environment, in this case to play with art and games, including compilers and interpreters! C# started with some multi paradigm elements and is now even adding functional programming, but being part of the .net family, there are limits. Yes, you can design a GUI AND a game in C#, but Racket allows you to create an entire programming universe from o/s to environment, SDK, compiler, GUI, language, libraries... all virtually!
If you look at a typical coding interview, you'll have the "solve this phony, contrived problem" on the whiteboard. Yet four of the hottest career areas in IT AREN'T in specific language coding (so much of it is being outsourced to India, China and Russia)-- they are in management of: 1. Data Science 2. Embedded Systems 3. Networking 4. Sploits.
There even is a new "CTO" type job-- CDSO, for "Chief Data Science Officer." These management, team leadership and high level positions don't require you to create a list prioritization algorithm on the whiteboard in C# in half an hour, but they DO require you to understand how systems from the machine and network levels relate to solutions in choice of languages, software and --especially-- paradigms.
In talking with programmers and engineers all day who submit new software for patents, I'm astonished at how many got all the way through even grad school (including Stanford and MIT) without taking a single paradigm class! They can generally tell you which apps work better with trees vs. arrays, but at a high level, why to choose functional vs. imperative is often really foggy.
Solution: PLAY WITH RACKET, then read Abelson! Even if you're an autodidact, this awesome and up to date Lisp text is perfect for self study when carving out your own dream job or starting your own practice. The authors are teachers par excellance, and the pedagogy is beyond painless-- you're half way through recursion vs. iteration before even knowing you've learned it! And while you're at it, you are playing with components and paradigms in ways you've never tried before even if you're a Lisp jock-- because this text takes the time to INCLUDE imperative and logical options. This is possible because Racket moves a little toward OOP just as C# (3.0 and up) has moved a little toward functional, including many steps beyond Scheme.
For those who feel Lisp is out of date or a "has been" (never mind that Lisp invented garbage collection and even presaged early oop (data/object/call/argument units) and that binaries and other newer data structures are coming back around to lists in some of the hottest research, even IN imperative), I guarantee that this book will dispel your doubts! And, if you tried Abelson, loved it, but was missing half the points (I sure was), try Racket first--Abelson won't become easy, but it will, as Abelson said himself as his primary objective, make it a LOT more fun.
Be SURE to get the second edition of Abelson, however, as he completely reoriented it around a new central theme crucial today to multiprocessing-- the time/memory challenge. You can get Ableson 2ed (see link in first paragraph) used at a great price now. I give it as a gift to programmer friends, and this new Racket text would make a great gift too! This author also wrote the awesome Little Schemer book (The Little Schemer - 4th Edition) which is another excellent adjunct to Abelson.
EMAIL ANSWER: A new lisper asked if this book will help with things like closure. Absolutely! In fact, lexical (or functional) closure, when combined with environments, binding and defun/define macros ARE oop at a very basic level, except that they REQUIRE garbage collection. Let Over Lambda (LoL) is "the" closure book, but Racket gives many more practical tips and uses than that "heavy" text (no comparison really, this book is pure enjoyment, LoL requires two double shot starbuck ventis per sentence-- NOT for beginners). Q. How can other languages implement closure? A. Technically C can't due to no garbage collection (hence no fast and unlimited stack vs. heap options, especially since it and C++ are stack based), but C# and many others can.
Although anonymous methods ARE NOT closure, they offer "closure analogs" like callbacks and blocks (in C and C++ for you circuit folks), Local classes in Java, Delegates, and after 3.0, even lambda expressions in C# (do NOT use closure if a lamda will work more simply), overloading operators, etc. Scheme/Racket/Lisp/Clojure... jocks will argue that the differences between oop and functional are semantic, because 1 macro can take care of inheritance, and object orientation is another word for a LISP list function combining procedure and state, and with closure, can easily duplicate the entire oop benefit. Macros are essentially functions that return lists as this book will teach us, but since those lists can just as easily contain code as data, as well as environments and bindings, the "oop" concept was either anticipated, subsumed, or invented by Lisp decades ago, depending on your point of view!
The whole point of learning Racket, at a deep level of understanding paradigm fits in addition to the fun apps in this book, is about time and memory and really "getting" high level (but deep and detailed) program and systems engineering, in many more aspects than most programmers encounter. Stack vs. heap based eventually becomes a sticky wicket for all programmers and engineers, especially with today's concurrency challenges. Look at Erlang-- it dances so easily between functional and imperative because it uses BOTH stack and heap! Besides, lists are way more intuitive and fun ds's (in my biased and elderly opinion) than trees, hash tables, binaries, etc.-- even ON the whiteboard!
Library Picks reviews only for the benefit of Amazon shoppers and has nothing to do with Amazon, the authors, manufacturers or publishers of the items we review. We always buy the items we review for the sake of objectivity, and although we search for gems, are not shy about trashing an item if it's a waste of time or money for Amazon shoppers. If the reviewer identifies herself, her job or her field, it is only as a point of reference to help you gauge the background and any biases.