Re^2: What's it with Perl Syntax ?!

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.

Comment on Re^2: What's it with Perl Syntax ?!

Replies are listed 'Best First'.
Re^3: What's it with Perl Syntax ?! by TomDLux (Vicar) on Feb 21, 2011 at 15:33 UTC
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` [download] 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.	[reply] [d/l]
Re^3: What's it with Perl Syntax ?! by Anonymous Monk on Feb 20, 2011 at 06:15 UTC
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.' http://www.builderau.com.au/program/perl/soa/Special-shortcuts-in-Perl/0,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.	[reply]
Re^4: What's it with Perl Syntax ?! by ELISHEVA (Prior) on Feb 20, 2011 at 06:31 UTC
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.	[reply] [d/l] [select]
Re^4: What's it with Perl Syntax ?! by eyepopslikeamosquito (Archbishop) on Feb 20, 2011 at 07:42 UTC
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: On Coding Standards and Code Reviews (covers what I consider important in writing maintainable code). reddit post about python "readability" chromatic blog about readability Re: Some Help for a Report About Perl (Readability vs Maintainability References) (update)	[reply] [d/l]


Perl: the Markov chain saw
	PerlMonks