Laziness Impatience Hubris

"We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris." -- LarryWall, ProgrammingPerl (1st edition), OreillyAndAssociates

In the second edition of the book (which sports not only LarryWall as author, but also TomChristiansen and RandalSchwartz as co-authors), there is a glossary which has pithy definitions for each of these terms:

Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer. Also hence, this book. See also impatience and hubris. (p.609)
Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to. Hence, the second great virtue of a programmer. See also laziness and hubris. (p.608)
Hubris: Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer. See also laziness and impatience. (p.607)

Re: "Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about."

?????

Perl is notorious for having people say bad things about it. What's with the above claim? Sounds very, ironic.

Sure, it's ugly - the code reads like line-noise to the uninitiated. Sure, it doesn't provide any nice models for anything but parsing limited structure from flat strings. But... ThereIsNothingPerlCannotDo ;). If Perl was created for the purpose of constructing large applications with long tail-end maintenance life cycles, I'd think it truly awful... but it worked well enough in the niche for which it was designed.

Oh I agree (well, kind of - I parse over 25,000 flat file websites each month without using perl (nor awk)) - but, the point is Larry Wall seems to have implied (or the person who created this page) that Perl was something that we would say lots of good things about in the long term, via maintenance and readability (and mentioning words like quality in a book about perl, is just..funny.. I could see it in an Ada advocacy/snob book, though).

That is an overly optimistic interpretation of the quote: "... that makes you write (and maintain) programs that other people won't want to say bad things about"). That's very different than "that makes you write awesome programs that other people will adore and say good things about". Good code is often *not* noteworthy. Perl has many ways to do a thing primarily so that it can fill in many niche tasks, but a good Perl programmer will produce code that is unremarkable; code you can understand at 4am on a Saturday morning despite your hangover. -- Oliver Smith

This may be a reason to not take anything we read from Larry Wall as truth - as his predictions of what people would have thought of perl seem to be way off, now that we look at history (after the book was written). That is, if this text was pulled from, his book? I don't know. If it is: above is proof that Larry Wall is not to be taken seriously, ever - especially when he makes estimates or hypothesis. Because apparently he was dead wrong on this one. And also: Type Safety is for lazy people, which Larry Wall seems not to grok.

LazinessImpatienceHubris aren't about Perl in particular. It's simply an observation made by man that has some resonance in the rest of hacker society - especially, I imagine, among people who think as LarryWall does about such subjects as 'ThereIsMoreThanOneWayToDoIt'. He isn't the first or last person to say something to that effect. Considering that it was stated half tongue-in-cheek, I can't imagine it proof of anything in particular.

The idea that pride - confidence that you can do better than what has already been done - is often a good thing is hardly new and has its share of truth: someone without pride or who puts the movers and shakers of yesteryear on too high a pedestal have one less motivation to challenge themselves to do better than them... though there are other motivations than pride to aim higher. Someday, though, the low-hanging fruit will be mostly gone; it will take much more than one man's hubris to find ways to improve things.

And, yes, types are for lazy programmers who get sick of finding the same damn errors by hand again and again. ImplicitTyping, as per Haskell or Ocaml, is for even lazier programmers who hate writing typenames and structures by hand. And FirstClassTypes are for programmers even lazier yet - those who don't want to take the effort to put everything into the program by hand. Most features appeal to laziness; they wouldn't be features if they didn't make something easier.

It seems this text may have been pulled from a glossary section - but still in a book about Perl with a Perl title. I'd take Larry's advice and actually use it against his language - which is, ironic - since the book about perl seems to go against perl. It's almost as if he created perl as the AntiPattern.

Additional note on hubris based on Greek mythology:

Hubris in Greek mythology actually means "to intentionally diminish another's honor." The hubris used then was more inclined towards an insult. Think of the American equivalent in a Simpson's episode where Homer picks up a glove and says "Sir, you've insulted my honor. I demand satisfaction. I challenge you to a duel!"

Aside from the fact that this is all utterly irrelevant to the LarryWall usage, I can find no etymological support for your claim, which appears entirely made up. Notably 'hubris' comes from the Greek Hybris, who was the personification of insolence, excessive pride and violence.

