Beautiful Racket(beautifulracket.com)
beautifulracket.com
Beautiful Racket
https://www.beautifulracket.com/
57 コメント
I'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:
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.
Regarding multiple languages in the same file.
Check out: http://docs.racket-lang.org/multi-file-lang/index.html
On 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.
I'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.
After 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.
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.
Well, I would have to say the documentation is so well done that it is fairly easy to find whatever you are trying to do. The tutorial steps and answers are straightforward. http://docs.racket-lang.org/quick/index.html
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.
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.
Exactly my thoughts the last time i looked at learning resources in respect to Racket.
BEST BOOK EVER
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/
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/
The 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.
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.
> 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
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
The 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.
This is a very interesting case where the author claims the book is not free, provides it on a public webpage, and does not want to provide a PDF or ePub. I would gladly be willing to pay for content, but I like to do most of my reading on a kindle. I am not willing to pay for a book if the author is trying to make it as difficult as possible to view his book (but at least the fonts are beautiful).
Butterick has Strong Opinions™ about Kindle typography that led him to that position. I largely share those opinions, to be fair, although I think it's a bit of a quixotic enterprise for many books; offline is more important than beauty. (And, really, the Kindle could do most of these tricks if Amazon gave a rat's ass; Apple's iBooks can do nearly everything that any other WebKit browser can with regards to typography.)
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.
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.
The biggest problem I have about not getting an offline copy is that he makes it clear that if the book does not perform to his expectations, then he will take it down.
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!
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!
It's already gone, so, no harm, no foul. (Hugged to death.)
If you can connect to the site, you could wget/curl after you pay.
If you can connect to the site, you could wget/curl after you pay.
> Butterick has Strong Opinions™ about Kindle typography
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.
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.
Luckily there are browser extensions like Stylus [1] to help fix these design decisions that don't account for those of us with poorer eye sight or older screens.
[1] https://addons.mozilla.org/en-US/firefox/addon/styl-us/
[1] https://addons.mozilla.org/en-US/firefox/addon/styl-us/
Well, does the author supply a bundled html for download? I don't like paying for things that can vanish any day, you can open a pdf viewer side-by-side a code editor too.
He has strong opinions about typography, period. It's not just about Kindle or any other device or format. I do recall asking about a PDF or ePub version of Practical Typography [1], but he refused saying none of the eBook formats are good enough. While I understand that to some extent for a book on typography, I don't understand it for a book on programming.
[1]: https://practicaltypography.com/
[1]: https://practicaltypography.com/
eBook reader typography - my experience is drawn from using a Kobo with various EPUB & PDF from multiple publishers - is almost always terrible.
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.
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.
[deleted]
What can any of these specialty devices do that a tablet with some apps can't?
Well, the main claim to fame for the Kindle over, say, an iPad (or even Amazon's own Fire tablet) is the e-ink screen. It really does make a difference in reading fatigue in my experience, I suspect because it's lit like paper, i.e., by reflective light. And, of course, the e-ink screen also means that it runs weeks without needing to be recharged.
I've never been able to understand this. I read from screens nearly all day and I've read books for many hours in a row on normal tablets. I have to wonder if this is nothing but a nocebo that will stop being a "thing" once screen reading is more common, like alleged motion sickness from normal television.
Not everyone is you.
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.
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.
Even if reading from a backlit screen doesn't bother you, you have to recognize that reading outside is much better on an e-ink display.
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.
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.
Reading outside is fine if the screen can go bright enough, but needing less battery power to achieve the same result does sound like a plus.
I strongly prefer reading on an eInk display. I work on a screen all day, but I'd definitely choose "Not reading a book" over "Reading it on a computer display" (a paper copy is still the best reading experience, though -- just less convenient for storage and other such things)
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.
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.
> I want to be able to read this with a code editor open, and the book side-by-side in a separate window.
Like this?
https://xkcd.com/1988/
Like this?
https://xkcd.com/1988/
Only when the book is "Learn Docker in 24 Hours."
I do it with two monitors like this:
https://i.imgur.com/QZWIvNq.jpg
https://i.imgur.com/QZWIvNq.jpg
I'm a big fan of rotatable monitors. A 4x3 display rotated to portrait is fantastic for reading most PDFs, if you set Acrobat to Fullscreen and Single Page View.
As a bonus, lots of offices have a closet full of old 4x3 Dell flat-panels somewhere, so there's no hassle with procurement.
As a bonus, lots of offices have a closet full of old 4x3 Dell flat-panels somewhere, so there's no hassle with procurement.
"on a public webpage" = "as difficult as possible"?
Also, author addresses these objections:
https://beautifulracket.com/why-you-should-pay.html
Also, author addresses these objections:
https://beautifulracket.com/why-you-should-pay.html
Part of the justification (which you may or may not buy) is that it's not intended to be viewed as static content. Therefore, a PDF or eBook is not an appropriate medium.
[deleted]
That makes sense to me but then I think the book needs a track changes feature. It might be there, but the site was loading slowly enough that I didn't really explore.
Your Kindle has rudimentary web browser, you might be able to read it there.
Practical Typography (written by the same author) has been a wonderful resource for me. Sometime I'll get around to working through this book as well. My high school is actually one of the last places to teach Racket/Scheme as an introductory language. Personally I find it a wonderful way of teaching the basics of computation and recursion. I wish more schools still taught it.
Several universities still teach racket as an intro language. Ex: Brown, Northeastern, Northwestern, etc.
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/
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/
This is an essay by the creator/author of How To Design Programs (currently at Northeastern) that lays out the pedagogy well:
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.
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.
Yale's intro CS class uses Racket: https://zoo.cs.yale.edu/classes/cs201/
"Practical Typography (written by the same author) has been a wonderful resource for me."
Yet his webpage fonts give me an absolute headache.
That doesn't give me a good gut feeling about "Beautiful Racket."
Yet his webpage fonts give me an absolute headache.
That doesn't give me a good gut feeling about "Beautiful Racket."
This is a great introduction to Racket as a language for building languages.
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!
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!
Here's a cache of A Programmable Programming Language since it's down for me atm
https://webcache.googleusercontent.com/search?q=cache:ATgZRm...
https://webcache.googleusercontent.com/search?q=cache:ATgZRm...
And here's a worked example of applying this approach, in this case to the domain of video editing: Super 8 Languages for Making Movies (Functional Pearl)
https://www2.ccs.neu.edu/racket/pubs/icfp17-acf.pdf
re: Programming in DSLs
I'm working on an engine for this https://geb.hofstadter.io
I'm working on an engine for this https://geb.hofstadter.io
Other fantastic projects by the same author:
“Typography for Lawyers” https://typographyforlawyers.com/
“The Book is a Program” https://docs.racket-lang.org/pollen/
“Typography for Lawyers” https://typographyforlawyers.com/
“The Book is a Program” https://docs.racket-lang.org/pollen/
Looks like it's being hugged to death.
I have little knowledge of lisps, but I'd like to implement a new language in one of them. What would be a better choice, racket or clojure?
One of Racket’s is explicit design goals is to be a toolkit for designing and implementing new languages, so I would say it is the better choice.
Yes I know, but I've heard some clojurists criticizing racket because of its data structures. So perhaps that would outweigh its benefits. Thanks for your opinion
How useful is this book for a Clojure programmer? I always wonder if there is cross-over in practices between the Lisps.
what a beautiful book.
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
Instead of the usual 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....) and some of those libraries are specific to the book (e.g. 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_.