The Three Great Virtues of a Programmer: Laziness, Impatience, and Hubris

http://c2.com/cgi/wiki?LazinessImpatienceHubris

by aaronchall • 11 years ago

147 61 11 years ago

aaronchall• 11 years ago

From the article:"

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) "

Foy• 11 years ago

Just today I was actually thinking laziness was one of my greatest assets as a developer. Always trying to find a way to make my work do as much of itself as it can, haha.

vacri• 11 years ago

To be honest, it's not actually 'laziness' as much 'desire for automation'. I've worked with a few actually lazy developers in my time, and it's not fun. For example, it's hard to be a software tester when the design documentation, in it's entirety, is on an A4 sheet in the lead developer's desk, and he's too lazy to make a copy for you. That was medical software, no less...

emerongi• 11 years ago

I would categorize it as efficiency. Laziness is when you have the means to do something, but you're just not willing to do it. Efficiency is when you take 2 hours today to save 10 minutes every day for the next 5 years.

QuercusMax• 11 years ago

I think "desire for automation" is in the right direction, but doesn't quite hit the mark. For me, it's more like "not wanting to solve the same problem twice". I don't really care if it's automated or not, but once I've solved a problem I don't want to think about it again (unless there's some new twist).

At my last job I was always getting bugged by support people asking me the same questions over and over. So I wrote documentation/guides telling how to solve the common issues.

TL;DR: it's not so much "robots are awesome" as "ain't nobody got time for that!".

jfoutz• 11 years ago

Beware false laziness. Slamming out a 500 character command line to build something is ok for a little while, but if it ever falls out of history, you're doomed. Write the Makefile and expend less energy overall.

seanp2k2• 11 years ago

Why not just copy/paste that into a .sh, put #!/bin/bash at the top, check it into source control, and call it good enough for now? I guess they call that a "Dockerfile" these days :)

sdenton4• 11 years ago

True laziness is building your own linux kernel because the length of your command line flags overran the limit allowed by the OS.

Jweb_Guru• 11 years ago

I do that all the time.

ngoldbaum• 11 years ago

The true lazy person starts with a cookie-cutter template whenever they start a new project. It helps when the path of least resistance is also the best practice.

ddrum0012• 11 years ago

...or just use a language where a cookie cutter isn't needed e.g. macros in Clojure

djdjgd• 11 years ago

echo !! > build.sh

artlogic2• 11 years ago

I've found the phrase "long-term lazy" is the quickest way to describe the first virtue: someone who's willing to work hard today so they can be lazy (or have more time for other things) later on.

sweezyjeezy• 11 years ago

I don't see how 'lazy' is a good word to use though. I would imagine someone who is lazy would be much less likely to write documentation than someone who isn't. Prudent is a much more fitting, if less eye-catching word.

Retric• 11 years ago

Ahh, but the lazy coder only writes the minimum documentation, because it's not automatically maintained.

//Here be dragons!

Means, look at the commit history and Grock it, before messing with this.

A prudent coder might go to great detail about how they think this worked five years ago when they wrote the comment which can be worse than useless.

artlogic2• 11 years ago

The "long-term" qualifier is important here. The best programmers I know are willing to go to great lengths to be lazy sometime in the future. Why write and maintain comments and documentation? Because you know when it breaks in the future it will be easier to fix, thus allowing you to fix the problem and go back to whatever "lazy" thing you were doing.

Let's be honest, the term lazy is loaded. I use the phrase "long-term lazy" because it elicits conversation. "You're looking for a trait that's considered negative? Why?" It's much easier to pull someone in by saying good programmers are lazy (in the long term) than good programmers are prudent.

anaolykarpov2• 11 years ago

I'm a Perl dev for less than 5 years. Since last week I changed the company I work for. The new company has a project which is 12+ years old.

This project has a code base written in Perl which seemingly violates all programming best practices: files of 50k LoC,functions of several thousands of lines, there are frequently 5-6+ levels of nested ifs. It contains all the technical debt it acquired during these 12+ years.

However, it took me less than an hour from the moment I got access to a working vm to make the first fix - display the correct currency on invoices which were not paid in usd. And this, in the context that it was the first time I logged into the app and I also had to find such a buggy invoice.

Now, tell me again how unreadable and hard to understand Perl is?

chipsy• 11 years ago

I'm increasingly forgiving of that kind of "primitive" code with giant, heavily nested functions, because the worst that can go _wrong_ with it from a maintenance standpoint is heavy duplication and overreliance on mutable state. Those are knowable quantities, and you can attack them systematically. Otherwise, everything is laid out for you in straight-line order. You can just read it and see "this happens before that" without having to run the program or a debugger, and nobody even has to burden themselves with giving "this" and "that" an explicit name(although a comment can be a real boost to finding what you want).

Codebases that are cleverly factored to within an inch of their life are much, much worse. There's no guarantee that the original factoring successfully decoupled anything, and all the additional content allows for new bugs to slip in "between the cracks" - parameters left accidentally unset, a hierarchy of functions getting called in the wrong order, etc. The original programmer has to spend more time coming up with ways to name and enumerate these details, allowing their eyes and thoughts to be taken off of the domain problem. Because more powerful programming tools are used, more powerful debugging techniques become necessary. And when the architecture breaks, the call stacks just get deeper as the heavy metaprogramming guns are brought out to make increasingly clever workarounds to the resulting issues - after all, nobody really wants to try to disentangle the code after it hits the point of architectural meltdown.

Of the two, copy-paste coding is definitely the lesser evil. So I allow some of that first and then clean up the low-hanging fruit.

anaolykarpov2• 11 years ago

Surprisingly, I still have to find duplicated code. They've warned me it is there, but I haven't seen it yet

mattmanser• 11 years ago

You can do that in any language. I've done that kind of thing in an hour in languages I've never even used before (uncompiled ones, obviously).

Perversely your first fixes are often easier than your later ones as you're not trying to make things better, you want to show off his good you are to your new boss/client.

The problems with bad code come when you have to make bigger changes and you're constrained by the existing design like a straight jacket.

Adding a £ or a $ or a € is really easy for any experienced programmer.

SwellJoe2• 11 years ago

I find it disheartening how much people trash talk Perl, while other languages that are extremely similar (JavaScript, Python, Ruby all share much more with Perl than they do with, say, Haskell or Go or ML), get a pass. It's become trendy to do so, to the point where people who clearly have never learned Perl or worked with it feel entitled to speak with authority on it. Taking it to the point of dismissing anything Perl's creator has ever said (as one of the commenters on this wiki page does) is absurd and means not listening to an extremely bright technologist (I mean, c'mon, Larry invented patch, the basis of a tremendous amount of awesome in modern software development!).

There are misfeatures in Perl, certainly, but there are roughly as many misfeatures in JavaScript. It's silly to dismiss it as "awful" when there's so much that is clearly nice about the language for many categories of problem.

hangonhn2• 11 years ago

I loved Perl when I first learned it. I loved it for the same reason I love Python now. It's very easy to express ideas I have in mind without worrying about the details. It's a great prototyping (as in prototyping ideas, not as in the type system) language. It was my introduction to "higher level" languages. That said, Perl suffers from having too many magical operators that makes it hard to reason about a snippet of code. I feel Python strikes the right balance.

Your comparison to Javascript is apt but I think a lot of us also find Javascript to be a bit of a horror. Recently I learned that Javascript doesn't handle modulus on a negative number correctly among other things.

adrusi• 11 years ago

Perl suffers from having too many magical operators that makes it hard to reason about a snippet of code.

Certainly a matter of personal preference, but a sprinkling of operators isn't so bad once you're acquainted with the language. Yes it's possible to weave a mess in perl, but most of the time you're just dealing with code that might have a few sigils preceeding an identifier, not ASCII soup.

I'd say the real issue is weak typing (implicit conversions between primitives, using strings for many things where some more specialized data type would have been more appropriate) and variable scope problems. These can lead to hard to locate bugs. Worse is the culture in the perl community of manipulating the VM's internals and generating code at runtime and all kinds of other extremely dynamic behaviors. It's amazing what perl lets you accomplish there, but when some package you got off CPAN does something weird and then something goes wrong, it can get really weird.

Recently I learned that Javascript doesn't handle modulus on a negative number correctly among other things.

That's not really true. Javascript doesn't have a modulus operator, it has a remainder operator, and it is completely valid as a remainder operator. The "%" operator is usually called the modulus operator, but it originated in C where prior to C99 its behavior on signed integers was undefined, and on signed integers modulo and remainder are equivalent. So javascript didn't want undefined behavior so they picked one definition and ran with it, it just so happens that C99 chose the other definition and it stuck.

raiph9• 11 years ago

[lang X] doesn't handle [basic math] correctly among other things.

From a recent talk[1], what are x, y, z in the following?

    x       =  7 ÷ 2;
    y       = -7 ÷ 2;
    z       = .1 + .2 - .3

    x    y     z

    3.5  -3.5  0             # human

    3    ?     tiny number   # c89; ? depends on compiler
    3    -4    tiny number   # ruby 
    3    -4    tiny number   # python 2/3    
    3    -3    0             # bc    
    3.5  -3.5  tiny number   # perl5
    3.5  -3.5  0             # perl6

----

It isn't just basic math.

How "long" is the following string?

    ปฏิบัติจริง

    7 characters              # human

    len("ปฏิบัติจริง")    = 33    # python 2
    len("ปฏิบัติจริง")    = 11    # python 3
    "ปฏิบัติจริง".length  = ?     # ruby

(For Ruby, I've found "the core language does not provide a way to count [human perceived characters]". [3] Is that still correct or out of date?)

----

Perl suffers from having too many magical operators that makes it hard to reason about a snippet of code. I feel Python strikes the right balance.

To quote Larry Wall, "Perl 6 ... has been rethought and rebalanced on every level".[4]

It might be interesting for you to pick a couple Perl 5 operators that you consider too magical; then we could look at the merits and demerits of those ops in Perl 5 and their equivalents in Python and Perl 6.

It's very easy to express ideas I have in mind without worrying about the details [of Python, now, and Perl, back in the day]

This, of course, has explicitly been a deliberate focus of all the Perls. Part of the point of Perl 6 was to remove the bits in Perl 5 that were problematic (including some "too cute/weird" stuff) and to introduce much nicer higher level abstractions (eg grammars instead of just regexes[5]).

----

I've long encountered vocal folk who underestimate or misunderstand Larry Wall and Perl to an absurd degree. Perl has been focused for over two decades on making it easy to get the right results when doing basic practical things (like integer division and counting characters) and, imo, that ought to be obvious to anyone who looks at the matter carefully.

----

[1] http://www.slideshare.net/Ovid/perl-6-for-mere-mortals and https://www.youtube.com/watch?v=lpu-3UF_b48

[2] http://www.reddit.com/r/perl/comments/2szv7m/beginner_progra...

[3] http://unicode-programming.readthedocs.org/en/latest/count-c...

[4] http://www.infoworld.com/article/2882300/perl/perl-creator-l...

[5] https://github.com/moritz/json/blob/master/lib/JSON/Tiny/Gra...

sspiff• 11 years ago

I never used Perl, but I use Ruby where people might have used Perl before. (Small one-off scripts or simple automation stuff)

People often attack the appearance and readability of Perl code ("write-only" code), but lot's of Ruby code I come across has the exact same problem, except that people seem to love adding 4 or 5 extra layers of abstraction on top of that.

krylon• 11 years ago

One can write totally incomprehensible code in any language if clean, readable code is not a priority.

And the opposite is true, too, of course. I have seen some fairly messy Python code and some marvelously clean Perl code. And I am fairly certain that over time, some people have written beautiful PHP code and ugly Lisp code.

In my humble experience, it is not so much a property of the programming language as it is of the programmer(s).

teddyh• 11 years ago

In the 90’s I learned and used C as a general programming language. For lighter tasks, I used shell scripts, sed, and awk, and I came to know them well, and I still use them regularly. I knew then that I needed a better programming language for general programming, and from a distance, I could see that Perl was like shell, sed, and awk all mashed together. I did not want it – it seemed like the entirely wrong direction to go. (Minor or domain-specific languages like PHP was out.) I had heard of Python, but did not try it until I was asked to write a small utility which was just complex enough that a shell script would not suffice; I took the opportunity to learn and use Python (then version 1.5) for it.

I have used Python at every opportunity since, and am happy to use Python 3 everywhere possible.

ddrum0012• 11 years ago

I suppose those who only write in relatively similar languages like JS, Python, and Ruby start seeing all the tiny differences and miss the entire subset of Lisp languages that offer so much more.

wmil• 11 years ago

Perl's critical failure is that most CPAN modules expect admin rights and a gcc build environment in order to install correctly.

That killed it on shared hosting and for small projects that may not have a server admin's support.

Also devs are used to having named arguments for their functions. Not supporting that is just silly.

And finally it's difficult to google things like $/, $", $% and $_ when you're confused.

justinator• 11 years ago

Perl's critical failure is that most CPAN modules expect
admin rights and a gcc build environment in order to
install correctly.
That killed it on shared hosting and for small projects
that may not have a server admin's support.

I install Perl apps on shared hosts all the time. The great majority I work on are cPanel-powered. They have a CPAN module installer right from within the cPanel.

Compiler support is an option, and is usually enabled by default. If it's not, it's easy enough to enable that in WHM (the cPanel for cPanel accounts basically)

cPanel is available on hosts like Bluehost, Hostmonster, (dog help us) GoDaddy. Most hosts that built their own control panel for hosting accounts have thus moved to cPanel. cPanel, no surprise, is a Perl shop themselves.

So, the 800lb gorilla of shared hosting control panels presently does what you say you can't.

I also ship Perl apps that specifically do not require outside CPAN Perl modules that require compilation, but have support for features, if they're present. Throw up the .gzip distro, throw up, "install.cgi", chmod 755, and visit the thing in your browser. It wasn't impossible ;)

raiph9• 11 years ago

It'll be interesting to c how the radically overhauled module management in Perl 6 pans out.

(They're making sure that installation is practical. For example, NativeCall, for calling C libs, does not require a C compiler.)

Also devs are used to having named arguments for their functions. Not supporting that is just silly.

The latest Perl 5s have this ("signatures").

Signatures are a central element of Perl 6. (They are way more powerful than in Perl 5, even the latest.)

it's difficult to google things like $/, $", $% and $_ when you're confused.

Yes.

Fwiw Perl 6 only keeps three of these oddly named variables (removing dozens of others) and they are simple in practice:

    name  concept    formally means the current/latest

    $_    it         topic (Nil or any value/object)
    $!    oh noes!   error (Nil or unthrown exception)
    $/    /regex/    match (Nil or parse tree)

AdieuToLogic7• 11 years ago

Perl's critical failure is that most CPAN modules expect admin rights and a gcc build environment in order to install correctly.

See this thread:

http://www.perlmonks.org/?node_id=630026

For how to install CPAN modules in alternate locations. Be sure to note the setting of PERL5LIB to the location you choose when running Perl in order to resolve the modules in the custom location.

Also devs are used to having named arguments for their functions. Not supporting that is just silly.

There are some idioms available to address this. If you are interested, reply and we'll discuss them :-).

And finally it's difficult to google things like $/, $", $% and $_ when you're confused.

If you have access to a Unix machine with perl installed, then running:

man perlvar

Will produce a man page enumerating the predefined variables which are difficult to use a search engine to find.

HTH

cbsmith• 11 years ago

I think you have to squint pretty hard to say that JavaScript, Python, or Ruby are "extremely" similar to Perl. It's really its own, bizarre world.

AdieuToLogic7• 11 years ago

I was going to click the link, but it takes way too much time to RTFA and I already know where this is going to end up.

Too soon?

raiph9• 11 years ago

I got it even if no one else did. :)

AdieuToLogic7• 11 years ago

Vielen dank!

Getting hammered by the votes was quite disheartening. I assumed indirect reference to one of Larry Wall's most famous quotes would be obvious.

Ah well, I guess what happens when I "assume" is it makes an ass out of micro-me ;-).

amelius• 11 years ago

I'm not sure if laziness is a virtue of a programmer. Often, writing the program takes a lot more work than the actual use (by that particular programmer) of it would warrant.

Take for example the developers of a word processor. Would all that effort spent on that office-automation software really cancel against the probably few letters and/or documents that a developer would write using it?

The Three Great Virtues of a Programmer: Laziness, Impatience, and Hubris

Related Stories