Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Re: What's it with Perl Syntax ?!

by Anonymous Monk
on Feb 18, 2011 at 10:24 UTC ( #888875=note: print w/replies, xml ) Need Help??

in reply to What's it with Perl Syntax ?!

OK I am one of those who write Perl code but are not Perl programmers. Perl does not have to be cryptic. But my guess is that the moment you become a proper Perl programmer you start to achieve your objectives with lesser (and perhaps more efficient) code and perhaps code that looks less readable to the non-monks. This does not happen so much with other languages. Everyone writes more or less the same way. Popularity of a language will suffer if the non-monks are not comfortable with.

Replies are listed 'Best First'.
Re^2: What's it with Perl Syntax ?!
by ELISHEVA (Prior) on Feb 19, 2011 at 21:24 UTC

    But my guess is that the moment you become a proper Perl programmer you start to achieve your objectives with lesser (and perhaps more efficient) code and perhaps code that looks less readable to the non-monks.

    In my experience quite the opposite is true. The more experienced someone is the more readable their code becomes. Experienced programmers in any language know how to use the language's features to make the code self-documenting. They remove clutter by encapsulating logic in functions and methods. They chose variable names and method names wisely. They take advantage of the languages scoping rules and cluster data close to the methods that use them.

    Sometimes experienced programmers do use some of the less common features of a language, but their experience ensures that they are used to improve overall readability. Of course, you will have to look that funky syntax up in the reference manual, but this is no different than reading a good columnist in the New York Times or ploughing through a Faulkner novel. You'll go to the dictionary from time to time reading those, but once you know the words, you have the feeling that "yeah - that word says it best". A good writer in both English and code chooses words carefully.

    The programming equivalent of "big words" that you have to look up in the dictionary exist in every language. I've written some pretty complex code using Java generics. I doubt your average Java programmer could read it without some thought. Heck, if I've been away from it, I need to crack open the docs and relearn things just to dig into my own code. Php has a bizillion functions and the naming of those functions sometimes seems just a little haphazard. If you code using some of the more unusual ones, your reader is going to be spending time in the docs even though it is "only" Php.

      I've recently been going through a number of the exercises at ProjectEuler. I did find it amusing that some questions turn out to be a one-liner in Perl.

      On the other hand, I imagine many people, Perlers or otherwise, would require some hep with

      my $sum = reduce {$a + $b } map { .... } grep { ...... } @some_array

      Yes, it can be broken into an explicit block, spread of several lines. Besides being more verbose and slower, the block focuses on what happens element by element, while the dense version thinks in terms of the data set.

      As Occam said: Entia non sunt multiplicanda praeter necessitatem.

      I realize that you can write bad code in any language. However, less readable code may not necessarily qualify as bad code.

      The author in the article below says 'Perl is renowned for being a language where you can express complicated commands in a very small amount of space.',339028313,339272650,00.htm

      May be good Perl programmers do not sacrifice readability for brevity. However, it would appear that Perl allows 'brevity' like no other language. I mean no offence when I say all this. All I am trying to say that when an average programmer is learning a new language, he/she may find the brevity a bit hard.

        May be good Perl programmers do not sacrifice readability for brevity.

        Good programmers (and writers) in any language adapt their writing style to circumstance.

        I think it is a common mis-perception that greater expertise means the need to use that knowledge in every circumstance. Perhaps that mis-perception is no different than the high school kid or college student who goes crazy writing essays with the longest possible words hoping to impress their teacher with their mastery of the English language? Eventually they figure out that sometimes less is more (one hopes).

        If I am writing a one liner on the command line, I might use shortcuts like you describe. No one has to read it again, including I, and it saves typing. For code that has to last a long time, I tend to avoid them. while(my $line = <STDIN>) is far more self documenting than while(<STDIN>). Additionally, those shortcut variables are fragile. They tend to get reset easily. As a result, the wise programmer transfers their value into something more stable as soon as possible.

        The situation is similar to a skilled speaker that can talk the slang of the day with their friends on the street, use simple language with their two year old child at home, and write academic papers for publication at work. It is all English (or French/Hebrew/German/etc), but oh how different.

        Where I might agree with you is that Perl's flexibility makes it more vulnerable to the same errors and mistakes we make when learning to write natural language. Java generics are obscure but you aren't likely to be responsible for reading and writing such code unless you are a fairly abstract thinker to begin with. Perl's more obscure shortcuts help with tasks even a beginner needs to do. As a result, it is a lot easier for someone learning to program to be like that high-schooler with Perl than it is with Java.

        Update: added final paragraph.

        You are using the term "readable code" without clearly defining it. I think "maintainable code" is far more important. Some of the things that help make code "maintainable" are:

        • Sound domain abstractions.
        • Wise program decomposition.
        • Highly cohesive, loosely coupled modules.
        • Descriptive, explanatory, consistent and regular names.
        • Minimizing the exposure of implementation details. Minimizing the use of global data.
        • Minimizing the scope of variables, pragmas, etc. Avoiding action at a distance.
        • Avoiding duplication (DRY).
        • Encapsulation.
        • Interfaces that are: consistent; easy to use correctly; hard to use incorrectly; easy to read, maintain and extend; clearly documented; appropriate to your audience.
        • Useful commenting and documentation.
        • Components that are testable in isolation. Comprehensive test suites.
        • Avoiding unnecessary cleverness (encapsulating and commenting it when cleverness is required).
        • Establishing a rational error handling policy and following it strictly.
        • Logging effectively. Logging enough information to trouble-shoot customer problems without the need to attach a debugger.
        • Checking the result of all file operations, API calls and external commands, and handling unexpected results.
        • Consistent code layout.
        • Avoiding "big arse" functions.
        • Avoiding magic numbers.
        Perl doesn't stop me doing any of this. Indeed, it nicely supports all of the above points IMHO. Note that a more subjectively "readable" programming language does not somehow magically prevent you from violating any of the above points. Personally, I have little interest in cosmetic issues, such as whether one prefers forced indentation (a la Python) or considers Perl's regex syntax or use of $ in variable names "ugly" or "line noise", for that is just personal (subjective) preference and has little to do with writing maintainable code.

        See also:

Re^2: What's it with Perl Syntax ?!
by chromatic (Archbishop) on Feb 19, 2011 at 02:07 UTC
    This does not happen so much with other languages.

    Certainly it does! See The DailyWTF for copious examples.

    Everyone writes more or less the same way.

    I can find examples of good Java and bad Java as well as good Python and bad Python. (COBOL's probably an outlier.)

Re^2: What's it with Perl Syntax ?!
by luis.roca (Deacon) on Feb 20, 2011 at 20:05 UTC

    A good, advanced Perl programmer isn't writing code that's hard to understand for beginners to the language and programming novices. They write advanced solutions to advanced problems. It's those solutions and the problems they address which are difficult for beginners to understand. That is the case for any language.

    A one line conditional statement isn't hard for me (a beginner to both programming AND Perl) to recognized because I've learned and seen examples of them in use. Other than being cool names, I had no idea what implode or explode were supposed to do in PHP (two of the very first functions you learn in the language). One step further, imagine going into a Python forum and asking "Hey, what does '>>>>' mean? I keep seeing it in my book?" I'd be laughed out yet that's a question I had when first researching what programming language I wanted to learn.

    These are small particulars that you have to look past and instead ask: "What is this language's approach to solving problems and is it similar to the way I think or want to work."

    "...the adversities born of well-placed thoughts should be considered mercies rather than misfortunes." Don Quixote

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://888875]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (4)
As of 2017-01-23 02:29 GMT
Find Nodes?
    Voting Booth?
    Do you watch meteor showers?

    Results (190 votes). Check out past polls.