3 ms·
I really like this book and highly recommend it. My only complaint is that because it is so directed (you're writing a programming language and it wants to get
by ketralnis 8y ago
I really like this book and highly recommend it.
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
Instead of the usual Racket
#lang racket
That's using some support from Racket where you say "I'm writing the `br` language" and Racket goes and runs your code in that language instead of Racket. That "language" is really just Racket with some libraries pre-included (https://beautifulracket.com/appendix/from-br-to-racket-base.html https://beautifulracket.com/appendix/from-br-to-racket-base....) and some of those libraries are specific to the book (e.g. https://docs.racket-lang.org/br/index.html?q=br#%28mod-path._br%2Fsyntax%29 https://docs.racket-lang.org/br/index.html?q=br#%28mod-path....).
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_.
- threatofrain 8y agoOn the matter of learning Racket, I've heard some good things about How to Design Programs (2nd Edition): http://www.ccs.neu.edu/home/matthias/HtDP2e/index.html http://www.ccs.neu.edu/home/matthias/HtDP2e/index.html.
- wikibob 8y agoThe approach in this book is one of if not the best in computer science pedagogy. 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.
- klibertp 8y agoI'd say HtDP is a good book for learning programming, but I don't think it's the best introduction to Racket. It also uses a specially crafted languages (a series of them) and focuses on the process of coming up and implementing the design, while removing most of the usual problems (cryptic error messages, too complex docs, too advanced techniques) which the beginners encounter. It's great as an introduction to programming, and it's even worthwhile a quick read for more experienced programmers (esp. self-taught), but it's definitely not about learning Racket, at all. The Little Schemer may be slightly better, but on its own, it too is not about learning Racket. Actually, I guess there's no book about Racket itself (EDIT: other than this one to some extent (in "explainers")) - existing books either focus on the basics of programming (HtDP, Realm of Racket) or on specific algorithmic problems and techniques (The X Schemer, SICP). Which is kind of natural given the educational background, but it makes it harder for already established programmers to learn Racket to get the job done.
- Sinidir 8y agoExactly my thoughts the last time i looked at learning resources in respect to Racket.
- Scarbutt 8y agoAfter you have read HtDP2e, I found that racket-lang.org has all you need. 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.
- magpi3 8y ago> 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. 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
- bdowling 8y agoThe title of the book is “Beautiful Racket: How to Make Your Own Programming Langauges with Racket”. It’s reasonable to expect that a reader unaware of the distinction would get the impression they’re learning about Racket.
- jjwiseman 8y agoI've been doing full-time Racket for the past few months, and my experiences echo some of what you said, even for general purpose programming. 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. I like Racket. But there are enough small things (like these, and a few others, like e.g. not getting stack traces on errors in the unit test runner) that I would probably choose Clojure for my next Lisp-appropriate project.
- soegaard 8y agoRegarding multiple languages in the same file. Check out: http://docs.racket-lang.org/multi-file-lang/index.html http://docs.racket-lang.org/multi-file-lang/index.html