Exegesis 6 (Perl 6 Subroutines) Released

chromatic writes "Perl.com has just published Damian Conway's Exegesis 6 which gives practical examples demonstrating how to use the new subroutine and method semantics in Perl 6. This is the companion to Larry Wall's Apocalypse 6 which discussed the changes planned for subroutines in Perl 6."

There's a long way to go

[Dancin_Santa]

I mean, whitespace hasn't even been made meaningful yet.

Where's $\space and $\tab ?

Re:There's a long way to go

[TedCheshireAcad]

Oh lord, variable names/function calls with whitespace.

That would truly make perl executable line noise.

Re:There's a long way to go

[luugi]

Check this out. :)

New Whitespace-Only Programming Language [slashdot.org]

Keywords

[Gortbusters.org]

The one thing that I always found unpleasant when moving between languages was the keywords... so, I picked up a C book, migrated to C++, then Java, picked up PHP along the way. Everything was fairly similar with keywords and syntax, and then perl threw a monkey wrench into the mix. I've never looked at python, are there similarities there or are the perl gurus guiding us through their path of enlightenment?

Re:Keywords

[ajs]

Perl has keywords picked up from C (for, if, while, int, printf, etc.); BASIC (substr); Modula (module); CPP (defined); and many other sources. It's very much a post-modern language in the sense that it seeks to deconstruct all other languages and re-build itself in their images without actually being just a collage of their parts.

HOWEVER, that being said Perl has a huge advantage over the keyword restrictions of most languages. I'll show you a sample of some code, and you tell me if you can see what the advantage is:

$time = time();
$localtime = localtime();
print "UNIX timestamp $time is $localtime\n";

