I'm particularly excited about this idea. As I was reading Graham's "Erase your
darlings" blog post, I had an idea: I should have playbooks at the root of my
monorepo.
I can have playbooks for the following:
- How to install NixOS
- How to build GCR images from Nix expressions
- A collection of miscellaneous shell commands (e.g. "how to kill a process by name")
- What series of steps should I follow when I receive a paycheck
I already keep README's at the root of each package, which I think is where many
of these instructions belong. Other tutorials that I write for myself that do
not belong to any package can go in //playbooks. I also will host my personal
habits in //playbooks since habits are a bit like playbooks for life. Let's see
how this idea ages as the caffeine wears off...
I've been trying to read 15 minutes in the mornings. I also recently purchased
some house plants that I have been watering daily before I do my yoga routine.
I think it might be a good idea to version control my habits, so that I can
audit them as they change.
I'm publishing these on my website, so that I can refer to them wherever I had
internet.
I'm considering this essay one of my favorites from Paul Graham. The essay
argues that good taste and bad taste exist. Graham argues against relativism in
design and cites a variety of examples of architecture, typography, writing,
sketching, painting, aircraft design, and others that bolster his opinion.
TL;DR - Design should strive to be:
- Simple: Prefer simplicity to complexity when possible.
- Timeless: Design today for tomorrow by pleasing yesterday.
- Pointed: Focus always on the problem; don't work for work's sake.
- Suggestive: Constrain usage without suffocating the user.
- Humorous: Prefer light-heartedness to sobriety.
- Difficult: "Good design" is takes time, effort, and tremendous skill.
- Ostensibly effortless: Solutions should look obviously correct.
- Symmetric Appreciate symmetry.
- Natural: In nature, form ever follows function.
- Iterative: Write; rewrite; rewrite; rewrite; throw away; write; publish.
- Imitative: Be confident enough to copy others' existing, beautiful ideas.
- Communal: Pay attention to "Schelling points" and join the party. Don't be the
Milanese Da Vinci.
- Fearless: Question the status quo; expect others to challenge your solution.
Maybe this is my recency bias writing, but "Being Popular" may be one of my
favorite Paul Graham essays that I've read.
"Being Popular" outlines Paul Graham's ideas about what an ideal programming
language would look like. This essay took me 1-2 hours to read, but it was worth
the time.
Here are some quotes that I enjoyed (not sorted in any meaningful order):
"A friend of mine rarely does anything the first time someone asks him. He knows
that people sometimes ask for things that they turn out not to want. To avoid
wasting his time, he waits till the third or fourth time he's asked to do
something; by then, whoever's asking him may be fairly annoyed, but at least
they probably really do want whatever they're asking for."
"In this particular case there is a way to finesse our way out of the
problem. If we treat data structures as if they were functions on indexes, we
could write (a x y) instead, which is even shorter than the Perl form. Similar
tricks may shorten other types of expressions."
"The latest hot language, Python, is a watered-down Lisp with infix syntax and
no macros."
"Hackers would think a lot more highly of Lisp if Common Lisp had powerful
string libraries and good OS support."
"I think language designers would do better to consider their target user to be
a genius who will need to do things they never anticipated, rather than a
bumbler who needs to be protected from himself."
Some take-aways:
- Let's refer to Python as "Diet Lisp" from now until the end of time.
- Fight to keep your user-base small for as long as you can. Only fools want
large user bases.
- Rich Hickey definitely read this article; he took some ideas with him; he left
some ideas behind.
- Focus language design efforts around defining rich standard libraries,
especially for string manipulation.
- Worry little about supporting backwards compatibility; design a language that
can and is often rewritten.
- Shift the burden of optimizing code performance to the user by designing a
powerful runtime profiler that is tightly integrated into the language
runtime.
- Minimize the costs users face when experimenting: ensure that your language is
interactive; ensure users can create REPLs quickly.
- Support OS-level libraries (think about Go).
- Maximize introspection and hackability.
What a useful read!
Read Paul Graham's notes about the benefits of building Viaweb with Lisp. I
found it interesting how his competitors (in the 90s) were using CGI scripts to
build their web applications. I wonder how much of his advice would hold true
today...
- Programming Bottom-Up: Benefits of writing reusable utility functions and
amassing a personal utility belt. Specifically how lisp makes this easier than
most or all languages.
- This Year We Can End the Death Penalty: Voting against the death penalty is
voting against the killing of killers *and* the killing of innocent people,
since some estimate that 4% of people on death row are in fact innocent.
As I mention at the top of the org file, I cannot rely on my web browser
informing me which of these essays I've read; it only shows me which of the
links I've clicked.
