Beautiful Racket
beautifulracket.com
beautifulracket.com
My only complaint is that because it is so directed (you're writing a programming language and it wants to get you there very quickly) it abstracts a lot of stuff that you'll need to know if you're doing anything other than following this book. For instance, a lot of the code you write will start with
#lang br
#lang racket
So if you're following along the book, the upside is that that he can skip explaining a bunch of stuff about Racket packaging and libraries. But the downside is that he skips explaining a bunch of stuff about Racket packaging and libraries. If you want to take what you've learnt here and go write a programming language in Racket, you're going to have to go and learn all of that stuff anyway. You're going to have to take apart `br` and figure out how to map its parsing stuff to Racket's and you'll find that almost none of the scaffolding from the book can be copy-pasted without including the book's libraries, and many of the concepts aren't even reuseable if you want to use Racket's parsing tools instead of the book's largely bespoke tools. (Just including the book's libraries themselves can be difficult because of how Racket's packaging works. In the New World of Racket packaging, you install a library _on your machine_, not as a dependency of your project. So if you want to run your code on another machine, you first have to manually install the library on that machine before your code can run, and Racket's tooling around this is currently very sub-par.)
But I'll say again that it's a great book and if you're interested in Lisp and Scheme in particular, you should buy it and you should read it. It's great. Just know that you'll have to read the book _and also learn Racket_.
This book specifically is in need of significant editing.
As an alternative, see the incredibly good “How To Code” class from UBCx on EdX (don’t be put off by the title). It’s a direct implementation of the approach in this book.
The Little Schemer may be slightly better, but on its own, it too is not about learning Racket.
Although they overlap on some topics, comparing little schemer to htdp is comparing apples to oranges.
Also, htdp is just racket in my opinion, it differs very little from the students languages, I did the whole thing using just plain racket and didn't have any problems that couldn't be solved in two minutes visiting docs.racket-lang.org (and they were rare), but sure, you won't get to know all of racket because that's not the point of the book.
I do think there is a need for more YouTube videos on the basics. I seriously think Racket is way better than any other for scripting and quick programs. It just needs some more libraries which comes with more developers.
THE ONE WEAKNESS OF RACKET = Everyone just solves the same problems over and over again because it is so fun and easy.
Most dense book ever
Took my 30 restarts to get through it. This is my way of doing programming books: Read till I get stuck or feel unconfident in what I learned. Restart at page 1 and I ALWAYS get through where I was stuck. Get stuck go back to page one, rinse and repeat.....
Seriously I am an old fart that read a book to learn Assembly for C64 when I was 11. I have never had something fundamentally change the way I do anything. I mostly write R and my R writing style is night and day different and I could use the Scheme parts of it.
Highly recommended.
Secondly, go through Realms fo Racket with a kid (I did with my 10-year-old daughter). Teaching is the best way to learn.http://www.realmofracket.com/
Why? The book is not about how to program and build languages in racket. It is about how to program and build languages in beautiful racket (br). Learning how br was written is a good exercise for the reader, but it's not necessary to effectively use br
Initially I loved the support for multiple languages via #lang, but in practice it's not as easily composable as I would like (e.g. there's no way to combine multiple languages in a single file), and it sometimes tends to hide an API that I'd like to use behind #lang magic (priority sometimes, but not always seems to be given to documenting the use of a language via #lang vs. using its API).
The lack of an ability to install a library locally, along the lines of npm or virtualenv, was a surprise. Especially combined with the approach to packaging versioning: There is no versioning. When a package is updated, everyone gets the new version and there's no way to ask for an older version:
10.5 How can I specify which version of a package I depend on if its interface has changed and I need an old version?
In such a situation, the author of the package has released a backwards incompatible edition of a package.
The package manager provides no help to deal with this situation (other than, of course, not installing the
“update”). Therefore, package authors should not make backwards incompatible changes to packages. Instead,
they should release a new package with a new name. For example, package libgtk might become libgtk2. These
packages should be designed to not conflict with each other, as well.
Having said that, though, this is a book that I'd argue is better in the browser than on the Kindle or as a PDF. I want to be able to read this with a code editor open, and the book side-by-side in a separate window. PDF books don't reflow, and in my experience Kindle just isn't particularly good for tech books.
Among other things, code listings tend to be a mess. It's frustrating when technical publishers release digital versions of their works, and the code snippets (for example) turn out to be PNG files. That works great for a PDF intended to be printed on paper, but doesn't scale well to an ebook reader.
Like this?
As a bonus, lots of offices have a closet full of old 4x3 Dell flat-panels somewhere, so there's no hassle with procurement.
So, even if I pay for this wonderful book (and it /is/ wonderful!) and nobody else/not enough other people do... And then it's gone!
If you can connect to the site, you could wget/curl after you pay.
People tend to blink less when looking at a bright, backlit screen than they do when looking at a passively lit screen. The eye is dryer when you blink less, and thus more easily irritated.
"Computer Vision Syndrome" brings up 250,000 hits on Google Scholar. I'm skeptical that it's a nocebo at this point.
I have a Kindle and I like it because it's small, the battery lasts forever, it's single-purpose, its inexpensive, and is usable in all lighting conditions. Of course you can come up with an equivalent list for your tablet, but the reasons will be different and those differences are enough to justify both products existing.
The other pro for the Kindle is that if I put it in flight mode, I need to charge it once a month or so.
Apparently so, as the website has a strange skinny/tall hard-to-read font for prose, and another strange hard-to-read font for code.
Also, author addresses these objections:
The authors of Racket specially avoid arguments about teaching language X in introductory CS. The pedagogy and curriculum are significantly more factors in effectively teaching CS [1]. The design of Racket with its restricted languages reflects that.
[1] https://www.janestreet.com/tech-talks/curriculum-design/
http://www.ccs.neu.edu/home/matthias/Thoughts/Developing_Dev...
The speaker in the talk linked is a previous Ph.D. student of the author above.
Northeastern, Brown, Northwestern, and Waterloo all use the approach in HTDP as far as I'm aware, even if they don't use the book itself. Racket just happens to be the language of choice (or rather X Student Languages are, not even Racket) because they fit the pedagogy well.
Yet his webpage fonts give me an absolute headache.
That doesn't give me a good gut feeling about "Beautiful Racket."
For those interested further, there is a lot of work with Racket in this respect. A recent paper previously hit the front page of HN on "Domain Specific Languages" (DSL's), which is basically the idea that you should write a programming language for each problem to make it easier to write programs in that domain rather than writing complex spaghetti code in a general-purpose language or writing a library that badly ports to the general purpose language. I'm a bit biased here, but I think this could be the next big step in programming in the next few decades as we see people not writing libraries but writing DSL's to make for easy writing of programs.
HN Discussion: https://news.ycombinator.com/item?id=16454854
The authors of the paper are mentioned in the acknowledgments of this book as well!
https://webcache.googleusercontent.com/search?q=cache:ATgZRm...
I'm working on an engine for this https://geb.hofstadter.io
“Typography for Lawyers” https://typographyforlawyers.com/
“The Book is a Program” https://docs.racket-lang.org/pollen/