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.

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.

This is of course what Larry meant, not the literal meaning.

The whole Perl 6 thing is the ultimate in this form of lazy; 15 years of design work on both the culture and the technology just so he can die in peace in his old age rather than worry about having to be reborn to continue tinkering with Perl 5.

> ... rather than worry about having to be reborn to continue tinkering with Perl 5.

So autovivification such as:

  my $larry;

  $larry->{Please}->{Add}->{Feature}++;

Won't incant a commit in Perl 6?

:-)

Latest Rakudo responds with a compile-time error:

    ...
    Unsupported use of ->(), ->{} or ->[] as postfix dereferencer; in Perl 6 please use .(), .[] or .{} to deref ...

Following the advice leads to:

    my $larry;
    $larry.{Please}.{Add}.{Feature}++;

which leads to another compile-time error:

    ...
    Undeclared names:
        Add used at line 1
        Feature used at line 1
        Please used at line 1
    ...

Those "undeclared names" were probably meant to be string hash keys. So try that:

    my $larry;
    $larry.{'Please'}.{'Add'}.{'Feature'}++;

Bingo.

By the way, that's an unusual way to write such code. The periods are optional, so this is equivalent:

    $larry{'Please'}{'Add'}{'Feature'}++;

And the braces, which support any expression, such as strings as used in this example, are typically not used. Instead, typical code uses angle brackets, which assume the words within are strings:

    $larry<Please><Add><Feature>++;

Finally, in Perl 6 it's often useful to use an array sigil (@) or hash sigil (%) instead of the general purpose scalar sigil ($):

    my %larry;
    %larry<Please><Add><Feature>++;

I don't know if I've incanted a commit in Perl 6 by writing this, but ya never know... :)

----

An old sig of mine (slightly reworded) from the 90s:

If I could live my life again I think I'd believe in reincarnation.

(golf clap initiated)

Well played good sir, well played indeed...

:-D

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.

Lazy coders will pile things into one commit or not use version control

Call it lazy; I call it productivity. When the tool introduces more work than the fix, something is wrong. I can do 5 or 10 fixes before lunch. Except I have to go through a ritual of source management that slows me to a standstill, not to mention derailing my train of thought utterly.

I'm curious: are you specifically talking about the GitHub-style fetish for "a fork and feature branch for everything, followed by a merge"? I've been on a tear lately against GitHub after having another go at using it (it's where the collaborators are) and finding that it's still as terrible as it's ever been.

Have you used Git extensively outside of GitHub or done much with Mercurial? Patch-based/commit-only workflows are the right solution to, I dunno, probably 75% of fixes and don't get in the way like the aforementioned approach, which tends to be misapplied (read: used 100% of the time because GitHub demands it).

Commit-only workflows are very light on ritual, since it's got about the same overhead as leaving a two-line comment. Mercurial makes it even lighter, because you don't have to futz around with the index like you do in Git (so long as you're only changing an existing file and haven't introduced a new one).

You can use the -a parameter with git commit to make it work somewhat similar to Mercurial.

I do use it, but that still qualifies as having to "futz[...] around with the index":

> -a, --all

> Tell the command to automatically stage files that have been modified and deleted, but new files you have not told Git about are not affected.

But this wasn't supposed to be a Git vs Mercurial post. It was supposed to be a GitHub vs sanity one, where Git-based solutions exist in the latter, too, which is why I mentioned use of Git outside of GitHub.