Randal L. Schwartz

It looks like accent problem for me.
Take couple of people, english speakers. Let's assume that one has cockney accent, and other - some asian english accent. They both speak english, but do you think they will understand each other? They do, eventually, but I think it will be quite hard to both of them.
The same thing in perl, it offers too much flexibility, and each developer can choose his own style, his accent.

Well, it isn't as simple as that. I've never written any Java but I can basically read Java. I've never written any PHP but I can read *some* PHP. I've never written any Ruby but I can read a lot of Ruby.

I can almost never read Perl code. Yes it's just because it's a *very* different language to the ones I'm used to (Python, C# and JavaScript mostly). However it's also at least partly because Perl chooses to place such syntactic significance on sigils, that *unless* you know precisely what they mean you have *no hope* of working it out.

Still, easier to blame your critics than listen to them I guess.

To voidspace.org.uk - the point is that cross-language readability is not that important as intra-language readability. Cross-language readability would be nice I don't say it would not - but trading it off for intra-language readability is quire reasonable. And sigils do make it easier to parse a Perl program in your head once you are familiar with them.

But I kind of agree with Ivan above that this is not the whole story.

I never had a problem reading Perl. I think the reputation comes from all the regex expressions. That being said, regex in any language is ugly.

Permit me to share my own experiences with Perl. Our company has just parted ways with a "hbase expert" who wrote primarily in Perl, & Perl has gotten quite a ribbing around here, & it's certainly not all warranted. That said-- Perl is, indeed, Post-modern. You dig your own holes. ¶

Some background-- I did 4 years of Perl, circa 1998-2002, and was fairly young at the time. I think I still am in possession of one of NIH's many copies of your Learning Perl. ¶

It's hard to guess what my coding style was a decade ago, but I'd wager than in my younger age, I was subject to flash and flourish in coding at that time, & "concise code" or a glimmering recognition of some x86 ASM I'd picked out on Phrack brought me shivers of delight. My role was often either small cgi script development (mod_ what?) or maintence script writing, and I tended to shuffle among a bunch of small projects. ¶

Picking up a Perl project, even as the vested maintainer of a script, was always an new experience-- I barely refrain from calling it a chore. There's a geography to the script, localities enforced not by constructs like inheritance or packages or modules, but by whim of authors and line number. That preference for "concise"? Understanding what special vars are bound to what at the time, and whose making implicit use of them? Challenging. There's a beauty there, but appreciation of any piece of code in such a form is attained through one means-- continued service. Yes, there is a more elegant reduced form. Yes, it will require numerous scalpel precise dives into exacting corners of perldoc to understand, and yes, the answer is there, and the question is only whether you've the will and inner being to extend yourself to the capacity required for understanding. Perl is organic, not mechanistic-- the post-modern nature, the many ways to slice it-- that's freedom, that's having control of your own destiny. Organic means each body of code is grown anew from essential scraps, not printed to pattern, and that is a very different experience from our training, from rhetoric on methodologies and engineering classes and encapsulation. ¶

I'm going to introduce some classist statements here-- the professional coder's I interact with's respect for Perl is low. Rabble, and loose they say. The enthusiasts-- they deride Perl, but with deference, respect, and tongue hopefully in cheek and grin hopefully knowing. My favorite joke is that Perl is a "write only language," and indeed, I felt that pain time and time again; even when I felt relatively proficient in the language, there were always higher heavens of understanding and personal attainment that I either never knew or had forgotten once or many times. My younger self's personal challenge revolved largely around understanding the layout of the documentation-- it was the rote required to decypher syntactic mysteries. But these mysteries, although confounding, were shallow. Perl taught me perseverance, to know to keep digging, that inner purpose of any body of code could and reveal itself and spring forth into my mind and that all I had to do was keep digging. Perl taught me appreciation for weaving understanding in: an appreciation for layout, and documentation, for using my powers for good! Restraint and form were at least as important as being concise-- a body is grown in a narrative, and making that narrative self evident in the body was capital, so that others and my own paths upwards and downwards through the code would be easier. The body had to shed it's own understanding, be it's own map, because otherwise we were left surmounting the kinds of thicketed obstacles young me had struggled so hard to map out. ¶

Perl is indeed post-modern and that comes with implicit challenges, of defining one's own nature in a destructured verse. At the time, being young, the challenge I picked up was "the answers are there." As I've continued coding, the challenge presented looks much different-- I've seen good, well designed Perl projects with 100k loc, and I've begun to understand how important judgement and framing are when coding. That notion of regional locality within a script grows and takes new forms as it becomes a series of compartmentalized scripts. Perl doesnt provide you a ready fit framework for your problem, it gives you the freedom to frame your own system, and that was an incredibly powerful and slow lesson. ¶

