

Readable Perl (compared to lang*) - tomneo
http://greenokapi.net/talks/ReadablePerl.pdf
NO FLAMES PLEASE.
Another i++ of perl's &#60;blah&#62; is not required.<p>What have been the successful trade-offs interms of readability in &#60;language&#62;?<p>CPAN Power
http://search.cpan.org/~fxn/Acme-Pythonic-0.46/lib/Acme/Pythonic.pm :P
http://search.cpan.org/~shancock/Perl-Tidy-20090616/lib/Perl/Tidy.pm
http://search.cpan.org/~elliotjs/Perl-Critic-1.105/lib/Perl/Critic.pm
Lots of modules((like Class::*) to simplify boilerplate code which inturn enhance readability.<p>Flowcharts[not exactly related to readibility]
http://search.cpan.org/~jnagra/Perl-Visualize-1.02/Visualize.pm
http://search.cpan.org/search?query=GraphViz&#38;mode=all
http://search.cpan.org/~tels/Devel-Graph-0.12/lib/Devel/Graph.pm
======
Locke1689
I notice the conspicuous omission of any Python or Ruby in that comparison
(i.e., the languages which most directly compete with Perl's historic
specialty)...

One thing that struck me is just the shear amount of features and ways to do
things that are built in -- whether it's good or not. For example, the
"unless" operator strikes me as very useless. It certainly doesn't save any
typing and it seems that the existence of many ways of doing the same thing
makes it _more_ confusing, not _less_.

That said, I'm definitely in the "Perl has serious readability and maintenance
problems and Python makes me weak in the knees" camp.

~~~
kingkongreveng_
Perl is perfectly readable. Go find me perl I can't read on CPAN.

Like C++, perl greatly rewards expertise and experience. If you want to be
able to read everything inside two months, well, go elsewhere. But I'd say
you're missing out.

~~~
amix
I think you got a point. Other well designed languages don't require an expert
level for understanding of well written code. Perl (and at some extent C++)
requires a lot of knowledge and experience before you can read code. I, for
example, don't find @_ that readable or logical - it can mean anything and in
Perl operators usually have different meanings depending on the context (which
makes it even harder to read code).

So Perl is readable if you are a Perl expert - for everyone else it's pretty
unreadable.

~~~
thwarted
Of course @_ _could_ mean anything, but it means just one thing, which is
documented in the perlvar man page:

    
    
       @_  Within a subroutine the array @_ 
           contains the parameters passed to that subroutine.
    

Access to the man pages does not make one an expert, anyone can read them. I
seriously hope that anyone who is intending to successfully understand or
modify code know enough about the language it is written in to actually be
able to read it.

There are idioms in every language, _especially_ in syntax. Python's
inheritance declaration looks like a function call or an argument
specification. Ruby's uses < to indicate inheritance. PHP and Perl are more
self-documenting in this regard, using "class _subclass_ extends _baseclass_"
and by assigning to a variable named ISA within a package respectively.
Python's decorator syntax is non-obvious, and uses a perl-ish sigil to boot.
Ruby using sigils to indicate scope (vs type, which is how it is done in both
perl and older BASICs) is non-obvious. Python syntax for single element tuple
creation. PHP's arrays allowing both integer and string indexing in the same
array, and its "hashes" or "dicts" keeping order, leads to idiomatic code.
Perl assignment list expanstion when using arrays and hashes as subelements on
the LHS eating up the rest of the input is idiomatic. unless is idiomatic in
perl, but only because few other languages have that kind of construct, and
instead force you to use an if-not, which isn't always as readable. Perl's map
and sort look like they can take closures, but they're really BLOCKs which is
slightly different. The difference between Proc objects, blocks and lambdas
and how they can be converted between each other and called in ruby is
idiomatic.

Latin is readable if you speak Latin -- for everyone else it's pretty
unreadable.

~~~
amix
I will reference to Steve Yegge's rant on Perl. It has a lot of examples on
Perl operators that are overloaded:
<http://steve.yegge.googlepages.com/ancient-languages-perl> \- - and how their
man pages isn't a big help.

While other languages of course have their special syntax, Perl is very
extreme in this regard. This is best illustrated by the following diagram of
special Perl operators (where most of them are only found and used in Perl):

<http://www.ozonehouse.com/mark/blog/code/PeriodicTable.pdf>

~~~
tomneo
you underestimate ur memory mate :P and yegge is wrong. "references" were
added to perl because of lexical variables.

~~~
chromatic
> "references" were added to perl because of lexical variables.

I'd like to see a citation for that. My understanding was to allow for simpler
nested data structures.

~~~
tomneo
my mistake ... what i meant to say was lexical variables, lexical closures
also needed the concept of references.

~~~
chromatic
> ... lexical closures also needed the concept of references.

I can't imagine how that could be, unless somehow you mean that "first-class
functions require references in Perl 5", which is true only insofar as first-
class functions rely on the design concept of references.

If Larry had invented the idea of a reference context (not the most precise
term, but I think it's understandable), references would have been unnecessary
in Perl 5.

~~~
tomneo
> "first-class functions require references in Perl 5" yes thats what i meant.
> to put it simply. perl4 did not have lexical variables, first class
> functions, proper syntax for nested data structures. larry said let there be
> references. its one big hammer to solve all problems.

i think perl6 is using a different appoach based on laziness for nested data
structures. there are always strings and do blocks which assign and return
globs with randomised but unique name(gensym but perls gensym is returns a
GLOB reference so you have to write ur own).

reference context == continuation right ?? in sub bar { ... $foo = sub { ....
} ... return \$foo}, i think \$foo also captures the lexpad of bar using a
single reference to $foos internals. thats all.

otherwise i think one would need continuations like in ruby or scheme or
perl6.

------
tomneo
a note ruby's syntax philosophy is a bit on the lisp side. python's syntax
philosophy is pragmatic. perl's syntax philosophy is on the linguistic side.

thats is why its "bare syntax" like sigils and all are wierd like the case
endings in english. but they follow laws which when groked can be abused. like
say "ness" can be added to adjectives to create nouns and so on.

eg) in ruby or in python varible names are like this, foos =
["foo","bar","foobar"] in perl you simply say @foo = ("foo","bar","foobar").

since perl treats $foo differently from @foo. (but most however do use @names
due to their natural inclinations). see
[http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata....](http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata.html)
if you can grok gramatical cases.

------
balding_n_tired
I find myself increasing the proportion of Python I use, really for two
reasons: the libraries that come with PythonWin; the PythonWin environment,
not least the REPL. I agree that Python is rather prettier, but this has very
little to do with it.

------
forinti
I think comparisons usually don't take into account that Perl code is very
compact. If you were to unroll a perl 3 liner into a Java 30 liner, would the
Java code be as readable? I think not.

~~~
pasbesoin
Yes. I often find the "context switching" in scrolling around a lot more
inhibiting that the density of e.g. Perl syntax.

Perl syntax also builds on a rich heritage. If you are familiar with that
heritage, it's a lot more evident. Conversely, as you learn Perl, that
heritage is elucidated. (For example, learning Perl in a Windows environment
(I know...) and then moving to UNIX.)

------
fexl
It is true that script kiddies write ugly and unreadable Perl code. It is also
true that professionals write highly disciplined and beautiful Perl code.

Incidentally, on the subject of object orientation, I concur with Sriram
Srinivasan's preference for Composition instead of Inheritance. He writes in
"Advanced Perl Programming":

"Then when John Ousterhout's Tk came along, I marveled at the ease of creating
widgets, even though it was in C and provided all the features that Motif
provided (and much more). The Tk architecture used composition, not
inheritance. I have been suitably chastened."

------
onewland
scribd link is broken

