Cool. I'm always game for a good discussion of DSL's and Lisp (Racket).
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.
Thanks for recommending that essay. Reading through it I found myself first agreeing, every other attempt sings about Lisp's wonders without showing you the what/why/how, only woo. Then, here I was halfway through this essay also not yet knowing what the fuzz is about, and when the author finally gets around to it I end up not really sold on it. I have given Racket and CL my time before only to end giving up, not having found "enlightenment" or even the motivation to keep at it. Another day, with more free time I expect I'll give Beautiful Racket also a try.
So glad to see him articulate what I've always felt about x-exprs.
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.
Dunno...I know the style is intentionaly and maybe I'm just not the right target audience for these kinds of essay, but I find this kind of "storytelling" style incredibly longwinded, verbose and actually rather annoying.
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.
Any one using Emacs and tweaking it using elisp might also agree on the "Why Lisp?". In short, everything is an expression in Lisp languages -- Racket, Elisp, .. So one just codes as they think; they don't have to write separate statements to appease the language syntax.
Yes exactly. I already know Racket for academic reasons, but I've been interested in tinkering with DSLs (I've always longed for an embeddable functional programming language that I could have complete non-programmers use to provide simple formulas and conditional logic) so this is right up my alley.
Looks like an interesting book. And, on my surface pro, it's pretty. It's not very readable, as it is only dark-on-light, high contrast -- I prefer "night mode" for reading long-form.
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).
It's only readable on my iPhone because it's a 6+, on anything smaller it would be infuriating and it's not ideal for me anyway. Not only that but in 'reader mode' the formatting is completely wrecked such the the content actually disappears. This is all a shame because my preferred way to read something like this is on a mobile device, although I suppose it could be semi-deliberate to nudge you towards buying.
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.
For some reason, Butterick is averse to both making a PDF available and to responsive design. Perhaps — as a typographer and book designer — he prefers to control how the layout looks even if it means it looks bad on smaller screens.
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.
I could care less for a PDF - but epub is a pretty useful format for actually reading a book. And a Kindle book is also rather nice (mostly due to kindle syncing location in the books across devices etc - I would prefer to buy ebooks without the DRM, as there's the worry one will lose access for various technical or business reasons).
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.
Butterick cares deeply about typography and Amazon doesn't so I can see why he doesn't make a Kindle version. I too buy mostly Kindle books because it's easy to remove the DRM. It's been a while since I looked, but that was more difficult on Apple and Google ebooks.
So he cares deeply about making the book oook beautiful for a specific arbitrary subset of people and doesn't give a crap about that for the set of people that happens to include me. Nice to know.
I don't think the "arbitrary" is justified. It's a group of people who use a platform over which a reasonable amount control over typography and layout can be maintained.
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.)
Actually, turns out the actual chapters have the opposite problem: Too big text, with too big margins and a ragged right that makes it legible, but unreadable. The front page is still too tiny to read...
I am disappointed too. This looks like a very interesting book and there would be plenty of room on my bookshelf among the many Scheme, Common Lisp, and Clojure books that I have paid for and refer to frequently.
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.
I've found linear navigation to be a bit of a blocker with e-readers; they're great for narrative, but with something more reference-like, you often need to hop back and forth and the interface is more limiting.
I'd just like to say that I admire Matthew Butterick's creative experimentation with business models for web publishing and absolutely adore Practical Typography to the extent that I've purchased several of his fonts and intend to purchase Beautiful Racket as well. It can be hard to imagine that there's a world for type design on computers outside the formulaic mundanity and advertisement-laden nature of the rest of the web, but then you get brilliant stuff like Practical Typography and now Beautiful Racket and you can see the world we don't have in contrast to the one that we do...
It would be nice for there to be a bit more institutional knowledge on how to get people to pay for your product among these experiments.
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
In particular "this book is not free" while giving the whole thing away really emphasizes the dissonance you have to deal with when exposing yourself like this but it does so transparently and unpretentiously, I think.
Maybe I'm naive, but I doubt specifically saying "don't pay me just $5" will increase his ability to make money. I do enjoy his snarky tone, but seriously, telling people to either pay $39 or just use it for free doesn't make much sense at all.
Well I think it's mostly a case of deciding how much of a priority it is and how that's reflected in the overall design.
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.
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.
I was responding to a post about design, so this reply was about design.
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.
>Other issues with the design is huge unattractive margins and the main page containing almost no information when first loaded.
"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.
Are you using Firefox? I see the same black box in Firefox too (which is actually an SVG inside an <img> tag), but in Chrome, it renders fine: https://imgur.com/a/NdvKN
It looks like the SVG's style block[0] applies a black background to the svg element:
svg {background: rgb(1.0,1.0,1.0)}
which fails to render in chrome due to the floats but renders fine in firefox. If set to white or removed entirely, it will display correctly in Firefox.
There's a lot to like about racket. The cross-referential documentation is amazing - thanks to Scribble built in as a documentation language. Another thing which makes it super fun to write is module+ - the ability to interleave a submodule within another module. Writing unit tests in line with what they're testing is a great way to provide examples of what a function does.
I'm an intermediate scheme programmer (experienced in C, Python, etc), and one thing I really didn't like about R6RS in general, and Racket in particular, is the amount of bloat.
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?
First, a small defense of Racket. Racket has a small core relative to its apparent size; most of the bloat is in optional library code. All the fancy special forms for pattern matching, classes, contracts, etc are just optional macros from the libraries, and everything eventually expands down into this rather small core language:
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.
I'm no marketing guy so please excuse what may be some naive questions
prompted by his how-to-pay page. I gather that tiered pricing is
considered good practice, but how effective is it to use a jokey, edgy
and possibly sarcastic or insulting tone when explaining the rationale? Does it not undermine his professional credibility, or is there some new trend in this area that I'm unaware of?
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 have read part of this book and it is a really well written book especially to use racket to construct computer languages . I didn't understand how to use racket to make languages until I read this book.
I cursory read the FAQ, somewhat funny that it's a series of questions with a "no" answer, that made me curious about the author, so I looked for public speakings on YouTube. Right now the first hit is a 18 minutes presentation of this book (so I think as I haven't watched it yet) called "(sixth RacketCon): Matthew Butterick -- The Making of “Beautiful Racket”".
I thought that someone else here could be interested...
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.
Has anyone used Racket for a long running application server? Last I remember it did not have native threads (ie, it could only use one core), and I don't know about it's reliability compared to something like the JVM.
It uses separate native threads with shared state for futures, though there are limitations on supported operations without defeating parallelism; it also offers message passing parrallelism with places, which I think are implemented as native processes.but may be threads (it's conceptually shared-nothing processes, but so are Erlang "processes" which are multiplexed onto native threads.)
But, in any case, Racket can use multiple cores, though the APIs for doing so are different than conventional threading APIs.
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.