Perl 6 Grammars and Regular Expressions

An anonymous reader writes "Perl 6 is finally coming within reach. This article gives you a tour of the grammars and regular expressions of the Perl 6 language, comparing them with the currently available Parse::RecDescent module for Perl 5. Find out what will be new with Perl 6 regular expressions and how to make use of the new, powerful incarnation of the Perl scripting language."

Comments

RE

[s1283134]

I love regular expressions.

Better asked at slashcode.com perhaps, but

[Scott Lockwood]

How will this affect people running slash? In a slightly related question, when will Slash support Mod_Perl 2.x, and Apache 2?

Re:Better asked at slashcode.com perhaps, but

[Zorilla]

About the same time they get around to supporting XHTML and CSS.

Re:Better asked at slashcode.com perhaps, but

[Neil Watson]

When mod_perl 2 (actually, 1.99_17) is no longer a development release.

Re:Better asked at slashcode.com perhaps, but

[imroy]

Or PostgreSQL.

Perl goodness

[Zorilla]

HXGF*&#$()#P*&ULJKDFHV)(&*#$utrhk:jlhdsf(p*&#$OJDF >KLJDFP)(*$#&pyu:

Crap, I think I just accidentally programmed a web browser in Perl

Re:Perl goodness

[b12arr0]

Uh, that's not a web browser, it's clearly a web server.

Re:Perl goodness

[Zorilla]

It curls fries, too, you know.

Re:Perl goodness

[Commander Doofus]

There's a bug in your code, it should be HXGF*&#$()#P*&ULJKDFHV)(&*#$utrhk:jlkdsf(p*&#$OJDF >KLJDFP)(*$#&pyu: . Hope this helps.

Re:Perl goodness

[Black Perl]

Just so people know, Perl gets its reputation for being line noise largely from its early adoption of regular expressions. For example:

s/^\/\\\$(.*)$/\/\/$1\//;

But now this syntax has made it into just about every other language. And so now you can accidentally program a web browser in any language.

Re:Perl goodness

[jandrese]

There are two things about regular expressions:

1. Perl chose a keystroke-efficent syntax that makes them unreadable to anybody who doesn't know how to read them. It also made them very compact and easy to write for anybody who does know how to read them. They look very intimidating, but underneath they are usually easier to understand than the C like perl code surrounding it.
2. They are amazingly useful. Seriously, if you have never learned about Regular Expressions you owe yourself a lesson in how they work and what they do. I've seen people spend days working on stuff that can be written (more efficently!) in a regular expression in a matter of minutes. Pattern matching is the sort of thing that every general purpose language should have, it is a shame that the basic Regular Expression libraries that comes with most Unixes is such a piece of crap. Who wants to deal with the arcance invocation method, the extremely limited syntax, or the syntatic sugar like: "[[:digit:]]{2}:[[:space:]][[:space:]]*[[:alpha:]] *" when you could write "\d{2}:\s+\w*"?

Re:Perl goodness

[Anonymous Coward]

> Who wants to deal with the arcance invocation method, the extremely limited syntax, or the syntatic sugar like: "[[:digit:]]{2}:[[:space:]][[:space:]]*[[:alpha:]] *" when you could write "\d{2}:\s+\w*"?

Maybe when you want them to match the same thing. \w matches letters and digits (and underscores I believe). [[:alpha:]] matches letters only, and it's localized, unlike [A-Za-z]. There is no perl equivalent, except of course to use the named character class, which perl happily supports. You'll note that recent versions of GNU grep have snuck in perl regexes with the -P flag.

Re:Perl goodness

[Anonymous Coward]

A web browser? That's:

perl -MHTML::Strip -MIO::All -e 'print HTML::Strip->new->parse(io($ARGV[0])->scalar )'

A web server? That's:

perl -MIO::All -e 'io(":8080")->fork->accept->(sub { $_[0] < io(-x $1 ? "./$1 |" : $1) if /^GET \/(.*) / })'

Re:Perl goodness

[RangerRick98]

A lot of people don't seem to know that you don't have to use slashes as your delimiters. I use curly braces, myself, which would make the example you gave a little clearer:

