There's this idea in the Perl community that it succeeded due to Larry's theories about syntax, but I think that's a bit of a myth.

Everybody forgets that when Perl was created, the idea of a 'dictionary type' as a standard feature was a pretty exotic notion, and the idea of wasting such jewels of computer science on sysadmins and philosophy majors was almost scandalous.

And of course now we have entire languages built on dictionary types, like Python and Javascript, and nobody thinks it's weird.

I wonder what the Perl of our time could be. If someone dragged all the neat bits of Haskell into a language that mere mortals could use, that might be a start. And in fairness the Perl 6 people think they can bring parsers into the mainstream. Personally I think they're a bit overobsessed with syntax, but I'd be happy to be proven wrong.

Look at it this way: pretty much any "Programming ______" book will at least touch on that language's regexp implementation. How many such books currently cover implementing basic parsers for non-regular grammars?

So yeah, if Perl 6 can bring parsers to the mainstream by providing easy, visible tools to implement them, and even simply by making parsers something you learn about in the course of learning Perl, that'll be a huge win for us all.

(i think Expert F# might also, i can't remember)

http://book.realworldhaskell.org/read/using-parsec.html

http://programming-scala.labs.oreilly.com/ch11.html#External...

I think it's only been very recently that there's been a growth in parsing paradigms that are more amenable to inclusion as libraries with ease-of-use at least vaguely comparable to regexes. Things like combinator-style parser libraries (Parsec and similar libraries in other languages), and OMeta (http://tinlizzie.org/ometa/).

When you actually get down to writing it, a top-down parser is a fairly simple beast. A programmer doesn't really need many extra tools to do it. You just create a bunch of functions which peak-at symbols, consume symbols and call each other.

The art is in having an exactly nailed-down specification concerning how these function are going to work together before you even begin. And that art comes from first analyzing and manipulate your language's grammar. That's a process that's distinct from the final code that you write and it requires knowing a little bit about abstract languages. (Your functions are pieces of the language but not the language pieces one would intuitively imagine. The parts of a language are great examples of "programming objects" which are not "object oriented" objects).

What's hard about understanding an abstract language is that it isn't a command or feature that within a language but is ... a language in itself. Creating an abstract language involves moving to a higher logical level, just using a programming language involves moving to a higher logical level than using an application. It's not that it's impossibly hard but it requires a student to interrupt any rote learning they're doing and think. It's a great thing but it's also a road block to a significant percentage of students.

Given this situation, I'm not sure how any language feature can help. Sure, you could plunk a whole parser generator into the code but I'd say it's harder to understand the combination of language specification and generated-code that results from such a thing.

I'd like to know how the Perl 6 people expect to deal with this challenge.

I agree that it would be nice to move people from complex regular expressions to reasonably simple parsers.

Writing a recursive descending parser isn't hard, as you said, but it's again something that needs testing, you need put some effort into it to get good error messages from it - and why would you repeat such a task? Also you often need to write a lexer -- another burden of which Perl 6 grammars free you.

Regarding your thoughts about abstract languages: Perl 6 provides tools to make experimenting with them rather easy, which helps learning about them.

I've made the experience that a reasonably good programmer can write some 20 lines of Perl code, and it does what he wants. That doesn't imply that he can write a 20 lines grammar that does what he wants, without doing some debugging and corrections first.

Writing grammars is a skill that just has to be learned, line any other skill too. Providing tools that make it fun and rewarding to play with parsing stuff is the best we can do.

I remember working on perl when you still needed to keep both perl4 and perl5 around on a system... today, though, perl5 is the scripting language you can depend on having, that you can depend on being there and compatible.

This is also the major resistance to perl6. Goddamnit, perl5 works. I don't want to go back to the bad old days when i had to write everything in sh (or test it across two major revs of perl) if I wanted it to run properly on all systems.

I know that the language writers always claim backwards compatibility is a priority, and it is, kindof, but, for example, don't try to upgrade the base python on a RHEL5 system. you /can/ but it's a /huge/ pain in the ass and it means you will have to do more work every time yum or some other python-dependent base bit is upgraded.

for us, perl occupies the niche that bash occupied in 1997. Now, it /can/ do more, but we are utterly dependent, at this point, on the bash replacement.

They need to focus on "Where perl has been" while it has been out of the limelight because, believe me, perl still rocks for productivity and performance.

Moose has revolutionized the object system (a system that was so flexible that it just gave you the parts and said "go build it")

Perl::Critic has created a baseline which all production scripts should be above.

PSGI and plack have changed the way you build and deploy and perl webapps.

In fact, the perl community and the current stars of CPAN have come so far, and have had so much going on that I have difficulty keeping up with the massive strides they are taking, let alone summarize those changes here.

Release. Perl. 6.

The success of perl 5 is in no way determined by perl 6. Perl 5 development continues unabated. As jrockway says here, "Think of Perl 6 as Perl 5's Clojure".

Though my personal opinion is that the naming, and the confusion it creates, sucks and makes it really easy to think that perl (5) is dead because perl (6) hasn't been released yet.

There have been 31 releases of Rakudo Perl 6. Pugs had half a dozen.

What more do you want?

In meantime for Rakudo Perl6 the direct link is: http://rakudo.org/how-to-get-rakudo

Looking forward to Learning Perl 6 when it starts to come along.

chromatic is currently writing a book called "Modern Perl", which teaches Perl the way we know it today, idiomatic, safe, structured Perl.

We just need more of such efforts.

I'm going to be blunt. I actively dislike Perl, not Perl developers, but Perl. This is because I believe it not only gives people the rope to hang themselves with but encourages them to do it in 6 different ways.

The problem that I have most though, is the reaction to this silly bit of fun. Instead of proving that Perl is awesome and showing what you can do with it, I mostly heard a lot of griping. I'd really love to see Perl 6 succeed and those guys do something amazing, new and innovative that breaks from the mold that I think of them in. But until they do, I'm not going to listen to their whining.

P.S. Tim is also right there are lot of great things we got from Perl, but that doesn't mean they should be allowed to coast on them forever.

(Have you seen the Python that non-programmers write? Holy shit! It's like 1980s Perl, but worse! Almost like bad code has nothing to do with language, and everything to do with programming ability.)

However, some languages make it far easier for you to write bad code and Perl is at the front of the pack.

In my own opinion each programmatic device should be expressed 1 way. Shorthands are not a good long term strategy, because they increase the chances of massively diversified coding styles.

On the other hand, I simply cannot stand to write Python because the One Way to Do It that tends to be provided is rarely the One Way I Want to Do It.

It's okay that some communities and some languages say "There should be one-- and preferably only one --obvious way to do it", though. After all, if I believe "There's more than one way to do it", that applies to languages and communities, too. If a language whose community believes in only one way to do it makes you happy, use it. If you're like me and prefer having many options to express individual pieces of code however feels most appropriate for that specific situation(e.g., expressing a series of transformations on a list as either a list comprehension or a pipeline like series of feeds connecting higher-order functions), use a language that lets you do that. Neither is better for everyone. Nor is the programmer who prefers either type of language any better than the programmer who prefers the other.

  > P.S. Tim is also right there are lot of great things
  > we got from Perl, but that doesn't mean they should
  > be allowed to coast on them forever.

(Think of how non-radical PHP 4 -> PHP 5 and Python 2 -> Python 3 were, and how hard it was to get people to switch. Now imagine differences 100x those, and you can start to see Perl 6's relationship with Perl 5. P5 is going to be around for a long time; it's a great language, and people are going to be using and improving it for a while. P6 is a good language too.

They both happen to have the same name, though, which apparently confuses people.)

While the radical difference between Perl 6 and Perl 5 might discourage adoption, I wonder if the less radical changes of PHP 4 -> 5 and Python 2 -> 3 may have contributed to their slow adoption. After all, if there is no radical benefit you will receive from switching your code to a backwards-incompatible new version of your language, it can be hard to justify doing so.

http://en.wikipedia.org/wiki/Comparison_of_programming_langu...

Having primarily used Python for scripting, I am not too familiar with Perl. Could you explain a little more what you mean by this?

Perl provides many, many different ways to achieve the same thing. This is somewhat by design, in the idea that Perl should match your own intuitive style. But most people's styles are not yours, and it becomes impenetrable.

IMHO Ruby's strength over Perl is the much stronger OO, Python's strength is the focus on "there is only one way to do it", which lets most people be able to grok most of your code.

I couldn't go back to Perl by choice now. I first jumped to Python just to get some sense of clarity in my life, but now I prefer Ruby due to how its extreme openness means there are some really awesome gems out there.

  > Python's strength is the focus on "there is only one way
  > to do it", which lets most people be able to grok most of 
  > your code.

It's a bit like the subtle philosophical differences between two dialects of the same language, say Received English and an inner-city slang.

> There should be one-- and preferably only one --obvious way to do it.

The follow-up I think hammers home the subjectiveness of ‘obvious’:

> Although that way may not be obvious at first unless you're Dutch.

Perl lets you get under the hood in a way that either is frowned upon, impractical, or prohibited in other languages. So there's a language for every temperament now.

For example, in Perl, [if you wanted to], you can roll your own object system. That makes some people happy, and other people uncomfortable. But much of Perl has moved on to one very cool object system, Moose.

The Tim Bray article reads as if he's unaware of Modern Perl and all the Perl 6 stuff which has been back-ported to Perl 5. In all honesty, I had to check the date because the article had a 2002 feel to it.

use strict; use warnings; is not required. Moose is not the default object system.

You can't say, "Oh, this library has that feature!" Thats not good enough. It has to be built-in, not optional, core to the language. If you're working by yourself - you can write code in any language well. In groups, that is NOT the case. Writing Perl in groups requires rigorous code reviews and cooperation, and even then nightmares are hard to avoid. Expressiveness has its downsides. You cannot simply bring a Perl noob onto a project and not have him ruin it. You CAN bring a new Rubyist onto a project and they can be productive.

These assertions beg proofs.

This begs the question, what's core? Python's regex could go either way, for example.

CPAN is core to the Perl language and deliberately so. If you don't like this ethos then Perl isn't a "language" you should consider.

[ This doesn't really matter much for long-running scripts or controllers in a webapp, but it does for a lot of other applications ]

In short, I think some people feel that there are too many ways to do it.

Anyhow, that said, I think that people are too quick to write Perl off. Some of us are still writing Perl. Maybe I'm not doing anything big or fancy, but it's all documented, readable, and every single script on my computer uses warnings and strict. If you compare Perl to duck tape, I'd be like McGuyver: always keeping a roll of it in my pocket.

I've looked back at some of those one-offs, and for the life of me I can't tell what they are supposed to do.

On the other hand, I have written some largish projects in Perl, and when I constrained myself to a very explicit dialect of the language (almost Javaish in verbosenss), I found it to run fast, and be highly maintainable. I cracked the code open to a 20k line project I wrote 4 years ago and was able to jump right in.

In that respect it's a bit like C++ in that you can write code to be unreadable or you can write it to be readable if you constrain yourself to a non-idiomatic subset of the language. But unfortunately, the Perl community tried to embrace and open attitude towards this (there's more than one way to do things) that ultimately ended up embracing the "get it done now and in as few lines as possible" idiomatic unreadable code style.

I think other than that, OO is an important factor, Perl's OO system was so hard to do right, and other languages OO just seemed to embedded and clean to work with, but also Perl has not really found itself (for some reason) in many embedded systems, in GUI programming, on client-side systems (e.g. Javascript), etc. all places where it could have done well, but for whatever reason just never found a good comfort zone the way it does for sysadmin type tasks (and a few very small domains like computational linguistics). The Perl community seems to have spent a decade endlessly spinning around the drain of supporting backend work, and never approached the more sexy applications of the language.

Also, Perl 5 tends to be used for a lot of unglamorous admin work. So, although almost everyone's got a few utilities or cron tasks on their system written in Perl, they're not shouting about it from the rooftops.

Also, Python is an easy language to learn, and so people like to learn it and blog about how easy/nice/shiny it is: http://xkcd.com/353/ .

  for $line (@array) {
    print $line unless $seen{$line}++;
  }

> print $line unless $seen{$line}++;

> }

The impulse to golf is strong …. How about

    $seen{$_}++ or print for @array

?

That's why I always use the non-clever version for my code, except with foreach instead of for, just so that it reads like English.

Clever is fun, though. I do understand the temptation. I admit to having done crazy stuff like turning a JAPH into a vulnerability scanner (in retrospect, the "fork until there are 256 of you and scan an entire subnet at the same time" thing wasn't that great). But I usually find myself wanting to come back to the code and know what I was thinking.

Being too clever makes that difficult.

Used in small doses and when you need something quick and dirty, it has been immensely useful, much like vlookup() in Excel.

If you mean just the idea of using a hash to mark things you've seen before, though, that is very, very useful. But I would write it as:

foreach $item (@list) { # Print every item in the list skipping duplicate items. print $item unless $seen{$item}++; }

Because then I don't have to think about what's happening with all the magic $_ variables Perl is tossing around. Sure, they're convenient. And I do use them some of the time. But when things break, I'm usually glad that I was explicit about what I was doing rather than relying on Perl's magic to know what I intended to do.

Maybe that's why I like Perl so much? I tend to code in as strictly disciplined a manner as I can manage, so I don't end up regretting it later.

But more importantly, I have not seen anyone post equivalent Python or Ruby code.

You're right that the overall pattern is VERY useful.

Well here's a fascinating stat from OSCON 2010. The language with most (presentation) tracks was... wait for it... Perl!

* Perl - 17 tracks

* Python - 16 tracks

* Java - 13 tracks

* Javascript & Ruby 7 tracks each

Interesting eh? :)

(FYI, a "track" is a group of related talks, not a single presentation.)

re: track - OK to clarify within the Perl track there were 17 presentations. See http://www.oscon.com/oscon2010/public/schedule/topic/Perl)

Also, note that Tim's probably right about string manipulation. A lot of times when Smalltalk was perceived as slow even when it was fast, had to do with string manipulation. (And bad programming!)

>Yes, there were other languages with some of these characteristics before Perl. But Perl had all of them...

Being honestly aware of the strengths and weaknesses of the tools one uses, and being willing and able to move to other tools if necessary, are attributes that will probably help one have a much happier career.

Maintainability (and by corollary readability) is PARAMOUNT.

Post mentioned most programming is string manipulation. Well even more code must be maintained. It is the #2 tool feature / programmer skill. (#1 is being able to get shit done and thus create something needing maintenance).