The key note for hubris in mythology is that you are insulting someone else, whether by putting someone down and/or elevating yourself in the process.

However, modern literature added "excessive pride" as a definition which is more common today. It was later added for how someone diminishes another's honor by elevating themselves above a deity/hero/person. Mortals comparing themselves to the gods or heroes, usually in contests, is the most common form of hubris in Greek mythology.

Here are some myths which help illustrate that key point: 1. Athena and Arachne - Arachne commits hubris by comparing her weaving skills with Athena's. 2. Apollo and Pan - Pan challenges Apollo to a music contest of Lyre vs. Pipes. 3. Prometheus - Prometheus matches wits with Zeus and pay a serious price. 4. The Judgement of Paris - By judging Aphrodite as the fairest of goddesses, Paris puts down Hera and Athena who were also in this contest. 5. Semele - A less apparent one: Hera diminishes Semele's honor of giving birth to the wine god Dionysus by killing her.

Here's a more detailed synopsis of another myth to further explain hubris in mythology:

Niobe is a queen who has 6 sons and 6 daughters. One day when her people are supposed to worship and sacrifice to the Titanid goddess Leto, Niobe stops them and orders them to worship her instead. Niobe supports her claim by saying not only is she as beautiful as Leto, but she has 12 children while the goddess has only two -- the twins, Apollo and Artemis.

Niobe's hubris here is insulting a goddess for having fewer offspring. A known saying in mythology is to never compare yourself to the gods, lest you feel their wrath. If Niobe simply says she has lots of children and stops right there, her claim is still of pride, but she hasn't made the comparison which becomes the insult.

Because of what Niobe claims and her stopping the sacrifice to Leto, the goddess is deeply insulted. In return for Niobe's hubris, Leto suggests something should be done with Niobe's children to restore her honor of having born beautiful Olympian gods. Apollo and Artemis proceed to kill off Niobe's children as punishment. The punishment itself is now like a retaliating act of hubris (insult) against Niobe by Leto.

