Iridescent Bivalve Secretions are from New Jersey, Nacre is from MIT

| 6 Comments

Perl's in kind of a bad way, mindshare wise, but look sometime, really look, at the Perl 6 RFCs.

How many of those problems are still real problems?

Forget the CPAN. It's not that the CPAN is bad. (It's great!) It's not that you can't find great code on the CPAN to solve many of those problems. (You can!)

I'm glad Perl borrowed and implemented Python's lousy object system in such a minimal way only in so far as it allows for things like Moose which replace and improve upon and supersede it in such a dramatic way that I'm not sure Moose would have existed if Perl's default object system were better.

Are you still wearing your "I'm not a Perl programmer!" shoes? Step back one more step.

Does it make sense to you that if you want to write object oriented Perl in 2011, almost ten years after the P6 RFCs identified 361 pain points in Perl, you still have to download an extension because the Perl community can't or won't agree on one good way to write classes and objects by default and doesn't want to manage the task of adding an object system to the Perl core because it might change, and even if the Perl porters took on that burden, you still probably wouldn't be able to declare a class with the keyword class, because package is (and here is where you step forward several steps) pretty much just as good and really the same thing if you squint?

Does that make sense to you?

By no means do I fault the implementors. Modifying Perl is difficult. I don't blame anyone for not wanting to dive into its guts to refactor things to make it easier to add new features or to fix bugs or to improve performance or even to see if something is vestigial code which can go away without breaking backwards compatibility. It's not fun, and people like Nick and Rafael and Dave and Zefram and Florian and Karl and too many other people to mention who've done far more than I have have my full respect and deserve your respect as well.

Even so, take another step in those "I don't know much about Perl, so tell me about it?" shoes.

Renaming Perl 6 won't change two facts.

  • Perl has no Larry. That Larry doesn't have to be the Larry, but a sufficient quantity of Perl hackers must respect the new Larry as a suitable Larry.
  • At almost every point where the design of Perl requires a hard choice between improving (or maintaining the status quo of) the language for people who've been using Perl for years or decades or improving the language for people who haven't, the default choice has been to circle the wagons and keep the status quo.

Renaming Perl won't change that. All of your marketing material can rigorously refer to "hydrogen" as "Elevo Aeris", but you haven't changed the physical properties of a single atom. Oh, the Perlmanity. If you believe that Perl's popularity depends on a feature set, you need somehow to provide:

  • A better object system
  • Function signatures
  • A better reference syntax
  • Continued internals overhaul to improve Unicode handling
  • Better defaults
  • An extension system which doesn't require learning a new language which is half-C, half Perl macros, and half reformed Cimmerian
  • A distribution mechanism that solves the Enterprise in Mothballs problem
  • A gradual typing system
  • A parser reusable outside of the act of writing code
  • The possibility of running on other VMs
  • The possibility of JIT or other optimizations
  • A parallelism and concurrency solution better than heavyweight ithreads
  • Improved uniformity of syntax and semantics along the lines of autobox
  • An exception system which does the right thing by default

... and I've probably left out a few things.