s{^/\\\$(.*)$}{//$1/};

And of course, you could always use the x modifier (i.e., s{}{}x) to split the regular expression across multiple lines and document it.

Re:Perl goodness

[ajs]

Perl chose a keystroke-efficent syntax that makes [regular expresssions] unreadable

No, it most certainly did not. Regular expressions as they exist in Perl today are a direct descendant of POSIX regular expressions which derive from the original work done by Ken Thompson (which resulted in the grep program, which stands for "global regular expression print"). That syntax further dates back to the giants in the field of computational theory, and was specialized only slightly for text matching.

grep, awk, sed, ed, vi, emacs, and dozens of other programs and languages for Unix used this notation before Perl came along and adopted it, so let's not pretend that this syntax is somehow Perl's doing.

The extended regular expression syntax of today IS perl's doing and in almost all cases it has been a process of making regular expressions both more powerful and more readable, culminating in Perl6's rule syntax which is highly readable by comparison.

Re:Perl goodness

[Anonymous Coward]

Perl chose a keystroke-efficent syntax that makes them unreadable to anybody who doesn't know how to read them

Maybe it's just me but I find everything in the world is unreadable to anybody who doesn't know how to read it!

Re:Perl goodness

[David Gould]

The regular-expression syntax is far from being the only reason for Perl's reputation as a write-only language.

As reported, here, there's also the matter of the ridiculously large and cryptic collection of global and internal variables ($@_$%&|`). And then you've got optional punctuation (including such essentials as quotes for string literals and parentheses for function calls) and all the freakishly bizarre syntactic constructs for referencing and dereferencing objects (and people think "*" and "&" in C are confusing -- sheesh!).

I could go on for hours listing the things I found to hate about Perl when I had to use it, but now I've got some PHP code to get back to.

Re:Perl goodness

[PylonHead]

I'm sure you're right. In pursuit of a similar time saving conciseness I'm going to start dropping all my variable names down to a single letter.

Re:Perl goodness

[Anonymous Coward]

Perl didn't "choose" much of anything; its original syntax and semantics are largely based on awk, sh, sed, and a few other traditional UNIX tools, although it has been extended greatly since.

Re:Perl goodness

[jandrese]

Um, that was my point. Larry Wall could have chosen a different syntax (as he has done somewhat with the Perl 6 expressions), but instead he chose the keystroke efficent but hard to read version. It's not like there was a standards body forcing that syntax down his throat.

POSIX on the other hand ignored most of that historic syntax and instead chose their horribly bloated keyword syntax.

Re:Perl goodness

[jandrese]

Most of the blanket condemnations about how difficult it is to read Perl regular expressions comes from people who don't really know how to read them (at least in my experiance). If you know how they work and the (fairly limited) keywords it is pretty easy to tell what any normal Regular expression is doing. There are ways to obfuscate a regular expression, but in general they're a lot more straightforward than the code around them.

Re:Perl goodness

[ajs]

Larry Wall could have chosen a different syntax

There really aren't many choices. The current regular expression syntax is the only form I've seen tried, with only minor variation.

as he has done somewhat with the Perl 6 expressions

Perl 6 regular expressions have almost exactly the same syntax as Perl 5. The parts that are new are not regular expressions. Cosmetic differences (like [] vs <[]> are fairly ignorable syntactically. It would be like saying that Perl 5 will use // as the comment character instead of # (not that it will, just an example).

All of the inline comments and whitespace are part of Perl 5 extended expressions, though the word-matching on whitespace is new to Perl 6.

POSIX on the other hand ignored most of that historic syntax and instead chose their horribly bloated keyword syntax.

That's not really part of the regular expression syntax. Having [[:digit:]] as an alias for Perl's \d is hardly a different syntax so much as sugar. The fundamentals of POSIX regular expressions are the fundamentals of all modern regex syntaxes:

• alphanumerics are literals
• backslash is a character escape
• parens are used for grouping
• *, +, ? and {} are repeat count specifications

These are the fundamentals of Perl regular expressions, POSIX, and all of the other modern regular expression engines and in turn have only a few small differences from the basic regular expressions which Unix started with.

I've often thought that the ease with which regular expressions can be accessed within per was a blessing and a curse. So many people like yourself seem to think that Perl championed regular expressions, when in fact it just followed AWK's lead in integration between C and Ken Thompson's regular expression implementation (which in turn inspired the version that was written from scratch by Henry Spencer and used by Larry for Perl).

If you have a new syntax in mind, I suggest introducing it and seeing how it does. Modern regular expressions are an incremental improvement on classical set notations, and have served us well to date, but I'm sure someday someone will see a better way.

Re:Perl goodness

[bedessen]

When you see a regular expression like that it's a good indicator that the person that wrote it wasn't very familiar with how to write good REs. The above suffers from "leaning toothpick syndrome." If you are trying to match the '/' character, then don't use it as the delimiter of the RE. For example, compare the following REs, which are equivalent:

m/\/\/(.*)\/\//i

and

m,//(.*)//,i

Using ',' for the delimiter of the RE means you don't have to backslash-quote the forward slash to use it in a match.

This is just basic RE stuff and has nothing to do with perl. In fact, perl gives you many tools such as the "/x" modifier that allow you to vastly clarify the meaning of long and complicated REs, to the point of having indentation, extra whitespace, and even embedded comments. It's not perl's fault that many people only have a cursory knowledge of REs, and so they tend to write terrible REs.

Re:Perl goodness

[Anonymous Coward]

I need help with a regex:

(\(\
(^.^)
(")")

I would really like to know its function, thanks!

Re:Perl goodness

[Anonymous Coward]

As reported, here [mrchuckles.net]

Ah, you have learned about Perl from a humor piece.

ridiculously large and cryptic collection of global and internal variables

The only ones you need to know are the default variables: the default array @_ and the default scalar $_ . Yes, it's weird. Every language has idiosyncrasies. You learn them. You move on.

all the freakishly bizarre syntactic constructs for referencing and dereferencing objects

Here's an object reference:

$object

Invoking an object method:

$object->method();

Retrieving object data:

my $value = $object->{data}

Let's say $value is actually a reference to an array, and you want to dereference it to get your array back:

my @array = @$value;

Maybe this is freakishly bizarre, or maybe you only know PHP, and balk at anything different.

Re:Perl goodness

[Anonymous Coward]

...and it's probably more secure than IE.

Grammar

[dprust]

It is good to see PERL focussing on what makes it great. There is no other language, IMHO, that handles text input as well as PERL does. Adding this level of processing just makes it even more powerful.

Re:Grammar

[Anonymous Coward]

Perl is made great by its ability to provoke raging flame wars over ephemeral points:

It's "perl", you strongly-typed, weak-minded illiterate; not "PERL". Everyone knows that as of Sep. 17, 1999, the perl community decided arbitrarily (and overnight) that it isn't an acronym anymore.

Re:Grammar

[stratjakt]

Acronymn or not, are you trying to say I can't yell it?

PERL! PERL! PERL! ATTICA! ATTICA!

Re:Grammar

[Mr. Muskrat]

Perl never was an acronym. It's a backronym.

Perl is the language and perl is the interpreter. Remember, "only perl can parse Perl" and it's easy to remember.

Re:Grammar

[TheFlyingGoat]

Yeah, now that I've RTFA, I realize just how cool these advances are. They've basically taken some of LISP and built it into Perl, but added a few extensions and predefined strings on top of it. Besides looking MUCH cleaner and being MUCH easier to read/maintain, it should be much more powerful for programmers that know LISP.

Re:Grammar

[pclminion]

If that's true, then how come Larry himself writes in the preface to Schwartz's Perl book that Perl was named for "Practical extraction and report language?"

I mean, it's from the horse's mouth.

Re:Grammar

[Da Masta]

Think back to what your parent meant by backronym. Larry wanted to call it perl/pearl and came up with the "practical extraction..." part to justify it.

Re:Grammar

[Anonymous Coward]

From my Camel Book (by L. Wall et al):

To those who merely like it, Perl is the Practical Extraction and Report Language. To those who love it, Perl is the Pathologically Eclectic Rubbish Lister.

Both from the horse's mouth. Throughout the book, it's capitalised as Perl or perl (the language and the compiler/interpreter). From that, I infer that it's not really an acronym...

Re:Grammar

[Anonymous Coward]

Haha... nice troll. It's funny to see the moderators get duped.

Re:Grammar

[sbszine]

He also says in the camel book that it stands for Pathologically Eclectic Rubbish Lister : )

hrm...

[Anonymous Coward]

"...zztop-wants-a-perl-necklace dept."

i do not think that means what you think it means.

Re:hrm...

[bluelip]

I disagree. Unlike the unsuspecting females I've offered them to recently, I think they knew exactly what it means. :)

Re:hrm...

[Razor's Edge]

Slang
http://216.239.57.104/search?q=cache:WH5fKEkW0XEJ: www.londonslang.com/db/p/+%22pearl+necklace%22&hl= en/

Please!

[DAldredge]

Can we PLEASE just talk about Perl? 5000+ posts about why ruby and python are better from people who have never programmed something important get a little old...

Re:Please!

[DAldredge]

No. Much like I have faith that the sun will rise tomorrow I have faith in my fellow /. posters to take this discussion off target.

Re:Please!

[kclittle]

Pre-emptive counter-strike...

Re:Please!

[Pxtl]

Noticed that... at any rate, I will now. Python is cooler than Perl - yes, its just as crufty and bloated, but its legible. And yes, I have worked on large-scale Python projects.

Ruby looks really cool, but I'd rather just have Ruby blocks added into Python than sacrifice legibility as much as Ruby does. Python closures/lambdas are teh suck compared to Ruby blocks.

So, what does this news mean for Parrot? We any closer to seeing our sexy cross-language interpreter/VM yet?

Re:Please!

[Zorilla]

Don't worry. Leave it to Slashdot mods to mark anything that doesn't mention Perl at least 6 times to get marked offtopic.

(Hell, my sig gets even the most innocent of my posts marked as troll )

Re:Please!

[Darby]

No. Much like I have faith that the sun will rise tomorrow I have faith in my fellow /. posters to take this discussion off target.

Ahhh... but your faith that the sun will rise tomorrow is only backed up by one piece of evidence a day.

Re:Ok, start the flame wars under this post

[DAldredge]

We are talking about Perl, not (L(I(S(P))))

Re:Ok, start the flame wars under this post

[Zorilla]

Ok, folks; choose your topic:

a) Is it called GNU/Linux or Linux?
b) Emacs vs Vi
c) "Ok" goes on the left, "Cancel" goes on the right.
d) Security is based on market share - NO! Apache is more secure despite bla bla bla!
e) 45 RPM LPs sound better than reel-to-reel!

Big problem

[Smallpond]

Perl 6 will support Perl 5 regular expressions by using the :p5 modifier.

Meaning that it is not backward compatible without modifying your source code.

Note to those who are going to respond "Just install both!": look at the first line of your perl scripts.

Re:Big problem

[WWWWolf]

The idea of :p5 is not just that you can take Perl 5 code and modify it to make it work.

The idea is that if you don't bother to write a zillion-rule grammar to match whatever you're trying to match, you can still use the P5-style regular expressions you know and love. It's another case of Not Swatting A Fly With The Nuke.

Re:Big problem

[Speare]

Um, ALL PERL CODE IS TREATED AS PERL5 CODE unless you use a specific Perl 6 keyword in your script. Perl 6 interpreters will not require you modify your scripts AT ALL to use Perl 5 scripts.

Therefore, it's just Perl 6 scripts which want to use Perl 5 regular expression syntax, which would want to use the :p5 modifier.

Don't get your knickers in a bunch.

Re:Big problem

[Zaak]

Meaning that it is not backward compatible without modifying your source code.

Thus spake Larry Wall in Apocalypse 5:

...we took several large steps in Perl 5 to enhance regex capabilities. We took one large step forwards with the /x option, which allowed whitespace between regex tokens. But we also took several large steps sideways with the (?...) extension syntax. I call them steps sideways, but they were simultaneously steps forward in terms of functionality and steps backwards in terms of readability. At the time, I rationalized it all in the name of backward compatibility, and perhaps that approach was correct for that time and place. It's not correct now, since the Perl 6 approach is to break everything that needs breaking all at once.

And unfortunately, there's a lot of regex culture that needs breaking.

And from Apocalypse 1:

It would be rather bad to suddenly give working code a brand new set of semantics. The answer, I believe, is that it has to be impossible by definition to accidentally feed Perl 5 code to Perl 6. That is, Perl 6 must assume it is being fed Perl 5 code until it knows otherwise.

In other words, it is backwards compatible, it isn't backwards compatible, and when you install Perl 6, you are installing both.

TTFN

Re:Big problem

[Anonymous Coward]

In other words, it is backwards compatible, it isn't backwards compatible, and when you install Perl 6, you are installing both.

Flip-flopper!!!

Re:Big problem

[Tassach]

That still doesn't answer the fundimental question:

Will it be possible to distinguish Perl6 code from line noise?

Re:Big problem

[jdavidb]

The first line of most of my Perl programs is

#!/usr/local/bin/perl5.6.1

I admit that's an ancient version of Perl, but unfortunately that's what I'm stuck with here. At home it might say perl5.8.5 or so.

I realized a long time ago that I'd better have every program I wrote tied to specific installation of a specific version of Perl, to avoid problems in installing future versions or new modules. Has nothing to do with Perl 6; it's just good configuration management. I can at any time install another perl without interfering with the one installed or with any programs that are using it (and I intend to play this card at work at some point).

Re:Big problem

[TimToady]

As always, that will depend on who is trying to do the distinguishing, and more importantly on whether they're actually trying at all. People who do try generally don't have much problem with Perl 5, and Perl 6 will be much improved in that respect.

Re:Big problem

[Anonymous Coward]

Oh my God... THE SKY IS FALLING!! HOLY FUCK! WE HAVE TO GET OUT OF HERE RIGHT NOW!

Wait, wait. You could just keep using Perl 5 until you get off your ass and make some changes, or use it forever, for that matter. Disaster averted.

Re:Big problem

[ajs]

As others have pointed out, Perl 6 interpreters (at least the default one that is Parrot-based) will hand your code off to Ponie or something like it by default. You will have to start your program with the module keyword or the use 6 statement to force Perl 6 behavior, or use a special binary (e.g. something like /usr/bin/perl6).

The :p5 modifier is not there for backward compatibility so much as to allow the programmer to choose the model of regular expression to use. There are trade-offs. Here are two Perl 5 regular expressions:

