Re: Slow evolution of Perl = Perl is a closed Word

[xdg]

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:

• Grow the pool of Perl developers faster by lowering real or perceived barriers to adoption
• Grow the domain of work for which Perl is an optimal solution

To me, both of those seem like worthy goals. So, from that perspective, kudos to the Anonymous Monk for reminding us of them.

[dsheroh]

A thoughtful post, but I disagree. I don't see so much "knee-jerk defense of Perl" as (healthy) skepticism about the OP's assertion of the central importance of IDEs, threading, and GUI development. Sure, all three are considered sexy by large segments of the geek population, but, at least in the problem domains where I work, they're pretty thoroughly irrelevant.

The last time I used an IDE or had to deal with threading per se was in 2001 and I eventually abandoned the IDE (MS Visual Studio) on that project because it was getting in my way more often than it was helping. In the broader sense of concurrency that you brought up, that project was the last time I encountered something that called for anything beyond the ability to run multiple independent instances of a process or maybe occasionally fork a child to handle a large chunk of processing, then die. I don't think I've done a GUI since 1998 or 99 unless you count web pages or a trivial Perl/Tk project that I did just for the sake of seeing what it's like.

I suppose you could call this a reflexive defense of Perl, depending on how you look at it, but I don't think that would be accurate. It's much more a statement of "You think that stuff's so important, huh? Prove it." I don't deny that IDEs and GUI tools (both GUIs for development and tools for developing GUIs) would make it easier to attract new blood (albeit with swampyankee's caveat of IDEs tending to enable 'code now, think later' work styles) and being able to trivially create pervasively-threaded code would do wonders for buzzword-compliance, but I'm not convinced that these things would do anything to truly improve the language or the community.