It was very much of a time and place, and obviously people are welcome to take or leave it. I certainly cringe that every language now seems to need its own twee, jokey, book-long tutorial, like Learn You a Haskell for Great Good and Clojure for the Brave and True. But Why’s (Poignant) Guide captured the playfulness and nostalgia for lost time that the Ruby community evoked for a lot of people back then, especially those that had grown up with computers but drifted into enterprise software and watched the joy of technology slowly seep out of their lives. Whether it's a good way to learn Ruby the language, I don't really remember.
Another senior DBA lived on a boat, so I took my DBAs over to his boat and we spent the afternoon, then went for a walk in the tony seaside town at which his boat was moored. We went to an art gallery.
One of the pieces was a semi-abstract gradient, but the colors could definitely remind one of the sky, and the steely gray of the ocean. I loved the way you looked at it and kind of got lost in the middle. It "felt" like the ocean more than "looking" like the ocean to me.
Another DBA was standing there looking at it and said, "I don't get it."
"I'm not sure there's something to 'get', exactly."
"Is there a boat or a person hidden in it? I can't find it."
For this person, looking at a picture had to have a point--a subject. It was, on some level, a "Where's Waldo?" exercise and since he didn't solve the problem of finding Waldo, he didn't get it.
But not everything's like that. It's okay to not like something. It's okay to not get it. You can still be a DBA. You can still have a picnic on the boat.
I said this elsewhere too -- while in general I like things _like_ the poignant guide, and appreciate its existence, I never actually finished reading it.
To me it's an interesting touchstone work showing/reminding that the "invisibly neutral" tone we've collectively adopted is still an editorial choice and cultural moment.
I'm sure writing and communication styles will drift back and forth over the next few decades. Sometime soon (if not already) another generation of younger developers will coalesce around some document that feels authentically counter-cultural, like their own late-night jokes and dreams have been given just enough coherence to hook them in, and then I probably still won't get it because I'll be out of touch.... :)
For what it’s worth, I felt the same way, but never dared voice it.
I think it’s worth appreciating as a thing of beauty. The raw talent required to make it is just incredible, and it probably takes a Rubyist to fully see the intricacies of what we’re meant to “get”. There’s a place for this kind of work, and it’s one of the delights of life that it exists at all.
I did get it, and I would argue this book made me a better engineer. People learn different ways and retain knowledge differently. Some folks do really well with technical manuals and minimal but factual informational, and some folks respond better to more novel approaches. _why's guide was definitely the latter, and a vocal group of people seemed to agree. While _why's version was definitely on the far side of novel, the approach itself was used in a whole series[0] of books. It's all good that it wasn't your thing, and you're not an idiot, it just wasn't your style.
Mostly the same, except I don’t feel like an idiot for not getting it. I thought it was self-indulgent and too clever by half. But I admit that’s just taste and not a measure of its objective worth.
I have a theory about _why’s popularity though. I think a lot of it comes from the cohort of us who were strictly trained in a C/Fortran/Knuth Art of Computer Programming style old-school approach. When your first presented with the mind blowing ideas of what programming can be when you start to liberate yourself from the machine — if the source has a quirky voice, there always remains a soft spot in your heart for them, be it the Little Schemer, SICP or _why.
it characterizes programming in a way that is basically incoherent to most stereotypical programmers
(i agree with you, for the record, it was gobbledegook to me too)
the question is: does programming represent some kind of subjective expression, or some kind of objective precision? why's little zine says it's the former, but that's not how i see it at all
programming is, for me, like working on math problems, or balancing equations, it's strict and pure and precise, and that's what i love about it, there's no connection to anything like art, or writing (in the novel sense), or other kinds of subjective expression
but for some people, programming is like art, or writing a novel, or in any case a subjective expression of some abstract idea (or ideas) that they have
Programming, objectively speaking, is nothing like balancing equations. When balancing equations, there is only one right answer. When programming, there is a goal and a series of subjective choices need to made in order to reach the goal. There are many right answers. The art and craft is in those subjective decisions. You might not care about the craft in those decisions, but, objectively speaking, I don’t think you can reduce programming to something like balancing equations.
What type of programming do you do? Because in my experience, programming is as much an art as it is a science (or mathematics). In my previous job, I had to classify phone numbers as either 1) valid NANP [1], 2) invalid NANP [2], or international, and it wasn't clear cut like balancing equations. I was surprised that the Oligarchic Cell Phone Company (our customer) didn't even send us valid phone numbers!
[1] North American Numbering Plan, 10 digits, with a three digit area code, a three digit exchange and a four digit number. From what I was able to understand (there wasn't a single document that described this), the three digit exchange had to start with 2-9, and the second two numbers couldn't be 1 (so no area code like 211, 311, 411, etc., but 201, 210 were valid), and the same for the three digit exchange, EXCEPT maybe for toll-free numbers (like 800-xxx-xxxx or 866-xxx-xxxx) where the exchange could be 211, 311, 411 (I never did get a clarification on that point).
[2] A number that might present itself as a NANP but doesn't follow the actual NANP specification.
[3] In telephony, there are two concepts, international numbers that can be dialed world wide, and "local", which can only be dialed from inside a region (like North America) or country. A number that starts with a "+" is considered international, which should be followed by a country code (one to four digits, starting with 1 to 9, with no rhyme nor reason as to length). If it doesn't start with a "+", it's a "local" number, limited to, as I stated, a region or country.
There is also no requirement that a "local" number be related in any way, shape, or form, to an international number. For instance, a "local" NANP number like 305-867-5309 can be represented as a international number as +1-305-867-5309, but for several countries, just taking the "local" number and adding a "+<country code>" won't work. Different rules for different regions/countries.
i think my example of "balancing equations" was a poor one. obviously, there is almost never a single objective solution to a programming problem.
probably a better metaphor for programming is as a craft -- not a pure science, like math; not a pure art, like painting or writing; but much more akin to something like woodworking
Worth noting that mathematicians also argue over the art vs. science approach to math itself. Ask one what makes a formula "elegant", for example, can lead to some hand-waving that boils down to "you know it when you see it."
My take: the art is always about the human communication through the medium. As soon as programming is abstracted beyond the 1s and 0s, every choice represents a mental model for communicating intent from a human to a computer and by extension, from a human to a human. Writing "elegant code" is all about communicating intent to other programmers.
You can say the same about math - so much of the human-ness of math is backed into the symbols we use to represent things and relationships. Just think of the human impact of doing multiplication in Arabic numerals vs. Roman numerals and you can understand how math is totally a human construct.
But underneath it, the logic of multiplication is non-human and those that focus on that are the "science-minded" ones. But so much of our human understanding comes from the "art-minded" ones, for obvious reasons.
Mathematicians love arguing about which proof is the most elegant or most insightful, and which definitions are the ones that most captivate the essence of a concept (ask three mathematicians from different fields to define Euler's constant e, for example).
So yeah, there is very clearly a human and subjective element in mathematics, even when the results themselves are objective (modulo axioms and inference rules).
it's definitely possible to model programming as an art, and there is value in that model, but (imo) that model is neither productive nor accurate in most programming contexts
Knuth doesn't mean "art" as in "fine art to be admired" but rather "art" as in a description of something about which it is not possible to be purely scientific about.
> To summarize: We have seen that computer programming is an art, because it applies accumulated knowledge to the world, because it requires skill and ingenuity, and especially because it produces objects of beauty.
(See also, from an earlier paragraph “When I speak about computer programming as an art, I am thinking primarily of it as an art form, in an aesthetic sense.” — though the summary is a better reflection of his views.)
right! and, to build on that: people who see programming as maths understand it fundamentally differently than those who see it as prose, they approach every aspect of programming differently, evaluate "quality" on entirely different metrics, etc.
in my experience, this is a major source of friction in programming teams, and deserves to be addressed more directly -- if i had it my way, i'd prefer that those who see programming as prose would be disabused of this incorrect notion, but i understand that this is my bias speaking, and not any objective truth :)
As both a writer and someone who has a degree in math, I see the segregation of prose and mathematics into fundamentally different categories as arbitrary, perhaps even incorrect. I see an artistic element to mathematics, just as much as I see a mechanical element to prose. The mechanics of the thing tell us what we can do, the art of it tells us what we want to do. Perhaps even _why we do it.
I find the strict separation of human intellectual activities into "soft" humanities and "hard" sciences kind deeply sad. I'm not claiming that writing is the same thing as performing a physics experiment, but to me, humanity is at its best when it combines both of these elements instead of keeping them apart.
i fully understand and appreciate the distinctions, and equivocations, you're describing here. i also agree with you that the best "stuff" acknowledges and maximizes both left- and right-brained parameters
my point is less about these abstract concepts, and more about the perspectives that human beings have when engaging with this "stuff"
concretely -- when i'm playing a musical instrument, my brain is in a mode that is completely different than, and totally incompatible with, the mode my brain is in when i'm writing a program, or working on a math problem
it's one or the other
why's book reads to me as a "playing an instrument" perspective on a "writing a program" problem, which doesn't work for me, at all -- personally!
With Ruby I feel (feel being the operative word) like I’m free to get the computer to do what I want and create something that looks good and makes me happy.
But in other languages I immediately feel cramped and constrained - and the code looks ugly to my eyes.
As for correctness and quality, number one is it has to fulfil the business requirements I’m being paid for (and I’ve shipped lots of crappy code that I’m ashamed of but the clients are very happy) and secondary, I like to look back at it and see something elegant that also looks good in an editor.
Of course, the definitions of elegant and “looks good” are the real questions here.
yep! and i have almost exactly the opposite experience!
with ruby i feel (same caveats) like there is so much ambiguity that i can't build a coherent and predictable mental model of my program -- it makes me feel anxious and unsure
what you characterize as "cramped and constrained" i probably experience as "precise and unambiguous" -- it makes me feel calm and in control
no judgment from me about which of these perspectives is better or worse, i don't think there is any way to say that, just want to point out this interesting difference in perspective among practitioners
You can't learn a programming language like that, unless it already has very similar paradigms to languages you already know. For example, try to learn APL[1] or Haskell like that (or just assembly if you haven't done any kind of assembly yet).
[1] And that's not just because of the arcane symbols.
