Exegesis 7 Released (Perl 6 Text Formatting)

chromatic writes "Perl.com has just published Exegesis 7, Damian Conway's explanation of how text formatting will work Perl 6 (and now, Perl 5, thanks to his Perl6::Form module) will work. Think of it as Perl 1 for the 21st century. Also, Parrot 0.1.0, the virtual machine for Perl 6 and several other dynamic languages, released on Leap Day -- ever wanted to program in an object oriented assembly language?"

Comments

The best thing about Perl

[rgmoore]

One thing that you really have to love about the people who write Perl is that they have a sense of humor. This kind of document could be extremely boring and bland, but Damian had the good sense to liven it up by using humorous examples, mostly drawn from Shakespeare. He's doing some great work, but he's also obviously having fun doing it.

Re:The best thing about Perl

[Saven Marek]

The long lost art of Good Documentation. There's been quite a case made lately (read ESR's CUPS rant for an example) for software that doesn't need documentation, when its method of use is made obvious merely by it's design. I think for consumer software that's just meant to be used one or two ways sure that's a good idea.

But for something like Perl, it's all in the documentation. Here's to writers like Damian Conway not only providing summaries for new releases, but writing the original documentation!. If only it paid well!

That been said O'Reilly would sell a good deal less books if the original docos were all they should be cracked up to be. Guess it doesn't have to be that good! There's nothing like getting a new fresh O'Reilly title in the mail.

Mac desktops, OSX hints, scripts and more

Re:The best thing about Perl

[Anonymous Coward]

I was lucky enough to be lectured by Damain Conway on the fundamentals of programming in C. Easily the best lecturer I have ever met. Of all the lectures in Computer Science he was the only one who managed to pack out the theatre everytime. I swear people came in just for the show.

A great combination of humour, intensity and analogies created an enthusiasm to listen and in turn learn. He even spent long hours writing applications to demonstrate principles (think virtual C intepreter with GUI).

Whats more he loved to teach, he wasnt just there to complete his hours required like most lecturers.

I wish we could find more people as talented as Damian to teach us. The world would be much smarter if we could.

Re:The best thing about Perl

[ajs]

Documentation is far and away the thing that sets Perl apart from other languages. There are some bad things you can say about Perl's documentation, but most of them are criticisms that you can't even begin to make of other programming languages because they simply aren't in the same ballpark.

I blame POD for this. POD is just a simple set of markup controls you can add to a plain text document to make it easy to translate it into other documentation and markup formats. It's so simple in fact that there's really no mental hurdles to sitting down and writting the docs for your program, module, language feature, etc., and so people do! Just about every peice of code uploaded to CPAN has a full suite of documentation for every module it provides for this reason. What's more, you can type "perldoc Foo" on any system with the "Foo" module installed and get a copy of that documentation ready at your fingertips.

I even use Pod at work. it's an easy format to teach to people, and what could be simpler than writing a simple text file documenting a procedure you want people to follow. Then it's automatically turned into HTML and added to our internal Web site. Would that the rest of my job was that easy...

Re:The best thing about Perl

[rgmoore]

It also helps enormously that there are clear expectations of what Perl documentation is supposed to look like. By the time you've read the documentation for four or five modules, it's very clear that there are expected parts. Everyone knows what the format is supposed to be, so everyone uses it. That means that A) you know where in the documentation to find the information you need, and B) it will be there when you look for it.

Re:The best thing about Perl

[Ed Avis]

On the other hand, nowhere in Perl's documentation is it fully documented what

$a = $b + $c;

does. Compare this with languages like C or Scheme or (I think) Python that have a formally defined and documented semantics (even if C allows for some cases that are explicitly implementation-defined or undefined behaviour).

Re:The best thing about Perl

[Ed Avis]

Binary "+" returns the sum of two numbers. Is that not clear enough?

No. For a start, it doesn't. What if one of the arguments is a string? Or a reference? Or undef? What if the numbers are quite large - the result will not be exactly their sum but an approximation. The same applies for very small (close to zero) numbers.

If you're worry about what a number is, you could check: perlnumber - semantics of numbers and numeric operations in Perl

Fair point. But I wasn't really considering the + operator so much as the statement
$a = $b + $c;
Even if you know what + does, the semantics of the above statement are still not defined anywhere. Which of $b and $c is evaluated first, for example? (And yes, it does matter, consider tied variables.)

The fact is, Perl is defined almost entirely by its implementation - there's no way you could start with the current manual pages and write a different implementation that would be compatible with most code. There's far too much DWIM which is not clearly defined anywhere.

Re:The best thing about Perl

[ichimunki]

There's far too much DWIM which is not clearly defined anywhere.

Seems to me that this is more of a problem with the language design than a problem with the documentation-- most operations are somewhat ambiguous when used in odd ways (like trying to add two strings even though the manual clearly states that + wants to add two numbers). Do you really expect the docs to attempt to cover every possible thing that might happen as a result of using the + operator? Personally I'd prefer the language throw an error if + isn't a defined operator for the data types in question, but Perl will happily convert your string to a number (which is amusingly bad, because if the string contains digits, you get a number, if the string contains letters, you get nothing).

By the way, the POD page mentioned 'perlop' clearly states that + is performed left to right. There is a whole section at the very beginning that talks about associativity and precedence.

Re:The best thing about Perl

[ajs]

1. Javadoc isn't well suited to man-pages

you mean like "man ls"? i thought we were creating documentation websites...

Sure that too, or PDFs or command-line extraction form installed modules or whatever. There should be no difference. Docs are docs, and it should all come from the same source, no?

Me: Javadoc is not just simple text[...]
You: could you explain further[...]

Sure, here's an example from the Javadoc site:

/**
* A class representing a window on the screen.
* For example:
* <pre>
* Window win = new Window(parent);
* win.show();
* </pre>
*
* @author Sami Shaio
* @version %I%, %G%
* @see java.awt.BaseWindow
* @see java.awt.Button
*/

Ok, start with the fact that there's embedded HTML. Mistake. HTML makes it bulky to write docs. HTML is also not abstract enough to easily convert into, say, TeX or PS without a full rendering engine to get it right.

Second, it's not free-form, so my doc might not fit into the Way that Javadoc wants me to approach such things.

Let's look at POD for roughly the same thing (I am going to start at an odd place because the above was just a snippit of a presumably complete document):

=item Window

A class representing a window on the screen.
for example:

Window win = new Window(parent);
win.show();

Ok, now you might have at the bottom of that document:=head1 AUTHOR

Sami Shaio

=head1 VERSION

$Id$

=head1 SEE ALSO

L, L

=cutAre you seeing the differences here? Free-form to accomodate the vast array of needs, high level of abstraction from both the content AND the medium for ease of translation to just about any format (Perl ships with translators to nroff/man, HTML, LaTeX, and plain text but there are dozens of other converters out there).

This difference suffuses the Java and Perl mindsets. Java has its own way of doing things and doesn't need to bow to local system standards. Perl finds a way to do its own thing in powerful ways while also adapting to the local culture.

You also mentioned Jakarta, which while very cool, is a sort of rebelious subculture within the whole of the Java community. I would point you back at Jakarta for an example of how the model that Perl, Python, Ruby and many others follow has been forced upon Sun's Java community because it's the right solution.

Again, I want it to be clear: I respect Java, the JVM and Java's documention. It's just that I feel there's even better tools available (and no reason you can't document your Java code using POD!)

Re:The best thing about Perl

[ajs]

"You couldn't write a compatible perl implementation using just the manual pages"

That's both true and false. I would consider any program which implemented everything that was in the Perl documentation to be "compatible" (you have to understand what a behemoth undertaking that would be...), but Perl has never had a formal specification, and as such... just like every other language for which that's the case... there is a great body of code that relies on bugs, undocumented features and other implementation-specific aspects of the reference implementation. Your compiler would be "compatible" with Perl, but not with perl (note caps) and so would be of use only to those who were willing to test against it or modify existing code to work with it.

Perl 6 is evolving a complete specification to address that among other concerns, but... what exactly were YOU trying to solve for? Did you want to write a Perl 5 compiler, or were you just looking for something to complain about?

Perl 5 DOES do what you asked... it docuements (perlop, perlref, perlsyn, etc) all the way down to the gory details of the C implementation (perlguts, perlapi, overload, etc) what happens when you $a=$b+$c so I don't see what the problem is.

Re:The best thing about Perl

[Just Some Guy]

If you like POD, then Python's doctest module will blow your mind. Basically, you include example code snippets in your documentation to demonstrate how the code is supposed to work. Then, the doctest module finds all of those snippets, evaluates them, compares them to your example results, and reports on any differences.

So, not only can you easily document your code, but you can trivially insert automated test cases for later verification. Good stuff, that.

PS: I'm at home, sick with a fever, and jacked up on cold medicine. Proofreading is beyond my ability today. Please take any grammar mistakes with a grain of salt. :)

Uh...

[double-oh three]

"ever wanted to program in an object oriented assembly language?"

Uh... I gotta say... No.

Re:Uh...

[Brandybuck]

I thought about this for five seconds in pseudo assembler, then my brain started leaking...

register cx public inherit register ax
push bx
push dx
ax::pop cx
bx.mov ax
shl bx->shr

Re:Uh...

[orthogonal]

I thought about this for five seconds in pseudo assembler, then my brain started leaking...

Leaking is especially apropos, because you should be thinking about encapsulation -- keeping implementation details from leaking --, not inheritance.

I actually did a toy program or two -- very toy, class assignments -- in assembly after I knew C++, and consciously employed an Object Oriented outlook in designing the programs.

This really is easier than it might seem at first: the second biggest hurdle -- and the most important first step -- to OO design is to always think of the entities in your program as objects with responsibilities.

(The biggest hurdle is discovering -- and I use the word "discovering" intentionally, because it's a iterative process of exploring your problem domain -- where to "carve nature at the joints", or where one object ends and the next starts. Alas, a further discussion of this hurdle is beyond the scope of this comment.)

Given that you keep in mind that you're dealing with objects, and that OO requires you to do so polymorphically, -- that is, you want to be able to do the same sorts of things with objects of different sizes and shapes -- you'll quickly find that you need a level of indirection, some stand-in for the actual object, a proxy that is itself the same size and shape for every kind of different object. In C (and C++ and Java) that "same-ness" proxy is a pointer; in perl, it's a hash, which the language conveniently handles the pointing to; in assembly it's a pointer too, or given assembly's inherent weak typing, a memory address.

Just as the real first parameter to every C++ member function is the (hidden and implicit) this pointer, any object-oriented assembly is going to have to pass an object pointer to any functions called on that object. The object pointer will be the address of the actual object, and the object's state, instead of residing in numerous functions -- as you'd do in non-OO structural programming -- will reside in the object, at that pointed to memory.

Finally, and most tedious, is the need for one function called on the object to access other member functions of the object. Essentially, we need a way to determine which of several possible functions foos should be the foo called for a particular object. C++ generally implements this as an array of pointers to function, perl by means of a hash map. Implementation details are implementation details, but essentially you need to specify some ordered list of (address of) functions when the object is created. A naive (and inefficient) implementation that would look like very late binding (and weak typing) to a C++ programmer would be simply to have each object include in its state an array of address; better solution would, as usual in computer science, involve a few more levels of indirection.

The point I'm trying to make is this: Object Orientation isn't so much a property of one language or another -- although some languages support it far better than do others --, as it is a property of the way you think about the problem domain and about programming in general. It's an outlook, a mindset, a world-view, and it's maintaining that world-view, much more than worrying about the implementation details, that matters.

Good Object Oriented programmers can -- and do -- write OO code regardless of the language they're writing in. Programmers who still don't get OO will write bad, pointless OO even in languages that support OO the best. And really good programmers know when to use OO, what parts of it to use, and when not to use OO.

I predict...

[rokzy]

lots of lame jokes about Perl code being incomprehensible despite the fact it can be the most readable.

Re:I predict...

[Anonymous Coward]

Shamelessly stolen from some other post here for your enjoyment ;)

#!/usr/bin/perl

