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."

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

[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

[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

[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

[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

[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

[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

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.

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: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 \/(.*) / })'

Comment removed

[account_deleted]

Comment removed based on user account deletion

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

[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

[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

[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.

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. :)

You asked for it!

[ArthurDent]

Inconceivable!

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

[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 [perl.org] 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

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 [poniecode.org] 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.

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?

[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?

[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?

[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]

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?

[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?

[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?

[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 l

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?

[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 i

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.

aw hell

[The Unabageler]

I'm going to have to rewrite my sig.

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 pseudoco

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 :-)...)

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.

Adoption

[base_chakra]

Years ago, Eric Raymond wrote [python.org]:

"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

[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 [cpan.org] 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

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

[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 a

Re:Adoption

[smittyoneeach]

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

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.

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 arbitrar

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/^

correction

[sleepingsquirrel]

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

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

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 [ozonehouse.com] , 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 [ozonehouse.com]

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 [cpan.org]. I have personally used Perl for many projects, as do TicketMaster [ticketmaster.com], ValueClick [valueclick.com], Morgan Stanley [morganstanley.com] and Ryanair [ryanair.com] 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 [java.com], 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 [cpan.org].

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

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

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: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: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!

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: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!

Re:Ok, start the flame wars under this post

[Zorilla]

Of course you meant 78 RPM, right?

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

[0racle]

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

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

[Matthew Weigel]

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

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: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.

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: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

Re:Runs great under Gentoo

[Zorilla]

Damn, I knew I forgot one on that last post I made. [slashdot.org]

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 :)

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 [c2.com].

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 gene

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

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 strin

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.

[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 t

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 )

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
Rub y
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...

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"

Re:Perl6 -- an interesting curiosity

[TimToady]

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

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.