The same goes (to a slightly lesser extent, since you don't *have* to use the prefix-sigle &) for subroutines and all of the other miscelaneous Perl data types that can be named (obviously those that cannot be named like stashes never conflict with a keyword).

Re:Keywords

[smallpaul]

I've found other languages have the same advantage. vtime = time() vlocaltime = localtime() print "UNIX timestamp " + time + " is " + localtime This isn't any language's syntax in particular...but you get the idea.

Re:Keywords

[ajs]

You gave the example:

vtime = time()

Actually, that's a great example! Let's say you write that in C. Then, a year later ANSI C 0x is published and lo, "vtime" is now a keyword!

In Perl, you are guaranteed that your variables will never conflict with keywords. Not ever. Not even if you try.

Re:Keywords

[smallpaul]

There is absolutely no chance that either time or vtime would be keywords in any version of C. C has 32 keywords and they grow in number at an incredibly slow rate. Yes, the problem of new keywords interfering with existing code is real but it is tiny. Perl's solution is, in my opinion, like taking a baseball bat to a cockroach.

Re:Keywords

[ajs]

There is absolutely no chance that either time or vtime would be keywords in any version of C

You make this assertion (which I can't understand the origin of), but then say:

C has 32 keywords and they grow in number at an incredibly slow rate. Yes, the problem of new keywords interfering with existing code is real but it is tiny

Um... so, it's not "absolutely no chance", but "tiny".

You're sort of thinking about this backwards. The question is not "when a new keyword is added, will my variable name be on

Re:Keywords

[Simon]

C has 32 keywords and they grow in number at an incredibly slow rate. Yes, the problem of new keywords interfering with existing code is real but it is tiny

Um... so, it's not "absolutely no chance", but "tiny".

A couple of points:

* The chance really is tiny. Keywords are rarely added, and when they are they are chosen carefully.

* Code refactoring tools exist for the case when a clash occurs. Use them.

* Having manditory prefixes for all variables is a terrible price to pay in terms of readability

Re:Keywords

[ajs]

Pulling data out of complex structures (think list of hash of foobar) is a nightmare in Perl thanks to these prefixes.

Oh so?

$complex{data}{structure}{of}[$n]{hashes}[2]{array s}{and}{an}->object(); = "Stuff";

That does not seem very nighmarish to me. What's more, manipulating complex data on the fly is trivial in Perl:

$struct = [1, 2, 3, { a => [5, 6, 7], b => [8, 9, 10]}]

which would be an array of 4 elements, of which the fifth element is a hash of two elements, the values of which are them

Re:Keywords

[ajs]

Speak in favor of Fortran, please do. It was a language that was hobbled by some of the physical limitations of the day, but still it was a wonderful language.

COBOL was a product of its environment, and could never have been a good language. If it had been, that would have defeated the point :-(

But, no. C has become SO widely used in the world that it has eclipsed even COBOL at this point. Just your avergage Open Source distribution has more C code than what was produced at 90% of the banks out there (of

Re:Keywords

[ajs]

There is no advantage

No, I pointed out a few already, and there are others. You simply happen to disagree. That's fine too. Perl is about accomodating disagreement in a single language, and that's hard to do with a limited keyword set.

You're carrying type-information around everywhere you go, because you think it allows you to add keywords

I've pointed out elsewhere that type information and variable glyphs are different. They do have an association to type, but it's a loose one.

For example:

$x = 1;
$y

Re:Keywords

[Q2Serpent]

When they say "keywords", I'm sure they meant "functions in the global namespace".

Re:Keywords

[los furtive]

Perl's solution is, in my opinion, like taking a baseball bat to a cockroach.

Sounds like a good solution to me!

Re:Keywords

[Billy the Mountain]

What's wrong whacking a cockroach with a baseball bat? Here in Houston, carrying a baseball bat as protection against cockroaches is common sense, plain and simple.

BTM

Re:Keywords

[jbolden]

Nice try but no. See apocolypse 1, you need a keyword to be in Perl 6 syntax otherwise it falls back to Perl 5 for the entire file. So absolutely nothing happens.

Re:Keywords

[ajs]

No, you're mis-reading A1.

You can define syntax on the fly. What *will* happen for backward-compatibility is that certain Perl 5 features will be searched for, and those features will initiate a Perl 5 mode. For libraries this is easy ("package foo" is the first thing in every Perl 5 module), but in general-purpose code you have to get a little more context-sensitive.

However, there will of coruse be a command-line flag for "just do Perl 6", so you might write

#!/usr/bin/perl -6
use syntax::bash;
if [ -e /et

Re:Keywords

[ajs]

You're comparing apples and oranges.

This has been an advantage of Perl since it's very first release.

What you're talking about (compatiblity betwen 5 and 6) is neither mitigated by, nor a result of that feature.

Re:Keywords

[RevAaron]

Heh- perl, the postmodern language... A common excuse for its appearance of being a rubbishy collage.

"Oh no good sir- what you see before you isn't a child's mess, it is in fact ART! High Art! Postmodern, abstract! If you can't understand it, well, you must be some sort of stunted freak with no appreciation for anything of intelligence in life."

That said, I enjoy perl on occasion, to that I'll admit. However, I have a big number of annoyances with Perl 5. Part of it is with Wall's assertions about perl

Re:Keywords

[crucini]

Actually, you could make your point more strongly by omitting the parentheses after the function calls:

$time = time;

etc.
And doesn't that line kind of warrant the comment:

#Dread at control, mon, an' I an' I come a Freeside when I an' I come.

Re:Keywords

[jandrese]

I thought the point was that most of the time we don't care if it is an int or a float, we just want it to work correctly. Obviously if you try to do something like (note, the . operator concatenates strings):
$foo = "bar";
$foo++;
Perl is still going to stop you, but when you do:
$foo = 123;
$bar = "Foo is $foo";
Perl does the right thing and automatically stringifies the number for you. You don't have to worry about converting your numbers to strings and back. You can even do things like:
$foo = 12

Re:Keywords

[msuzio]

Actually, the following code (in Perl 5):

$foo = "bar";
$foo++;

Result in $foo holding the string "bas" right now ;-). I haven't puzzled out the Perl 6 stuff enough to know what would happen then (probably a compile time error in assigning "bar" to $foo if $foo is declared as holding only numerical types).

Re:Keywords

[ajs]

In Perl 6, it would depend on what type $foo was. If it was an integer, then your initial assignment would set it to zero, and then the second statement would make it one.

If you never assign it a type, then it defaults to a fully-functional scalar and behaves much as a Perl 5 scalar would.

Re:Keywords

[Waffle Iron]

Can you see the advantage here?

int a=1;
WriteLine("a is type {0} and has value {1}", a.GetType().ToString(), a.ToString());

What's the big deal about that? In Python, for example, you can do the same thing with much less fuss:

a = 1
print 'a is type %s and has value %s' % (type(a), a)

or with your positional parameters:

a = 1
print 'a is type %(1)s and has value %(2)s' % { '1': type(a), '2': a }

The same string conversions happen. 'a' is still an integer, and the language knows it. You just don't hav

Re:Keywords

[moonbender]

But the Python version contains lots of special characters and special syntax, especially the positional one ("%(1)s", wow!), which make it hard to read for anyone not accustomed to the printf format string. I think the version of the original poster is very convenient to read and understand, even though I am more accustomed to the style of your code since I know some Python and a lot PHP.

Obviously, this is a matter of taste and familiarization, though.

...and in Ruby

[MenTaLguY]

a = 1
print "a is type #{a.type} and has value #{a}"

(in case you're wondering, you can put arbitrarily complex expressions inside those curly brackets)

Re:...and in Ruby

[MenTaLguY]

That's a good point, actually. I don't think so, currently. I'm not even sure that's desirable, since that'd mean having to put chunks of code in the message file.

In cases involving a message file, you'd probably end up having to use Ruby's sprintf (which is no better than C's).

Thanks for pointing that out; I've been digging myself in here doing that type of string interpolation in some fairly inappropriate places if I wanted to care about i10n later...

Re:Keywords

[ajs]

Having a weakly typed language is not an advantage

You're confusing variable glyphs with typing. While variable glyphs in Perl do indicate something about the typing, they are not type identifiers.

I was pointing out the advantages of glyphs, not types.

Apparently, script programmers cant deal with specifying that something is an 'int' or 'float' or whatever

Script is a misused word here, since the term litterally means a collection of commands as a user would have typed them, and while you can write Perl code that looks kind of like that, it's certainly not the way Perl is used). Shell programs aren't even always scripts (just look at your average configure program). Don't contribute to watering down the word, especially if you're just doing so to make the "what makes us real programmers special" weak assertion.

Ok, that said, Perl does offer typing, but only when you really need it. Since strong typing isn't needed in perl by default (Perl 5 and under have no real compilation mechanism, so the performance gains would be minimal), all you really need is to type *data* not *variables*.

You can type data using any number of tools in Perl including pack, unpack, sprintf and vec.

In Perl 6, there will be a just in time compiler, and eventually a stand-alone binary compiler. This introduces the need to access system types in a more rigorous way, and Perl 6 has typing features such as you would find in any other language. Of course, $x = $y will still work regardless of types (though it could cause a compile or run-time error if they are excplicitly incompatible, but that's not going to happen unless you really mean for it to). .NET has really solved this problem, but making it strongly typed, but every typed is derived from 'object', which has a pure virtual 'ToString' which allows you to easily convert anything to a string suitable for printing. Can you see the advantage here?

That's the approach of about 5-10 DOZEN languages (literally) over the last 10-20 years. Let's not credit C# with the "innovation" of objects as the only first-class data types (I assume you mean C#, since .Net isn't actually a language, but a Microsoft product that encompasses the .Net runtime, which in turn encompases C#... kind of like calling Java JSP).

Perl 6 is going down the same route as did Python (long before C#).

Perl 5 has fairly primative roots, and given those roots its typing system made sense at the time. Perl 5 does also have a universal base-class for all objects, but not all types are objects in Perl 5. They will be in Perl 6.

Re:Keywords

[chromatic]

In Perl 6, there will be a just in time compiler, and eventually a stand-alone binary compiler.

Parrot has both today. (Okay, it just picked up the standalone binary compiler a couple of days ago.)

Re:Keywords

[ajs]

Anyway, it looks like *somebody* is getting defensive about being a script programmer

Not at all. I'm simply not.

When I spend most of my day working on libraries that are used by a suite of tools, each of which is as modular and re-usable as possible, I find it hard to refer to that as "script programming".

The gulf between those two jobs is about as wide as the gulf between Web Master and C# programmer.

I meant any language that .NET supports... VB.NET, C#, J#, etc.

Then you are incorrect, since .Net a

Re:Keywords

[ajs]

Anyway, you are totally wrong, every object in C# is derived from 'object'. Same as VB.NET. Same as Managed C++

I think you're talking about the object model of the .Net runtime, and that's fine, but .Net runtime is not a language, and its objects are not language primatives.

To give an example of C++, and then discuss what is effectively an RPC-based library's object model is way, way beyond the scope of the original conversation.

Like I said before, this is not a unique feature to one, or even a dozen to

bleh - *cough*moron*cough*

[Ender Ryan]

j/k :P

You don't know what you're talking about. Weakly typed languages have nothing to do with script programmers not being able to specify types(what is that supposed to mean?), it is purely a convenience, and helps reduce the number of variables and lines of code required to get a job done. Really, it does.

Someone else already posted an example.

int a=1; WriteLine("a is type {0} and has value {1}", a.GetType().ToString(), a.ToString());

The beauty of it is when you translate the text. The translat

Re:Keywords

[bnenning]

.NET has really solved this problem, but making it strongly typed, but every typed is derived from 'object', which has a pure virtual 'ToString' which allows you to easily convert anything to a string suitable for printing.

Java solved that problem many years ago, and Smalltalk solved it many years before that.

Re:Keywords

[TheFlyingGoat]

I've found that Perl syntax is more like C++ than Java is. Similarily, if you know PHP, you basically know Perl.

I learned Perl quite a few years ago, and use it on a daily basis. When I needed to use PHP for some large projects, I was able to learn it on-the-fly in under a week. Sure there's a few PHP functions I still don't know, but I'll probably never use them.

The way I see the development of Perl is that they're making it backward-compatible enough for people to make an easy transition, while havin

For those who don't know....

[ajs]

The way Perl 6 is being developed is thus:

• Everyone in the world had a chance to submit RFCs [perl.org]
• Larry is taking each section of the 3rd edition Programming Perl and turning it into a white-paper on the way Perl 6 will work, using the RFCs that touch on that section of Perl as a sort of shopping list, and accepting, modifying or rejecting them as needed. These are called the Apocalypses [perl.org].
• After an Apocolypse is out, Damian starts working on some real-world examples to make it all more concrete. These are called the Exegeses [perl.org]. Sometimes these also have examples of syntax and semantics that have been worked out via the mailing lists [perl.org]
• Eventually, this will lead to the Design Documents [perl.org]

Hope that helps clear this up for those who aren't sure what's going on when they see a new Apocolypse or Exegesis come forth.

Re:For those who don't know....

[CoolVibe]

Thank you thank you thank you thank you thank you. No, really. Thanks. That was the _one_ missing piece of insight that I was missing.

Well, it seems like I have to re-learn lots of stuff about perl. Although I somewhat like the new syntax. Finally, perl has call by value and call by reference. Now, when will we get _real_ pointers? *ducks away to dodge the pelting of rocks in my direction* ;)

Re:For those who don't know....

[absolut_kurant]

Thank God Damian isn't working on the Apocalypses...

Perl 6 \not\in Perl ?

[Vagary]

Is it just me, or is Perl 6 so different from Perl 5 that they probably should have given it another name? Especially since Perl 5 will continue to be updated after Perl 6 becomes stable?

Perl 6 has so little backwards compatibility, it'd probably be better if they just through out all the legacy syntax and started from scratch with a new language. Not that Perl ever was elegant, but I'm starting to worry that things are getting out of hand...

Re:Perl 6 \not\in Perl ?

[chromatic]

It's not just you, but about 80% of the syntax stays the same. Much of the rest requires a few parser rule overrides. See ... And Now For Something Completely Similar [samag.com], also by Damian.

Backwards compatibility is a huge concern. That's why Ponie [poniecode.org] exists and why Dan's so careful about supporting Perl 5 semantics on Parrot. (As well, I expect 80% of the core Perl 5 tests will port to Perl 6 with surprisingly little work.)

Re:Perl 6 \not\in Perl ?

[chromatic]

Would that everyone were so blind!

• I have had code in Parrot for years. I have commit access.
• I've taken hundreds of kilobytes of notes during Perl 6 design meetings.
• I read the Apocalypses, Synopses, and Exegeses as they're being written and revised, weeks and months before they're released.
• I helped quadruple the number of tests in the core test suite between Perl 5.6 and Perl 5.8.

I think I have a pretty good sense of Perl 5, Perl 6, and Parrot.

I also know how many Perl Foundation dollars have been spent to get Parrot where it is today. It might be enough to hire one of the top .NET folks for most of a year. For the money, Parrot's a bargain.

Re:Perl 6 \not\in Perl ?

[chromatic]

Parrot's been around two years, not three. The oldest Perl 6 code I can find running on Parrot [perl.org] goes back one year.

Perl 6 isn't completely implemented on Parrot because Perl 6 isn't completely designed yet. Perl 5 isn't completely implemented on Parrot because no one's had the right combination of time, talent, and funding to implement it yet. The same goes for any combination of Perl and Parrot you care to mention. As of last month or so, there had been somewhere around five man years of Perl 6 and Pa

Re:Perl 6 \not\in Perl ?

[Ed Avis]

I don't think it is any more different from Perl 5 than Perl 5 is from Perl 4. Huge amounts of extra stuff (most importantly objects and nested data structures) were added from 4 to 5, together with quite a few syntax changes.

However, backwards compatibility will be more of a gap, because perl 5 is pretty much source-compatible with perl 4, but it doesn't seem that 5 -> 6 will be the same. (No, having a separate interpreter specially built to run older scripts doesn't mean source-compatible in this se

Re:For those who don't know....

[n1vux]

In addition to the Apocalypses and Exegeses, Damian and Allison have produced two

• Synopses [perl.org], which are shorter and quicker to market.

The names are a running gag on church-latin, that interconnects Larry's linguisticism, Damian's eclecticism, and the monastic themery of the Perl Monks' alternate retroynm for .PM. Larry's Apocalypses are not apocalyptic in the common figurative sense (although the neo-Luddites who think the only improvement on Perl5 is PHP or Python may think so), but are the Revelations of the gur, which is the original sense of the word, before it came to be used to refer to the particularly apocalyptic content of St.John's Revelations also called Apocalypse in the latin. The churchly Exegeses are non-canonical explanations of the deeper meanings of the canonical texts. And of course, synopses are shorter summaries, like Cliff Notes (TM) or Master-Plots (TM), and were originally applied to religious writings of course.

require sig 1.3;

Re:For those who don't know....

[Feztaa]

* Eventually, this will lead to the Design Documents

That's all well and good, but how far into the actual development have they gotten? I mean, it's kind of cool that they're saying "Perl 6 will do this, that, and the other thing", but how much actual work have they done?

All this time, I've sort of thought that Perl 6 development was well under way and that they were nearing completion, but your post makes it sound like Perl 6 is nothing but talk right now.

Re:For those who don't know....

[ajs]

And everyone will then use Python

Normally, I would not reply to a troll, but this one allows me to bring up an interesting point for those polarists that think Perl and Python are somehow diametrically opposed.

While they certainly have different approaches to language design, Parrot (the Perl 6 back-end) will have front-ends for many languages. One of them will, in fact, be Python.

So, will everyone "then use Python", well perhaps, but if they do, they'll be using Perl 6 ;-)

oh yeah

[tomstdenis]

sub Fahrenheit_to_Kelvin (Num $temp is rw) {

Verbosity in coding, yeah that will go over well with people who are used to

int lbn, rax, ... ; :-)

Don't get me wrong I'm a big fan of Perl, but not for its completeness as a language but for the ability to quickly write small utils to parse text.

But I suppose whatever floats peoples boats.

Tom

Perl floats *all* boats

[flicken]

That's the point of Perl. If you don't want to use the verbosity of:

sub Fahrenheit_to_Kelvin (Num $temp is rw) {

You don't have to! You could just as well use:

sub f2k ($temp) {

Perl will allow either. It's your choice. You can do the quick one-off-hack-it-up-at-3am-after-two-large-pots-of- coffee, and you can have a large programming project that must be maintained for years to come.

You have the choice. Pick whichever method fits the task at hand.

Re:Perl floats *all* boats

[Marx_Mrvelous]

Actually the parent is wrong. The bahavior os f2k($temp) is different than f2k($temp is rw) in that Perl will assume a constant variable by default. So no, you don't *have* do, unless you want to make your parameters read-write. Which could lead to less lines and variables later on.

Re:Perl floats *all* boats

[groomed]

The problem is that it'll be the one-off-hack that'll have to be maintained for years to come, while the large programming project will just sit and collect dust in a closet.

Perl6 is a mistake

[keesh]

I've been using perl pretty much constantly since the Pink Camel, and believe me, Perl 5 is an extremely good language for quick scripting things. That's what it was designed for. Sure, you can do big projects in it, but it's not exactly ideal. Recently I've started using Ruby [ruby-lang.org] as well, and I intend to move my department over to it instead of wasting time with Perl 6.

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster [mozilla.org]. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language [rubycentral.com] (and not one with loads of irritating whitespace [python.org] thank you very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal [lysator.liu.se] does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this [perl.com]. Does he want Perl 6 to be flex [gnu.org] or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. I'd prefer to use a language [ruby-lang.org] which has always been pure synthesis of science and engineering, not some half-baked imposter [beonex.com].

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying.

Re:Perl6 is a mistake

[Ed Avis]

BTW, a nondeterministic finite automaton is much less flexible than ordinary code; there are many things (checking for palindromes being the classic example) which code in a programming language can do but an NFA (and hence a regular expression) cannot. What you mean is that regexps provide a more concise syntax, and perhaps a more efficient implementation (since the regexp engine is in C).

Perl's so-called regular expressions are not true NFAs however, because they have wacky things like backreferences. In fact they are NP-complete [plover.com].

Re:Release on the long road to nowhere

[keesh]

This guy is not trolling

Erm, yes I was...

Re:Release on the long road to nowhere

[Mike Schiraldi]

Okay, that comment just made me change your little color dealie from red to green.

Re:Release on the long road to nowhere

[Ed Avis]

This guy is not trolling. He makes several valid points.

The two are not mutually exclusive, you know...

FWIW I strongly disagree with your assertion that Perl should not be used for anything longer than a few hundred lines. For longer programs you do need more discipline and a more structured approach. That is as true in Perl as in any language. Writing clear and well-separated code does not have to mean UML diagrams. (Though you can have those with Perl, if you really insist.)

Re:Troll-by-reference

[Anonymous Coward]

Probably because he doesn't know what he's talking about, and there are numerous errors in his post.

For example, he claims that each variable has its own prefix in Perl 5. That is completely false. A "variable" in perl is a reference to a typeglob, which contains memory slots for each type of value a "name" ( variable ) in perl can store: a scalar, a hash, an array, a filehandle, and a subroutine. The prefixes before a name in perl determine which slot you access ( it is the context you are calling the v

Re:Troll-by-reference

[Ed Avis]

Your terminology, using 'variable' to refer to a whole typeglob slot, is nonstandard in the Perl world. Most programmers (and Larry himself AFAIK) would say that $x is a scalar variable and @x is an array variable. They are both variables and both different.

Referring to the whole typeglob with *var is rather esoteric (not saying it's never used, just it is used far far less often than accessing variables normally), and when you do use it, you talk about typeglobs not variables. *var is a typeglob, which

seems like

[butane_bob2003]

the language is becoming more obtuse if thats possible. The perl programmers I know don't get along well with other languages, mostly because they have spent so much time learning the intricacies of Perl syntax. Even coming from C, Perl syntax is unnatural. Seems like once you go Perl, you can never go back (or try to learn a new language). I've never met a perl programmer who could tell me what a design pattern is either. I guess they don't go for re-use much in perl progging. I think if I went to hell, satan would probably make me write a Perl parser. (without the help of Yacc)

Re:seems like

[chromatic]

the language is becoming more obtuse if thats possible.

Read the last page of Exegesis 6 [perl.com] to see the Perl 5 version of the code. It's astonishingly simpler and clearer in Perl 6.

The perl programmers I know don't get along well with other languages, mostly because they have spent so much time learning the intricacies of Perl syntax.

See the Inline [cpan.org] modules on the CPAN.

I've never met a perl programmer who could tell me what a design pattern is either.

See Perl Design Paterns [perl.com], an article on Perl.com.

I guess they don't go for re-use much in perl progging.

See the CPAN [cpan.org].

I think if I went to hell, satan would probably make me write a Perl parser. (without the help of Yacc)

I've read the Perl parser. You're right about this one.

Re:seems like

[RelentlessWeevilHowl]

Read the last page of Exegesis 6 to see the Perl 5 version of the code. It's astonishingly simpler and clearer in Perl 6.

That particular piece of Perl 6 functionality would have to be expressed as that particular chunk of Perl 5 code to get a comparable effect. Fine.

My personal concern is in how in the preceeding 10 pages, he describes another umpteen "simpler and clearer" ways of achieving the same effect (most of which seem to have subtle gotchas).

Re:seems like

[chromatic]

That's a fair concern.

Damian intended to demonstrate as many of the new features as possible while reusing one example and progressing through more and more powerful techniques. He thought it'd be simpler and easier to understand. It's a difficult article to write, no matter how you approach it, since it summarizes to a list of "Here's another way to do that, having these advantages and these disadvantages:" statements.

I think he suceeded, but it's also possible that I'm too close to the material t

Re:seems like

[mshiltonj]

it's also possible that I'm too close to the material to judge this accurately.

chromatic? close to perl? say it ain't so!

Re:seems like

[jdavidb]

I viewed a presentation about design patterns at YAPC::NA::2002.

I once had a software engineering professor who over a period of several weeks refused to believe me that Perl was an object-oriented language (like C++, not like Java or Smalltalk). He was finally convinced when he taught design patterns, giving the factory class as an example, and I said, "I did that this morning in Perl." His jaw dropped.

I still consider myself a Perl programmer, but I was laid off last November and moved to a new job that is primarily Oracle PL/SQL programming. I only knew the bare minimum of PL/SQL, but already I am one of the guys people go to in this office when they have PL/SQL questions. I've helped about six people more experienced than me through fixing mutating table problems, and I'm learning more constantly through reading and experience.

I credit my experience with Perl extensively for helping me to be a good PL/SQL programmer. In my experience, good Perl programmers (the ones you're likely to see speaking at a conference or writing a book) use the right tool for the job, constantly pick up new languages (Ruby and Python are pretty popular), and do a better job programming in those languages because of their Perl experience.

Re:seems like

[Angst Badger]

Even coming from C, Perl syntax is unnatural. Seems like once you go Perl, you can never go back (or try to learn a new language).

I came from C (not that I exactly left it) and I didn't find Perl unnatural, and it hasn't crippled me for other purposes, unless you count involuntarily prepending '$' to variable names in C after a long session of Perl coding. As far as I am concerned, there are only three major problems with Perl:

1. Type sigils. The underlying theory necessary to implement variables without special leading characters dates back, oh, thirty years or so. (This is particularly egregious with PHP, where there is only one generic sigil for all types rendering them pointless anyway, but that's a separate gripe.) The '$' notation for shell scripts existed to simplify the ad hoc parsers most shells use; it has no place in a full-blown language.

2. Complex data structures. Even C syntax for deeply nested pointers is cleaner than Perl. Mostly because of 1, above.

3. Writing large applications in Perl depends totally on intense self-discipline as a programmer, and everything about Perl actively encourages you to break that discipline. TMTOWTDI, past a certain point, is a liability, especially with large development teams.

Obviously, Larry and Co. feel differently about these things, but they drive me up the fnarking wall.

I think if I went to hell, satan would probably make me write a Perl parser. (without the help of Yacc)

If Satan really wanted to put the screws to you, he'd require yacc. (The inside joke, for those who aren't deeply into compiler design, is that Perl can't be parsed by a yacc parser because it's not even remotely context-free. Whether that's a good idea or not is a debate that goes back to the days of the ALGOL design committee. The practical effect is that the syntax of Perl is described not by a formal grammar but by the implementation itself, which makes it all but impossible to validate a competing implementation.)

Re:seems like

[Dog and Pony]

I'm not sure if I agree with you that those are problems. Different, yes, but not necessary problems. I came from C and Java mainly, when I encountered Perl, and at first I thought it looked butt ugly and a bit hard to read, yes. But the benefits can be immense.

The sigils really help code being readable, you always know what to expect from the variable. Although, good naming and good programming practices is enough in most other languages.

Then, like someone else pointed out in some other post up there, y

Re:seems like

[bsartist]

Seems like once you go Perl, you can never go back (or try to learn a new language). I've never met a perl programmer who could tell me what a design pattern is either.

I write Cocoa apps in Perl every day; in doing so, I use delegation, observer, and MVC design patterns, among others, on a regular basis. I picked up the habit after - wait for it - learning Objective-C. What's more, I wrote and maintain an open source project that's approaching 10k lines of mixed Perl, Objective-C, and C.

I will grant

Re:seems like

[Aadain2001]

Exactly. I'm currently doing a very nice sized project in Perl (currently over 3,000 lines of code, inline documentation(thanks POD!), and debug lines), and I am adhering to a very strict design pattern because I know that I am not going to be the one to maintain this for the next several years. Perl is great at quick little hacks that help make your life simpler without thinking too hard. But that doesn't prevent Perl from being used in a full blown project just like any other language such as C, C++, J

Re:seems like

[larry bagina]

Actually, C allows:

if (is_true) parse(); else exit(0);

perl's statement if (condition) is nice, but I feel it only exists to make up for the lame if/elsif/else support.

Honestly, I wonder why if/else/elsif blocks need to be enclosed with {}. C has shift/reduce error, but perl is context-sensitive, so it can't be explained by language purity.

Holy syntax overload batman!

[jtdubs]

I've never seen a language with so much syntax. Perl 5 had more than enough, now they've more than doubled it.

You have { } for blocks, and for automatically parameterized blocks (ie. anonymous functions).

You have =, := and ::=, ~=, ~~, .... = does assignment, := does binding and ::= works at compile time and is normally used to define types and such, ~= is pattern matching, and I have no idea what ~~ does.

You have the new <== and ==> pipeline operators. They are dataflow operators. Like so:

$foo ==> my_func ==> $bar;
is the same as
$bar <== my_func <== $foo
is the same as
$bar = my_func($foo);
is the same as ...

You already had the $,@,%,& to prefix variables with.

You have more uses for * now, as in slurpy arrays and splicing. As in, the * can make an array parameter slurp up all the remaining arguments, or it can make an argument flatten into a list of arguments.

They've added some wierd << foo >> syntax that I didn't even bother to read about as I was in syntax shock.

They've added ^ which indicates that a variable in a block is actually a parameter and therefore the blocks is actually a parameterized blocks (ie. anonymous function). So, now you can't tell if something surrounded by { }'s is just a block of code or whether it's an anonymous function. Although, I don't think this is a problem as it's usually obvious from the context.

And I didn't even read to the end of the paper!

Makes me want to go write some Lisp, which is perhaps the antithesis of Perl. Lisp has the maximum possibile flexibility through having the minimum possible syntax. Perl originally had little flexibility, now they are trying to add more by adding more syntax. The problem is, if they want to get anywhere near Lisp-level flexibility with this method they'll need to move to Unicode for the syntax!

Justin Dubs

Re:Holy syntax overload batman!

[MagikSlinger]

Makes me want to go write some Lisp, which is perhaps the antithesis of Perl. Lisp has the maximum possibile flexibility through having the minimum possible syntax. Perl originally had little flexibility, now they are trying to add more by adding more syntax. The problem is, if they want to get anywhere near Lisp-level flexibility with this method they'll need to move to Unicode for the syntax!

See? My Modified Godwin's law [slashdot.org] is right!

On a serious note, you could always write Lisp like programs in Perl

Re:Holy syntax overload batman!

[ajs]

if they want to get anywhere near Lisp-level flexibility with this method they'll need to move to Unicode for the syntax!

Ok, first off... Perl 6 will use Unicode by default, of course, and yes there is some talk of using things like the dot-product symbol to mean roughly what you would expect it to mean. However, that is limited by the practicality of entering and viewing Unicode characters with modern equipment. Perhaps in another 10 years....

Now, that being said, I would argue that Perl 5 already presents 99% of Lisp's flexibility. Perl 6 leap-frogs Lisp by presenting Lisp's flexibility in a package that is far easier to use (though, as you point out, perhaps not easier to LEARN).

You already had the $,@,%,& to prefix variables with.

But in Perl 6, they are rationalized a great deal, and made simpler to use (e.g. Perl used to use the glyph to indicate the type of operation being performed on a variable, no the type of the variable. In Perl 6, that has been changed to reflect what most programmers expect, so @foo[0] is the correct notation for accessing the zeroth element of an array, not Perl 5's $foo[0]).

Perl 6 is going ot be hard for outsiders to jump into at this stage because it doesn't exist yet. If you're not steeped in the culture of Perl 6's design, you won't be able to see where it's going, so everything looks kind of scary.

However, in about 10 years, I expect Perl 6 to be seen as the starting point of a new kind of programming and a level of symbolic abstraction that allows us to start looking at code in a much more constructive way.

Re:Holy syntax overload batman!

[imnoteddy]

Now, that being said, I would argue that Perl 5 already presents 99% of Lisp's flexibility.

I disagree. Much of Lisp's flexibility comes from having programs represented in the same form as data (S-expressions) which lets you build a data structure and then pass it to one of Lisp's EVAL family. Perl's eval(), while useful, is a poor cousin of Lisp's facilities.

Execute data, not code.

Re:Holy syntax overload batman!

[ajs]

Much of Lisp's flexibility comes from having programs represented in the same form as data (S-expressions)

That's the part that Perl does not have, and never will (though Perl 6 comes as close as a truely compiled language reasonably can). However, most Lisp code really doesn't benefit from this fact as much as it does from its side effects.

Let me give you an example. One side effect of what you describe is lambda functions, and a cool feature distinguishes lambda functions from simple function pointers in C is closures.

Perl provides the equivalent of Lambda functions in the form of anonymous subroutines, and they are also closures.

So, while you are correct that much of the flexibility of lisp falls out of S-expressions, it's not true that you cannot have that flexibility WITHOUT S-expressions.

What Lisp *does* have that Perl 5 does not is an excellent macro mechanism (which also falls out of S-expressions).

That is probably the one major thing that Perl 6 will need in order to truely surpass Lisp's flexibility for general purpose tasks, and while it has been much discussed on the mailing lists, it won't be realistic to decide on it, and nail it down fully for a few itterations of the apocolypses. But it's certainly clear that Perl needs some form of macro system that is at least very nearly as flexible as Lisp's.

Perl's eval is a red-herring. It's really a totally different (pair of) functions from Lisp's eval, acting as either parser or exception-handler. Lisp's eval is much more comparable to Perl 5's ->() operator which dereferences and executes a code reference which can be a reference to an anonymous or named closure, a subroutine or a regular method.

You can also build CVs, which are just data-structures, in C and present them to Perl as a code reference. That does give you all of the power of Lisp, but you have to drop down to C to do it, so it isn't at all trivial or useful for routine use.

Re:Holy syntax overload batman!

[Fastolfe]

Is this "macro system" different than the one presented in this article? Damian's showcasing a macro syntax on some of the later pages of the article that involves evaluating Perl code (similarly to a Perl 5 BEGIN block) and injecting the returned string directly into the code where the macro is called, where it is immediately parsed as the parser picks up where it left off.

I admit that I'm not completely familiar with how Lisp does things, but is this a sufficient macro system for your needs, or are you

Re:Holy syntax overload batman!

[ajs]

As I said in the other reply, I thought macros were being held off until the grammer building system in Perl 6 was better fleshed-out. I haven't read A6 yet, only the stuff that Larry wrote leading up to it and a little bit of the chatter after, so I wasn't aware that had snuck in.

Re:Holy syntax overload batman!

[Trilaka]

Ok, I must clarify a few things:

(though Perl 6 comes as close as a truely compiled language reasonably can)

I can't believe I even read that. Perhaps you are just trolling, but for the sake of those who do not know better, lisp is actually more of a truly compiled language than perl. Perl is interpretted by the perl interpreter (aptly named perl). Lisp is compiled down to machine code.

Secondly, this Exegesis covered Perl6's macro capabilities. It works very much like lisps, actually. Granted, my pe

Re:Holy syntax overload batman!

[ajs]

lisp is actually more of a truly compiled language than perl

Yes, and no. First off, don't assume that I don't know Lisp. I try to hide it at work because I have so many co-workers working in Lisp, and a basic working knowledge is actually more of a handicap in this crowd than ignorance....

Lisp is never truely compiled. It can be compiled down to machine code, but you always have to keep the S-expressions around, just as you keep a non-static inline function around in C or C++, except in C and C++ that co

Re:Holy syntax overload batman!

[ajs]

You have a good point at the end about expressions. I was being a bit too restrictive. I disagree with you elsewhere. Perhaps some compilers do what you suggest, but GCC allows for FILE* to iostream conversion in ways that ANSI C++ does not, and I don't call that C++ either.

You seem to only focus on where we disagree, so I'm going to let this one go for now. I do agree with you that Lisp is a flexible and powerful language. I think it was a shame that Perl only started to adopt some Lispisms as of version

Re:Holy syntax overload batman!

[smallpaul]

Remember though folks, if you don't want to deal with this complexity, you don't need to.

Sure, as long as you never need to maintain code that deals with it.

Re:Holy syntax overload batman!

[_ska]

''Now, that being said, I would argue that Perl 5 already presents 99% of Lisp's flexibility. Perl 6 leap-frogs Lisp by presenting Lisp's flexibility in a package that is far easier to use (though, as you point out, perhaps not easier to LEARN).''

Ok, thats funny. I can't speak to the flexibility of Perl 6, but you are on some serious chemicals if you argue that perl5 has 99% of Lisps flexibility.

Perl has some real strengths (and real weaknesses, of course), but it is pushing it to claim it even approache

The World Needs Idealised Perl

[Vagary]

In the denotational semantics community it was long ago decided that real programming languages are too messy and too much of moving targets for serious theoretical research. As a result, the most popular language is known as Idealised Algol which is a simplified and cleaned-up version of Algol-60 (I'm told Algol-W is the closest implementation).

Now that Perl 6 has a rich operator definition system*, we can look forward to Idealised Perl (IP). IP would be a version of Perl stripped down to only the necessary syntactic building-blocks. Even if much of Perl 6 were implemented in C, it'd be possible to define all the syntax in terms of IP. If you're writing code for maintainability instead of prototyping, using IP as much as possible will ensure a smaller learning curve for non-gurus. IP will be simple enough to actually allow teaching Perl in universities.

IP could be the elegant yet expressive language we all (whether we like Perl or not) wish Perl would be.

* This is, IMO, the only really neat and elegant thing to come out of Perl 6 so far. If operators can be defined to the point where most mathematical formulae are executable, Perl will become a revolutionary tool.

Re:The World Needs Idealised Perl

[axxackall]

At the beginning there was LISP, the language with the biggest language report. You don't like various Perl assignments? How about various Lisp quotes?

Then they decided to idealize it and created Scheme - the language with the smallest language report. Both languages are good, but both language have lost their popularity to first imperative and then OOP ones.

I think the length of the language report won't help Perl either. People are already re-writing Perl code to Python. Why? Perhaps because they don'

Re:Holy syntax overload batman!

[CanSpice]

Makes me want to go write some Lisp, which is perhaps the antithesis of Perl. Lisp has the maximum possibile flexibility through having the minimum possible syntax. Perl originally had little flexibility, now they are trying to add more by adding more syntax. The problem is, if they want to get anywhere near Lisp-level flexibility with this method they'll need to move to Unicode for the syntax!

But, you see, the problem with writing in Lisp is you're writing in Lisp.

Re:Holy syntax overload batman!

[Ed Avis]

Lisp has the minimum possible syntax? You sure about that? I'm no Lisp hacker, but it seems that the language has at least two ways of defining functions, at least three different kinds of quoting (plus anti-quoting), and a reasonable number of syntactic shortcuts like ; for constructing pairs. In terms of total punctuation per line of code, Lisp and Perl probably come out about equal.

Any Sufficiently Advanced Language...

[Vagary]

A disclaimer: I used to program Perl for a living, but we had a falling out some years ago (around 5.0?). So if you don't think there's any merit to what I'm saying, then feel free to consider this a troll:

Shortly after I started reading Exegesis 6 I was somewhat frightened by how complex Perl had become since I stopped keeping track of updates. Of course scripting languages have always been known for borrowing the best from other programming languages, so I kept reading in the hopes that I'd recognise something. I saw some features like the is constant declaration and started worrying that maybe they'd decided to borrow some features from the very popular but insanely evil Visual Basic. But then I saw this:

type Selector ::= Code | Class | Rule | Hash;

and realised that, just as Python is (alleged to be?) adding Lisp-like features, Perl is adding ML-like features! That line above is (minus the '::' and ';') straight out of a Haskell program. Then I started to notice more Haskell-like syntax:

• Anonymous function declaration syntax: -> $animal { $animal.size < $breadbox } would be (\animal -> animal.size < breadbox) in Haskell
• Multisubs are like pattern matching: multi sub feed(Cat $c) {...} multi sub feed(Lion $l) {...} would be
  feed (Cat c) = ...
  feed (Lion l) = ...
• New infix operator definitions: infix:~|_|~ would be the function named (~|_|~)
• Junctions are like list comprehensions: all(newvals) would be [x | x <- newvals] (it almost seems like junctions are lazy from the way Damian talks about them?!)

And I'm sure a more thorough reading would turn up even more. (For example, the smart-match operator reminds me of the type inferences done in a Hindley-Milner type system.) So it appears that any sufficiently advanced language contains an implementation of a purely functional language, not specifically Scheme. :) Has Damian (who certainly has Haskell exposure) or Larry ever mentioned any of these influences?

Forgot Currying!

[Vagary]

One more thing:
I'm really happy to see Perl include currying, I can't think of a programming language that I would be completely happy using without it.

There's more than one way to do it?

[MoxFulder]

Perhaps the Perl motto should be changed from TMTOWTDI to TAMODVPCWDSSAAMSTWDI:

"There's a multitude of different visually pleasing constructions with deceptively subtle syntax and auto-magical semantics that will do it."

Okay, I love Perl 5... Perl 6 looks really cool but overwhelming. I'm glad they're adding the options for stricter type-checking and such, but remembering the syntactic shortcuts is gonna be even harder. I don't even want to know what the parser code looks like...

Re:There's more than one way to do it?

[rmohr02]

Perl 6 looks really cool but overwhelming.... I don't even want to know what the parser code looks like...

Well, you don't want to know what the parser code looks like in Perl 5 either.

Anyway, they're adding a bunch of weird stuff, but I'm fine as long as I can still use normal syntax.

eval @ in scalar context != size of @? What?

[embobo]

@date_and_time is evaluated in the scalar context imposed by $date, and the resulting array reference is bound to $date.

Huh? This seems wrong. Evaluating an array in a scalar context should return the size of the array, not an array reference.

Re:eval @ in scalar context != size of @? What?

[Fastolfe]

In Perl6, the "context" of a variable actually gets a little more specific. In a vague "scalar" context, yes, an array will resolve to a reference to itself.

However, you can examine either in a numeric context and obtain the number of elements within it. So things will work as you expect, you just have to realize that "scalar" is now a real vague term.

A sharp detour from past Perls

[Junks Jerzey]

I like Perl. I use Perl often. I also know and use a variety of obtuse languages, including wacky ones like Forth, J, and Haskell, plus more traditional languages such as Python, C++, various BASIC derivatives, etc. In short, I'm not an anti-Perl troll. Blind language advocacy is for newbies.

That said, I can't help but think that far too much thought has been put into Perl. One of Perl's real strengths has always been that it wasn't designed up front so much as accreting things have have been proven to work: hashes, formats, regular expressions, dynamic typing, back quoting, evaluation of variables inside strings, and so on. But Perl 6 is getting years of forethought, and all of that forethought is beginning to weigh things down. The old Perl way would have been to say "Look, now we have a simple parameter passing scheme like that one Python, one which has been proven to work." The Perl 6 way is to start with a series of odd little features, then keep modifying them and adding sugar to them until the end result, after a number of iterations of this, ends up being something that looks and works like Python's parameter passing scheme, but takes ten pages of explaining to fully explain,

In short, this is the kind of thinking that begat PL/1 and Ada and other spectacularly complex languages.

Re:A sharp detour from past Perls

[Jerf]

The old Perl way would have been to say "Look, now we have a simple parameter passing scheme like that one Python, one which has been proven to work." The Perl 6 way is to start with a series of odd little features, then keep modifying them and adding sugar to them until the end result, after a number of iterations of this, ends up being something that looks and works like Python's parameter passing scheme, but takes ten pages of explaining to fully explain,

This thought keeps occurring to me. Actually, wi

Re:A sharp detour from past Perls

[demi]

...but it has a lot of it already there,

I'm curious what you think is coming in Perl6 that Python already has. The exception mechanism I suppose, and mixed positional, named and optional parameters. Anything else?

and a lot of the other stuff isn't necessary because that's just not the way things work in Python.

The reason people get into flamewars over Python vs. Perl is because of this philosophy: if Python doesn't do (or doesn't do well) what you want it to do, there must be something wrong with

Speaking as a Perl programmer...

[metamatic]

...will someone please hurry up and add Unicode support to Ruby so that I don't have to learn Perl 6?

Re:Speaking as a Perl programmer...

[GnuVince]

You do realize Ruby is open-source? Let that someone be you maybe?

Re:Speaking as a Perl programmer...

[metamatic]

Not knowing Ruby makes me far from ideal as the person to fit it with Unicode.

Flame War....

[Tsali]

I don't know which gets more trolls... Perl or VB6... or VB.Net or C# or Java or Python.

I think it merits a poll.

My vote: Perl.

Most languages have regular expression components now to help with text processing.... so can someone tell me why you would pick up Perl when other languages are prototypical (VB/Python), strongly OOP (Java/C#), or need to be around forever because people have been coding them for decades(COBOL, C, C++)?

Note: Personal preference is Java, Python, and VB.Net in that order. I am

Perl 6 is a pantheon...

[LoveMe2Times]

I see Perl 6 as kind of a pantheon of programming gurus, and you can subscribe to whichever you like (or tell them all to screw off). The most important thing about Perl 6 is you can use whatever programming style suits you best. In a corporate environment, that style can even be dictated down by the powers that be, too. If you're one of those people that thinks that Lisp (et all) is (or is not) understandable, or thinks Java is a brain-dead C++, or that C++ is error prone Java, then Perl 6 may not be for you. You let (percieved) flaws obscure the important benefits, and as a result you miss out. Objectively, you would be examining the trade off between learning curve and increased efficiency over the time period of the project. In many cases, it is in fact better to stick with the tool you know, even if a different tool would be twice as effecient. Since it's just not possible to learn every single tool available, as professionals, we have to pick the most effective set of tools that we care to know given our interests and other expertise. This brings us around to the great thing about Perl 6: in one cohesive, sensible framework, it gives you really broad coverage. You don't have to learn it all at once--you start out using Perl 6 like Perl 5; then when you decide you want to do some lispy type things, you don't have to learn Lisp and a whole new toolchain, you can learn to do lispy types things in Perl. If you want to do things that would be well suited for C++ templates, you can learn the Perl 6 mechanisms for it instead of undertaking C++. And what is really, amazingly cool is that Perl 6 is shaping up to be a cohesive, well considered framework; it's not a jumble of competing ideas that don't play nicely with each other.

If you've worked with C++ templates and metaprogramming, then you certainly understand the benefits being offered by a lot of the Perl 6 constructs. But the Perl 6 way is much more comprehensive, direct, clear, and intentional. Everything with blocks, anonymous subs, closures, multi methods, named parameters, operator overloading, and macors offers unbelievable oportunities for meta-programming. Once Perl 6 gets rolling and starts developing its own equivalent of Boost [boost.org], then programming will never be the same. Boost changed everything already, but you've probably never heard of it; but Perl 6 will have mainstream appeal, acceptance, and use that Boost will never have.

Hahaha... um... no.

[mobileskimo]

If you're gonna troll, atleast do it well. Or just don't.

Re:Problems

[ekidder]

Ow! My groin! I've been doing perl applications development for telecommunications for about three years. Lots of TN3270 screen scraping. Lots of painful TN3270 screen scraping.