Beautiful Racket v1.0
beautifulracket.com
beautifulracket.com
But what struck me immediately was the quality of the "Why Lisp Why Racket" essay. This is probably the most compelling that I've seen as it gets specific and cites near-term benefits – not just the elitist "it's good for you" or "it'll make you smarter" stuff. Nicely done.
It often gets overlooked because we all understandably want to hype something in a language that's really cool, original, abstract or otherwise reflects well on us. But being able to intuitively, iteratively and rapidly work on XML & HTML files is lush, and the IDE with built-in REPL is just gravy for this purpose.
Even if working on XML and HTML files is boring and a technically solved problem in most languages, it feels better in Racket to me, and the essay did explain why it feels better.
It's quite ironic that he needs 24 (in words: twenty-four) paragraphs to get to the first concrete answer to the title question: expressiveness.
And it's unreadable on my Android device (both Firefox and Chrome), due not being a responsive design - the text is simply too small to read. For comparison I've read a handful of books on my Android - both epub and Kindle.
A minimal test of design for reading on the web, should be - how much easier is this to read than the Linux Documentation Project's HOWTOs, or the Debian install guides? If the answer is "it's harder", something's wrong.
(Although, that is a nice idea for a side-project, a simple (set of) stylesheet(s) for LDP/Debian/Plain html documents that adds responsive styling - fonts, choice of light/dark, perhaps CSS columns on a wide screen like the Surface).
Edit: I was assuming buying would get you an ebook version that would solve the mobile readability issue, but I don't see any mention of that on the 'why I should pay' or 'how to pay' pages. In fact it only mentions the 'web based book you see here'. Exasperating.
From the FAQ:
* Will you ever release this book as a PDF or e-book? No.
* Do you plan to optimize this book for mobile? No.
And I'd like an offline copy - I do sometimes read in places without Internet access.
Without any of these - I'd be hard-pressed to buy - even if the content is excellent.
That's not arbitrary if your goal is to create books that conform to a particular standard.
(it's also possible there are technical reasons. The book is written in Pollen, Butterick's publishing system for web-based books. I don't believe it supports output to other formats.)
The author's style seems to be very opinionated and blunt, and I appreciate that, but a web-based book is not better for me.
The reasons listed are great examples of the benefits of web-based books, but I do not find web-based books readable.
I read the FAQ, and I get it: he's not releasing a paper version. Ever. I may power through it on a screen, someday, if it is well-received.
I always just buy a (physical) book.
Good documentation is hard to find and having a physical copy means that I it will be available to me for decades. Almost 20 years ago I picked up a hardbound copy of "The C++ Standard Library: A Tutorial and Reference" by Nicolai Josuttis and it is still something I love having within arms reach of my keyboard.
It is one of the few newsletters that I actually enjoy reading and is satisfyingly infrequent.
Too many times I see projects say they're not making much money from these sorts of efforts, but when I go to the project I can't even figure out how to give them money! LWN is a prime example of lost opportunities (count how many steps it takes to go from "see subscriber link" to "be subscribed")
Personally, I'd throw something in the footer of every page of this book to link to a payment page. Make it easier for people to give you money after reading something interesting! Nagware might be annoying, but "this book is not free", right?
EDIT: Just went through the LWN subscriber flow. It took me... 10 steps? to get subscribed. I've dropped out of this flow before
As you say, if you make easy for people to pay you, more people will pay.
Ease, I think, is a function of the quality of offering, i.e how good it is such that people will more readily part with their cash, and the actual ease of making a payment.
If you have great content and people want more yet the path to subscribe is tucked away so no one can find it, people won't pay (or can't in extreme cases).
If your content sucks, including devaluation via aggressive pushes for payment, I don't think people will be so keen to pay.
That said, I think more people tend to pay for the latter. Your get rich in 30 days with a pay now button every other paragraph and huge discount-that-isn't-a-discount is a prime example.
https://i.imgur.com/DmPKqhM.png
This is in contrast to something like nytimes.com which is really well designed.
svg {background: rgb(1.0,1.0,1.0)}
Non-functional and ugly? I'd say this is subjective, but I find this assessment objectively wrong.
It's complete accessible, and totally functional for what it does -- present a series of sections and display code examples. And it's also quite obviously well designed from an aesthetic perspective.
(There's no black box in the actual site in Chrome, but even with the black box, it's a totally fine functional design).
As for the NYT, it looks like a compromise between looking like a print newspaper of yore, a portal of slightly less yore, and a modern news website cramming everything in the same start page.
Yeah, it's a subjective opinion. Something looking good is also an opinion.
What I mean by non-functional is that the attempt at design was non-functional on my browser resulting in dead space and unattractive design.
Since this book is about programming, it already sets a precedent for potentially pretty but non-universally-working solutions. Something I personally try to avoid as much as possible.
Other issues with the design is huge unattractive margins and the main page containing almost no information when first loaded.
Honestly, this all wouldn't normally bother me as there are tons of books whose online sites have OK at best design. And maybe it's a great book, but complimenting it on design specifically seems wrong.
"Huge unattractive margins", or use of ample "negative space", has long been a staple of the design vocabulary. Nothing inherently unattractive about it.
If what you want to say fits in a small space, don't make it take over the screen, and don't try to cram every level of information on a single page.
And it's the opposite of the overly busy, migraine inducing NYT website you mentioned as a good example of web design.
I'm a staunch minimalist and one of the things that appealed to me learning scheme for the first time was the minimalism of the language syntax. Then I started learning about Racket (and Clojure) and realized they give you the kitchen sink of syntax and language features and take all the minimalism away.
So my question is: How much extra effort would it be if I wanted to do whatever is described in this book in an R7RS implementation, like Chibi, instead of R6RS?
Racket can be used in many ways.
https://docs.racket-lang.org/reference/syntax-model.html#%28...
The default `#lang racket` is a big batteries-included language including all that stuff, but the core `#lang racket/base` isn't very big. I always program in `#lang racket/base` and pull in just the libraries I need. For me the most beautiful part of Racket is this juxtaposition of a small core language and a big extended language implemented through a standard library of macros.
You can also install a distribution of Racket that leaves out bloat like DrRacket, Slideshow and the teaching language packages from the release variants page: https://download.racket-lang.org/releases/6.8/
As to your question, Beautiful Racket appears largely a guide to the language extensibility features that are specific to Racket and not shared by other Scheme systems like Chibi. Things like the `#lang` system, lexer library, and syntax highlighting integration in DrRacket. I imagine you'd get the most benefit out of it by working through it in Racket, and subsequently thinking about how to apply the ideas in other systems like Chibi.
Is it a good idea to tell people how much to pay based on how much you think they should be able to afford, or is it better to let them decide for themselves with just a little subtle help? I'm thinking of how Apple sells iDevices at several price points separated by big increments for small increases in memory rather than directly asking people how rich they are.
On a related note, if you were in charge of a budget for acquiring books on behalf of an organization, would you be able to justify spending any of it on a web published book like this one with no hard copy? Would it raise any eyebrows to opt for a higher price tier with exactly the same offering as a lower one?
I thought that someone else here could be interested...
edit: clarifications
As mentioned in the comments here, Racket's documentation is wonderful. I've yet to come across a better mix of technical reference, guiding narrative and a wealth of usage examples.
Perhaps relatedly, as a scheme(-like), it is tail recursive, implying infnite recursion and can be used in a near-purely-functional way if desired.
That's perfect :)
But, in any case, Racket can use multiple cores, though the APIs for doing so are different than conventional threading APIs.
p.s. thank you for wonderful job anyway.