Hacker News new | past | comments | ask | show | jobs | submit login
Beautiful Racket (2016) (beautifulracket.com)
158 points by gurjeet on May 12, 2022 | hide | past | favorite | 11 comments



Before I started feeling comfortable with the official Racket docs, Beautiful Racket served as an accessible reference as I began exploring the language.

I'm turning into a big Racket fan. I just rewrote my website's backend in Racket [0], and I've been learning how to publish packages for the ecosystem.

[0] https://github.com/jacobwhall/jacobhall.net


Related:

Beautiful Racket - https://news.ycombinator.com/item?id=17033533 - May 2018 (53 comments)

Beautiful Racket v1.0 - https://news.ycombinator.com/item?id=13881535 - March 2017 (58 comments)

Beautiful Racket - https://news.ycombinator.com/item?id=11220237 - March 2016 (53 comments)


The name Scheme somehow makes sense to me ("in the grand scheme of things"), while the name Racket does not, even though it parallels the alternative meaning of the word "scheme." ("Matt" would be a more fitting name, looking at the names of the people involved :)


Here is an explanation:

> Scheme was originally called "Schemer", > in the tradition of other Lisp-derived languages > such as Planner or Conniver.

> The current name resulted from the authors' use of the ITS operating system, > which limited filenames to two components of at most six characters each. > Currently, "Schemer" is commonly used to refer to a Scheme programmer.

So the Schemer, Planner and Conniving we get to Racketering.

The dictionary on "a racket":

    2.
    INFORMAL
    an illegal or dishonest scheme for obtaining money.
    "a protection racket"


Interesting model, it's an honor system to a read "free" (as in not toll-gated) book on the web, with a starter price of $40 USD. https://beautifulracket.com/how-to-pay.html

I admire the model, and the try-before-you-buy but somehow paying $10 for a book I won't get around to reading ever most likely is a lot more appealing, whereas starting a book knowing that I should pay $40 somehow is off-putting enough to not make me want to try.

Good on the author for being creative. Just sharing how my grey mush responds to the whole situation.


It's really curious that in terms of energy spent on a problem, the site seemingly ranks feedback regarding price & price complaints higher in annoyance than freeloaders who pay nothing & say nothing. Feedback about pricing is also categorized under excuses, and boiled down to a simple set.

The boiling down builds on the implication that the author is happier if you are a freeloader than a feedback-giver, especially if your feedback meets the condition that you aren't yet comfortable paying.

This is also just as true if you are trying to give the author any amount of money, as long as it's less than $40 and you aren't a student.

So, you could be fully employed but living on a strict budget so you can move out of an unhealthy living situation, and decide that the book was worth your time to read but that you don't have the money, and then discover that the author thinks of you as "bro" and boils your exceptions down to "I already heard it." And that's just one example.

If you have questions about why you should pay, you will have to exert more energy than a freeloader (in time spent reading/parsing/contacting the author about your proposal that's higher than $5).

This is a problem. Sure, the book being free is "generous," especially if you're a freeloader, but the book is also very not free and the author makes this clear to the reader. Readers are considered to be reading under tacit subjective agreement governed by the author's published pricing frameworks.

The author (I don't know them, nor have I read the book) also seems rooted to the concept of intrinsic value. A lot of people in programming are not, and find it not only foreign, but a highly subjective, awkward way to request a judgement of others. Some people are really bad at deciding what is "worth" their time and many people do not actually think of their time in this way. Many of those same people also really want to support their community with what amounts to boundless creativity, if they can.

Like a lot of people who use the phrase "vote with your wallet," the author ends up redirecting a lot of the purchasing conversation to an either-or dichotomy: Worth it, not worth it. However in reading the details, it's clear that the author is also aware of a number of different ways of looking at the value of the book, but those ways aren't directly involved in the pricing mechanic. This reads strangely and creates an unnecessarily awkward hand-wave effect.

Racket is presumably a very nuanced language. I wonder if the book's audience is really comfortable with such a binary treatment of the customer & payment mechanic.

I think a really good start in repackaging this situation, as an author, would be to first determine exactly how much you need to make to keep the book alive. Especially if the book is in danger of not surviving/living on. What does it mean to you, in terms of expense, to keep the book alive? What is the minimum you'd accept yearly, for example? This is probably a huge point of leverage in communicating with the readers.

An exact number is important, because it's pretty unfair and inconsiderate to ask that the book's best audience blindly subscribe to a potentially limitless concept of paying the high end of the spectrum for works that are also free-to-most, in order to keep a book "alive". Especially if it's also fair to say that the book is of potentially infinite worth to the author, because this does not also reflect the reality of a single book in the market in isolation and could really muddy the emotional waters of charging money for something for which one could never be paid enough, if being honest in one's own intrinsic-value view.

Even if you think it can never be reached, publish the number. Update it as you make money and update the pricing model as things get better.

This would be much more fair to those who like the book, but who also grasp the inequity of the situation as it stands.


> nor have I read the book

My background: unlike the parent, I have read the book. I am a freeloader, but I am a grateful freeloader. It's clear love and effort went into producing the book.

Frankly, I think the "tl;dr" response above by someone who hasn't even read the book totally justifies the author's alleged dismissal. The author set the price. The author doesn't want to hear your complaints/criticism/feedback that their pricing is wrong. I believe that is their right.

I think this is exactly the same situation as a startup trying to convert free customers to the paying tier. There are free customers that you don't really want as customers. You set your price so you don't have to deal with them...


You read and didn't pay? How does being a grateful freeloader equate with not feeling that the book was worth your time?


I had read the post [1] here on HN at the time, about how he faced abuse in the Racket community, but when posting this submission I did not recognize the author of the book was the one.

I'm glad his work hit the frontpage. This would hopefully attract more attention to his work, as well as the problem in the Racket community, if the problem still persists.

[1]: https://news.ycombinator.com/item?id=27531508


After that piece appeared on HN, Racket leadership posted an apology [1] but didn't announce any changes to their policies or procedures to prevent the issue from recurring. In particular, there were no consequences for the person in Racket leadership who had committed the abuse

[1]: https://groups.google.com/g/racket-users/c/7F4Y5Xsdny8/m/r_g...


Matthew Butterick's work is pretty well known within Racket and has brought many people to the language.

I found it sad to read he had been bullied by Matthias Felleisen and as a consequence no longer contributes to Racket. It is a big loss, and I hope something can be done to bring him back.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: