Reading Code Versus Understanding a Language

by Curtis Poe

One of the common complaints against Perl is that it's "write-only". For many Perl programmers, this is regrettably true. Perl, by design, allows you to get things done in a quick and dirty manner. It's an explicit design goal which allows, amongst other things, the famous "one liners" in Perl which get so much done so fast. However, this freedom comes with a price and that's a heavy price. Newer Perl programmers often write excruciating code, but experienced Perl programmers write code that is relatively easy to read, once you understand the language. There's a huge difference between reading code and understanding a language. But when does a language go too far?


13 Comments

Daniel Berger
2008-01-22 12:29:04
"It’s not necessarily the syntax. Many people will never understand Lisp or Scheme, despite the lack of syntax."


Ok, so when most people say 'syntax' they really just mean 'notation' and, in my opinion, Notation is King. None of the language features matter if you can't get past the notation and you'll just give up. I'll bet I'm not the only person who gave up on OCaml because the notation is just so outlandishly bizarre compared to what I'm used to from other languages.


As for studies, a cursory search didn't reveal anything, though there is a discussion about IT and aesthetics on Wikipedia at http://en.wikipedia.org/wiki/Aesthetics. Studies on aesthetics is where I would start.


As for list versus scalar context, I actually consider it the number one reason Perl's notation is often difficult to both read and understand. Not sigils, though that can compound the problem.

Aristotle Pagaltzis
2008-01-22 13:29:50

FWIW, nowadays I’m leaning towards putting the following utility function in much of my code:


use Carp qw( croak );
use Scalar::Util qw( reftype );
sub slice (\[@%];@) {
    my ( $container, @idx ) = @_;
    if ( 'ARRAY' eq reftype $container ) {
        return @{ $container }[ @idx ];
    }
    elsif ( 'HASH' eq reftype $container ) {
        return @{ $container }{ @idx };
    }
    else { croak "Unknown type for first argument in slice" }
}


Given that, you can write just


my @foo = slice @$bar, qw/this that/;


and the worst of the ugliness is contained.

Sammy Larbi
2008-01-22 13:53:20
I get what you're saying about "if you can’t read my code, that’s my fault; if you can’t read my language, that’s your fault."


But at some point, that obviously not true (as you say your initial assessment may not have been fair).


The problem might be more down to a learning curve. You mention:


That’s almost guaranteed to be a bug, but if you don’t know context, you won’t know why. If you don’t know context, you’re not an experienced Perl programmer.



I don't think you mean it this way, but the first thought that came through my mind when I read it was "So you're saying in order to understand a Perl program I must already be an experienced Perl programmer."


Perhaps if a language is so terse that it takes too long to figure out things (also as you mention), it starts to become the language's fault.


I'm not talking about taking 10 years to really learn a language. I'm talking about being able to understand it by learning a few basic rules. You shouldn't have to learn an entire API of one letter and symbol functions to grasp what is going on in some code (at least, for a high level language).


I guess I'll stop rambling now. There's a point in there somewhere, though I'm not sure I made it very well. =)

chromatic
2008-01-22 16:32:40
I'll say what Ovid is dancing around: if you don't understand context and don't know how to look up Perl's syntax in the copious free documentation that comes installed with Perl, you have no business maintaining Perl programs.


Similar rules apply for any language you care to mention.

George Jempty
2008-01-23 03:19:42
@chromatic, re "you have no business maintaining Perl programs"


Typical Perl "community" hogwash. What if you don't have much of a choice, e.g. your employer just foists some Perl programs upon you, because you've programmed for them in Java and PHP and they figure you can probably pick up another language? Poor sod is just going to be flame fodder for the Perl "community" -- how many of the sh!theads who seem only to know how to shout RTFM are actually going to provide useful feedback, such as RTM, and in particular the stuff about context.

nicg
2008-01-23 06:15:21
@George Jempty


I think you're being a bit unreasonable here. I'm not a java programmer. However, if I came across a bit of java syntax I needed to understand, I would read the docs first. Then if I couldn't understand it I'd ask a question. If I were to say "I don't do java but I have to maintain this. Help me", I would expect to be told to RTFM.


I've found that the perl community is very happy to answer questions that start "I've read the docs and I still can't understand this piece of syntax. Can anyone give me a hand here?" I don't know which bit of the perl community you are talking about here - it's not one I've come across in the last 10 years.


But... in the situation you describe, the obvious answer is that you will need to learn the language in order to maintain the code. This would be true where I to be given a java program to maintain (in real life, that would be 'yesterday'). If learning the language doesn't help with the particular piece of code that would be a good time to ask the community.


The basic issue here is, if you have to maintain code in a language you have to learn the language. Period. If you make that effort, then the language's community will support you. No one will do you your 'homework' for you.

cryptocarnivore
2008-01-23 07:40:53
@Aristotle:
looks great! Hope you have posted this thought to p6lang already? (Might indeed be so simple no one has thought about it yet)
Besides following the Haskell road, it fits Perl's goal of being concise very well. And replacing $"!�} swearing by a four-letter word is even Huffman-neutral... well, cheated for two characters...


@all:
The same dilemma of conciseness vs. learning curve is inherent to any language, especially natural languages. It's a truism that any text gets written for a specific target audience and cannot be understood easily by everyone.
Only bad writers and programmers tend to forget about that.


Technical terminology as an example can be very clear and concise to those who have learned it, while being cryptic and strange to everyone else. This is because of its very nature, being based on prior knowledge.
Your favourite sociolect might be as condensed as letting a specific grunt substitute two sentences worth of speach. To communicate with a wider audience you are bound to use the audience's language.
The fact that perl faces some problems of real world languages probably shows it has Done Something Right.


For programming languages, there's an additional relation between verbosity and maintainability. Think of domain specific languages like regular expressions. No one wants to maintain the dozens of lines of code equivalent to even simple regexps. (And no one likes being forced to learn a domain specific language, either).
Maintainability gets impaired at both ends of the verbosity range. While perl's typical one-liners stand for overly condensed language use, a language is undercomplex if you start using code generators solely to reduce the amount of typing required.


So what?
Watch you language! It's that simple. Or: with power comes responsibility.


When talking to your computer tete-a-tete, you may use as much golfing and obfuscation as pleases your mind and compiler.
When talking to CPAN, use whatever language is appropriate for the problem. If inexperienced programmes are forced to read your code just in order to use it, you have failed anyway.
For the remaining vast majority of code: well, if your code will be maintained by interns, you decide how much time they spend on the problem and how much on understanding your language use...


George Jempty
2008-01-23 08:30:28
@nicg


Baloney. Pity the poor newbie who wanders into comp.lang.perl.misc, for they have just entered the Soup Nazi's store. Yes I speak from personal experience, but in the intervening years, like Elaine from the Seinfeld episode, I've obtained the recipes.


Last time I went to comp.lang.perl.misc (http://groups.google.com/group/comp.lang.perl.misc/browse_thread/thread/e5a91cbcffa838aa/4710e6c8896beba8?lnk=st&q=#) to ask if there was another "way to do it", the obfuscation and insistence on an unreasonable level of precision when asking my question was absurd. It's ironic that for a language whose motto is "there's more than one way to do it", their community seems more interested in adhering to the unspoken motto "there's only one way to ask a question on comp.lang.perl.misc"

Daniel Berger
2008-01-23 09:38:49
I think we're getting offtopic here. Yes, you should learn the language. The question is how difficult it is to learn the language in the first place. How do you quantify that? I mean, if I were to hand 500 aspiring programmers a book on Perl, PHP, Ruby and Python, how could we measure ease of learning? I don't know how you would measure that directly.


I think the best you can do is to get a general vibe based on blogs, language groups, etc, and follow the herd by paying attention to what they like and dislike about any given language, or what drives them from language A to language B. This is still problematic, though, as programmers tend to follow the money, regardless of language difficulty.


I think difficulty of language goes beyond the initial learning period though. I'd say another indication of language difficulty is how difficult it is to remember something after you've learned the basics, or even after you've been programming in the language for several years. If the notation consistently trips you up even after years of programming in a given language, and you have to constantly "look it up in the copious documentation", you've got a problem.

chromatic
2008-01-23 11:47:00
@Daniel,


I agree. That's one reason I think people praise PHP.net's copious documentation so much -- without it, no one would remember the language's argument order or function naming unconventions in the face of that glorious wad of inconsistency.

Aaron Trevena
2008-01-24 03:28:23
@george,


Your problem there is that you're thinking usenet == community - it isn't. usenet is the last hideout of the internet dinosaurs who consider JWZ and Zed Shaw rants to be pieces of art.


I've never been on clpm, heck I doubt even a thousandth of a percent of the perl community have used it.

BBear
2008-01-25 19:26:56
Just remember, "An experienced programmer can write FORTRAN in any language!"
John S.
2008-01-30 05:10:38
There have been studies done on what makes a language easy to learn and use.


The take away from most of the studies is "regularity, visual acuity, minimal semantic distance, and scalability".


Perl is great. When it was basically the only thing, I used it. But it's learning curve and RE-learning curve is so steep that I gave it up when better things became available.


It says a lot about a language that when you stop using it for a while, you can still come back to it and understand the program (Python and Ruby), vs. having to relearn the language (Perl, and sh).


People who regularly use Perl think it's relatively easy and don't understand the complaints about its syntax, just as people who regularly use English think it is an easy language to learn and use.


As for supporting Perl programs . . . most of the ones I've run across in business are small enough that it is more productive to rewrite them than to try to maintain them.


But, to each their own (unless the boss weighs in, of course).