Why Sponsor Oils? | blog | oilshell.org
Joel Spolsky's writing has come up a few times recently.
Two weeks ago, I quoted his 2002 post Fire and Motion in a "Blog Backlog" post, comparing the Kubernetes and Windows ecosystems. (This post got ~500 comments yesterday!)
Last week, someone mentioned the same post in another popular thread:
The unreasonable effectiveness of just showing up everyday (typesense.org via Hacker News)
2066 points, 577 comments - 7 days ago
My neighbor Mario also appreciates Joel's writing more than a decade later.
It's amazing that a 19-year-old blog post is still valuable, and that people remember and enjoy it. So here I recommend more posts from Joel's blog.
Every programmer should understand Unicode basics, O(n2) bugs, and the Unix philosophy. Joel covers these topics in a memorable way.
Ever wonder about that mysterious Content-Type tag? You know, the one you’re supposed to put in HTML and you never quite know what it should be?
Yes, you need to know this! It's relevant to Oil.
As with Fire and Motion, my recommendation of this post caused light bulbs to go off a few weeks ago.
Every time I fix an O(n2) bug I think of Shlemiel the Painter! You might have a few of these problems in your codebase.
So today, take a deep breath. Walk with me, please, through a little exercise which will be conducted using the C programming language.
Related: Accidentally Quadratic
Joel reviews Eric Raymond's book in
The book is so full of incredibly interesting insight into so many aspects of programming that I’m willing to hold my nose during the rare smelly ideological rants because there’s so much to learn about universal ideals from the rest of the book.
This is how I feel as well. The author's tone is sometimes offputting, but there's a lot of real knowledge there. It's well written, and it will come up again on the Oil blog.
duncanlock reminded
me
that Raymond calls this The Rule of Representation.Rule of Representation: Fold knowledge into data so program logic can be stupid and robust
I've put that on my Slogans, Fallacies, and Concepts wiki page, along with Rob Pike's version, and I want to write a blog post about it. Whenever different people say the same thing in different words, it's worth generalizing into a concept with a name. (Recall my sketch of the Perlis-Thompson Principle, one of the most important ideas in software architecture.)
Note that algebraic data types are a mechanism for obeying the rule of representation. They let you encode conditional logic with data rather than code. After almost 5 years, this style is still paying off. I've mentioned it in several release announcements, like the recent release of Oil 0.8.12.
The book is generously available for free online, and in print form. I have the print copy, with commentary by Ken Thompson, Brian Kernighan, and other Bell Labs legends.
catb.orgIn fact when [Lotus] Notes 1.0 finally shipped it had been under development for five years. Notice just how dang long it took before Notes was really good enough that people started buying it.
In the open source world, LLVM is another example. I mentioned in the HotOS Notes that I want to double down on this analogy:
Oil is to bash as LLVM/Clang are to GCC.
LLVM was initiated in 2000, but it really became popular after about 10 years. And it's more popular than ever now, to the point where people complain about the monoculture.
Another anecdote: I had not even heard of Python until 13 years after it was created (2003). I've now been using it for 18 years!
The value of software — especially foundational software — is "back loaded".
There are two different meanings of "fire and motion" in this blog post:
What drives me crazy is that ever since my first job I’ve realized that as a developer, I usually average about two or three hours a day of productive coding.
The bad meaning is when companies keep you on a treadmill by constantly releasing incompatible software (e.g. the modern cloud). I indeed called this "motion without progress" in the Shell Design Philosophy post.
The good meaning is when you show up every day and accomplish your goals!
I don't want to criticize Google too much, because working there taught me nearly everything I know about software. But again it's funny how history rhymes.
Joel talks about what Microsoft has in common with is grandparents, and that analogy applies to Google too.
Basically, by the time she got to be 65, every mistake she'd ever made in her life she had corrected by creating a new procedure by which she made sure that she never made that mistake again.
This relates to a reason I use Unix shell. It's a great tool to practice making mistakes, and quickly fixing them, when there are no consequences. I find that programmers can get "stuck in their heads" and become scared of mistakes.
It's rational to be scared of mistakes if you aren't fluent in diagnosing and fixing them. But it's more effective and feasible to improve at fixing things than to improve at planning and modeling. Fixing things increases your knowledge, while planning is limited to things you already know. (Related: situated languages and programs.)
The first 3 articles explained basic programming knowledge, and the last 3 provide color on the process of writing software.
Do you have any other favorites? Let me know in the comments. I picked these from memory after ~20 years, without looking through the archives.
This reminds me that I have his book in storage: Joel on Software (Amazon)
If you want to read more blog posts about software, in a different style, see Popular Posts With Many Comments (Oil's greatest hits).
If you didn't get enough, here are few more posts:
My comment on
Why I turned down my Y Combinator interview (facetdev.com via Hacker News)
314 points, 104 comments - on March 21, 2019
Links: