From C# To Perl: Readability

Posted by Brian Sat, 08 Jan 2011 23:13:16 GMT

Let’s talk about readability. It’s a fact that code is read far more often than written. Listening to the Perl community, you would think that it is the most readable computer language ever devised. Larry Wall loves to talk about linguistics and applied some of his knowledge on the subject when creating Perl. The result was… interesting.

Waste No Keys

How many keys does your keyboard have? Want to use a language that seems to go out of it’s way to find a use for every one of them? Perl favors terseness over readability to almost a pathological point. This is exemplified in its use of magic variables. You can find a full list of them here. Now imagine reading a code base that uses any significant fraction of them. To be fair many of them are almost never used. Even seasoned Perl hackers would have to look them up. Also, you can see in the documentation that they also have readable aliases. If you are using any of the obscure ones you should probably use the alias instead.

On a related note Perl seems to have inherited from C the almost pathological need to abbreviate. C system code tends to abbreviate variable names to the point of confusion if you aren’t familiar with the codebase. Perl programmers seem to carry this over into non-system code. I’m a big believer in Domain Driven Design, which states as one of its tenets that you should speak the same language as your users. This should carry over into your code. Once again, when I come back to a codebase six months from now I don’t want to have to think about what that abbreviation was for. Sometimes you can save too many keystrokes.

Ambiguity

Perl gurus often seem to highlight the fact that their language is closer to natural language than most. They consider this to be A Good Thing. I don’t. Natural language is messy, ambiguous, and full of nuance. I want my code to be as clean, clear, and straightforward as possible. If this comes at the expense of succinctness, so be it. I’m writing this code once. Others (and me) will be reading it many times. This is one reason any scientific field of study comes with its own jargon. The goal is to eliminate as much of the ambiguity as possible by distancing itself from natural language.

In contrast, the foundation of C#’s syntax comes from the C/C++/Java model. I don’t find anything inherently superior to this syntax (it is pretty dominant though), but one thing it does not suffer from is ambiguity.

TMTOWTDI

This is where I feel readability suffers the most. Perl’s motto of There’s More Than One Way To Do It encourages significant fragmentation of what are built-in concepts in other languages. For example, there are countless different modules to write object-oriented code. Perl5 has a half-assed OO implementation, leaving it up to module writers to provide most of it. This means that you can have considerable Perl experience but stumble upon a code base that looks like nothing you have seen before. A Perl developer using Moose might as well be writing a different a language.

However, this could be an advantage if you wish to define any sort of DSL, something that is difficult at best to do in C#. Most C# programmers who wish to define a DSL are best served to learn Boo), another language that runs on the .NET framework that is much better suited to the purpose. A true DSL is also difficult in Perl though. The closest I have seen so far is something like Moose, which looks like a DSL in parts. To contrast with another language, before learning Perl I was working with Scala, which through the use of some advanced features allows you to easily define a DSL. To a user it simply looks like you defined new keywords.


To a large extent readability comes down to what you are used to so of course C# is more readable to me right now than Perl. However, some of these issues have nothing to do with my lack of Perl experience (such as pathological abbreviating). Some of the Perl community recognizes these problems. There seems to a sharp divide between traditional Perl users and a group that prefers to use what it calls Modern Perl. Put me in the modern camp.