($e,$x,$y,$v,@m)=(shift,0,0,1,1 ,1,0,0);unshift@s,$_,$_ for 1..$e-1;unshift@s,$e;
@p=(1,0);for(@s){push@m,$d= shift@m;push@p,$a=shift@p;$d?$a?++$x:++$y:$a?--$x: --$
y,$l[$y][$x]=($e=>10?$v10?'00':$v100?0:'':$ e10?$v10?0:'':'').$v++,for 1..$_}
warn"@$_\n"for@l

But yeah, I *do* like Perl, I use it and it's FUN. Moreso than most other languages *shudder*vbscript*shudder* ...

A guy walks into his coworker's office....

[Shut the fuck up!]

The screen is covered with what looks like a still shot
of a copy of "The Matrix" screen saver.

He looks at it a minute, and realizes that the coworker
is reading it, so it can't be a screen saver.

He thinks about it a second, and then asks "Do you always
ready your email fully encrypted with PGP like that?
Decoding PGP in you head like that is _really_ impressive!".

"No," says the coworker, "that's just a Perl script I'm
working on".

Re:A guy walks into his coworker's office....

[sisukapalli1]

I know you are trying to be humorous and all... However, I feel this needs to be said...

With Perl, you can make the script/program/module as beautiful as you want, or as ugly as you want. Just to contrast with Java, Java forces you to be verbose -- very verbose. People claim that it makes them productive and it leads to maintainable code, but too much verbose code can be very confusing. With Perl, you have a choice of coding style, but there is no choice with respect to verbosity in Java.

There are places where clear, concise expression is useful. The tradeoff is that the readers have to have the vocabulary to comprehend what is written. Very few people complain "Gee, that guy writes in complex language, it is unreadable." Likewise, reading well written Perl code requires some familiarity with Perl.

Regarding how things look to unfamiliar people, try to look at a screenful of the most beautiful poetry (just pick a language that you are not familiar with -- may be Chinese, some Indian language), and then look at Perl code :)

S

Re:A guy walks into his coworker's office....

[Indigo]

> Java is boring, but uniform, and much more suited to large projects.

Agreed. Of course this makes Java the new Cobol... am I the only one that thinks this?

Yes, it's dependable. Yes, it's good for large scale projects. But God yes, it's boring.

Re:A guy walks into his coworker's office....

[JInterest]

With Perl, you can make the script/program/module as beautiful as you want, or as ugly as you want. Just to contrast with Java, Java forces you to be verbose -- very verbose. People claim that it makes them productive and it leads to maintainable code, but too much verbose code can be very confusing. With Perl, you have a choice of coding style, but there is no choice with respect to verbosity in Java.

Other than your suggestion that Java code's "verboseness" makes it confusing, what you describe is exactly how things should be.

Java is highly maintainable precisely because it doesn't employ a "there's more than one right way to do it" approach. That is why it is so suitable to distributed projects, multi-programmer projects, and in fact, why it is used in a lot of large open-source projects.

Perl is a glue language designed to be used for short programs that perform useful tasks for an individual programmer. For such purposes, archaic structures and code conventions are perfectly acceptable. Can it be used for other things? Sure it can. COBOL can. PASCAL was. Doesn't mean that it is the best tool for the job, by the way.

Maintainable code isn't produced by a desire for self-expression. It is produced by following conventions. Java platform code has been described as "self-documenting" precisely because it lacks shortcuts that create obscurity. Of course, no code is REALLY self-documenting, but Java code comes darn close.

Please note that I am not knocking Perl. I use it myself and it is very useful for the things it does well. You should not, however, compare peas and apples. Perl is not comparable to Java. The languages are designed for different purposes and their structures and means of writing source for those languages reflect those differences. Perl was designed to be a super-shell language. Java was designed to be a net-ready systems and application programming language. Different purposes make for different languages and platforms.

Re:A guy walks into his coworker's office....

[Wiktor Kochanowski]

This sample is just wonderful. It uses more than a page of code to implement something that would take at most five lines in Perl. Actually I think word frequency count is one of the little examples in Perl Cookbook.

And you claim that a page of full blown Java code, complete with classes, initializations, templates etc. is easier to understand than a quasi-functional transformation (as it would have been written in Perl). Well, duh.

Re:A guy walks into his coworker's office....

[TimToady]

If there is such a law, Perl 6 will break it. Switch statements force you to use $_ implicitly, for instance.

Re:A guy walks into his coworker's office....

[thoughtstream]

I seriously doubt that the task..Takes text on standard input, outputs word frequency counts sorted first by count, then alphabetically. ..can be handled with 5 lines and with equal clarity.

while (readline STDIN) {
for my $word (split) { $freq{lc $word}++ }
}
my @sorted = sort { $freq{$b} <=> $freq{$a} || $a cmp $b } keys %freq;
for my $word (@sorted) {
print "$word: $freq{$word}\n"
}

And in Perl 6 you could write almost exactly same thing:

while (readline $STDIN) {
for split -> $word { %freq{lc $word}++ }
}
my @sorted = sort { %freq{$^b} <=> %freq{$^a} || $^a cmp $^b } keys %freq;
for @sorted -> $word {
print "$word: %freq{$word}\n"
}

