http://qs321.pair.com?node_id=1106391


in reply to The future of Perl?

I think one of the big problems in Perl's future is one of the same ones people have been battling for years. Perl is meant to make the easy things easy and the hard things possible. However, one of the hard things about Perl that could be easier is grasping the language and documentation.

I refer you to syntax of Data::Dump and the associated thread as an example. In particular the words "The reason I remain confused is perlop" in Re^2: syntax of Data::Dump and "Sometimes the perl interpreter is too clever for me." in Re^4: syntax of Data::Dump are particularly telling. What is the cost of outputting data formatted as the language documentation asks for it to be input? What's the cost of accepting the input in a consistent fashion? Why is it normal to cite paragraph two (out of three) of footnote seven (out of eight, most of them multiple paragraphs long)?

A sharp blade cuts best, and Perl as the Swiss army chainsaw has a lot of sharp blades. However, a tool as old as Perl should be worn smooth about the handle which holds those blades together. The saying about a craftsman not blaming his tools assumes that a craftsman can choose and improve those implements. Lots of things about Perl have been improved over time, but there are still these odd gotchas people find surprising. A powerful tool can always be dangerous, but one should be able to be wary of the cutting edge and count on the handle.

The rule of least astonishment (principle of least surprise) usually makes allowances for audience type. Perl has a different core design than lots of languages, and it's okay to surprise a bit with context and such. However, when programmers are surprised by things on a pretty regular basis by little bits of things not part of the language design like the above example, that's bad.

Python is ugly (my opinion), Ruby is slow, and Java is wordy. Perl's weakness is that it's sometimes hard to predict without specific experience around that part of the language. We have a great community that provides support, which is a good thing because apparently we really need it. We need it to impart those nuggets of knowledge to the long-term apprentices who have chosen to follow the not so smooth path to Perl mastery.

Perl's future I think is less fraught with competition from Ruby and Python than people assume. I see competition from Go, D, Rust, and Lua from below now that systems and embedded languages are getting friendlier. I see Scala, Clojure, and Java coming in from the side. PHP and Hack will continue to follow behind, picking off the stragglers. Julia and R may grab a bit, too. The most interesting of these to watch I find to be Go, Rust, and D. Their goals seem to be very much aligned with the goals of Perl6, but they are delivering production tools.