7 ms·
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++) requi
by amix 17y ago
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 17y agoOf 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 17y agoI 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 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 http://www.ozonehouse.com/mark/blog/code/PeriodicTable.pdf
- tomneo 17y agoyou underestimate ur memory mate :P and yegge is wrong. "references" were added to perl because of lexical variables.
- chromatic 17y ago> "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 17y agomy mistake ... what i meant to say was lexical variables, lexical closures also needed the concept of references.
- chromatic 17y ago> ... 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.