Symbol table manipulation, source filters, run-time method generation via AUTOLOAD, proper closures, taint checking, lexical pragmas...
I think you'd be hard pressed to implement something like Perl's Moose in Python. I'm not completely sure it's possible.
There's a lot of tricky stuff that's easy in Perl but requires tons of hoop jumping in Python.
Don't underestimate the utility of perl one-liners. You can't do them in Python, both because of the whitespace and because in practice Python is too verbose.
> Don't underestimate the utility of perl one-liners. You can't do them in Python, both because of the whitespace and because in practice Python is too verbose.
The value in doing something in a smaller amount of lines is lessened by the lessened maintainability of unreadable code.
Where do you think the effort in maintaining software goes? Typing? Or maintenance?
Where is this unreadable perl? I can't find it. I have no problem reading perl by all kinds of people.
C, on the other hand, is frequently indecipherable because so many lines are spent doing something trivial that it's easy to lose the forest for the trees.
Generally ~kingkongrevenge. Many ways to do things means people who know enough to be competent at writing a language still have trouble reading code created by others due to unnecessary style differences.
Nonsensical. Perl has most of the lispish features of lisp. There is no re-implementation.
Here's a better rule: "Any sufficiently useful Lisp program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of standard perl and the best CPAN modules."
That's also nonsensical though. I think most useful Lisp programs will probably run faster in Lisp. Trying to fake defmacro alone in Perl will be probably be a waste of time and ultimately result in following the original Greenspun rule.
> The steeper learning curves are justified by the power.
What can you do in Perl that you can't do in Python?