Racket is a descendant of Lisp, a programming language renowned for its elegance, power, and challenging learning curve. But while Racket retains the functional goodness of Lisp, it was designed with beginning programmers in mind. "Realm of Racket" is your introduction to the Racket language.
In "Realm of Racket," you'll learn to program by creating increasingly complex games. Your journey begins with the Guess My Number game and coverage of some basic Racket etiquette. Next you'll dig into syntax and semantics, lists, structures, and conditionals, and learn to work with recursion and the GUI as you build the Robot Snake game. After that it's on to lambda and mutant structs (and an Orc Battle), and fancy loops and the Dice of Doom. Finally, you'll explore laziness, AI, distributed games, and the Hungry Henry game.
As you progress through the games, chapter checkpoints and challenges help reinforce what you've learned. Offbeat comics keep things fun along the way.
As you travel through the Racket realm, you'll: Master the quirks of Racket's syntax and semantics Learn to write concise and elegant functional programs Create a graphical user interface using the 2htdp/image library Create a server to handle true multiplayer games
"Realm of Racket" is a lighthearted guide to some serious programming. Read it to see why Racketeers have so much fun!
This is a werid book. Not because its content, or the topic at hand, but the path chosen to explain things. For example, even after reading the whole book, I don't have any idea why I should pick Racket over any other Lisp variant.
So, laundry list of things that put me off:
No real explanation on why I should pick Racket over any other Lisp (or any other language, for that matter); they don't say it's faster, or more accurate, or it's syntax makes you write less bugs or the compiler will prevent you from doing it so.
There is a strong favouritism for Racket. It isn't that unexpected, but they authors start by bashing other languages, which gives a feeling that they just want to make their favourite language look better (this goes away only in the last chapter, when comparing Racket to Java).
They use different words for common things. There isn't and IDE, it is a PDE, "program development environment"; the integrated development environment becomes "interactive development environment"; functions don't "receive" parameters, they "consume" the values, which make it sound more like a Rust thing, in which the function gets the ownership of the value and, on its end, the memory is freed, which doesn't happen in Racket.
There is a bunch of "trivial", "simple", and such. This is bad, specially if you want newbies to read the book; if they don't grasp the concept, saying it is "trivial" will make them feel bad about themselves.
A lot of explanations are basically "(+ a 1)" -> "adds 1 to a". Sure, one may not understand all the facets of the code, but when you explain "why" you wrote code that way instead of "what" the code is, it is a lot easier to understand.
Because the book is too focused on explaining one single library, some things feel like "if everything you have is a hammer". For example, there is one game of attacking monsters and which the authors put the target in the state, and it doesn't feel like this should be part of the state of the game. Sure, the selected target affects the state, but it is not part of the state, at least for me, and there isn't any good explanation on why it should be part of it.
Another example uses a complex number to represent points in a 2D plane. Sure, 2D points and complex numbers are composed by two elements, but that doesn't mean that 2D points are complex numbers. Types matter, even in dynamic languages.
So... yeah, I think I learn a bit of Racket, but I still don't know why I should pick it over anything else. Is it just the game building library? Should one pick a language exclusively because of some built in library? Doesn't anything else affects this decidion? (All questions are rethorical, it is obvious that you shouldn't pick a language just because one library).
OK so off the bat I did not do the exercises because I actually just wanted a primer on how Racket and Scheme compare to Common Lisp, I have other projects I want to finish first before coming back to that.
I think this book does a good job at being that, in that: 1) It teaches you the basics of how Scheme is written and 2) It teaches you some of the concepts that I think Scheme/Racket people focus on in program design
I am not qualified to talk about this book from the concept of a non-lisper or a non-programmer but I feel like if you don't know how lisp works and are a programmer this book will probably make sense to you.
I am a super big fan in general of books that use a series of games to teach concepts, because I find it more motivating than writing tools I may or may not have uses for. Probably the bigger thing is that by not being a consistent book-wide project I don't get bored if the example doesn't tickle me.
From a stylistic book I think the tone of the framing story is kind of sad and dumpy compared to the exhuberent joy and weirdness of Land of Lisp. I get people didn't want to rehash that, but I don't know, Scheme books are generally full of particular whimsy and joy that I don't know why this book had to be about a sad boy constantly needing help. Luckily this is only in the framing story, the text itself doesn't take on much affectation.
Anyway once I'm done a few project I was using this book as a stepping stool for I want to come back and see if I can truly comprehend some of the latter concepts that I'm personally not that used to, thunking and memoization and thinking about problems in game states. So in that sense the book did an excellent job stopping me from thinking of it as a primer and making me consider it in its own light.
This book did not meet my expectations. It is a good book if you're new to programming and want to learn Racket, but nothing more. Sadly, that holds true for all Scheme books out there. I was hoping for an in-depth (or at least, deeper) book on Racket, since the official documentation is a bit tricky to get into. Unfortunately, it doesn't cover much. You get to learn some basic constructs, but it goes nowhere near macros or complex Racket features.
The little sibling to Land of Lisp, this book showcases the cleanliness of Racket and the power of its "batteries included" approach; the concepts are a little bit more for beginners than the breadth of Land of Lisp, but it introduces the reader to idiomatic Racket and the possibilities for teaching and building more serious software. And the games, all with a graphic interface, are a lot of fun to build!
First book I have encountered that taught me Functional Programming without feeling like I needed to learn Lambda Calculus before going back to chapter 2. Was looking for a book to help me change the way i program and this one delivered. I had attempted Haskell at least three times and feel flat each time.
I wouldn't come at this without prior knowledge of racket or programming, but the material is presented in an engaging and humorous manner, all the code for it ships with racket, and there is no hand-holding, but good questions to help guide you.
TL;DR - Book itself is OKAY if learning Racket is really what you want, but you should do your research about what Racket is and what it can provide.
I haven't read many technical books, maybe 10-12, finished probably 2-3 out of them. And also in this book, I've read only 9 chapters so read my review with caution. I am not that disappointed with the book than with the language itself. I know a little bit of haskell and I wanted to dive deeper into functional programming so I picked up this book. The book didn't teach much functional programming and language itself is a mix of multiple paradigms. Maybe it was my mistake that I didn't do enough research before picking up the book. I already knew a bit of functional programming so I can't tell how much easy the book is for beginners. Also, I read all the titles and subtitles of all chapters after chapter 9. After chapter 9, the book more becomes about how to develop a good game and more about the delicacies of game than teaching language itself, it focuses more on how to tackle specific problems encountered in game development with algorithms and the Racket specific libraries, with the exception of chapter 11, which seems to be on lazy evaluation. Overall, learning Racket didn't seem to provide many advantages over learning any other ALGOL family language, at least from this book.