m{[a-z][A-Z]+}
m{^(?:\w+\d|\S+(?:\'s)?)$}

which are written in Perl 6:

m{<[a-z]><[A-Z]>+}
m{^[\w+\d|\S+[\'s]?]$ }

Note that Perl 5 syntax is actually a bit nicer for the first one, so you can continue to use Perl 5 syntax there. In the second case, the new bracket-operator is very handy for enclosing sub-expressions that don't have to be remembered in the positional variables (the same as the Perl 5 (?:...) operator). You can even mix them:

$r1 = rx:p5{[a-z][A-Z]+};
$r2 = rx{[\w+\d|\S+[\'s]?]};
$r3 = rx{^[<$r1>|<$r2>]$};

Perl 6 is about making the things that you're going to need to do the most often much easier and much more supportable in very large projects. Relax and enjoy it, it's going to be a great ride.

Re:Ok, start the flame wars under this post

[Anonymous Coward]

45 RPM LPs sound better than reel-to-reel!

You have GOT to be kidding!

Why would a satisfied Perl5 user migrate?

[winkydink]

What does Perl6 offer a satisfied Perl5 user? Is it faster? Smaller?

To this user, the last several releases (5.x) have looked more like opportunities for continuing royalty streams for perl authors (new versions of old books) than significant releases.

Re:Why would a satisfied Perl5 user migrate?

[Speare]

From what I've seen, it's more amenable to modular libraries and structured design. As for basic scripting where you may not even use a "package" statement, you probably won't care.

Re:Why would a satisfied Perl5 user migrate?

[XMyth]

See

http://it.slashdot.org/comments.pl?sid=128918&ci d= 10756138

Re:Why would a satisfied Perl5 user migrate?

[winkydink]

I've heard/seen that "this upgrade won't affect your existing code" song and dance before. In my youth, I actually believed it.

Re:Why would a satisfied Perl5 user migrate?

[WWWWolf]

Yeah, Perl 5 hasn't changed that much over time. But it has been around for a while. Perl 6 is just different.

From what I have seen from the announcements, the Perl 6 syntax looks far cleaner, probably more consistent and less ugly. Some of the new tricks look genuinely handy. For example, if it seems like type checking would be a good idea, you can have it if you want it, even on compile time!

Especially the regular expressions side seems pretty interesting, as noted in this article. Regular expressions have always been a poor but effective replacement for grammar-based parsing, and now finally Perl is going to have both integrated. There's probably going to be less whining about line noise.

And then there's something that I find especially interesting, though it hasn't been explained in detail yet: Complete tuning of the object system. In case you haven't noticed, Perl 5's object system is a complete and utter mess that looks and smells like it has been added as an afterthought, and rest assured it's going to be changed radically for better in Perl 6. I'm definitely waiting eagerly to see what Perl 6's take is going to look like - I sure hope it's something like Ruby, only it smells like a camel =)

Re:Why would a satisfied Perl5 user migrate?

[Anonymous Coward]

It uses a compiled p-code interpereter, with (eventually) optimizations, while still supporting dynamic code interperetation (eval's and the like). Yah, that's a trick. So it should run faster (even running P5 code).

Your P5 code doesn't have to be touched to run (all code is P5 unless it says it's P6), but if you touch it you can get improved regex grammar (see the article), access to non-perl(!) modules and libraries (python at least is being ported, and some low level stuff is being written in p-code directly) and the new object model, which should involve fewer buckys per common operation.

Of course, no-one's forcing you (unless you're not root on your system...)

Re:Why would a satisfied Perl5 user migrate?

[gurps_npc]

You left out the other two possible improvements.

Programs/Languages can be:

Faster

Smaller

More powerfull (more available features)

Simpler to use/understand

From reading this article, it mainly focuses on the last two that you did not mention. Perl 6 is trying to be a little bit more powerfull and a little bit easier to use /understand.

Re:Why would a satisfied Perl5 user migrate?

[XMyth]

I know what you mean, and really I haven't read into detail about this particular situation. However, if it truly executes code using perl5 by default unless a perl6 declaration is made then that would be more than just "backwards" compabability

Re:Why would a satisfied Perl5 user migrate?

[winkydink]

If I am a current, satisfied user, the last two are less important than the first two, as current & satisfied infers that I have all the features I need and already know how to use/understand.

Re:Why would a satisfied Perl5 user migrate?

[I Like Pudding]

If speed and size were the only two criteria that made languages great, we'd all be programming in NOOP.

Re:Why would a satisfied Perl5 user migrate?

[winkydink]

What other improvements besides speed and size would provide impetus for an already satisfied user to migrate? Assume for the moment, I do not have copious amounts of free time.

Re:Why would a satisfied Perl5 user migrate?

[cft_128]

In case you haven't noticed, Perl 5's object system is a complete and utter mess that looks and smells like it has been added as an afterthought

If you even consider it an object system; I use it daily and I'm still skeptical about calling it object oriented programming. Reminds me really of ADT with C with some new 'features' added to make it slightly easier. Not that I don't like it, I still find it very useful but....

Re:Why would a satisfied Perl5 user migrate?

[gurps_npc]

As someone that currently uses computers I find your assumptions to be patently false. And it appears to confuse the terms "Satisfied" with "considers to be perfect"

Current, satisfied user does NOT at all infer you have all the features you need.

"Current" just means you have installed it. "Satisfied" means you do not know of a currently existing product that does it better.

And the bad grammer/incorrect quote for the second part also reveals another mistake you are making. I said "ease of use/understand." Those are NOT things you can possibly "know", nor are they things that can be "completed/maximized". Just because you consider something "fast" does not make it move at the speed of light and therefore nothing can go faster. Similarly, perl is a language that while it satisfies my needs now, can be better, specifically it can be easier to write programs and easier to understand programs that have been written by other people.

Your definition of "Satisfied" is actually the definition of "Perfect". If we used if, no one is satisfied with ANYTHING at all, not their children, not their wife, not anything, because it means that Satisfie

Re:Why would a satisfied Perl5 user migrate?

[ajs]

You have to divide further. Let me illustrate:

Reasons to convert to Ponie (Perl 6 on Parrot):

• Access to code written in other high-level languages without glue code.
  
• Just in time compilation to machine code (no interpretation unless you eval a string at run-time!)
  
• Cleaner access to C and C++ libraries without glue code.
  

Reasons to convert from Ponie to Perl 6:

• Vastly superior OO model, especially when trying to interface to multiple large object trees.
  
• Debuggability improvements throughout the language.
  
• Rules are far more powerful than regular expressions.
  
• Lazy evaluation of lists powers huge efficiency improvements.
  
• Subroutine definition is much more powerful
  
• Named parameter passing is no longer ad-hoc and is available for all subroutines by default.
  
• much, much more.
  

Re:Why would a satisfied Perl5 user migrate?

[winkydink]

Perhaps you should go look up the difference between infer and imply. As I am making the inference, I can infer whatever I so choose.

Faster means faster than perl 5. smaller means smaller than perl 5. Got it? I have no desire to understand programs written by others. I have a staff for that. I'm only concerned about the ones I write myself.

Call your pharmacist, dude. You seem to be running low on anti-psychotics.

oh, and it's spelled "grammar"

jerk

Re:Why would a satisfied Perl5 user migrate?

[jonadab]

> What does Perl6 offer a satisfied Perl5 user? Is it faster? Smaller?

It features better support for key paradigms, including object-oriented
programming (finally, a real object model), functional programming (we're
getting continuations), and even some improvements for contextual programming.
In other words, Perl6 will be a substitute not just for Perl5 but also for
Scheme and Smalltalk.

Also, the whole Parrot thingydoo is going to allow software written in one
language to seamlessly use libraries written in another language, without all
the ugly messing around you have to do to accomplish that in Perl5. You'll
be able to construct a complete data structure in Perl code and pass it to
a library written in Python, for example.

Read the Apocalypse articles twice. The first time you'll recoil in utter
horror. (I did.) Then read them again, and you'll be very excited. I am.
The bummer is that we're still a while off from the release of 6.0

Re:Why would a satisfied Perl5 user migrate?

[ajs]

I misspoke. Ponie is perl 5 on Parrot, not Perl 6.

Re:Why would a satisfied Perl5 user migrate?

[babbage]

No one is taking /usr/bin/perl away from anyone else, so the statement is perfectly reasonable. If Perl6 doesn't follow through on the promise to execute Perl5 code at least as well as the old Perl5 interpreter did, you are absolutely not forced to upgrade.

This isn't like upgrading, say, the Linux kernel, where it's an all or nothing affair and once you've upgraded you can't go back and also use the older version on the same system. The current Perl5 and the future Perl6 toolkits should be perfectly capable of co-existing on the same system, so there's nothing to be afraid of in the compatibility department. But, if the promises to make Perl5 code run faster, and be both more debuggable and more extensible are true -- and they should be, but no one knows yet -- then you have a lot to gain by upgrading.

Re:Why would a satisfied Perl5 user migrate?

[gurps_npc]

Nice way to totally ignore my point, while being insulting. Try to keep the words like jerk to a minimum, they don't actually hurt my feelings, but they do look a bit immature.

Here, let me simplify it so that you can understand:

1) You already admit that you need help to understand perl (You apparently pay a staff to do it). If Perl was simplified so that even you could understand it, that would free up your staff for more important things. This is called an IMPROVEMENT. The mere fact that you have a staff to do it proves that it WOULD be an improvement. Even if you are so self-centered as to not care what any other person has to do, this would STILL be an improvement because if it was simplified enough so that you could understand other people's code then your personal abilities would be increased.

2) If you are only concerned about the ones you write themselves than you ARE concerned with the "easier to use" aspect of improving Perl. Even if you are some Perl GOD that knows everything that could possible be done with Perl now, that does not mean we can not upgrade perl so that it takes 1/2 as many lines of code to write the same program. This would clearly be an improvement for YOUR PERSONAL USE, even if you personally did not learn how to do a single new thing.

. P.S. I find it incredibally amusing that in the same posting where you say "ease of understanding a language is worthless" you also correct my grammar and spelling so that my posting would be easier to understand.........

Re:Ok, start the flame wars under this post

[Zorilla]

Haha, yeah, I know. I was pulling crap out of a hat at the end there, but I knew I had to provide at least one retarded audiophile option.

Re:Runs great under Gentoo

[Zorilla]

Damn, I knew I forgot one on that last post I made.

aw hell

[The Unabageler]

I'm going to have to rewrite my sig.

Re:aw hell

[isolation]

You really need a newline return in that sig.

Re:aw hell

[ajs]

perl -e '$_="\007/4`\cp%2,".chr(127);s/./"\"\\c$&\""/gees; print'

doesn't change too much:

perl -e '$_="\007/4`\cp%2,"~chr(127);s:all:eval(2)/./"\"\\ c$&\""/; print'

I'm making up eval(2), and I'm not sure off the top of my head what s is equivalent to (I know there's new rules around what "." matches in what contexts, but don't recall the details). Of course, I have nothing with which to test the example, so I'm not sure.

There are some great features for better one-liners in Perl6, though overall the language is not favoring them. I'm especially happy with the word-matching features (e.g. $x ~ m:word/a b c/ will match a, b and c with any whitespace separating them). Also nice will be the hyper- and pipeline-operators which will give new power and speed to Shwartzian Transforms.

Rules will come in handy for quick-and-dirty one-liners as well. For example:

perl -MMail::Address -nle 'print $1 if /\bmailto: (<email>)/'

This is not much different from the Perl5 ability to pre-compile a regexp into a scalar and then intepolate it into a larger regexp (since you're not taking advantage of any of the features of the grammar engine in the example), but it does give us a cleaner framework for this sort of thing.

Re:Ok, start the flame wars under this post

[TheFlyingGoat]

Those of us that use Perl as more than just system duct-tape know it's a programming language. Perl 6 will make that even more clear by being based on OO fundamentals rather than being a procedural language with OO tacked on top of it. This is just another debate that makes the OS community look like a bunch of freaks and zealots... just like the GNU/Linux thing. Get over it and start focusing on what the software does, not how to classify/name it.

Re:Ok, start the flame wars under this post

[Stradenko]

Yeah, no kidding. Everyone knows that an LP runs at thirty-three and one-third RPMs.

Personally, I think that the 72RPM phonograph records sound best, but that may just be a reflection of the kind of music that's most often found on them. They certainly have more character!

wow, looks like boost::spirit

[Sebastopol]

I'm surprised by the regex grammar. It looks a lot like how I use boost::spirit::rule for parsing regex in C++:

Perl6---

# note this is just a language example, not an accurate name matcher
grammar Names
{
rule name :w { };
rule singlename { + };
};

C++::boost::spirit--- // rule for parsing a token string
rule split = *(*space_p >>
(+graph_p)[append(tok)] >>
*space_p);

msg "Parsing input\n"; // 1. Parse declarations
while (!header_ok && getline(input, line) && input.good())
{
tok.clear();
parse(line.c_str(), split);

There are even grammar classes in Spirit.

I sure hope perl6 is faster! ;-)

Re:wow, looks like boost::spirit

[fireboy1919]

Perl 6 is probably producing a GLR parser, as Parse::RecDescent is a GLR parser (it means it would be slower, but more flexible).

Isn't Spirit a LALR parser? Or an LL(1) parser?

It's not going to be faster than Spirit, because GLR parsers are slower than every other kind of parser.

On the other hand, you don't have to do all the wierd stuff you have to do with Spirit because it's mostly just syntactic sugar on top of C++, and therefore uses only C++ syntax (which doesn't look much like the natural pseudocode for creating productions).

Re:wow, looks like boost::spirit

[TimToady]

The intent is that grammars default to recursive descent, but that it be possible to ask for various kinds of optimizations via pragma. The grammar for parsing Perl 6 itself will be a hybrid between top-down and bottom-up techniques to maximize both speed and flexibility.

Re:wow, looks like boost::spirit

[ajs]

Perl 6 will probably not be faster than boost, but keep in mind that you also gain the power of a fully dynamic programming language in Perl 6's rules. Rules act as closures and can also contain Perl 6 code. Hypothetical variables are really going to blow people's minds (I know they took me a while to grasp, and when I did, I just sat around saying "wow" for a while :-)...)

Re:Ok, start the flame wars under this post

[Anonymous Coward]

I've got a fully multithreaded perl script running under Win32. It wasn\'t too bad to write but some parts sucked. One of the things sucked because Win32 doesn't support alarm() calls and you have to manually poll sockets and I hate that shit, or use vec() and that's just insane (how many people understand how vec() works anyway???) The other big thing that sucked was the crappy mechanism for sharing complex data structures between threads. All's honky-dory if you're just sharing a scalar variable, but don't try a HoH or anything like that cause you'll find out that there's no auto-vivification, and you have to manually create the data structure in every thread that needs to access it, and that right there leads to lots of possibilities for "interesting" bugs to show up (it's not very fun to code or pretty to look at or understand once it's done).
But anyway none of that is really here nor there, but I just wanted to comment that Perl "scripting" isn't just CGI forms and stuff like that. You can really do complex applications in Perl. It's a full-featured language, portable (moreso that even Java, just look at the list of archs in the Configure.sh script), and able to handle most tasks that don't require a tiny memory footprint or direct CPU register manipulation.

It is about time to change the name from

[musterion]

Regular Expressions to Context Sensitive (at least) Parsing. I'm not a big Perl Geek, but I use it on a daily basis.

Re:Ok, start the flame wars under this post

[kclittle]

Face it! Ancient vac-tubes from old Russian radar units (putting out, oh, 15 watts) and getting their signal from running a sharp-pointed stick 'round a piece of congealed petroleum is the best audio technology in the world!

-- Mr. Luddite

Re:Ok, start the flame wars under this post

[Zorilla]

Of course you meant 78 RPM, right?

Adoption

[base_chakra]

Years ago, Eric Raymond wrote:

"Perl XS is acknowledged to be a nasty mess. My guess is the Perl guys would drop it like a hot rock for our [Python's] stuff -- that would be as clear a win for them as co-opting Perl-style regexps was for us." [emphasis added]

Maybe I misinterpreted ESR's intended message, but it would be disappointing if hypercompetition prevented Perl's already-influential regex extensions from exerting a positive influence on other platforms. Raymond seems to imply that the Python team only grudgingly included support for Perl-style regex. I understand that developement teams in similar niches each want to make a big splash in the industry, hopefully Python's great increase in popularity has softened the survivalist attitude that seems to characterize this Raymond quote from Python-Dev. Evolving regex can benefit everyone.

Note to those ready to mod me Troll/Flamebait: I'm not trying to pick on Python, I just happened to be acquainted with this candid quote.

Re:Adoption

[Anonymous Coward]

Raymond seems to imply that the Python team only grudgingly included support for Perl-style regex

That's not what I got from his quote at all. He said that it was a clear win for the Python people to use Perl-style regular expressions. And likewise, it would be a clear win for the Perl people to use Python-style C extensions.

Re:Adoption

[Black Perl]

Yes, you did misinterpret the message. Eric Raymond was a former Perl programmer, and is now a Python programmer. He was saying that Python's native-code-binding facility is superior than Perl's XS, and it would benefit Perl to adopt it. He mentions that Python benefitted from adopting Perl's regex syntax. Nowhere does he say or imply it was "grudgingly" done.

By the way, not long after he wrote that, Perl coders started using the Inline:: modules like Inline::C instead of XS, which is very easy to use. I do not know if this was an adoption of Python's technique, but I don't think so.

Re:Adoption

[base_chakra]

Yes, you did misinterpret the message. Eric Raymond was a former Perl programmer, and is now a Python programmer. He was saying that Python's native-code-binding facility is superior than Perl's XS, and it would benefit Perl to adopt it.

Thanks for mentioning that. You are absolutely right, and shortly after I posted the message I stuck my foot in my mouth when I saw to my horror that I had gotten it totally backwards and maligned Eric Raymond in the process!! Another casualty of the rush to post while the story is hot.

Re:Adoption

[kavau]

I don't know the context of the quote, but to me it reads more like this: "Python benefited greatly from adopting Perl technology in the past. I hope the Perl guys will be as open-minded as we are."

Not much hypercompetition there, if you ask me. But then, it might as well be me who misunderstood the quote.

Re:Adoption

[smittyoneeach]

The whole Parrot thing is about having a language-neutral virtual machine.

Re:Adoption

[Anonymous Coward]

The thing is, some of us have been using Perl 5 regex syntax for a loooong time here. Why? It's powerful. Damned powerful. But even still, most of us don't use or understand the full power of them (hell, I made it through the entire O'Reilly book on regexes, and there are still crazy ideas I've never tried or weird stuff to do with them & Unicode, etc.).

So yeah, if people port to Perl 6, they'll have to change $foo =~ /bar/ (in Perl 5, that m can be left off, but you can also write that as m/bar/ if you like) to $foo =~ m:p5/bar/ (the m necessary this time, due to needing the p5 backwards compatability thingy), or you can stick with plain old Perl 5. I *do* expect a bit of resistance, especially some of us who have the regex syntax ingrained into our minds by now, at least at first.

But this is how Perl works. Not unlike the Final Fantasy games, the previous ones seem to have almost nothing to do with the prior ones in most cases* but they keep improving (or trying to improve) things to make them more useful and more powerful.

* (Yeah, I know you see a *lot* more of the evolution of the games and game mechanics especially once you play the FFs not released in the US, but there really isn't much continuity to be had, save in the few that were direct sequels. What ever happened to the elemental orbs/crystals/whatever, anyhow?)

Re:Adoption

[jonadab]

Perl5's regular expressions have already had most of the influence they're
going to have. Quite a number of languages and utilities have adopted bits
and pieces of the Perl5 regex syntax and feature set. Many in the Perl
community hope that Perl6 grammar rules will be equally influential.

As for XS, I certainly agree that it's ugly and bad and needs to die; the
interlanguage call semantics of Parrot will hopefully make that stuff
completely obsolete. If I understand correctly, using code that's written
in Python from your Perl6 code will look something like this:

use Python::SomeModule;
my $object = Python::SomeModule.new();
$object.somemethod(@arg uments);

(I may have some legacy Perl5 syntax in there by mistake; I spend a lot more
time with Perl5 at this point than Perl6, so sometimes I lapse.)

Re:Adoption

[Anonymous Coward]

...and totally unrelated to the discussion above. ESR was talking about Perl 5.

Re:Adoption

[smittyoneeach]

See, now, totally is too strong a word.
The point I was developing is that

And likewise, it would be a clear win for the Perl people to use Python-style C extensions.

is an example of small thinking. When all your language objects are belong to Parrot, swapping out various regex engines, database engines, XML parsers, etc. suddenly enters the realm of the possible.
Someday.

Re:Adoption

[Anonymous Coward]

No, it's an example of thinking about the present day. If every project stopped work on its current major version when a new major version is underway, the state of software would suck. Perl 6/Parrot will be great, but we have no idea how far off it is, even if everyone did devote all their resources to it. Most people need things that work now, and some of them want to improve how things work now or in the near future.

Re:Adoption

[ajs]

Exactly. Python and Perl are not really competitors in the strictest sense. They both build on each other. In many ways, I think Larry would have made some of the choices that Python did, had he started out in the 80s knowing what he knows now, and that's evidenced by how much of Perl 6 draws from Python (as well as Ruby, Scheme, LISP, Smalltalk, C++ and Java).

Of course, the basic approaches to language design follow different philosophies (Perl's is one of inclusion, Python's is one of exclusion... both are valid). But I think in the final analysis both will be first-class citizens of the high-level language world for a long time to come, and the cooperation fostered by Parrot's runtime will help to ensure that.

ESR's problem with Perl is (and I've spoken to him at length about this) that it is easy to write bad code. I don't think there are many Perl programmers who would disagree with that. ESR's solution is to use Python. Valid choice. My solution (and that of many Perl programmers) is to write clean code, maintain it through CPAN and make sure Perl 6 makes it easier to write cleaner code. Again, a valid choice.

Re:Runs great under Gentoo

[G27 Radio]

We both forgot to mention Macs though. Suprising, since there are literally thousands of people using them these days :)

Re:Ok, start the flame wars under this post

[Matthew Weigel]

...then it will stop being a good duct tape for systems.

Complex grammars in Perl

[imnoteddy]

I can understand a desire for adding grammars that are more powerful than regular expressions in Perl 6 but it opens up a whole new can of worms.

The grammars appear to be in a class called "context free languages"(CFGs). Some CFGs are ambiguous in the sense that a given "sentence" can be derived from more than one set of rules. Traditional tools such as yacc/bison tell you where there is ambiguity in your rules - even then it isn't always easy to remove the ambiguity (trust me on this). If the Perl 6 system doesn't help the programmer debug the grammar he/she will not be happy when the parsing doesn't work as expected.

In addition, the article ends the description of features with "And much more...". It appears that Perl 6 grammars are more powerful than CFGs. If they can simulate a Turing machine...

Re:Complex grammars in Perl

[Abcd1234]

What bugs me is they don't describe the type of parser being generated. Parse::RecDescent does just what it says... it generates recursive decent parsers. However, recursive descent parsers are not as powerful as the bottom-up parsers generated by, for example, Yacc/Bison (LL vs LR).

Re:Complex grammars in Perl

[pclminion]

However, recursive descent parsers are not as powerful as the bottom-up parsers generated by, for example, Yacc/Bison (LL vs LR).

That's backwards. Recursive decent with backtracking can parse all LL(k) grammars for arbitrary k. OTOH, yacc/bison can only parse LR(1) which, although sufficient for most realistic grammars, definitely is not as general as a full LL(k) method.

Left-recursive grammars are a red herring -- you can always eliminate the recursion, and with backtracking you can deal with arbitrary lookahead requirements.

Re:Complex grammars in Perl

[Anonymous Coward]

Some CFGs are ambiguous in the sense that a given "sentence" can be derived from more than one set of rules.

You also just described the class called "regular expressions" (REGEXes). Perl never helped programmers sort out ambiguous regex matches before and yet the world still turns.

Re:Complex grammars in Perl

[jonadab]

> It appears that Perl 6 grammars are more powerful than CFGs. If they
> can simulate a Turing machine...

It's better/worse than that. Perl6 grammar rules can call arbitrary Perl6 code.

Re:Complex grammars in Perl

[Zaak]

That's backwards. Recursive decent with backtracking can parse all LL(k) grammars for arbitrary k. OTOH, yacc/bison can only parse LR(1) which, although sufficient for most realistic grammars, definitely is not as general as a full LL(k) method.

A few reminders:

Recursive descent with backtracking has exponential time complexity.

The set of LL(n) languages is a subset of the LL(n+1) languages.

The set of LR(n) languages is identical to the set of LR(n+1) languages which is identical to the set of deterministic context-free languages.

Left-recursive grammars are a red herring -- you can always eliminate the recursion, and with backtracking you can deal with arbitrary lookahead requirements.

Yes, but you have to alter the grammar and deal with nonlinear time complexity. Which is the reason LR(1) parsing is so common.

TTFN

NO!

[DAldredge]

Ignore me all you want! At least the voices in my head listen to me. ;->

Write Only Software

[Anonymous Coward]

We all know that reusability is a BAD thing. If you code in Perl you never have to worry about making your code reusable, since there is no chance in hell of ever reusing it.

Perl - brings the idea of reinventing the wheel to a whole new level :)

Re:Write Only Software

[Anonymous Coward]

And yet there's CPAN, the largest "non-reusable" code archive on the Internet that constantly gets re-used by Perl coders eveywhere...

Re:Ok, start the flame wars under this post

[Anonymous Coward]

Not all LPs were 33 1/3, some were released on 45 (and in some occasions, both) for 'improved quality'. Take for example, Metallica's Master of Puppets, released on both 1 33 1/3 RPM LP, and on 2 45 RPM LPs.

Perl6 -- an interesting curiosity

[Anonymous Coward]

Oh yeah. Larry and Co. went off the deep end with Perl6. I mean now they DO have the kitchen sink in there.

That's what happens when you take a philosophy "more than one way to do it" and run with it.. straight off a cliff.

It is impressive the way they unify everything though. I guess if you can't make a language simple and elegant, you might as well try and make it consistent.

And the new regexp syntax is sorely needed. Regexps have grown up now and the syntax needs to be rethought. So I hope the other less confusing languages like Ruby will pick up the new regexp syntax someday.

I would also love to see a relational query language (NOT SQL THOUGH.. maybe something like Tutorial D) embedded right in the language like regexps are... but that's a discussion for another time. Let's get some real relational databases first.

Anyway, Perl6 is quite fascinating, but slightly insane.

Did you ever go drinking one night, but decide to NOT drink and just pull out a lawn chair and watch what people are like when they are drunk? That's how I feel watching Perl 6 evolve from the cozy comfort of Ruby. Lots of fun as long as nobody pukes on me!

Re:Perl6 -- an interesting curiosity

[TimToady]

Lawn chairs are fine, but in actual fact, kitchen sinks are more useful.

bad example?

[TheSnakeMan]

I have to question how good this guy is, given that it seems as though he has a mistake in his first set of examples:

'whereas in Perl 5 you can match "hello there" with "hello there" itself, in Perl 6 you'd have to ask for /hello <sp> there/ instead.'

Then: grammar English { rule name :w { <singlename> <singlename> }; rule singlename { <[A-Z]><[a-z]>+ }; };

Shouldn't this be: "{ <singlename> <sp> <singlename> };"?

Re:bad example?

[TheSnakeMan]

Next time, I swear I'll read the comments:

# Perl 6 :w modifier surrounds all tokens with "automagic" whitespace,
# which basically means it will match what most people would call
# "words"

You're a language bigot

[Mr. Muskrat]

Sounds to me like you prefer PHP and therefore spent more time perfecting your understanding of it. If you know and understand a language (any language) your work will require less time and will (surprise, surprise) be easier for you.

(I'm a recovering language bigot so I can say this. :-P )

Re:You're a language bigot

[Libor Vanek]

I wrote at least some code in:
Bash
C/C++
Delphi
i386 ASM
Java
Pascal
Perl
PHP
Prolog
Python
Ruby
Visual Basic

So I have some experiences. But I see this also all around - I'm managing also 5 other SW guys and those who write in Perl produce really unmaintable code while the same ppl in C/PHP produce really nice code (when run through indent ;-)) - I know this is very small sample but I haven't seen on my eyes any large project (maybe except /. ;-))) written in Perl...

Pet Project

[orlyonok]

I'm studing seriously the posibility of tackling a whorty coding proyect, the rewriting of the entire LINUX kernel on a languaje very much but not unlike C and was considering doing it in C-INTERCAL but after seing things like this http://ozonehouse.com/mark/blog/code/PeriodicTable .html , I changed my mind and will use PERL 6 instead.

Re:Pet Project

[qualico]

Hmmm...make sure you don't make spelling mistakes in that languaje of your new kernel.

Guess Mark wants to resolve a host name. Here is a working link:

http://www.ozonehouse.com/mark/blog/code/PeriodicT able.html

Re:Pet Project

[FuzzyBad-Mofo]

Have you seen the Perl Power Tools project? Might be a good place to start.

Yes.

[MenTaLguY]

Perl 6 grammars are a full citizen of the language on a level with subroutines and classes (loosely speaking, in Perl 6, rule:grammar::method:class, actually). They're effectively Turing-complete as a result, since Perl 6 is obviously Turing-complete.

Perl 5 "regexps", by contrast, are more of a specialized second language bolted onto the side (I use quotes since Perl 5 regexps are already marginally more powerful than "pure" regexps).

Re:Yes.

[sheetsda]

I use quotes since Perl 5 regexps are already marginally more powerful than "pure" regexps

Are you sure? I looked into this because my instinct told me you were right and I wanted to know how much more powerful but then I found this line in the Camel Book: "The Perl Engine uses a nondeterministic finite-state automaton (NFA) to find a match" (Programming Perl 2nd ed., page 60). If correct that would suggest that Perl regexps and "pure" automata regexps are equivalent.

Re:Yes.

[sleepingsquirrel]

Don't forget that perl patterns support recursion. Perl can match (at least some) context-free grammars...

#match context free grammar --[0{N}1{N}] (e.g. 01, 0011, 000111, etc.)
$cf = qr/01|0(??{$cf})1/;

$init="0011";
print "matched $init\n" if ($init=~m/^$cf$/)

...and (some) context-sensitive grammars...

#match context sensitive grammar --[0{N}1{N}2{N}] (012, 001122, 000111222,...)
$h=qr/01|0(??{$h})1/;
$t=qr/12|1( ??{$t})2/;
$cs=qr/(?=$h 2+$)(?=0+$t$)/x;

$init="001122";
print "matched $init\n" if ($init=~m/^$cf$/)

Re:Yes.

[5E-0W2]

It's a kludged up NFA: Take for instance the regex /(.*)foo\1/; You can't match that with a pure NFA.

Re:Yes.

[Anonymous Coward]

Exactly right. The backreferencing capabilities of Perl regex imply at least a PDA (push-down automaton).

I knew Larry Wall was a badass hacker, but I was under the impression that the N in NFA was for "Non-deterministic." If he can program a true NFA he's better than I can imagine ;) /pedant

Re:Yes.

[5E-0W2]

It's not all that hard to convert an NFA to a DFA. Writing an NFA engine is easy. Designing and writing Perl is hard.

Re:Yes.

[Anonymous Coward]

If you take any theory of computing class, you'll probably end up writing an NFA.

An anecdote and an opinion.

[pragma_x]

Actually, I for one tried to learn perl once.

I tried to absorb the syntax docs one afternoon, but it gave me nightmares. Literally. It was as if the C-programming-part of my brain was in conflict with the oddball operators and constructs presented in the perl language. Ever since I've been haunted by perverse unreadbility of it all. I liken the experence to attempting to think in brainfuck.

So by this I know for a fact that perl is Not My Thing(tm).

Now, a more objective reason as to why perl isn't generally a good language (but not completely bad) is evident in the very syntax of perl itself.

Useful code shouldn't be as inscrutable as its compiled counterpart since that defeats the whole point. Perl is a language, so it follows that it is a communication medium. By that it should be able to communicate something to a party outside just the author and the perl interpreter. It can accomplish this, but not without the reader having to go through the mental gyrations of what could be best called linguistic decompression. The language has this tendency to impose this extra step to yield the information communicated. Simply put: it gets in its own way.

Now, useful programs on the other hand follow a different set of criteria of course. I've used perl-coded stuff online all the time, and enjoy its reliability and speed.

I'll give credit to the fact that perl is compact, terse, to the point and has a reputation for string manipulation. It fills this niche rather well, and is a prime example of the being "the right tool for the right job".

IMO, "the right job" for perl is about 2% of all programming tasks out there. This is evident by the fact that even though perl was the prominent CGI language of the mid-nineties, it lost the overwhelming majority of that interest with alarming speed.

As for python, I'm sure it fills a niche too... whatever the hell it is.

Re:An anecdote and an opinion.

[adamruck]

I think you went about things the wrong way. Why would you ever look at the nitty gritty syntax rules first when trying to learn a language. First do some simple examples to get the general feel of the langauage. Then learn the nitty gritty stuff as required.

"IMO, "the right job" for perl is about 2% of all programming tasks out there."

76 percent of all statistics..... You get the point. You really dont have any valid point here, every language is designed to do certain things, and people will use it for those things and more. Trying to say whats the best langague out there is stupid. Trying to say what percent of projects perl should be used on is also stupid.

"It can accomplish this, but not without the reader having to go through the mental gyrations of what could be best called linguistic decompression."

Have you tried to program in a logical language lately? Have you tried to program in a functional language lately? Have you tried to program in anything but your standard imperical/oo language lately? There are tons of styles of languages, and each one required its own linguistic decompression. Which one feels more natural its a matter of opinion.

Re:An anecdote and an opinion.

[Anonymous Coward]

I don't quite understand where you're coming from, because Perl is one of the few languages that has allowed me to code in the way I think. For most languages, I have to think like the computer does, ie. momentarily turn my brain into an i386 CPU (or whatever arch it is). But not so with Perl. It's been a real joy to be able to write in an almost Enlish-like syntax, eg:
foreach $line (@data) {
chomp $line;
my ($x, $y, $z) = split(':', $line);
update_coords($x, $y, $z);
}

Re:An anecdote and an opinion.

[MrBoombasticfantasti]

I tried to absorb the syntax docs one afternoon, but it gave me nightmares. [...] Ever since I've been haunted by perverse unreadbility of it all.

When I started to learn Perl (coming from a C background) I had quite a different experience. I really felt I had "come home", or something like that. Sure, you can write obscure code, but that's no different from C. But you don't have to, it can be very clear.

I'll give credit to the fact that perl is compact, terse, to the point and has a reputation for string manipulation.

I just love it for the short development times, and the fact that you can really use it for just about any environment. Want to do CGI? Sure! Just GUI? No problem! Connect to about every database there is, that's no biggie.

And what about CPAN? That's a part of Perl too! You get all that ready-to-run code for just about any problem domain.

IMO, "the right job" for perl is about 2% of all programming tasks out there.

Maybe you are right, but somehow I get a lot of those 2% jobs... ;-)

Now you have to excuse me, I have some perl coding to do! ;-)

Re:An anecdote and an opinion.

[Anonymous Coward]

Perl is a language, so it follows that it is a communication medium. By that it should be able to communicate something to a party outside just the author and the perl interpreter.

Not so. I think of Perl as akin to the language lovers speak...to the mindless observer, there is no meaning...to the observant, one can never predict what will happen next...to the couple, it's pure passion.

Re:An anecdote and an opinion.

[runderwo]

Perl is a language, so it follows that it is a communication medium. By that it should be able to communicate something to a party outside just the author and the perl interpreter.

Perl source does communicate, with people who know Perl. That's like saying English is a useless language because it is constructed ad-hoc and because the complainer has never been bothered to learn it. The fact that some people find English difficult makes English no less useful to people who most easily express or comprehend ideas in it.

IMO, "the right job" for perl is about 2% of all programming tasks out there.

Nice statistic. Where's your breakdown of all programming tasks, and the reasoning for the other 98% why Perl is not the right tool for the job?

This is evident by the fact that even though perl was the prominent CGI language of the mid-nineties, it lost the overwhelming majority of that interest with alarming speed.

That has nothing to do with Perl the language, and everything to do with the shift towards languages which are designed to execute within a web server process without forking. mod_perl fills this hole, but as a general purpose language it is not as tightly integrated with a web server environment as something like PHP or ASP.

Re:An anecdote and an opinion.

[Darby]

Come on, Larry. Why are you posting AC?

Re:An anecdote and an opinion.

[Anonymous Coward]

It's been a real joy to be able to write in an almost Enlish-like syntax...

$Your @enlish [sic] (#must, B) \\!"!"!"@@quite something. @I 'can\\\'t' $imagine =1231-`how U (ever) &passed @high~school.

Re:An anecdote and an opinion.

[Anonymous Coward]

Man you just don't have a clue if you are saying that mod_perl is not "tightly" intergrated with Apache, I mean holy ignorance.

http://perl.apache.org/docs/2.0/user/handlers/in tr o.html

And just do a *little* reading. mod_perl is THE interface for the Apache API outside of the API itself. By comparison PHP is sitting on the sidlines, and I won't even talk about ASP..

Eric

Re:An anecdote and an opinion.

[TimToady]

Sorry, guess again. Larry never posts AC--he has a policy against anything remotely resembling astroturfing.

Re:An anecdote and an opinion.

[runderwo]

And just do a *little* reading

Why don't you chill out? I am a mod_perl developer. What I meant by that comment is that you don't find mod_perl hosting environments as readily as PHP or ASP hosting environments, because mod_perl isn't provided in turnkey server setups that web hosting farms set up for their co-los. The reason for that is because Perl isn't seen as a web development language like PHP or ASP so it's not on the list of prerequisites for a web-server-in-a-box. Wishful thinking won't change that, only more people using mod_perl will.

Re:An anecdote and an opinion.

[ChaosDiscord]

Actually, I for one tried to learn japanese once.

I tried to absorb an english-japanese dictionary one afternoon, but it gave me nightmares. Literally. It was as if the english-reading-part of my brain was in conflict with the oddball characters and symbols presented in the japanese language. Ever since I've been haunted by perverse unreadbility of it all. I liken the experence to attempting to think in russian.

So by this I know for a fact that japanese is Not My Thing(tm).

.

Learning Perl is like learning a living human language. It's big and daunting, but you can relatively quickly learn a powerful and useful subset. As you continune to learn more and more you'll discover power and subtle shades of meaning. You'll feel better able to express yourself, to implement the solution in terms of the problem instead of the programming language. Instead of seeing a nearly infinite amount of work to learn the entire language, you'll see a nearly infinite amount of possibilities to explore as necessary. You'll take on a new problem domain and start wishing that Perl had just the right tool for the problem. Usually Perl does. It's rare that I finish a task and say to myself, "Wow, that was way easier than I thought." When I do, it's usually thanks to Perl.

Ultimately Perl is a big messy language because the world is a big messy place with big messy problems. Living human languages like english are big message languages for exactly the same reason.

Don't try to learn Perl by diving into the syntax docs, especially the reference ones. That's like trying to learn C++ by reading the STL reference.

Re:Ok, start the flame wars under this post

[owlstead]

Those of us that use Perl as more than just system duct-tape know it's a programming language.

Those of you that use Perl for more than just system duct-tape should have their head examined.

Note title.

You asked for it!

[ArthurDent]

Inconceivable!

Re:Ok, start the flame wars under this post

[Stradenko]

Erm...yes, of course...it's been awhile.

Re:Ok, start the flame wars under this post

[mr_z_beeblebrox]

Get over it and start focusing on what the software does, not how to classify/name it.

I disagree with this comment classifying and naming software makes it sound alive. I think we should describe or label it.

Re:amateur!

[VAXGeek]

What is a floppy disk?

Perl perspective

[Anonymous Coward]

I find that reaction to Perl by people familiar with highly structured languages is common. I think this is because Perl has things like weak typing and overly flexible syntax, things that make experienced programmers vomit in their own mouths. But what's great about Perl is that you CAN have strict grammar, and you CAN have strong typing, if you desire. It's just not required.

This makes Perl very strong as a teaching tool for beginner programmers. They can start out writing loose, messy code that gets the job done, and slowly work towards stronger, more structured language. People that wouldn't have the logical dicipline to jump directly into C++ can use Perl to learn logical programming one concept at a time, and eventually be ready to grasp required C++ concepts like objects. But you'll find that people raised on Perl, even if they primarily program with C++ or Java, always come back to Perl for the quick scripting or text-processing tasks.

I can't remember all that!

[warrax_666]

... so when I need a webserver, I just

$ cat /dev/urandom | perl

It usually works in 3 tries or less.

Re:I can't remember all that!

[gipsy boy]

Chances are bigger you'll release a worm that will destroy every windows machine on the planet.

Re:Ok, start the flame wars under this post

[MrBoombasticfantasti]

Those of you that don't grok Perl should have their posting privileges revoked. At least for this thread! ;-)

correction

[sleepingsquirrel]

oops, that last line should of course read...

print "matched $init\n" if ($init=~m/^$cs$/)

Re:Ok, start the flame wars under this post

[TimToady]

If you assume that languages can't scale both up and down simultaneously, please don't try to design any computer languages near me. Thank you.

Re:It is about time to change the name from

[TimToady]

Nah, you haven't figured out yet when the tail should wag the dog. In Perl culture, if you're gonna go and rename something because it's inaccurate or unwieldy, you have to have the hubris to come up with a new name that is shorter and handier. That's how "associative arrays" turned into "hashes" in Perl 5. And if you were up on Perl 6, you'd already know that "regular expressions" are turning into "rules" (though people are still allowed to say "regex", of course). While Perl likes technological hacks, Perl loves cultural hacks.

No, I think it fixed the colours here. Behold!

[Anonymous Coward]

http://shit.slashdot.org/article.pl?sid=04/11/08/1 511201

Let me guess.... the usual Perl backlash

[Anonymous Coward]

I get sick of the 'standard' backlash every time a Perl article is posted. Why do people have such a problem with Perl? It's an excellent, high-level general purpose programming language with a huge range of extension modules available. I have personally used Perl for many projects, as do TicketMaster, ValueClick, Morgan Stanley and Ryanair and I've also learnt a lot about software engineering and computing through Perl.

Yes, it does include a lot of symbols, but there is payback to learning them, and really most programs won't use much beyond $ % # () [] {}. Unlike some languages, Perl is not what I would describe as a 'bondage' language. If you want to program sloppy, you can program sloppy. That's fine by Perl. And this generousity is what gives Perl its bad reputation. This is funny since I and most knowledgeable Perl programmers can write perfectly clear and maintainable code. The way we do this is no secret--it's just by commenting appropriately, using meaningful identifier names and following the Perl style guidelines.

People can mock Perl all they like, but it is still a widely used powerful programming language and I am more productive in it than any other language. As a parting comment, a Cisco employee once told me (off the record of course!) that "Cisco would fall apart without Perl".

Re:Let me guess.... the usual Perl backlash

[ProfKyne]

Why do people have such a problem with Perl? It's an excellent, high-level general purpose programming language with a huge range of extension modules available. I have personally used Perl for many projects, as do TicketMaster, ValueClick, Morgan Stanley and Ryanair

How compelling, you just named some of Slashdot's favorite companies.

Re:Let me guess.... the usual Perl backlash

[mpmansell]

Personally I have a love/hate relationship with Perl.

The purist Computer Scientist in me loathes it. It is ugly, dangerous and has a weird botched together syntax.

Just as I self rightously convince myself of these self evident facts, some real cool trick saves the day and the wild inner hacker in me starts telling the CS part to stop being such a bore :)

Perl is a great language, though like all powerful tools it can be dangerous if misused. It is sometimes ugly, and just as often beautiful.

All that said, given the general trend within /. these days, I do suspect that most denigrators do so because they cannot handle all the squiggles :) God help them if they ever encountered APL :D

