A couple of years ago, I wrote Expression Visions for Perl 5 and Vision and the Perl 5 Ecosystem. I've changed my mind a little bit since then.
What do you use Perl for? It does a little bit of everything for me:
- text processing
- system administration
- dynamic web sites
- batch processing
- database automation
- graphic generation
- statistical programming
- textual analysis
- report generation
I've even written a game or two in Perl. All of this is possible because Perl is a general purpose language. Much of it is practical because the CPAN hosts plenty of working, well tested, easy to install, freely usable and redistributable code. As Matt Trout is fond of quoting Audrey Tang: Perl is my VM and CPAN is my language. (Thanks to things like Moops and Moose::Exporter, this is doubly true.)
Sometimes you hear people talk about the original intent of a language to prove (or disprove) something or other—usually to prove that you're a fool for using a specific language. For example, you might well hear that programming Perl for modern web sites is silly because "it was designed for system administration and later CGI", or that "Go is a great language because it was designed for systems programming". (Then again, PHP was designed as a templating language because TT2 didn't exist, and you don't see people writing microframeworks for TT2.)
A vision should guide the design and maintenance of a project or a programming language, but that vision should not constrain the uses of the language. For example, Java used to be Oak, a project to create a small language for set top boxes and not the language used by Sun to sell memory modules for Solaris boxes and the language currently used by Oracle to sell expensive licenses for everything from phones to database servers. Does that make Java the wrong language for Android programming? Does Guido's desire to write a better beginner language than ABC (one with library support) mean that Python can't be a decent general purpose programming language?
Vision can be a dangerous thing, too. Setting out to write the next great programming language for the next 20 years can doom you to perpetual rewrites, cause community schisms (D might qualify and Python 2 versus Python 3 currently does), or dim the hopes of widespread adoption if your language fails to impress with its changes (Arc). That vision in and of itself is too inspecific: you don't know what the challenges of the next twenty years will bring.
(You can predict pretty well that finding a way to handle concurrency and parallelism is important, but you have to keep in mind that they're two very different things. If you need to use as much computing power as possible, your language probably needs really careful control over memory to the point of knowing which pages are available to which processors and the cache implications. Whereas if you need to avoid blocking as much as possible, you probably need a system of isolated work units that you might find in the Erlang VM and high level language constructs to mark work units and their synchronization points without necessarily worrying about assembly level composition semantics.)
Being all things to all people is difficult, because without direct feedback from real users, you can only assume about the problems they're trying to solve. Worse, you'll probably default to the problems you're trying to solve. (I'd make a lousy pumpking because I can easily afford to upgrade my production software to remove smartmatch, for example, so the cost of deprecation is low for me.)
Yet you also want to allow your language to evolve to meet the needs of other users doing things you never anticipated. That's why I've come around to the idea that Perl is best suited as a solid core which makes using the CPAN easy and experimenting with new features on the CPAN easy. This leaves room for adding things like the p5-mop to the core while not requiring any one specific object system syntax.
In one sense, my evolving vision for Perl is a lot smaller. I'd like less XS and a faster runtime and less memory use, but from the language design, there's not much missing. (The aforementioned MOP and function signatures come to mind, but they're on the way.) The rest can happen on the CPAN—and that's fine by me.
