From other comments, I get the impression of a lot of knee-jerk defense of Perl. I thought that the OP actually did a fairly nice job of identifying some particular strengths and weaknesses, and did so fairly constructively. We need more constructive reflection of that sort.
(More to the point, we need people to actually go work on the weaknesses!)
Personally, I found some of the ideas compelling, though for slightly different reasons.
GUIs/IDEs: Two halves of the same coin. We're in a world where the vast majority of people learn to use a computer through a GUI -- that's the "natural" interface for them. Yes, some of us are old enough to have started their computing life on the command line. (Some of us are probably even older and will tell stories about punch cards, switches and vacuum tubes.) For those people, Perl may be quite natural. And, yes, some of those raised on GUIs eventually learn the power of command lines, speed keys, multiple terminal windows, etc., but I suspect that is not the natural orientation for most people.
As a result, I would hypothesize that for those who "think GUI", an IDE will seem like a more natural way to approach the task of programming. And likewise, creating a GUI application is more likely to be a meaningful accomplishment early in the learning process. (e.g. "Hello world" in a window with menus and buttons instead of "Hello world" printed to the console.)
If that hypothesis is true, then Perl is not well positioned today to be an entry level language relative to some other languages. I'm not saying that it can't be an entry-level language, just that other languages with strong IDE/GUI support are probably better at the entry-level for those raised with the GUI to begin with.
Concurrency: Beyond just the issue of threads and multi-core architectures is the more general use of concurrency in applications. My sense is that concurrency is a growing paradigm -- or at least that concurrency is seen as a lower-cost way to improve performance for certain classes of "hard" problems than other alternatives.
Again, if that hypothesis is true, it's worth examining what types of concurrency Perl might be well suited for (e.g. process-level parallelization with database-backed persistence and sharing) and what types it is less suitable for (e.g. thread-level parallelization) and seeing what improvements could be made.
Both of those ideas are aimed at the following:
To me, both of those seem like worthy goals. So, from that perspective, kudos to the Anonymous Monk for reminding us of them.
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
In reply to Re: Slow evolution of Perl = Perl is a closed Word
by xdg
in thread Slow evolution of Perl = Perl is a closed Word
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |