Hacker News Reader

Comment by Locke1689 | Hacker News Reader

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.

View on HN

I consider unless to be one of my favourite things in perl that would fit into other languages. The key to the multiple ways of doing things is to make code clearer - you have to look at it not so much as "there's more than one way to do the same thing" as "many things compile down to the same opcodes on the VM".

I suspect in other languages lots of things compile to the same thing -

  x = x << 1;
  x = x * 2;

should produce the same thing. But if I was affecting a bit vector I'd use the former and if I was affecting a number I'd use the latter - because while the operation at the machine level might be the way, they are conceptually two different things and I want to express the concept to the next developer to look at this code.

The fact that perl intentionally supplies lots of features to allow me to write my code to express my intent as clearly as possible is an advantage to me, just as I find the english language an advantage over, say, lojban.

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.

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.

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.

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

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

> "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.

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

> ... 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.

> "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.

Ah yes, Yegge's old rant and the Perl6 (not Perl5!) operator periodic table. Very new on HN!

Can you trolls at least get something about Perl5 to post about?! (Answer to a possible answer in advance: "What, you post about another language in the same family -- and claim not to be a troll!?")

I'll reference this, regarding language trolling on HN: http://news.ycombinator.com/item?id=963706

Because I'm just not going to be trolled discussing this on HN, again.

Yegge's old rant still holds true for both Perl 5 and Perl 6, nothing has changed. There isn't a table of Perl 5 operators - - and the Perl 6 operator table shows what kind of design principles are behind Perl. Anyhow, I wont stay back on the sideline when Perl lovers bashes other languages and spread BS about superiority of Perl.

>>nothing has changed [with Perl 5/6 since 2004]

Wow, can you go through the synopses etc and prove that? :-) [Edit: Please put especial emphasis in showing why Moose is bad.]

That was sad. Why don't you run along and try to "argue" with someone about Emacs/Vi, instead?

Just try to not again start with flaming a language/editor based on a reference to a very different language/editor with a similar name.

Also, try to find something better than outdated ranting based on a claim that a humorous speech shows someone is insane... :-)

Oddly, no perl lovers have bashed other languages in this thread, and it would be great if someone could point out that at least one of the things I said were perl, python, ruby, or PHP idioms isn't actually an idiom. So maybe you should stay on the sidelines, since the coach hasn't called you into the game.

I do see that PHP is underrepresented in my list, and I just ran across one of PHP's most confusing idioms the other day. The LHS of list expansion assignment requiring the keyword list(), which looks like a function call. I can't count how many experienced programmers have asked me how this assignment to a function call works, which proves this is an idiom. And the opposite is a perl idiom: some functions in perl can operate as lvalues, like substr.

I am referring to the slides which for me shows the ignorance of the Perl community and especially Larry Wall. For example this quote from Larry Wall which showcases his views on teh Powerness of Perl (Steve Yegge has more quotes from your beloved leader):

"The very fact that it's possible to write messy programs in Perl is also what makes it possible to write programs that are cleaner in Perl than they could ever be in a language that attempts to enforce cleanliness."

I know it is stupid to bite, but was this the best trolling you can do?

A claim that higher expressibility in a language (natural or not) doesn't imply better expressibility -- given that the user knows his tools.

(Well, your "argument" could also be taken as "anything that can't be written in standard Python isn't worth to write; that is all the expressiveness needed ever, Amen". Gödel might want to say something about that, but never mind.)

Dillinger(!) is claimed to have said "Bonnie and Clyde gave bank robbing a bad name". You give trolls a bad name.

It was nice of Yegge to quote the entire section of the perl man pages on how the .. operator works. Notice it is fully documented, all the different contexts it works in, what it returns, how it returns it, the different types it works on. One might consider perl to be OVERLY documented, and navigating the man pages works pretty well when searching from inside less(1). I wish python and ruby and PHP had their entire documentation, or even just a significant standard library function list, available as man pages on every system they are installed on (although, why Ubuntu's doesn't package up perl man pages as part of perl by default, I don't know).

Then look up the Ruby documentation for .. , which is also overloaded to have two different meanings, one that works inside conditionals and one that constructs Range objects when outside of Range objects, which is just as much syntactic sugar as anything perl provides. And the difference between .. and ... is visually subtle, I wonder how many off-by-one errors that operator idiom causes.

Perl can be readable. However its wide and varied language features make it easy to make it unreadable. I have nothing against Perl used in good hands by good people but that can't always be guaranteed. The unless operator is the example of one tiny special case (of an if statement) that got its own built-in. My feeling is that unless you have a number of very good usage cases for a feature and it greatly saves time and energy it should not be added as a built-in to the language.

It all comes down to this: Perl doesn't have a "Right Way"(TM) of doing things. Many people (perhaps yourself) feel that this is a good thing. I simply believe the opposite.

Reply on news.ycombinator.com