Side note: in mythology, Zeus does not really strike someone with a lightning bolt for any hubris, unless it's hubris committed against him. If one commits hubris against another god, the offended deity will often deal vengeance upon the transgressor themselves, or they'll get someone to deal with it for them. Zeus would strike someone with lightning for several main reasons: when someone broke a great oath, especially if they swore by the river Styx, or they are specifically told they will be struck by lightning if they violate it (check Homeric Hymn to Aphrodite - the story of Anchises); when someone violated another god and that god asked Zeus to strike the violator with lightning (Odysseus's crew eating Helios' cattle of the sun - Odyssey); when someone challenged Zeus (eg. Hesiod's Theogony - Titanomachy, Gigantomachy); or when Zeus wanted to use one of his ominous signs to clearly mark his presence (last lines of Book 24 in the Odyssey).

Not to say that any of this is the same as ExtremeProgramming, but there are clearly a few things that bear more than a passing resemblance (though they are ultimately different from each other IMHO).

The above definitions are pretty "short & sweet", perhaps a little too short for the uninitiated. They may require further explanation. Obviously they are intended to look a bit contrarian at first glance; these qualities are typically considered vices rather than virtues. I'm sure the irony was used partly for its attention-grabbing effect. But it was also used IMHO to suggest that these qualities can actually be desirable when they occur in certain ways.

OTOH, while it might be true that great programmers possess these three virtues, merely possessing laziness, impatience and hubris does not automatically make one a great programmer (on the contrary, it could simply make you a hugely arrogant and pompous ass - if you go it about "just right" ;-). There are right ways and wrong ways to possess them.

The way I typically think of Laziness in this regard is in the sense of "Laziness is the mother of invention." The more common saying uses "necessity" in place of laziness. But for me I think that "laziness" is the better word. It's a kind of "advance" laziness where you want to get rid of redundancy and eschew repetitive tasks (by automating them). You're not just thinking about how to be lazy right now, but about how to continue being lazy from now on through the foreseeable future (such advance laziness requires thinking ahead ;-). By the second or third time you start hand-coding up the same or similar "one shot" task, laziness should make you not want to have to code it up again (ever).

Lazier still is to look and see if someone else has already solved your problem (perhaps it's already on CPAN - the "Comprehensive Perl Archive Network"). If they haven't, then while you code up your solution, you see if you have any other related tasks you need to solve that this solution might work for (as long you're solving one problem, see if you can solve several at once with perhaps only a little extra effort). Squeeze as much benefit as possible out of the least amount of effort that will help this problem and others be solved once and for all.

This is what is meant by minimizing total energy expenditure. You want to minimize your own work, so you try to address possibly multiple problems (that really exist) with the same program, all the while trying to write things OnceAndOnlyOnce and RefactorMercilessly so it is easy to change. And if you end-up having to field a lot of questions about it, you improve (or create ;-) documentation and ensure that it too tries be non-redundant, and achieve things like LocalityOfReferenceDocumentation, which is why Perl5 has a mechanism for embedding the user-docs inside the script itself - something that is far easier for all-in-one-file scripts than for large systems. (See also WizardsAreLazy.)

Impatience has to do with how long it takes you to get off your lazy butt and get frustrated enough to automate repetition and eliminate redundancy and excess ;-)

Hubris may require a more detailed explanation. It is a word of Greek origin. I believe the literal Greek translation of "hubris" is "overweening pride." But what does overweening mean? I think the term became most commonly known from MrAristotle's work "ThePoetics?", in which (among other things) he describes the recurring themes/rules used by the dramatic playwrights throughout classical Greek tragedies:

There is a "tragic hero" (protagonist) who is almost always of royal blood. This demonstrates that if it can happen to these folks it can happen to us too ;-)
There is some sort of problem the tragic hero sets out to solve, but he/she always possesses some "character flaw" or "tragic flaw" (the Greek term here is "hamartia", in verb form (hamarta'no) an archery term meaning literally "to miss the mark" [Trivia: in Hebrew it's hhat-ta'th', having same meaning. Both are usually translated with "sin" of "to sin"]
The tragic flaw is usually "hubris", an excessive pride that causes the tragic hero to place his own importance above that of the gods, and/or before that of the family/household ("oikos" in greek).
The tragic flaw is (of course) the source of the main "tragedy" in the play, bringing about the hero's downfall or reversal of fortune ("peripety" or "peripetea").
With this downfall comes reflection where the hero understands what he did wrong (and whom he "done wrong") and learns some ethical lesson or moral imperative.
We, the audience, are then supposed to feel a sense of "pathos" for the protagonist and learn the lesson for ourselves, through his pain and suffering (which supposedly helps the audience experience "catharsis").

While this definition and its history seem to have more to do with Greek theatre than with Perl, programming, or software, IMHO it still forms the best basis for deriving meaning in other contexts. In particular, it clarifies the extent of the "excess" or "overweening" as being to the degree where one places one's own importance ahead of god(s) and family.

I think it's not too difficult to extrapolate the object of pride, and the "god(s) and family" from classical Greek tragedy into a software context: the object is the thing we are crafting (and ultimately ourselves), and the "gods & family" translate into "employer & family" or "business & family" (and sometimes even our religion). In the context of software, I believe the "pride" here refers to "pride in craftsmanship" of one's work: the self-satisfaction of a job that is indeed well done, and the peer approval or recognition that may result.

Those with this healthy degree of software hubris feel an obligation to go above and beyond mere customer requirements or business demands, to make the product "good" in ways customers might not directly perceive, or even care about, but which we and our peers would notice (things like code formatting/conventions, readability, maintainability, design flexibility, and even aesthetics of implementation and its presentation). Some would just call this good professional ethics, but "software hubrites" tend to take this much further than others typically would.

Many of these extra efforts often improve customer satisfaction indirectly (some of them might even improve employer satisfaction); but that's not necessarily the primary motivation for "excessively" compromising our schedules, our employers' interests, and often our families and friends (and even our religion, for true die-hards). When we suffer from this virtuous variety of hubris, we tend to do these things more for our own self-satisfaction and self-esteem, so that our peers might appreciate it and use it, and that it will be something we can feel proud of within our own professional/software circles.

This in turn lends itself to a kind of egoless pride that can work extremely well in team settings.

(All of which is just a very long-winded explanation of what is distilled into about 6 lines in the glossary of ProgrammingPerl ;-)

-- BradAppleton

[Hubris is] "overweening" [pride] as being to the degree where one places one's own importance ahead of god(s) and family.

This is where the distinction between hubris (tragic) and pride (heroic) is seen. The gods were quick to inflict severe punishment upon those exhibiting hubris, such as the punishment which kept Odysseus from returning home as a champion of the Trojan War in the second of Homer's two great epics.

Hubris is the result of a great programmer's skills leading to tremendous success, widespread acclaim, such that they believe that they cannot be wrong; not even the gods could challenge their code. It can lead a programmer to conquer the impossible, and also to horrible disaster. It is a path not to be taken lightly.

-- ChrisFay

I often thought that if I went for an interview and someone asked me what my greatest asset was (as a developer) I would say Laziness, however, I suspect that I wouldn't get the job. Now, at least, I can back up my statement with a reference to a published author.

I am lazy because I can't be bothered writing a 5,000-line solution when I suspect a 500-line one exists. I'd rather spend a couple of days scribbling on the back of an envelope, write 1,000 lines, refactor to delete five hundred of them (because it will save me time later) and go home early on Friday because the job is done.

If someone else writes the 5,000 lines I get annoyed because I'm going to have to get my head round it, bug fix it, maybe even throw it away completely and write the 500 lines anyway by staying up late. It ruins my day.

It's a huge advantage that I really can't be bothered with all that.

-- RichardHome

To me, the hubris involved often takes the form of "I can do this better". It spurs the creation of tools or code because the ones you have aren't good enough. You're using tool X, which cost umpty bajillion dollars, and you spend your time thinking "This is crap, I could write something better." And, because of laziness and impatience (fighting with the existing tool is too much work, and you want to get it done and go home), you do so.

I work with and around a lot of non-programmers and what I really see is the lack of these qualities - they take what they're given, learn to work around the problems, and do things the hard way. Over and over again. Laziness, impatience, and hubris are the spur that "great programmers (I consider myself to have these qualities, but I'm probably not a *great* programmer) have to make them write new tools. Larry Wall never would have written perl if he'd just kept chugging along with awk.

-- ChrisMellon?

Some may suggest he wrote Perl, a semi-clone of Awk, because he was too lazy to learn Lisp :-)