Or (since we're notionally talking about Perl 6 formatting here) in Perl 6 you could also write it more idiomatically as:

slurp $STDIN ==> split ==> @words;
for @words { %freq{lc $^word}++ }
@sorted = sort %freq: by=>[ {.key} is descending, {.value} ];
print form "{]]{6}]]}: {[[{60}[[}", @sorted>>.value, @sorted>>.key;

and have your output prettified as well.

Have you ever wanted to... NO! I HAVEN'T!

[Tackhead]

> ever wanted to program in an object oriented assembly language?"

Y'know, that couldn't be ANY MORE WRONG than an HTML rendering of a .GIF of a psychotic nun in a bondage outfit clubbing a baby seal to death with an Al Gore doll.

(With apologies to the denizen of the Monastery, from whom I stole the idea.)

ruby! ruby!

[Anonymous Coward]

I'm sure Perl 6 will just be the bee's knees, but I have long since switched to Ruby (or Python if I need certain libraries). As I get older, the philosophy behind Perl (more than one way to do it) really gets on my nerves.

So, I'm interested to see Perl 6 when it comes out, but I sure as hell won't be using it for anything.

Also I'm looking forward to a common runtime between the three languages so I can use Perl modules from Ruby. Now *that's* the best of all possible worlds, eh?

Re:ruby! ruby!

[geniusj]

I am also a huge fan of Ruby.. However, Perl 6 is going to benefit everyone. Ruby will be able to target the Parrot VM as well as languages like Python and TCL. What does this mean? As I understand it, this means that anywhere parrot is installed, your bytecode can be run. No matter what language it's written in. This also means you'll be able to do things like use perl modules from Ruby or use python modules from Ruby or use Ruby modules from Python, etc.

Parrot is very exciting. I personally can't wait. :)

Finally, a good update.

[Fiona Winger]

I have been using Perl for years now, and I have to say, its not been the best language to use.

Being one who's never gone along with the best methods of coding, I've stuck with Perl for the past few years. I deem myself pretty proficient in it, and I find a new plethora of exploration available to me now that Perl6 is out.

The fact that Perl6 is now a subroutine rather than hardcoded allows me to directly stream the formatting through the test. This is immensely helpful, for it allows me to organize the code more efficiently and get more out of my hard worked code.

Sure, some parts may seem like a step back, but this new versions is much simpler to use, and has some huge advantages that all coders should get use from. /me nods his hat to Perl6.

Re:Finally, a good update.

[Saven Marek]

You know, I'm not very big on perl coding, but I do really like the language. Your point about never having gone with the best methods of coding is something I noticed however.

I too wouldn't put perl as a "technically" best way to code ANYTHING, but it is however an intensely easy and powerful set of hacks, joined together quite well, and with a consistency that matches my own disorganised brain!.

I'm good for that. Getting something technically 'correct' in the coding world seems to me to be revolved around far more efficient use of resources and cpu speed than perl does. In my job however we have thousands of fast PCs, and only so many good coders. I go for whatever supports the coders, and for many of us that's perl

webalizer stats. thousands served monthly

C++ is object oriented high level assembler

[Anonymous Coward]

I have always thought of C as high level assembler, and C++ as object oriented high level assembler.

Re:C++ is object oriented high level assembler

[grub]

Olde Quote:

C++ is to C as lung cancer is to lung.

VM's

[beware1000]

Virtual Machines really seem to be the way of the future. But I am really not sure how I feel about them yet.. Parrot will have to prove itself yet, especially with the aftertaste .net and java have left in my mouth. Sounds like an interesting idea though even if only for a neatly compiling language

Re:VM's

[erikharrison]

Well, actually VMs are the way of the past - in research circles the VM has been around forever.

However, for what it's worth, Parrot's relationship to the JVM and the .Net VM is rather small. JVM/.Net are designed from the ground up to support systems languages (like Java and C#). They optimize for static typing and languages where most complexity happens at compile time. Parrot is a VM for languages like Perl, Python, and Ruby, (and TCL, and Lisp etc) whose typing is weaker, and where a runtime eval is a moderately common occurance.

What specifically about the JVM puts you off? Or is it the host language that bothers you?

Re:VM's

[voodoo1man]

JVM/.Net are designed from the ground up to support systems languages (like Java and C#). They optimize for static typing and languages where most complexity happens at compile time. Parrot is a VM for languages like Perl, Python, and Ruby, (and TCL, and Lisp etc) whose typing is weaker, and where a runtime eval is a moderately common occurance.

I have to disagree about typing. Python and Lisp (don't know about the others) type systems aren't "weak," but rather dynamic, meaning that they keep type information around at runtime. Java (don't know about C#) is weakly typed in comparison, as you can cast any class to Object and vice-versa, throwing away the type information, and an incorrect cast will only give an error at run-time (and then it may be difficult to track down if the original class type and the one cast to are closely related). This doesn't happen in dynamically typed languages, where you don't need to cast ("coerce" is a more appropriate term for dynamic type systems) objects to a generic type just to put them somewhere.

Re:I tried, but I failed

[grub]

If you like Python, check out Ruby. I've been monkeying around with it at work for small things. It's like Perl but readable.. and object oriented from the ground up.. and easy to work with.. hmm, on second thought, it's nothing like Perl.

Perl 6 is hugely ambitious, and that worries me

[Fortunato_NC]

One of the reasons I love Perl (cut my teeth with Perl 4, now write a lot of Perl 5 code) is that it is a virtual swiss army knife of programming languages. There is a lot of power in there, but you can choose to use only as much as you might need. The "TMTOWTDI" ethos also appeals to me. And, in reading the updates on Perl.com, I see that this exact same spirit is going into the creation of Perl 6.

So why am I worried? Well, it feels like Larry saw Microsoft's .NET announcements and said, "Hmmm...multiple programming languages that all compile down to the same bytecode and execute in the same virtual machine...sounds like a reasonable idea to me!" The Parrot VM is a neat idea, that goes even further than .NET since it's multi-platform, and definitely will be very nice when it's finished. But I feel like it's going to delay Perl 6. And as nice as Perl 5 is, languages like Python and PHP are beginning to surpass it in feature set and ease of use. I don't want Perl 6 to be irrelevant when it finally shows up.

Also, like a very impatient, immature kid on December 23, I want my Perl 6 now, damnit!

But, I trust the Perl 6 team. They're smart people. Read the newsgroups and the forums, and you'll agree. When Perl 6 and Parrot are ready for prime-time, I am pretty sure that I won't be looking over at Python and PHP and feeling guilty anymore.

Ah well, back to coding...

Re:Perl 6 is hugely ambitious, and that worries me

[Dalcius]

I'm scared too... I started my programming days in Perl and am very fond of it's flexibility and ease of use. I wouldn't mind the ability to do some formal class declarations and error handling a la Java, but I'm worried.

That said, Parrot sounds like it's going to shake some people up. From what I understand, it's a register based VM as opposed to stack based, meaning that preemption is possible. Judging from the speed and smoothness gained by using preemption in the Linux kernel, I'm drooling to see what this will be capable of.

I really hope, though, that they haven't lost sight of what makes Perl great, which is: it's just as easy to write good code as bad. The flexibility is 100% in the hands of the developer, not in an over-engineered and time/overhead consuming rule book. Comparing it to English is a good example.

Cheers

Re:Perl 6 is hugely ambitious, and that worries me

[scrytch]

That said, Parrot sounds like it's going to shake some people up. From what I understand, it's a register based VM as opposed to stack based, meaning that preemption is possible

The difference between stack and register based has nothing whatsoever to do with preemption, and has to do with reduction in the number of opcodes (adding two numbers becomes one instruction instead of 3 for instance). You still have to save register sets the same way you have to save stacks in a stack-based VM, since the task you're switching to won't know if it's clobbering already allocated registers ... unless the allocator knows ahead of time and allocates different registers for each task, but in that case it's not really preempting.

Re:Perl 6 is hugely ambitious, and that worries me

[Matchstick]

The reason Parrot is register based has nothing whatsoever to do with reduction in the number of opcodes. In fact, the Parrot VM opcode count is quite large, largely because of combinatorial issues. If every x86 opcode that used mod/reg/rm addressing was actually counted as (# mod/reg/rm combinations) opcodes, that would be roughly analagous to what's going on in Parrot.

Parrot uses registers for speed, that's "all".

Re:Perl 6 is hugely ambitious, and that worries me

[babbage]

The Parrot VM is a neat idea, that goes even further than .NET since it's multi-platform, and definitely will be very nice when it's finished. But I feel like it's going to delay Perl 6.

Nah, Parrot isn't the bottleneck. Parrot development has actually moved pretty fast: they quickly came up with a raw-functionality virtual machine, and at this point the Parrot engine seems to meet the basic runtime needs of Perl5, Perl6 [as specced out to date], Python, and PHP.

Parrot isn't done yet to be sure, but it's already complete enough that, for example, the employer of one of Parrot's main developers is already using Parrot as the runtime engine for their corporate software. [I'd get in to details, but I forget the details -- Dan Sugalski talked about it for the Boston Perl Mongers a month or two ago.] Likewise, there's already a mod_parrot Apache module under development that will allow Parrot targeted code to run, and run very quickly, while embedded in the web server. Longer term, one of the target languages for Parrot is Z-code, so that Parrot will be able to run old text games like Zork and Hitchhiker's Guide To The Galaxy -- with luck, this could lead to Parrot being the embedded virtual machine for portable game machines.

Parrot is, in other words, being actively developed, and there are big plans for it.

Parrot is hardly holding Perl6 back.

The bottleneck with Perl6 seems like the actual design work. Once Larry Wall puts out one of his Apocalypses, it never seems to be long before Damian Conway comes out with an explanation, including working code that can often be experimented with today under Perl5, with his Exegeses. There seems to be a ready pool of people eager to implement this stuff as it becomes available, it's just that the project is so *big* that it's taking a while for people to get anywhere with it in their spare time.

Re:Perl 6 is hugely ambitious, and that worries me

[TimToady]

...it feels like the language is expanding in every possible direction at the same time, and in the most complex way possible.

No, it's expanding in every possible direction in the simplest way possible. :-)

Seriously, there are pages and pages and pages of rambling explanations for changes to something already solid and useful, like regular expressions (which are already fairly complex as it is).

Yes, and your average regex in Perl 6 will be a lot simpler. Perl 6 is all about throwing out the unnecessary complexity in order to map the complexity of the problem onto the complexity of the solution more efficiently.

There are some gems in there, but do we really need it *all*?

Of course not. Nobody needs it all. I've never even used all of Perl 5. But all the bits we're putting in will make someone somewhere deliriously happy, because we've "matched the impedance" of the solution and the problem. And we're trying really hard to hide the bits that you don't have to know about upfront.

Do you have all the manpages on your system memorized? Do you expect to?

Perl's always been a language you can learn "small end first". That's not going to change.

Perl 6 is already coming across as much more complex than any language I've seen...

Then obviously you've never seen English. :-)

...this seems like a classic case of going off and attacking a major problem (a general, high-performance VM), before you really understand what it's for.

More like digging a tunnel through a mountain from both ends. When two groups are working hard on converging at the same point, they can usually work things out, one way or another. And the Parrot guys do understand pretty much what Parrot is for, or they would have just gone off and used an existing VM.

But Parrot's problems are small compared to the language's, and Perl 6 could come to fruition without Parrot. The Mozilla team seemed way off track for many years, but they eventually pulled together a good product (Firefox), in the end.

Our intent is not to come up with the language you'll use in six months, but the language you'll use in ten or twenty years. To that end, we've intentionally bitten off way more than any one person can chew. And we're just gonna keep gnawing on it till the thing is digested, and easily digestible by others.

Sorry buddy, this is where you are wrong.

[Fiona Winger]

Next time, you might want to try reading the article a little bit closer next time. ;P

Perl6 does not assemble to VM bytecode anymore.

Perl6 now assembles to assembly.

Yeah, but...

[Tailhook]

ever wanted to program in an object oriented assembly language?

Yes. However, some nights when I drive home from work I eye a bridge abutment thinking I'd like to bury my car in it at 140mph. So I'm not certain that whether I'd like to do something is a great way to evaluate it. What's your point?

BTW, is there a simple way to disable an airbag? Isn't there supposed to be a switch someplace? Thanks.

Re:Yeah, but...

[Thing 1]

BTW, is there a simple way to disable an airbag? Isn't there supposed to be a switch someplace? Thanks.

Well, sure, it's a three-step process (and I'm sure there's MTOWTDI):

*Click* remove seatbelt.

*Clunk* open door.

*Splat* roll out.

We need an alpha in 2004

[Ars-Fartsica]

I appreciate Damian's work in clarifying Larry's writings, but the perl 6 project has three years (timed from Larry's first Apocalypse) behind it with nary an alpha in sight.

I am sure something is coming down the pike, but making a huge announcement like a major rearchitect puts a lot of developers in suspended animation - unwilling to invest more time mastering and extending the "end-of-life'd" perl 5. Many of those people are now looking at other options.

As an aside, I'm not sure where the consensus is coming from for the new language proposals - the code samples in Larry and Damian's writings are becoming more and more cryptic. I wonder if they are making perl 6 to unapproachable by new coders.

Re:We need an alpha in 2004

[Anonymous Coward]

Anyone that is serious about learning Perl, has already learned it in the three years of waiting.

You don't pick a language because you think it'll be good in a year or two. You pick a language because it fits your current needs, and gets the job done.

Re:We need an alpha in 2004

[d00ber]

I agree. I was really starting to get worried because - up until a few months ago - it seemed they had also stopped maintaining Perl 5. Then they came out with 5.8.[123] in fairly rapid succession.

I think the combination of a long ramp to Perl 6 and no Perl 5 upgrades could have made the whole thing moot. Another year could have killed it.

Anyway, I'm glad to see Perl moving forward. For some reason Perl is the only script language I know (I've done Perl, Python, Ruby, Tcl) that I don't have to relearn. It has this strange ability to stick in my head.

Re:We need an alpha in 2004

[ajs]

I asked the same thing recently on the p6l mailing list. Larry responded with some interesting news. First off, I had not realized that he had taken a lot of time off last year for health reasons.

Second, he posted (as you can see from the link above) a full outline of Perl 6's specifications-to-be and explained that he's been spending a lot of time on A12. That's right, he's skipping over A7 (delegated to Damian) and A8-A11 (which he'll return to later) and doing the chapter on objects. This is an important part of the language, and really did need to be covered before the rest could be fleshed out. It seems that he expects most of the rest of the spec to be about as much work as A12 is alone, and he claims that's just a few days or weeks at most away from being finished.

That said, keep in mind that the cryptic things you see on p6l are the result of reading code snippits written in a language that doesn't exist yet. Every time Larry steps in and explains things, the picture gets a bit clearer (partly because Larry is a great communicator but partly because he's quite capable of and willing to cut away a lot of noise and render some signal from its remains).

Perl 6 is, as far as I can tell a lovely evolution of Perl... it's perhaps more orders of magnitude more evolved than I would have suggested as the next step, but looking at the good work it has resulted in for Parrot, I'm not sure I'd turn back.

Python/PERL users unite!

[ShatteredDream]

It's too bad that the teams had been only joking about joining forces. If the teams had worked together to create a conceptual clone of .NET wherein Python and PERL could be used interchangeably in the same runtime, the OSS developer base would be very well off right now.

Think about the possibility. First port PyQT and wxPython to parrot. You write your GUI code with Python and byte compile it to a neutral Parrot format. You need to do complex substring matching so you write some good reusable functions that take advantage of PERL's string handling capabilities and then byte compile them. Load them into the event handling code and you've got a great hybrid.

What would be really cool would be to see Java and a form of OO BASIC ported to Parrot.

Re:Python/PERL users unite!

[geniusj]

That's what Parrot is. Python and Ruby (as two examples) WILL be able to target parrot and run in the parrot VM.

Re:Python/PERL users unite!

[ajs]

No one is joking on the Parrot side. Check out the Pie-Thon

Parrot will run Python before it runs Perl, *that* should demonstrate how commited Parrot is to not just being Perl 6's back-end.

You'll be able to create a class in Python as a sub-class of a Perl 6 class which further derives from a Ruby class, and then call a method on such an object which is defined all the way up in Ruby.... no problemo. Parrot is going to change the way we choose programming languages for the tasks at hand....

Agreed, this may just be too much, too late

[Ars-Fartsica]

Perl 6 is by all accounts a new language. Yes it will detect and parse Perl 5, but we can already do that now. How many coders will follow the new syntax and features? This is no small task, I have read all of the Apocalypse/Exegesis articles end-to-end multiple times and a lot of it still hasn't sunk in. This is a major change.

Then there are the practical issues - will Parrot be fast enough and mostly bugless in time for Perl 6 to sit on top of it? I am concerned that we will need eighteen months of point releases and we haven't even had an alpha yet. Meanwhile people are looking at Ruby, Python, Mono/C# etc.

I recommend they just wrap up whatever concepts they have now and start moving toward an alpha. If we don't see one in 2004 I think most people will have moved on.

Re:Agreed, this may just be too much, too late

[TimToady]

I recommend they just wrap up whatever concepts they have now and start moving toward an alpha.

Which is precisely what we've been doing for some time now. Apocalypse 12 will be out very shortly, and it will look like a lot of new concepts, but they're mostly concepts we've been aiming at for a long time now. Get this through your noggin--it's not the conceptualizing that's the hard part. The "wrapping up" is where almost all the effort goes, because that's where the hard work of design is. Anybody can come up with a list of new features. We've had the RFCs for three years, and you know what a mess they were...

Re:Agreed, this may just be too much, too late

[ajs]

Very few people will ever learn Perl 6, just as very few learned Perl 5. What they will do is absorb the basics of the language from examples they've seen an write a basic subset. This is what happens to all languages.

The good things about Perl 6 are a) you have a rich and powerful language at your disposal that provides everything from dynamic grammar construction to advanced functional programming concepts and b) parrot will allow you to use libraries written in any other Parrot client-language.

Re:Agreed, this may just be too much, too late

[straybullets]

What they will do is absorb the basics of the language from examples they've seen an write a basic subset

This is very interessting since it's exactly what i do !

I consider myself a fairly poor coder, but still Perl helps me to do a lot of things very fast, and to a point i can say it pays a lot of my bills ! I could do most of this in VB but Perl is fun and intuitive.

Some times I need an new feature and Perl will then help me learn something new, thus making my coding skills a little better.

I realize that Perl is a good glue but not very "industrial". It's fun and all but when i look at the Rexx coder across the room, i wonder if Perl will not eventually end like Rexx, something mostly useless & readable only to old timers... And all the Perl 6 fuss with smart ass names (apocalypse, exegesis, jeez ...) isn't going to make me feel more confident about it !!

Wait & see ...

Ewwwww

[unfies]

... ever wanted to program in an object oriented assembly language? ...

God no. It's bad enough when a high level compiler attemps to guess what you want (C++, etc)... it'd be horrid if ya had to have something supposedly machine level guess...

Me either ...

[pavon]

but Parrot is really starting to excite me.

The main reason being it's potential use as a generic high level "ABI" of sorts. Look at GTK/GNOME for example. The developers choose to use C as the base language, largely because it was the easiest language to create bindings for - everything can link to C. But the problem is that C only implements procedural concepts. Anything else must be crafted from hand, like gObject. So you end up reimplementing all the features of a high-level object oriented language, in C, and often this implementation isn't even as efficent as the high level language's implementation. On top of that, when create bindings for a high level language, you wrap all of these gObjects inside of a native language object, and end up with double the overhead. So what it comes down to is that you worked four times as hard, and came up with something twice as slow, just to be able to have an object oriented library that many languages can link to.

Parrot has the oportunity to be for object oriented languages, what the C ABI has become for procudural languages - a common interface for programs of different languages to communicate. Imagine having high level libraries, that can be efficiently used by python, perl, ruby, befunge. Or having scriptable applications that are not just scriptable by one language, but by anything that targets parrot.

When you add to that they fact that it will be cross-platform, and more efficent then most of these high level languages were to begin with, it's hard not to get excited.

Re:Me either ...

[pbox]

Those are the promises of Parrot developers. It is however not that hard (but less wise) to get excited about promised values. It is better to get excited about delivered promises...

Parrot is not the first try at this "execution machine" model, and I suspect not the last one either. The only ones that survived (so far) are the ones that target a single language. Python, Java comes to mind, while mono and .net is barely limping along. Maybe there is more to this high failure rate...

At the same time it would be really exciting to see the birth of the first SUCCESSFUL cross-platform execution machine...

Re:Me either ...

[aled]

I don't know if you are talking about invoking scripts from Java, in which case you a lot of alternatives, from beanshell to jython (the python implentation in Java) and most of them could be run through BSF to have an uniform API.
DinamicJava on the other hand is an interpreter of a superset of Java.
I don't know what you find annoying: compiling and executing. That's the norm for most programs. Java programs are Just In Time Compiled but that is done transparently by the virtual machine and is faster than interpreted.

Re:Me either ...

[jadavis]

does anyone have information about the perl6 c interface? I use the C interface to python constantly; it's what really got me into python. I remember perl's was clumsier (there's a self-defining word if I ever saw one :) so I'd like to see it improved.

Conclusion/Highlights

[No_Weak_Heart]

Form follows format. From the end of this Exegis, some hightlights:

"Report generation was one of Perl's original raisons d'etre. Over the years we've found out what format does well, and where its limitations lurk. The new Perl 6 form function aims to preserve format's simple approach to report generation and build on its strengths by adding:

• independence from the I/O system;
• run-time specifiable format strings;
• a wider range of useful field types, including fully justified, verbatim, and overflow fields;
• the ability to define new field types;
• sophisticated formatting of numeric/currency data;
• declarative, imperative, distributive, and extensible field widths;
• more flexible control of headers, footers, and page layout;
• control over line-breaking, whitespace squeezing, and filling of empty fields; and
• support for creating plaintext lists, tables, and graphs.

And because it's now part of a module, rather than a core component, form will be able to evolve more easily to meet the needs of its community. For example, we are currently investigating how we might add facilities for specifying numerical bullets, for formatting text using variable-width fonts, and for outputting HTML instead of plaintext."

'cause i'm lazy, that's why

Re:Camel book :]

[dpuu]

You can read about the new regex syntax in exegesis 5 (and its corresponding apocalypse)

Perl remains beautiful

[Dr. Zowie]

Perl is the most beautiful language I've had the pleasure of learning. Lots of folks complain that perl must be ugly since it's so easy to write really butt-ugly code in it; but it's also very easy to write mindblowingly powerful, clear code. Enough thought has been put into the language design that you can abuse most aspects of the language and still get what you wanted.

It's easy to forget, when using perl, just how, well, tedious, it is to work in C (let alone C++) or shell or Java or even, yes, Python.

The exegeses so far have been full of fabulous goodies to use and abuse. The main problem, as others have pointed out, is that perl6 is still largely vaporware.

OO Assembly?

[gidds]

ever wanted to program in an object oriented assembly language?

No, but if I wanted to, I could already, thanks.

Re:OO Assembly?

[ajs]

There's several probelms with that theory. First off, the Java VM is designed to run Java and not much else. This means that if you want to write JAVA, but in and assembly-like way you're all set. Parrot by contrast is designed to run any dynamically typed programming language, so you can write whatever you like for it.

Also, the JVM is not really a very good development environment. It is, for the most part, only used as a back-end. Parrot is designed from the beginning to be programmed in because there will be many times that it makes sense for a library to target Parrot with chunks in C for performance reasons.

To this end Parrot provides a paper-thin abstraction called IMCC which allows you to write code without having to worry about register spilling, etc.

Give Parrot a try, and when you have I guarantee playing with stone knives and bear-skins won't seem nearly so appealing anymore.

Is text formatting relevant

[jfdawes]

After reading through a lot of this article and being blown away by the genuinely powerful and, dare I say it, awesome abilities that have been given to the form function, I'm left asking myself:

"Who gives a crap?"

Most the projects I've worked on for the last few years have predominately displayed text in web pages. Almost all the reports produced have been generated as HTML and then printed as necessary. The only text output done has been generally into log files, where you really don't need a lot of formatting.
While this is obviously a really great, well thought out piece of coding, ... that's all it is, some geek's personal project that doesn't really seem to have much relevance to the real world.

Maybe I'm just missing a huge community of people who spend most of their time looking at command lines and printing out reports in fixed width fonts.

Re:Is text formatting relevant

[ChaosDiscord]

Perhaps the biggest thing I took from this is that the increasingly specialized and unused fixed width formatting functionality in Perl is moving out of the core language and into a powerful module. Those of us who don't need it will never need to worry about it; those who need it will find it actually improved over previous versions. Finally "write" will be free in Perl to mean something slightly less crazy.

That said, I can think of one important use for fixed width formatting: email reports. Sure, you can use HTML, but you really ought to also provide a plain text version. Many (arguably crappy) web mail clients will only display the plain text, ditto for us crotchety old command line mail tool users. With a bit of care you have have your table heavy report in shiny HTML and your functional text all in one MIME encoded message. (Remember that "reports" includes things like your email receipt from an online store.)

Re:Is text formatting relevant

[Miniluv]

Ever notice html is just a lot of text? Ever notice that tables are what lots of reports are done in? Ever think that instead of some bizarre loop generating nested table elements so the boss can comprehend the data, you could now just use form?

Obviously not.

'Weak vs. Dynamic': Type Systems

[jstarr]

Not quite. Weak is not the opposite of dynamic, but the opposite of strong. Type systems may be either weak or strong, and may be either dynamic or static.

A weak type system will allow implicit type conversions, even those that are 'lossy' or improper. For example, converting a float to an int without requiring a cast. Or, more importantly, treating memory references (pointers) identically to integers. Pointer arithmetic is an abuse of a weak typing system.

Strong typing requires explicit casts and will throw errors where casts do not appear. Java, Lisp, Python are all strongly typed. Haskell is _really_ strongly typed. When you cast a object to type Object in Java, you are losing type information, but you are doing it _explicitly_.

C, Pascal, and Java are statically typed. Variables are created with a specific type in the code, not on demand. Python and Lisp are dynamically typed -- a variable's type is determined at run-time.

For example, in C:

int foo( int a, int b );

declares a function that returns type 'int' and takes two arguments a, b, both of types 'int'.

In Python:

def foo( a, b ):

declares a function that may or may not return a value (and whose type is known only at run-time) and takes two arguments, which may be of any type (although, internally, the program likely assumes a type).

There are some quirks in the type systems of many languages. In Java, for example, "str" + 3 doesn't have any normal meaning, but the developers have defined any operation using a string as concatenation. In Python, and in most languages, such an expression will either return an error on compilation (static) or when running (dynamic).

However, all combinations are possible and type systems are a fertile area of research.

Yes you are

[hummassa]

(missing a huge community etc.) many, many projects need the ability to write in fixed-width fonts to a printer, p.ex. the output of your supermarket cashier ticket / credit card ticket. This is a real world-class application to formats (because those little printers are best suited to the job and they write in monospaced). There are others, many, many others.

Re:Meanwhile PHP surges ahead

[daperdan]

Check out Amazon. The net's largest retail site seems to put a heavy emphasis on Perl. You don't see a whole lot a php in the job requirements there do you? There may not be big growth in Perl but it's still in big demand.

Judging by the number of sites that depend heavily on Perl I can assure you that it's not going to be sidelined soon.

It's true that PHP is a fantastic language for small sites. Mod_perl is a hog when it comes to memory but memory is cheap and mod_perl is tried and tested. There's a reason slashdot uses mod_perl to power its site.

Re:I tried, but I failed

[erikdotla]

"Like Perl but readable" is an oxymoron. If it's readable, then it's not like Perl.

Re:"end-of-life'd" perl 5?

[rgmoore]

And don't forget about Ponie, the project to build a Perl 5 interpreter on top of Parrot. That means that Perl 5 should continue to be useful even if the existing core code is eventually scrapped. This, of course, is one of the principal advantages of having a multilingual VM; any language that can target that VM can be maintained with much less effort.

Re:I 3 Perl

[typobox43]

You obviously don't come here often...

Re:I 3 Perl

[D'Sphitz]

Obviously you don't come here often enough to know you could check how often I come here by clicking my name.

You obviously don't come here often...

Re:I tried, but I failed

[jadavis]

I like python and that's what I mostly use where applicable.

One thing I've come to realize though is that perl is unique among the languages that I know. Perl is the only computer language I know of that is so complete as a language.

Like a spoken language, perl is highly context-sensitive and one idea can take many different forms. It's deterministic and precise, of course, but it has a much more natural feel.

For example:

while(<STDIN>) {
chomp;
print;
print " ...\n";
}

is a valid perl program, yet we never go through the details of where exactly we're storing the standard input, nor do we have to explicitly state what we're "chomp"ing, nor what we're printing. It's all obvious, what ELSE would we be chomping or printing? In most other languages, like C or python, we'd have to store them in a variable, or do a complex function call or something.

So perl uses lots of implications and context, like a spoken language does. It's really a marvel in some ways, because it's a group of people agreeing on a real language, rather than simply a set of commands.

I love python, but it really is just a structure, there isn't much language to it. I'm not even saying that it's a weakness.

I'm just saying perl is unique because it's actually a full language that allows very imaginative expression, much like english. Think if Shakespeare was trying to write in python! Nobody would care, Macbeth would be about 12 lines long. I don't know how all this relates to the cost-effectiveness of programmer time, but it's interesting, that's for sure.

Object Oriented Assembly does/did exist

[pkphilip]

Turbo Assembler (later versions) from Borland did support a level of object orientation. It actually shipped with examples of object oriented assembly code.

OOPs in TASM

Re:Deja vu all over again ....

[TimToady]

Sure, I remember it. And that's why Perl has formats. Is this a problem for you?

Why Perl reports are *so* important ?

[master_p]

I don't get it, since I have never worked with Perl, so I am asking the perl programmers out there: what is so special about plain-text reporting ? there are fine tools out there that can produce beautiful html reports that plain text will never be comparable to. I understand that text reports may have their uses in the back office, but that accounts for a small percentage of overall reporting.

Furthermore, 'reporting' is a not a feature of a programming language. The same report package could be done with C++, for example. Will Perl 6 bring something *really new* in the programming languages department ?

Academia is Backwards

[Vagary]

Maybe they all go off and become Perl programmers instead of going to grad school?

But seriously: academia has very little room for people with interests like Damian's. Academia does not encourage the kind of research that would make professors better teachers, instead the research should be as esoteric and far from undergrad subjects as possible. And grad students who like to "hack" are told to get over that impulse despite the fact that it would probably make them better teachers.

Re:I tried, but I failed

[TimToady]

Equivalent Perl 6:

class A {
has $.a is rw;
}

class B is A {...}

$b = B.new;
$b.a = 1;
say $b.a;

Re:Unicode operators!

[TimToady]

No, Larry is personally in favor of letting users add Unicode operators. Big difference.

Re:perl can do text/plain at last

[chromatic]

We're not going in numerical order anymore; we're going in order of importance. Apocalypse 12 should come out in the next few weeks. That's everything objects.