Re:Let me guess.... the usual Perl backlash

[Anonymous Coward]

I get sick of the 'standard' backlash every time a Perl article is posted. Why do people have such a problem with Perl? It's an excellent, high-level general purpose programming language with a huge range of extension modules available. I have personally used Perl for many projects, as do TicketMaster, ValueClick, Morgan Stanley and Ryanair and I've also learnt a lot about software engineering and computing through Perl.

Of course you are right. But let's not forget that there are also lots of completely useless Perl projects as well.

EBNF's BNF's

[vivin]

The grammar and rule syntaxes are very reminiscent of BNF's and EBNF's although maybe not as descriptive.

so many for so long

[trulymadlydeeply]

PERL is a great language. Ugly yes, but once you get used to it there's is no going back to C/C++ or JAVA, at least in a mostly tool-less environment like UNIX. For many classes of programs, the productivity you get from PERL is an order of magnitude greater than in C/C++ (some would argue that I just need to learn the STL classes....). I think most of this is because PERL is interpreted....the code, debug, compile cycle is significantly shortened. You also never wonder what version of the code you are running.

PERL 6, however, seems to be dead. I've been following its progress for a couple years now and it is going almost nowhere. The decision to move to a bytecode interpreter looks like a huge mistake. Most people are fine without the bytecode interpreter and it has split off dev resources from the issues that would help your everyday user -- "syntactic sugar". For instance, PERL as it is doesn't have named function parameters, each function is just passed an array of parameters (unlike in pretty much every other language I know--C, LISP, Java, etc)). Adding this functionality would presumably be simple to do, without implementing a bytecode interpreter. OO support is also lousy in the current PERL.

