Perl vs. The Rest of the World

ziggy on 2002-02-12T15:23:51

Here's an observation I heard from brevity just over a year ago. (paraphrased):

If you take a reasonably astute Perl programmer and show them a random snippet of Perl code, they should be able to tell what the code is doing, and if it's good code or not. (e.g. poor idiomatic usage, overuse of constructs like backticks, etc.)

Python, on the other hand, encourages a single style, so that it becomes quite difficult to discern whether you're reading code written by a beginner or an expert. This also makes it quite difficult to look at a random piece of Python code to see if it's good code or not (e.g. poor idiomatic usage, etc.)

I'll chime in with some observations about Java that davorg seemed to agree with: while Java may be "prettier" than Perl at the individual statement level (no sigils, no "line noise"), it is actually a very verbose language, and it takes a long time to say anything meaningful. Furthermore, because of the deep object orientation of the language, it can seem like everything needs to be written in terms of containers, (constantly reimplemented) interfaces, hierarchical class decompositions, etc. Translation: lots of code required for very little effect (even though the focus on interfaces and system properties makes class libraries quite interchangeable).

It's also been a very long time since I had to deal with C++, but I came across a discussion of using XP in very large C++ projects. It turns out that the compiled nature and innate drive-to-complexity in C++ makes constant refactoring difficult, thus making XP projects in C++ more tricky than XP projects in Smalltalk, Java, Python, Ruby, etc. I won't claim that I've witnessed this myself, but it does seem to fit with what little I remember about C++, and the little I've read about langauges like Ruby and Smalltalk.

 

The upshot of it all is that the amount of code you need to type is important, as is the way that code "looks". A good language makes it visually obvious what's going on (or what's going wrong) even when the code is reasonably terse.

Or, more concisely, Larry was right all along. It just took a lot of time for some non-Perlfolk to find proof of that. :-)


On elegance

pdcawley on 2002-02-13T11:50:13

Thinking about elegance some more, it seems to me that people are confusing surface gloss with real, deep, elegance.

The canonical examples of deep elegance are, I believe, mathematical. (Lapsing into TeX for a moment) $ e^{i \pi} + 1 = 0 $ and all that (though that particular equation isn't really elegant, it's just really, really satisfying). In maths, you get to express your elegant stuff by, in part, careful choice (and creation) of notation.

Hmm... where am I going with this?

Oh yes. If you listen to the Lispers and SmallTalkers and their ilk, you'll often hear them talking about the idea that, when you write an application what you're *really* doing is inventing a notation that allows you to describe the application, and then describing that application in your new language. Good and 'elegant' programming languages let you come up with a notation in which the top level description of the application is utterly clear to the reader. And of course, they generally make the claim that their language of choice is the 'best' for this.

Perl lets you do this. It's mutability means that you can usually express your intent clearly, if you just stop to think carefully about what you're doing. (And if you aren't occasionally stopping to worry about good names and what you are trying to express, then you should probably start doing so. Or maybe stop programming.)

Because it doesn't try to enforce its way of doing things, it frees you to do the thing in the most appropriate way. The cruft exists in part because all these different ways of doing things, OO, Procedural, Functional, Declarative, in one big regex, Aspect Oriented etc... all have to share a syntax and we (Larry) have had to make compromises. But what we lose on the swings (All those 'ugly' sigils!) we gain on the roundabouts (Easy interpolation of variables into strings and regexes)

That's not to say that I wouldn't love to get my hands on some of those lovely tools that are available for other languages (Class browsers! The SmallTalk Refactoring Browser! scheme's define-syntax!), but what we have right now is great -- 'It Fits My Brain'(tm). And what's being talked about for Perl 6 is greater still.