What You Can and Cannot Teach about Encapsulation

Chris Yocum recently argued that Perl (5) can be difficult for lazy and undisciplined programmers. I agree; when the default of a language or ecosystem are difficult, laziness wins.

Isn't that an axiom of Perl? Laziness wins, so let the compiler and runtime and libraries do the work so that lazy people will still get their jobs done well?

The question is "What do you encourage?" Which design decisions does your language allow people to make with the least friction? (Leave out the people who distrust arrays and so they use the filesystem to process aggregate data structures, line by line—I've seen this, but not in Perl. These people need more help than language design; this is active malice and hostility toward programming and programmers.)

I come back to the example of Moose because it's a great example. Moose doesn't explicitly say the right way to handle instance variables is through accessors, even though that's probably the best way to handle instance variables. Moose also doesn't explicitly say that the best way to initialize instance variables is through named parameters passed to a constructor, even though that's a great approach. Instead, Moose makes those seem natural and easy such that you must be actively malicious (or be very curious, or have very specific, special needs in your project) to stumble upon a different approach.

Moose doesn't explicitly teach encapsulation is good! I'm not sure how well you can teach that, until the student has experienced the problem of poor encapsulation. Even so, you can teach the student good habits and you can hope that osmosis will drill in the point that encapsulation of instance variables leads to fewer problems.

Compare that to the Perl 5 documentation about how you can bless any type of reference, how you can manipulate data structures, and—oh, look over there at that blessed typeglob in core libraries!

The old Perl 5 way of doing something special when you need something different than default is to cram something else in a C-shaped box to fit the C-shaped prejudice of the core Perl 5 VM. After all, experienced C programmers know that an object is just a struct with an extra pointer hanging off it for method dispatch. (Larry has since resolved not to borrow features from Python wholesale.)

(Incidentally, this is why many novice programmers who've just learned Ruby think that Ruby is more flexible than Perl: Perl 5's Perlish API for metaprogramming is horribly ugly because of early and foolish consistencies. Even so, Perl 5 lets you manipulate more things than Ruby does because while ugly is skin deep, its manipulexity is chromosonal.)

The Moose approach is simpler: there's an official metaobject protocol with a very Perlish interface and no distinction between the Perl side and the C side. (You can't teach consistency either, but you can certainly demonstrate its presence and its absence.)

The lesson from all of this is simple: if you want to help the lazy programmers in the middle of the spectrum, make their lives easier by making the right thing so easy to do that their laziness will prevent them from doing the wrong things.