Comments

  1. Avatar Jeff said 1 day later:

    Computers cannot prove that two programs are equivalent except in trivial and naive cases. Therefore there is no good automated method of determine if there’s only one way to do it. This gets far more complicated when we realize that C# and Perl are both Turing complete and due to this property there will always be more than one way to do it. Thus don’t get your knickers in a knot because you have a choice, because if you don’t see the choice, you’re not trying hard enough or being creative enough.

  2. Avatar Ambiguity said 1 day later:

    Ambiguity and natural language. Well you don’t seem to understand that when we communicate, our communication exists in a context. That context or the lack of context is the ambiguity you’re railing about.

    What bothers me is you claim that science is one way when in fact it is very close to programming. I take a name or a concept, I provide a definition for it and then use it. This is how you’re supposed to program. Abstractly.

    You don’t seem to understand that perl has semantics and that doesn’t make it ambiguous, as well as C# has semantics for the same reasons. Your whole ambguity argument is way off base and your real world example betrays what you meant, instead your example of a scientific paper shows that we define what we will use, and then use. Thus in every context we can create ambiguity simply by using certain names, words and concepts.

    Your point about abbreviation is silly, most of those terms exist in the POSIX context. Thus in the context of POSIX are perfectly meaningful and map one to one. Otherwise for actual perl operations beyond operators there is very little that is truly abbreviated.

    Perldoc perlfunc and find out.

  3. Avatar nperez said 1 day later:

    As a polyglot that has spent a lot of time developing C#/Java applications in addition to the large body of open source work I do in Perl (professional and personal), I do tend to agree with you.

    Perl has matured significantly in the past couple of decades, but remnants of yesteryears Perl due tend to pervade the business space. This is the kind of Perl that makes your eyes bleed from just reading the source and seeing stupid things like symbol table manipulation (probably because tools like Moose simply didn’t exist yet). The community tends to call this ugly body of code that relies on the obscure crap in particular perl versions the DarkPAN.

    A lot of old school Perl simply never gets updated for any number of reasons, the main one is that it just continues to work. The rabid backward compatibility of Perl is one of its biggest boons but also one of its biggest banes.

    Anyhow, the Modern Perl camp is growing. Significantly. Lot’s of CV requests for Perl talent require tools like Moose, Catalyst, or DBIx::Class. And the core contributors to those projects are highly sought after.

    And personally, I tend to write Perl as if I know someone who doesn’t know Perl will someday be reading the code. This means avoiding some of the more terse idioms, not relying on side-effect behaviors (which unsurprisingly future-proofs a lot of things), and meaningful variable and method names (without abbreviation). And I don’t think I am alone in that matter with respects to the projects to which I contribute. It is just good software engineering practice to make sure that the codebase in question is accessible. Unfortunately, in my opinion, TIMTOWTDI and Perl’s fluid and terse idioms means that it takes more discipline to engineer accessible solutions than in other languages and therefore raises the bar somewhat between mediocre and superb developers.

  4. Avatar Naveed said 1 day later:

    I disagree with your statement that “a true DSL is also difficult in Perl.” Perl truly is great for creating DSL’s. And the Perl community has created some very beautiful ones. Take a quick look at:

    http://p3rl.org/Test::Class::Sugar

    http://p3rl.org/MooseX::Declare

    http://perldancer.org

  5. Avatar Brian said 2 days later:

    I must say I’m shocked anybody actually read this. With that being said…

    @Jeff, I’m well aware what it means for a language to be Turing complete, but it has absolutely nothing to do with TMTOWTDI in the Perl sense. Of course there are multiple ways to accomplish any non-trivial task in any language. I simply feel that Perl embraces this to an extent that it causes fragmentation of the language. This is an old argument between Python and Perl camps. I happen to come down on the Python side.

    @Ambiguity, you are absolutely right. That part of my argument was poor. Consider it retracted. However, you missed the point about abbreviations. I am not talking about keywords or magic/special variables. I should have made clear that when talking about Domain Driven Design I am referring to business code. If you are writing system code of course you can abbreviate with POSIX standards. What I am referring to is the tendency for this habit to bleed over into business code. It is the nature of such systems that they have high churn and that changes are often made by programmers who had nothing to do with the original. Unless your team has agreed upon and documented for future developers some standard abbreviations for core concepts, clarity of purpose should absolutely win out.

    @nperez, thanks for the helpful info.

  6. Avatar Brian said 2 days later:

    @Naveed, thanks for the examples. I got spoiled by DSL’s in Scala recently, but hadn’t found any similar examples in Perl.

(leave url/email »)

   Comment Markup Help Preview comment