The feature request framework was also lacking. Everything went up to Larry Wall, who decided things basically as God. I saw at least one simple and powerul thing dismissed out of hand -- a built in loop counter. So often in while loops it makes sense to have a counter of the iteration #...this requires at most a single addition for each iteration but was skipped.

The stated goal of PERL6 was improving XS, but this doesn't require a bytecode interpreter either.

Of course, this is all running off volunteer labor so I shouldn't complain too much!

Re:so many for so long

[Anonymous Coward]

And once you get used to RUBY, you'll never go BACK to PERL. You'll ALSO stop spelling random words that aren't acronyms all in caps, like Perl, Ruby, Java and Unix.

Re:so many for so long

[SammyTheSnake]

For instance, PERL as it is doesn't have named function parameters, each function is just passed an array of parameters (unlike in pretty much every other language I know--C, LISP, Java, etc)).

Then send a hash into the array (apologies, I've not done any Perl recently so this is likely to be wrong in details, but the essense is correct):
sub blah(@) { print $_{"parameter1"} }

Re:so many for so long

[SammyTheSnake]

For instance, PERL as it is doesn't have named function parameters, each function is just passed an array of parameters (unlike in pretty much every other language I know--C, LISP, Java, etc)).

Then send a hash into the array (apologies, I've not done any Perl recently so this is likely to be wrong in details, but the essense is correct):

sub blah(@) {
print $_{"parameter1"}
print $_{"parameter2"}
}

blah(parameter1 => "cheese", parameter2 => "on toast")

Cheers & God bless

Sam "SammyTheSnake" Penny

Re:so many for so long

[TwistedSquare]

PERL is a great language. Ugly yes, but once you get used to it there's is no going back to C/C++ or JAVA, at least in a mostly tool-less environment like UNIX. For many classes of programs, the productivity you get from PERL is an order of magnitude greater than in C/C++ (some would argue that I just need to learn the STL classes....).

Actually, I always find that Perl has a tipping point. Usually I start writing a text processing program in Perl, and somewhere around a few hundred lines I realise that using Perl has become untenable and I have to revert to another language (C++ in my case). Perl is just too sloppy and too hard to read to be used for large programs in my opinion.

Re:so many for so long

[Anonymous Coward]

Where can I start? This post contains so much misinformation that it's hard to tell.

PERL 6, however, seems to be dead. I've been following its progress for a couple years now and it is going almost nowhere.

The perl mailing lists seem to be going strong.

The decision to move to a bytecode interpreter looks like a huge mistake. Most people are fine without the bytecode interpreter

The Parrot FAQ. Most people were fine with machine code, then assembler, then C. Should we stop trying to improve things?

and it has split off dev resources from the issues that would help your everyday user -- "syntactic sugar".

People who want to work on Parrot, work on Parrot. People who want to work on the compiler, work on the compiler. This is an Open Source project, limited by the people who want to be involved, not a proprietary project with strictly limited resources.

OO support is also lousy in the current PERL.

Yet another reason for the rewrite.

The feature request framework was also lacking.

Are you serious? The entire world was solicited for suggestions, which were then discussed openly before being passed to Larry (see next point). What was lacking?

Everything went up to Larry Wall, who decided things basically as God.

When it comes to Perl, Larry Wall is God (although I'm not sure he'd thank me for the comparison). Larry has kept overall control of Perl in a similar way to that in which Linus Torvalds has kept overall control of Linux, by being an excellent leader.
If you disagree strongly with Larry's decisions, feel free to start your own language project.

I saw at least one simple and powerul thing dismissed out of hand -- a built in loop counter.

Simple, yes, but powerful? I don't think so.
Here's what Larry said

The stated goal of PERL6 was improving XS, but this doesn't require a bytecode interpreter either.

Wrong. See The Parrot FAQ, again. Search for "PARROT AND PERL".

Of course, this is all running off volunteer labor so I shouldn't complain too much!

Well that's one thing you're right about anyway.
Feel free to dislike Perl, but please inform yourself before ranting, or you may end up looking like a fool.
-- Jim Gillespie, posting as AC because I've already wasted enough time replying to this drivel.

Re:Ok, start the flame wars under this post

[jonadab]

I prefer the which-time-and-date-module-is-best argument. I like DateTime.

Heh.

[warrax_666]

Personally, I find the < form uglier -- I'm not sure why, but I guess it has something to do with the pipeline

$ cat bla | prog1 | prog2 | ...

"flowing" purely from left-to-right, as opposed to

$ prog1 < bla | prog2 | ...

where input flows from right-to-left then right again.

Also, the former is marginally easier to modify if you need another stage of processing before prog1.

To each his own, I guess. :)

Re:Heh.

[GGardner]

as opposed to
$ prog1 < bla | prog2 | ...

where input flows from right-to-left then right again.

There's no law that requires the < to be at the end of the command, you can always type:

$ < bla prog1 | prog2 | ...

Re:Heh.

[TheLink]

I still stick to using cat and | because I'm afraid that one day I may type > instead of < and on some systems that overwrites the file... After all they are next to each other on my keyboard.

Re:Ok, start the flame wars under this post

[0racle]

I believe that singles were often 45's.
/Too young to remember.

Re:It is about time to change the name from

[brpr]

Regular Expressions to Context Sensitive (at least) Parsing. I'm not a big Perl Geek, but I use it on a daily basis.

No, the grammars this system parses are a subset of the context-free grammars (if we exclude any context-sensitive behaviour created at a higher level using actions).

You'll love this quote then ;-)

[Kristoffer Lunden]

The purist Computer Scientist in me loathes it.

"Much as I hate to say it, the Computer Science view of language design has gotten too inbred in recent years. The Computer Scientists should pay more attention to the Linguists, who have a much better handle on how people prefer to communicate."

--Larry Wall

Re:You'll love this quote then ;-)

[mpmansell]

Nice quote and so true.

I'm all about Perl

[HenryKoren]

I have programmed proficiently in many languages:

Cold Fusion, Visual Basic, Matlab, C, C++, Javascript, Java, C#, XSL, SQL, and PHP.

But now that I'm stuck on mod_perl2, I find myself choosing Perl again and again for any purpose it might fill. And it does the job damn well. I can endure the other languages my work requires... They get the job done. But every time I go back to Perl its like a breath of fresh air. It really is a wonderful language. CPAN and cross-platform really seals the deal. Even the simple OOP system in Perl 5 is a thing of beauty, despite being a hack. The syntax grows on you too... If I could program Perl exclusively I would do it in a heart beat.

Nobody can disrespect Perl out of ignorance and call themselves a software engineer.

Re:OMG!

[imroy]

Since you claim to have written both codebases, perhaps your difficulties say more about your ability to program in Perl (or any language) than about Perl itself. I've written a lot of Perl code and I couldn't think of (re)writting in a language where all variables are global (no namespaces) or other poorly thought-out "features".

Re:It is about time to change the name from

[musterion]

I'll have to dig out my copy of Aho and Ullman and brush up. I've not taken a good look at the "strength" of the new matcher.

Re:It is about time to change the name from

[musterion]

I'm not really advocating a change of name from regex, only to recognize how much more powerful the matching has become.

strong typing in Perl?

[rp]

I have really thought on how to get strong typing in Perl 5, and i think it's impossible. With strong typing I mean full compile-time verification that wherever a variable (or constant, parameter, array slice, any piece of syntax that denotes a value) is asserted to be of a certain type or in a certain class, it is 100% certain that all values this variable can possibly assume will indeed be of that type / in that class.

For arbitrary Perl 5 code this is obvious, but I don't want it for arbitrary code: I want it for my own Perl code. I want to be able to provide type/class definitions for all the arguments and return values of all subroutines that appear in a particular piece of Perl source code (both my own and calls to subs defined elsewhere) and have the compiler verify: assuming that all these foreign subroutines satisfy the typing specified here, are my own subroutines 100% guaranteed to satisfy it as well?

There doesn't seem to be a way to do this with Perl. Perhaps there is something in the Devel::* namespace now which is suitable? It's been a while since I tried this (and gave up on programming larger projects in Perl for that reason).

Dangerous?

[TheLink]

How's perl dangerous?

In my experience (as a IT security guy) C and PHP are more dangerous than perl.

C - "runs arbitrary code of the attacker's choice" given _common_ stupid programmer mistakes.

PHP - developers fond of features that encourage bad/insecure ways of doing things - e.g. magic quotes, global track vars. Take away such popular PHPisms and PHP starts to look like perl ;).

Re:Dangerous?

[mpmansell]

I also am in security, as well as more general development and I never said they weren't dangerous, nor said they were less dangerous than Perl.

I doubt anyone would say playing Russian roulette wasn't dangerous, yet using a fully loaded gun is definately more dangerous.

The danger in Perl lies in the fact that its lack of strong typing and somewhat promiscuous behaviour when autoloading is used can lead to serious problems when not carefully audited or managed. There are also other possible problems and Perl is not really suited for writing large systems in, although many people do insist on doing so.

Remember, 'dangerous' doesn't only mean security. Up until a few years ago, for most computer systems it meant damaging data, giving wrong results or just plain blowing up. This definition hasn't changed, despite people now more commonly using it to mean internet security.

Re:Ok, start the flame wars under this post

[TheLink]

"I disagree with this comment classifying and naming software makes it sound alive. I think we should describe or label it."

Sound alive? How about "toe tagging" it then?