John Redford wrote: > The future of Perl is more likely to be one of changeless stagnation, > near-universal existence, popular usage for infrastructure, and limited or > no use for general purpose programming. And I am not sure why Perl users > would be upset by that -- I don't see anyone upset that bash or grep aren't > being used more widely and replacing languages/tools that aren't all that > much like them anyway. One might be content to see Perl do best that which > it does best, and not worry about the things it does not do.
"...not sure why Perl users would be upset by that?" Because Perl spent a good number of years as a good quality, general purpose programming language, developers got use to that, and now that's going away. Because developers - likely to their detriment - become emotionally invested in the tools they use, particularly ones that have been around as long as Perl has. They want it to be viable, so they can continue using it. This may not be rational, but its easy to see why it happens. > The Little presentations are spot-on when they describe Perl as being "glue" > -- that was its origin and that is what it was one best at. Now it's not. > And it won't be again. > > Perl's popular origin was based on its operation as a tool that glued > together the functionality (not the code) of existing tools like sed, grep, > find, sort, sh, and so forth. This is all true, and yet utterly irrelevant. If you look into the historical origin of many languages you will find an initial purpose that its current use has greatly diverged from. (Actually, for many of the tools you list, technically Perl didn't glue them together, but rather subsumed them. Once I learned Perl, I practically never used awk or sed again. But that's besides the point, as Perl was indeed a consummate glue language.) > Also, any time I hear Perl advocates talking about how dynamic typing is > better than static typing, it just reminds me that Perl doesn't have type > inference. Supposedly planned for Perl 6. (I'm guessing as a way to make the code easier to run on the JVM.) What do you see as the advantage to type inference over dynamic typing? The obvious one seems to be that it lets you emulate dynamic typing in a statically typed language by doing all the dynamic typing determination at compile time, and thus better efficiency. How often do you run across cases where the compiler infers incorrectly? Doesn't it defeat the purpose of choosing a statically typed language? This feels much like an implementation detail. From the programmer's perspective, they want dynamic typing, and the execution to be fast. Whether that's implemented under the hood as run-time dynamic typing or compile-time type inference should be irrelevant to the programmer, as long as their performance objectives are met. > Of course, the substantial problems of Perl are intractable. One cannot fix > them without changing Perl into a completely different language -- even if > one maintained backwards compatibility, there would be a serious question of > why one would bother to do so. > > ...there is not much you can take away from the language and still > call it Perl. Now if only there was a language that was shiny and new, leapfrogged the other dynamic languages with innovative design, all while incorporating the spirit and flavor of Perl, so former Perl developers would largely embrace it.... Oh yeah, Perl 6. When Perl 6 for hit the scene, I don't think enough Perl developers were ready to jump ship to it, even if it had been production ready. Now that it is finally getting close to being usable, is it still innovative, or more on parity with the competition? -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