From http://www.perlmonks.org/?node_id=149961

#!/usr/bin/perl
use strict;map{$a++}
('g','r','e','p')
;$a=$a-$a--+$a++;$a++;$b=int
(rand($a));$b++;map{chomp;@INC
=split(/\D/);push(@_,(int($INC
[$b]/$b),int($INC[$b+$a]/$b)))
;}(<DATA>);map{printf("%c",$_)}@_;
__DATA__
L076I146H216a097m218u351
z122p224b294i105a194r342
n110t232i315e101i210s345
s115e202(096s115n220#096
&032c198$096^032e202)096
^032#064?096<010>020\030

Apparently this whole thing was originally a joke. The source? Larry Wall himself in "Hobbits Would Make Great Programmers": http://youtu.be/G49RUPv5-NU

Turns out the best programmers embody traits and virtues related to hobbits:

Persistence: Stubbornness to keep slogging through when the going gets rough,
Smart: Can Outwit Enemies,
Social: Can deal with a group of team members that may think very different than you,
Literate: Be able to read and write documentation
Slightly Insane: Able to view the long term while dealing with the problem at hand (able to work with details and abstractions at the same time)

Or More Paradoxically, to be a better programmer:

Be Lazy in an industrious way.

Be Impatient in a very patient way.

Be Proud in a very humble way.

-- ApeInago?

Why Good Programmers are Lazy and Dumb: http://blog.outer-court.com/archive/2005-08-24-n14.html