John Siracusa discusses Perl on Hypercritical
In episode #15 of Hypercritical, John Siracusa presented Perl in (largely) a very positive light to what I assume is mostly a non-Perl audience.
I'm including my notes on the discussion below, but I recommend listening to the podcast yourself to form your own impression: http://5by5.tv/hypercritical/15
I couldn't find a discussion area linked from the episode page, but I noticed someone posted it to Hacker News as "John Siracusa and Dan Benjamin on high-level programming languages [podcast]."
Notes on Hypercritical #15
Most languages stink.
What should a high level language have?
- Memory management
- Native Unicode strings
- Native regular expressions
- Native object system
- Named parameters
- Succinct syntax for common operations
- Acknowledgement, at least, of concurrency
Languages are slow to change, unless controlled by a single vendor (i.e. C#).
In considering the aesthetics of a language, many people find non-word characters ugly (but it depends on which languages you come from). Sometimes the prettier language (or fighter jet) wins.
The major objection to Perl from non-Perl people is probably that Perl is ugly. They may not like the dollar signs. Perl was their first exposure to regular expressions.
John: "What objections do you have to Perl?"
Dan (playing devil's advocate, somewhat): "Legibility. Where are the frameworks? Where is the next generational thinking? What can Perl do besides text parsing? How is Perl used in the real world?"
People looked a Perl long ago and haven't looked again. They dismiss it.
What's wrong with Perl?
- Unexpected default object system (build your own), but this is also a strength
- No language specification (only perl can parse Perl)
What's good about Perl?
- Perl has been a breeding ground for object system experimentation
- Perl has the largest group of developers doing "advanced stuff" in a semi-popular language
- Perl has practically every advanced feature found in other languages
- Perl can and does incorporate computer science research, such as the 2002 paper "Traits: Composable Units of Behavior". This is possible because Perl is a backwater and doesn't have popular API's or platforms tied to it.
Other languages should go ahead and steal ideas from Perl, as Perl has from other languages.
Dan: In 2011, the popular apps to build are for the web, mobile, and desktop. Why should someone learn Perl?
John: Language choice should depend on the task. Use PHP for its ease of deployment. Use Ruby if you want Rails (an aside: the main insight from Rails is convention over configuration).
What would you use Perl for these days?. . . [pause]
- You *could* write web applications in Perl, but it's not recommended. Use whatever is popular (currently Ruby on Rails, something Python, PHP if necessary) in order to get more support, lots of books, etc.
- You could rewrite your slow application in Perl because Perl offers great interfaces to fast C libraries.
Reasons you might find yourself writing Perl
- You and your team already know Perl
- You're working on a (perhaps legacy) application that was originally written in Perl and there is no reason to re-write it.
- You're looking for experience in a different language and way of thinking.
Perl people have a hippie/creative slant to them. They are artsy/fartsy in a liberal arts sort of way.