You can work around many of these problems with the CPAN (in one shot with things like Task::Kensho and perl5i. Thank Larry and countless volunteers for that...

... but are you still wearing your "I've heard about this Perl thing, but why would I use it?" shoes? Take a Perl project of modest complexity. I have a few with several thousand lines of code apiece. They're not huge projects, but I've done the rodeo circuit enough times that I get a lot of use out of CPAN distributions.

Install all of the dependencies of one of these projects in a fresh Perl sometime. Track all of them. Run Devel::TraceUse on the top-level program sometime. Go through that list. Group those dependencies into categories of similar behavior. Go ahead. I'll wait.

The problem is that your average Perl project of moderate size which uses the CPAN needs to load multiple, competing modules to provide behavior that arguably should have been core language behavior five years ago, if not ten or twenty.

The problem is also that the voluminous documentation to which IRC continually points frustrated novices (telling them that the F is for Friendly) assumes in many places a working knowledge of C, shell, and Unix, as well as an existing overview of how Perl itself fits together.

What will help the frustrated novice who sees a dozen competing projects for exception handling and doesn't know where to start. Yes, yes, I know, Task::Kensho, but do you really want to say "To throw an exception in Perl, you must first configure a CPAN client. Oh, you don't have root access? Convince your system administrator to install and configure local::lib, but some people prefer App::perlbrew, and I hope you're not on Windows, ha ha... wait, where are you going? All you have to do is pipe a shell program downloaded from a web page into...."

I know, I know. It's frustrating to think that Perl is in a holding pattern and can't evolve while Perl 6 has been just around the corner for a decade. But that doesn't change anything. Perl will not evolve into something more popular for new projects as long as it huddles within the safe, comfortable fortress walls of "Well, we've always done it this way, and it would be scary to change it."

(I don't believe that most contributors have that opinion, but given the difficulty of making changes to Perl and the potential disaster if part of that change is wrong and the implication that the world could be stuck with something awful for years if things go wrong, there's very strong pressure not to do anything. I also believe that the last eighteen months in the world of p5p demonstrate potential for huge, enormous, world-changing improvements in what Perl is and can be, and I'm excited for the future of Perl. I gladly use CPAN. I look forward to Perl.16 and 5.18 and 5.20. I have great respect for every contributor to Perl and the CPAN and don't blame any of them for the current situation. It just happened. Good things are happening. The tides are turning. This is no accident. Now how do keep that momentum and direct it effectively?)

Features, of course, are only part of the problem. PHP is a mess of a language in many ways, but it's popular because it does a couple of things right enough. Ruby is a flawed language, but it has buzz because Rails did a couple of things right. Python and Perl share many of the same flaws (and Python adds a couple and takes away a couple), but its marketing message (however nonsensical) is at least consistent. Lua is incredibly minimal in features and frustrating in what it lacks, but its designers have a laser-like focus on what the language is and will be, and it succeeds in its niche because of that. JavaScript is Perl 4 awful in writing large projects, but it spins the pork pie hat of every skinny-jeans hipster in the tech world because it's there.

It's easy to blame "Perl 6" for Perl's conservatism, but it's wrong. Perl has consistently demonstrated the relentless desire not to lose existing users instead of the relentless and focused desire to attract new users.

(Don't hold it against Perl, however. P6 has demonstrated a different problem: the relentless and focused desire not to produce working software which might possibly attract users. You can tell because of the monthly whining noise which comes from Rakudo marketdroids begging for attention to justify their hobby.)

Want to make Perl more appealing to the person who loaned you that pair of shoes? (Start by giving back the shoes.) Let's talk about fixing Perl instead of fixating on how not having a major version number means we can never fix Perl.

By all means complain about the overloading of the name "Perl" to mean two similar things which are not the same thing. It's an easy target. Just don't delude yourself that a name change will happen or that it will accomplish anything meaningful. The version number 6 has been doing its damage since about 2001, and it's hard to imagine that it can do any more.

6 Comments

Let’s talk about fixing Perl 5 instead of fixating on how “Perl 6” means we can never fix Perl 5.

Who are the people who are fixating on that?

Just don’t delude yourself that a name change will happen

I’m not and almost no one else is either.

or that it will accomplish anything meaningful.

Absent the change, there is no way for you to prove that, and none for people who think otherwise to prove otherwise, so this so much hot air.

In contrast, people thinking Perl 5 is dead because Perl 6 has been so long in the making is reported fact. You can argue down its importance with long arguments of course.

Who are the people who are fixating on that?

How else do you understand the argument "Perl 6 is holding back Perl 5"? I've heard that dozens of times.

You can argue down its importance with long arguments of course.

Who would a name change convince now?

How else do you understand the argument “Perl 6 is holding back Perl 5”?

Such that the perception of Perl 5 as being slated for obsolescence due to Perl 6 is holding hostage any attempts to improve the perception of Perl 5. None of this relates to the language itself; Perl 6 is not preventing Perl 5 from improving, and indeed Perl 5 has been improving all the time and continues to do so and will continue in the future too.

Who would a name change convince now?

In the near term, no one. In the near term, it would actually make things worse. I said that, didn’t I? But in the long term, it would allow the naïve outsiders who come at us with a fresh mind, not knowing the history, to form a different first perception. In other words the name change idea appears to me to suffer exactly the same circle-the-wagon dilemma that you see Perl 5 being in.

I see your point, thanks.

To spoil part of my advocacy talk for YAPC::NA, if you subtract the few million programmers in the world from the seven billion people in the world, you still have seven billion people. They're the ones whose confusion will be real and material, and not the people who've used Perl before.

If changing the name of one or both languages helps the other seven billion people, it might be worth considering. You have to balance that against the short and medium term pain of losing mindshare, as well as all the awkwardness of bifurcation. You also have to get Perl 5 to the point where it can discard Perl 1 backwards compatibility, or it's not worth it.

That's a lot to ask and still probably not worth doing, but at least I can understand it.

There are no easy answers.

There are no easy answers for how to improve Perl 5 for the very same reason…

That’s why I concluded “I don’t know what to say”.

Erm ... thanks for the shoes? The soles are pretty worn and the laces frayed. :D

I am one of those non-Perl programmers. Are you suggesting to dump Perl 5 for Perl 6? Extend Perl 5? I am as confused by what you want and what you admire about the languages as I am with obfuscated Perl! :) The peek you've given me under the kimono suggests there's a lot of religion in the Perl community - and only the loudest, dislikeable, and/or crankiest voices seem to prevail in groups like that. Not knowing much about Perl past what you've written, it sounds like a mess.

I say just fork your favorite one of the languages, do the renaming to "Oyster" or "Unicorn 'Splodes" or whatever will attract new users, and finally burn that bridge. Maybe you don't break backwards compatibility with the new language, but symbolically you are breaking ties and you unleash the refactoring dragon. Be the Linus Torvalds absolute dictator of the new Perl, you decide what makes it into the new builds with Git. Just friggin' do it.

Ultimately, I don't think anyone who seems hostile to the idea of forking will actually hate you or retaliate against you (long term.) Maybe they're secretly wishing for the Perl bridge to burn?

The real lasting value to me with this whole Perl 6 deal is the Parrot VM, not Perl. Getting this "what's-the-better-version-of-Perl-to-learn" limbo situation out of the way would be helpful to the promotion of that VM, which I am looking forward to.

Dave

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

sponsored by the How to Make a Smoothie guide

Categories

Pages

About this Entry

This page contains a single entry by chromatic published on June 25, 2011 8:00 AM.

Perl and Names was the previous entry in this blog.

Novice Shibboleth, Pluggable Optimizer is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


Powered by the Perl programming language

what is programming?