Are you a good Perl 5 hacker?

Do you know how to access the symbol table yourself, without resorting to string eval ? Do you know how to find all of the variables within a package or all functions within a package?

This metaprogramming—or reflection—is a fundamental part of higher programming languages. While all symbolic languages intend to operate on parametric symbols instead of raw data (that's why you can write equations in programming languages instead of using your computer as a glorified adding machine), higher languages operate on language constructs as well.

You can see this in lower languages such as Java, where the only good way to make flexible and extensible programs is to generate big wads of XML which control your AbstractFactoryInterface instantiations such that the classloader can inject the right code to make the language do what you need without forcing you to write even bigger wads of repetitive boilerplate Java code.

(During a consulting job several years ago I had to generate 60+ unique reports with Crystal Reports. The reports differed by way of two column names, but Crystal Reports wasn't flexible enough to let me define one report once, then pass in the two parameters I needed. This is why 4GLs failed.)

Metaprogramming and parameterization and flexibility beyond "This is how you write programs in this language, darn it, and you shall never think of doing anything different that the language designer didn't have in mind." may be difficult to implement well and it may not completely satisfy everyone, but it's useful and necessary.

Consider Package::Stash. If you couldn't remember all of the answers to all of the questions in the first paragraph, you'll probably find P::S much easier. (Certainly it's less buggy and much less annoying than munging the symbol table by hand.) Use it when you need it. It's nice. It's Perlish. It doesn't look like the dog's breakfast of random punctuation that you need to manipulate symbol tables (which are even uglier than the standard dereferencing syntax, because they're special hashes).

Now that I've explaind a bit of programming language design philosophy, explained a dead end in programming language design, and pointed you to a useful tool from the CPAN, let me get to the point:

There's no excuse for something like Package::Stash not being core behavior of Perl 5.

Think about that for a moment.

How can you defend Perl 5 as a practical language, one which makes easy and hard things possible, when standard higher language behaviors such as symbol manipulation are so eye-gougingly ugly and esoteric by syntax that they are out of reach of even adept Perl hackers? These are not black magic concepts (else MIT wouldn't have taught freshmen Scheme as a first language). They are fundamental to a proper understanding of symbolic computing and practical programming.

I know the arguments against subsuming something like P::S in the core though, and they're all nonsense.

You can already do all of these things with the existing syntax. You can also store relational data in flat files instead of an RDBMS. That doesn't justify anything.

Not everyone will like this syntax. The core should come up with something everybody like. Nonsense; the core should provide one really good way to do something (and the "They're just hash references with special keys and some other bits glued on!" approach isn't it) without precluding alternate approaches. Refusing to do something without complete consensus is as much a recipe for failure as adding every feature proposed without considering its necessity, utility, implementation, and coherence in the gestalt.

What about all of the existing code that doesn't use it? Irrelevant; it still works. That code's already written. The cost of writing that code is a sunk cost; you'll never get it back, no matter how much you penalize code under current maintenance and new code written from this point forward.

There are plenty of dependencies of popular CPAN distributions which do not represent failures of the Perl 5 core to provide useful features in a usable way, but consider this: every time you have to install or load one of several competing exception or function signature or list handling or library management or build systems or FFI workalikes or object system modules in a large chain of dependencies (of which a transient bug in any costs you debugging time), you're paying a tax the core developers have levied on all users in lieu of subsuming useful and necessary language features into the core of Perl 5 itself.

Things have improved in the past ten years (and especially the last 18 months), but this is why non-Perl programmers look at Perl 5 and say "Modern? That's what you call modern?" All of the rounded corners and hip slogans and fauxhawks and body spray in the world won't change that.

Of course, it's difficult to criticize p5p for its conservatism: no one has stepped forward with a coherent and singular vision for the continued and managed improvement of the design and implementation of Perl 5 as Perl 5—nor is it clear that p5p would accept anyone other than Larry doing so.

Is there a solution?