In accordance with the recent "The Two Things About Programming" [The Fishbowl], I'd say I've started the journey from Computer Programmer to Software Engineer. Thank you Perl for teaching me about freedom, and the consequences that come with it. Programmers, there's a challenge out there if you're game-- you have the freedom of the world, whatever language you write in-- and it's up to you to navigate the array of possibilities in front of you & distill out some essential body which is as understandable as will be required to be understood, as compartmentalized and consistent as is required for comprehension. You dig your own holes, and you grow stronger clawing and climbing your way out (p.s. stop digging). ¶

(reposting on my *cough cough ahem* [livejournal]... thank you greatly for this opportunity; I hope I havent done you wrong, misused this form overly much, and/or am not entirely amiss).

Everyone always said Perl is hard to read. It never has been for me. At least not harder than any other language.

I asked other people about it. A java programmer for example and the only thing he had problems with were classes.

My opinion was and still it that it depends a lot on people. It is the reason why multiple programming languages and paradigms exist. Everyone thinks in a different way and while many people can think in a similar way it doesn't mean everything equally hard/easy for them.

Once I showed some quick and dirty code to a good friend of mine. I don't have it anymore, but I know I had to add a lot of comments to understand it on my own. It came with a lot of stuff unique to Perl and it was the result of a few hours work shortening the code just to look how short I can get it. To my surprise he understood it. My friend doesn't know Perl and only tried two languages until now (Lua and PHP). He doesn't even get OO, but he understood everything without reading the comments. I tried to convince him to learn some Perl, but he wants to stay with Lua. He only does some personal game programming using an engine and therefor doesn't have use for Perl. He doesn't like sigils and semicolons.

It's pretty interesting what people find hard/easy sometimes.

My biggest problem have been references and pointers or what to write into .h files when I learned C(++). Of course at some point I got it, but it took a while.

So readability is a lot about how your brain works and possibly what your first programming language looked like.

I don't fully agree with you Randall. What I found is that in practice, especially short utilities and in unix-related scripting, Perl is a lot easy to make reading difficult. There's a culture of encouraging writing hackish or 1-time use perl program using as short operators as possible, like 1 character symbol. It might conveys "dense" meaning, but damn it overwhelm readers. Of course those utilities sometimes age much longer and survive through the next unlucky maintainers.

This is probably less of an issue with language, and more of the writer itself trying to save time typing a few more characters, or being a smart ass trying to proof their ego.

Good thing is, a good Perl program most likely is easy to read :)

Most of the people who say perl is unreadable either never learned perl or have never seen modern perl. The flexibility and power of perl that makes it possible to write obfuscated code also makes it possible to write code that is more readable and elegant than other languages that are more restrictive. And now for some code! Here is one of my favorite modules http://p3rl.org/Test::Class::Sugar , a DSL for writing tests:

use Test::Class::Sugar;

testclass exercises Foo {

    test that Foo knows his brother {

        my $foo = Foo->new();

        is $foo->brother(), 'bar', "yes, foo's brother is bar";

    }

    test that Foo can poo {

        my $foo = Foo->new();

        ok $foo->poo, "good job, foo can poo";

    }

}

Test::Class->runtests;

I have not seen a testing framework in any other language as readable, intuitive and fun to use as that. Just because you have seen or written unreadable perl code, it is not fair to say that "perl is unreadable".

Sorry for the extra newlines in my last post. I put my code example inside 'pre' tags, and it seems to render it with an extra newline for each line. If someone knows a better way to post code samples, then please share :)

Is readability:
a) A qualitative assessment of how easy a document is to visually parse
or
b) A qualitative assessment of how easy the content of the document is to comprehend (however you assess that)
or
mixture of the 2
or
other?


I find English translations of "Tractatus" easy to parse - but hard to comprehend. Enid Blyton's Famous Five adventures don't pose me the same problems, although ethically I struggle with the notion of the parents allowing 4 children and a dog to spend 2 weeks unsupervised in a remote lighthouse.


What part does the language play? The grammatical rules and syntax are the same for both. But I have to work much harder to map Wittgenstein's words to an internal narrative thread I can follow.


Vocabulary does make a difference, to a point. Wittgenstein uses terms like "function" and "proposition" where Blyton does not (or if she does, in a completely different context). A rough analogy might be hash slices. I remember the mild shock I experienced when I first saw them in the Cookbook. It just looked soooo wrong. Near unreadable, especially with a hash reference. Now they are a part of the perl vocabulary I just know how to use. But I don't expect to immediately understand any code I see that contains them any more than I expect to understand Wittgenstein because I know I can think of a function as a (possibly infinite) look-up table (or perl hash).


Syntax criticisms, whether it be python's indentation, perl's sigils or {put your favourite pet-hate here} are a part of human nature it would seem. Individuals who choose to dismiss a language on aesthetic grounds aren't necessarily wrong to do so, but they do unnecessarily limit their own understanding of what can be done with software.