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

I 3 Perl

[poptix_work]

This was an excellent read.. glad to see perl is keeping up with the times!

Re:I 3 Perl

[D'Sphitz]

story posted @ 06:36
your comment posted @ 06:36

You read all 13 pages of that story in less than a minute? or are you a karma whore?

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 3 Perl

[poptix_work]

I donate to /. (aka, subscription) I saw the story in the 'mysterious future' =)

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

[aled]

That most be a personal attribute of the author because sense of humor in scripting languages is fully a property of "Monty" Python.

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

[D'Sphitz]

and C) you know where to put it yourself

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

[jroller]

man perlop

Binary "+" returns the sum of two numbers.

Is that not clear enough?

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

Perl the only language I'm aware of that is possible to learn and master directly from the man pages.

Re:The best thing about Perl

[ichimunki]

From 'perldoc perlop': Additive Operators, Binary "+" returns the sum of two numbers. Not to be argumentative, but what else do you need to know? There are a lot of potential subtleties due to the fact that $b and $c could be references to all kinds of things, but do you really expect some sort of essay on the topic when reading all the other documentation around this makes it clear what those subtleties might be?

Re:The best thing about Perl

[ajs]

More to the point (though you're right ichimunki), those essays exist in clear, well-written form as "perlref", "perlsyn", and many other "man pages" (actually POD documents which get turned into man pages by pod2man) which are all described in the "perl" man page which serves as an introduction and table of contents for the rest of the core docs.

Re:The best thing about Perl

[tbone1]

If you are a programmer who can't understand

• $a = $b + $c;

then give up and go into management.

Re:The best thing about Perl

[haystor]

If you have a problem with that line of code it arises from the fact that Perl expects you to know what you're doing and will allow you to do it.

The simple answer to what that does is: it does what you expect it to. Perl is not a "safe" language in the sense that it will stop you doing something. It is a different language entirely in the sense that it tries its best to complete whatever you ask it. If you want to add a string to a reference it will try without complaint, even if the result is meaningless. To some of us, this is what computers are all about.

Assume the programmer knows what they're doing and try to get the job done. That's a good goal for a language.

Oh, and as for documentation, I consider the error messages and warnings to be documentation as well. And in this respect Perl outshines *all* other languages.

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

[cygnus]

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

are you kidding? have you not seen Javadoc? it does precisely what you describe... and with XDoclet, you can do full-blown code generation right from your documentation, which is conveniently embedded right in your source.

Re:The best thing about Perl

[Ed Avis]

The simple answer to what that does is: it does what you expect it to.

That's all very well, but 'what I expect it to' is not documented anywhere, so you can't say that Perl has complete documentation, which is what we're discussing. I'm not arguing against the merits of Perl, just pointing out that in a formal sense it can't be said to be well documented.

Re:The best thing about Perl

[Ed Avis]

perlref, perlsyn and the others are useful but there's no way they completely specify perl's behaviour. You couldn't write a compatible perl implementation using just the manual pages - it would have to be trial and error comparing against the existing implementation.

Re:The best thing about Perl

[ajs]

"have you not seen Javadoc? it does precisely what you describe"

And yet the vast majority of Perl programs and modules I run into are faithfully documented in detail while the same is not true for most of the Java that I've tried to use (I will note that that's not NEARLY as much as I've been exposed to Perl over the last 13 years).

As far as I can tell this is because:

1. Javadoc isn't well suited to man-pages
2. Javadoc is NOT just simple text with occasional markup
3. Java doesn't have a strong culture of collaborative development communities which lead to good documentation

I guess, in short, it's just a cultural difference compounded by some unfortunate design choices.

Still, it's good that Java has something. Most languages don't.

Re:The best thing about Perl

[cygnus]

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

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

2. Javadoc is NOT just simple text with occasional markup

could you explain further? because it looks that way to me...

3. Java doesn't have a strong culture of collaborative development communities which lead to good documentation

hit this stuff: jakarta. it's excellent.

Re:The best thing about Perl

[haystor]

Ah.

I think that like most people, I've only read formal documentation as a last resort. I suppose very rarely I have a highly technical nuance of code that requires a formal definition.

I don't know what to say. It seems Perl is best learned by immersion and topical vocabulary rather than a book of grammar.

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

Re:The best thing about Perl

[Ed Avis]

You're right that it would not be practical for the documentation to cover every case of what happens using the + operator: that's because Perl is a big language and it has hairy syntax and semantics. A smaller language like Scheme or Forth can be documented in its entirety, but Perl can't be short of saying 'look at the implementation'. That's why I don't think it is right to say that Perl is the best-documented computer language.

Re:The best thing about Perl

[Ed Avis]

I'm not particularly looking to complain about Perl - I use it more than any other language - I am just questioning the assertion that Perl is better documented than any other language. It isn't, because there are very many aspects which aren't documented rigorously anywhere and are defined by the implementation. Many other programming languages do have a complete specification.

Re:The best thing about Perl

[cygnus]

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?

yes, and that's why there are a whole suite of tools at places like doclet.com to do just that. XML, RTF, PDF, etc.

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.

HTML is easy... among programmers, who can't manage a <PRE> tag? and that stuff isn't necessary at all... the text can be formatted or not, as you see fit. and tools to create different types of documentation have already been written, so you never have to worry about parsing it.

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

what's not free-form about it? you just type /** and whatever you want to say, and then */. if you want more structure, it's there for you. if you just want to blatt something out, that's fine, too.

Are you seeing the differences here?

other than the fact that it's at the bottom of the document rather than on top of the thing it actually describes and that that syntax is more verbose, not really...

You also mentioned Jakarta, which while very cool, is a sort of rebelious subculture within the whole of the Java community

that's sort of an uncharitable assessment of the stewards of the java servlet api and reference implementation, isn't it?

Re:The best thing about Perl

[ajs]

I've never come across any example of what you describe. I've certainly seen people relying on bugs or "features" that crept in by accident, but the same is true for gcc. I've never seen real Perl functionality that isn't in the docs... at least not in a production release.

What's more is Perl has a history of slapping people down for relying on such things by deprecating them and then removing them (e.g. the recent discovery that some people were relying on "my $foo = 1 if 0" to behave like a static initializer!

Rely on anything that's not documented in the perl documentation, and you WILL get burned.

Re:The best thing about Perl

[ajs]

that's sort of an uncharitable assessment of the stewards of the java servlet api and reference implementation, isn't it?

No, it's an uncharitable assessment of Sun's treatment of them.

Bottom line: there are 6752 modules on CPAN. I invite you to tour them and evaluate the quality of documentation relative to that available for all of the Java stuff... it's a stark contrast the depth and clarity that you get when you don't force people into a box. If you don't see the box, that's cool... carry on.

Re:The best thing about Perl

[Ed Avis]

I was thinking of the various bug reports I've made to rt.perl.org, eg #23061, or #23140 (which is documented, but obscurely). Sometimes there is no documentation to say whether a behaviour is a bug or correct - the implementation defines the language and so any bug report for it is by definition invalid :-(.

Re:The best thing about Perl

[ajs]

I have to admit that figure shocked even me... over 6000 modules available for Perl?! Wow!

Ok, so I dug some more and I believe that number now. Here's a summary of the most popular top-level namespaces in which many of these modules live:

Summary:
305 Apache
254 Net
178 XML
166 Text
151 Class
150 HTML
135 Lingua
133 CGI
131 Tie
127 Math
108 File
107 Tk
101 Mail
101 Bundle
100 WWW
99 Data
95 Acme
92 DBIx
89 Crypt
67 POE

And the stunning thing is that that doesn't even cover many of the things I use every day (PDL, Gimp, CPAN, Parse, Time, MLDBM, etc.) as well as modules that ship with Perl (threads, strict, IO, Storable, etc.)

Man, I just love CPAN.... imagine your joy when it's all available to you in whatever language you please through Parrot!

Re:The best thing about Perl

[ajs]

Sounds cool. I think there was something like that for pod at one point too. I suspect it was abandoned because Perl already has a comprehensive build and test system and integrating the unit testing with the POD documentation would have meant removing a lot of the flexibility of the testing system or inserting a lot of hair into the POD documentation (thus defeating it as Plain Old Documentation).

I can see the merits of both approaches. Good to see There's More Than One Way To Do It...

Re:The best thing about Perl

[cygnus]

Bottom line: there are 6752 modules on CPAN. I invite you to tour them and evaluate the quality of documentation relative to that available for all of the Java stuff...

i have, and i've been quite frustrated by important things i've felt are omitted sometimes. i was having a hell of a time with DBI a while back and had to experiment to find out what i needed... i haven't had problems like that with JDBC. but i'm sure things go the other way sometimes, too. a win for java, i think, is that since there's less obfuscation possible in java syntax, a peruse of the source often reveals a lot of answers, too. if someone decided to play Perl golf one day and didn't provide comments, you're stuck. actually, in my case, even with the comments, i'm stuck if someone played Perl golf. :)

it's a stark contrast the depth and clarity that you get when you don't force people into a box. If you don't see the box, that's cool... carry on.

i'm still missing the part where you conclusively pointed to the box. all i'm getting so far is that you like the syntax better and the ability to intersperse comments throughout the file. but those seem to me to be personal preference issues. otherwise, it seems to me that both are equally capable and have expansive toolsets that utilize them.

Re:The best thing about Perl

[ajs]

there's less obfuscation possible in java syntax

That's just wrong. Plain wrong. Unless you can show me at least a casual proof of that, I'm going to assume you just don't know what you're talking about.

Of course, if you just mean "I think Perl syntax is ugly," that's your perogative, but don't go stating it as fact, much less as a fact regarding what is or is not possible. You could argue that certain aspects of context-aware lexical transition in and out of quote-like operators constitute a degree of semantic obfuscation and build from there, but that's such a small aspect of the language that it's really not worth quibbling over, and certainly not the basis for such a broad assertion on your part.

Other than that we seem to have come down to differneces in taste and personal experience. Like I said... carry on.

Re:The best thing about Perl

[cygnus]

at least a causal proof? what more could there be than a causal proof?

the most you're going to get out of me is that there's an obfuscated Perl contest and no counterpart for Java... that says something about both Perl (operators often have side effects, there are arcane variables like $[ that can blow everything you normally assume about the language out of the water, etc.) as well as the community that uses Perl (there's sort of a celebration of difficult to read code going on).

you don't *have* to write hard-to-read code by any means, however.

Re:The best thing about Perl

[ajs]

Well, let's look at those:

With 23061, the docs are pretty darned clear:When a constant is used in an expression, perl replaces it with its value at compile time, and may then optimize the expression further.It doesn't get a whole lot simpler than that. Granted, there is some wiggle-room left, but the perimeter of that wiggle room is clearly defined, and below that (just as below the definition of much of C's setjmp and longjmp) you enter implementation-specific regions.

It is certainly reasonable to submit enhancement requests around such things if you think perl is implementing Perl in a way that is counter-intutive, but any program that implemented the spec according to the documentation above would be conformant.

As for #23140 you are complaining that something that behaves EXACTLY as documented is not the way you want it. I understand that, but the documentation is clear on what happens to $1..$9 when you enter a new regex...

It seems like you're saying that because there are well documented edge-cases that can be confusing to programmers that the implementation and the documentation aren't in sync. I would disagree strongly with that assessment.

Mind you, I'm not disagreeing with your assertions in either of those bugs (I haven't thought either one through enough yet), but you seem to be upset about something that isn't quite the content of your bug report....

Re:The best thing about Perl

[ajs]

Quote you: "the most you're going to get out of me is that there's an obfuscated Perl contest and no counterpart for Java."

[link mine for emphasis] Note, I'm not familliar with a programming language that lacks such a contest, and C was the first (IOCCC was famous before Perl existed).

Quote you: "operators often have side effects"

You don't actually program in Java, do you? This is just getting silly. Are you saying that Java operators have no side effects?! Let's try out "a=b" for starters....

"there are arcane variables like $["

One man's arcane is another man's "perfectly well documented and easily found via the table of contents, and no it doesn't affect the whole program, read the docs"... but to each his own.

That's beside the point though. You spoke not of variable names, but of syntax.

"as well as the community that uses Perl (there's sort of a celebration of difficult to read code going on)."

Nope. I highly disagree. There is humor and entertainment in whiddling down people's few-line RSA encryption algorithms into the minimum line-count so that it fits on a T-shirt for political reasons... there's command-line usage where how little you type matters, but I don't think anyone celebrates difficult-to-read code in the large... more to the point, those who upload such code to CPAN get the words "maintainable code" explained to them rather harshly.

Again, I was not talking about your feelings about the language or its developers. You said, "there's less obfuscation possible in java syntax". That is incorrect, as far as I know... but feel free to PROVE that wrong.

Re:The best thing about Perl

[cygnus]

Again, I was not talking about your feelings about the language or its developers. You said, "there's less obfuscation possible in java syntax". That is incorrect, as far as I know... but feel free to PROVE that wrong.

nah, i'll just go on thinking it by myself. :)

Re:The best thing about Perl

[ajs]

Ah ok... I thought we were discussing this like rational people, not just flinging random phrases around. Cool, that means I can leave now.

Re:The best thing about Perl

[cygnus]

*I* was discussing this like a rational person, and being diplomatic. you were being a fanboy were saying "Perl HAS TEH BEST DOCO EVAR!!" and wouldn't admit other languages could possibly have feature parity. and then i apparently stepped on your toes by suggesting that Perl might be difficult to read. newsflash: perl has that reputation. google "perl ugly syntax" and see how many results you get.

*then* you ask me to "prove" my claim. talk about picking nits... i'm obviously not using the term 'obfuscation' in it's mathematically provable sense but it's plain old dictionary one. excuse me for speaking the plain english language in an arena where it could be confused with pedantic jargon. this is silly.

I tried, but I failed

[(1337) God]

I just couldn't wrap my brain around Perl.

I ended up giving up and learning Python instead.

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.

Re:I tried, but I failed

[Anonymous Coward]

Yeah, except for the 75% of its operators that are cribbed straight from Perl...

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:I tried, but I failed

[Dr. Zowie]

There are two reasons you might find perl code unreadable: (1) you don't know enough idiom; or (2) the coder was sloppy. My cow orkers used to always complain that perl looked like line noise; then they learned regular expressions.

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.

Re:I tried, but I failed

[Cobralisk]

Macbeth would be about 12 lines long. I don't know how all this relates to the cost-effectiveness of programmer time...

Everyone knows programmer cost-effectiveness is measured in lines of code.

Re:I tried, but I failed

[xteddy]

You can translate this into Ruby pretty easy:

while readline do
chomp!
print
print "...\n"
end

I think it's OK, if small scripts use implicit $_ to get the job done fast. But if programs get more complex, Perl gets into your way more often because of the context sensitivity.

Consider this code snippet:

while () {
chomp;
do_something();
print;
print "...\n";
}

Now if do_something does something like this, you have a big problem:

sub do_something() { $_ = 'void'; }

Ruby shines in that area, because small scripts can be refactored to more complex programs very easily.

If you want to move your script from an imperative style to a more class based object oriented design, you can just begin to add class definitions like

class A

attr_accessor :a

end

class B A
end

b = B.new
b.a = 1
puts b.a

at the top of your script. In Perl you have to go through lots of @ISA-orgies and have to define default constructors and accessors manually. And you end up pretty fast with a big mess.

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:I tried, but I failed

[jadavis]

Uh.. that wasn't exactly what I was implying. First, I said "All this" (referring to other aspects of my post) and second, I said "I don't know", meaning that I'm not even trying to relate any of this to programmer cost-effectiveness. My post had absolutely nothing to do with programmer cost-effectiveness, and certainly didn't try to tie it to lines of code.

Re:I tried, but I failed

[rk]

Ha! I've used regular expressions for years and I still think they look like line noise.

Powerful? Absolutely. Expressive? You bet. Elegant? Maybe. Beautiful? No freaking way.

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.

Re:Uh...

[onash]

the real first parameter to every C++ member function is the (hidden and implicit) this pointer - not every member function, as static class functions don't need a this pointer

as you point out Object Oriented programmers can write OO code but that doesn't mean that the encapsulation that is possible with C++ can be used in C. The Linux code is a good example; it is Object Oriented but uses function pointers instead of virtual functions which makes it difficult to understand

Object Oriented design isn't Object Oriented programming.. it's just a part of it

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

Re:I predict...

[aled]

But that's the irony, it usually isn't.
Oh well, this being /. and talking about Perl I'll be waiting the karma whipping.

Re:I predict...

[rokzy]

the beauty of Perl is that it's very flexible. of course you *can* write massively obsfuscated code, but that's like saying linux is crap because the admin can fuck everything up with rm -rf.

if you want, you could write Perl code that reads just like English (with the exception of regular expressions, but they're so powerful it's worth it).

Re:I predict...

[aled]

That's why I use Perl when I need a quick hack. I used to do some few pages scripts to process files that are used rutinely but now we will port those to some other language, maybe Java. I prefer to pay the price in "verbosity" to have more easily maintained and reusable programs. I still will use Perl to do fast one-timers. The right tool for the right problem.
I have seen a little Python and Ruby, just still not enough to do all the stuff, but personally I like more Ruby. It looks like a cross of Perl and Smalltalk.

Re:I predict...

[jbrocklin]

I agree completely, perl is just fun to code in! I've had to use asp at work here for the past month or so, and while it was incredibly easy to learn, I kept finding myself digging through books/websites to find something that I could have done in perl very quickly. Part of that is definately due to me haveing much more experience with perl though. But it just wasn't fun to use, as it seemed incredibly backwards in some cases. Though other things were very nice (and much like PHP). I've tried ruby, and looked at python, but I'll stick to perl, C, and C++ to get my work done.

Regular expressions are also cool...not a way to impress the ladies though...but imagine a world in which it were! How cool would perl coders be then? All of these people would be the Hugh Hefner's of the world!

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

[Unoti]

Java only forces you to be a little verbose. Try COBOL! You're right though.

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

[Shut the fuck up!]

Yeah, of course it was a joke. I am a full time Perl programmer. I never write unreadable code, it's well commented and other developers usually have no trouble figuring it out. Even people without a lot of Perl experience. Having and enforcing a coding standard is key though. Amongst many other things, I get very unhappy with my developers when I see things like $_ in the code (especially when it is invisible). Like any other language, you just have to keep on top of things and do things the right way.

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

[crass751]

I hate verbose languages. My VB code would be much more readable if MS had decided to use curly brackets instead of words to end blocks.

That being said, I'd rather hack in perl any day of the week over most other languages. Stuff just gets done, and it gets done relatively quickly.

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

[de Selby]

I hate verbose languages. My VB code would be much more readable if MS had decided to use curly brackets instead of words to end blocks.

Or even just indentation.

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

[Anonymous Coward]

Here is the main point of the parent.

but too much verbose code can be very confusing

Are books confusing to you? What does it mean that verbose is confusing, verbose can not be confusing. That's why AppleScript is not confusing, it is designed for new programmers and extremely verbose.

The reason why perl is confusing is partly because of the $, @ etc... and partly because you use regular expressions all the time even though it is not needed. Regular expressions can be useful sometimes, but in general it makes the code unreadable. In addition, the variables like $_ $: $; $] $[ ... are all meaningless to lots of people. Please don't be an idiot and try to correct me that some of those variables do not exist, I know, but there are plenty of variables that start with $ and ends with another characters. Similarly the same with @. For strings like say $aString you want to be able to use $aString[20] to access the 21th character. Also things like $aString.DeleteAllSpaces() is more intuitive then $aString=~s/\s+//g; In other languages you can still use regular expressions, in perl you must use them.

Trying to defend the perl even though these obvious problems may be good on slashdot, hovewer if you look at people in the industry and education, many people don't consider perl to be a serious language. That's a scripting language, like VB and VBA and people use it for that purpose only.

Just because you say that perl is easy to read or write on slashdot will not change the problems. So even though you don't realize, what you are doing is actually hurting perl.

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

[aled]

Is boring only when you are doing stable, proven things with it. I can have a little fun sometimes but my customers may not apreciate it.
But judge by yourself, look a small sample of what's coming. How does this compares with perl and how much clearer it seems? less the comments, of course :-)

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

[pompousjerk]

use strict; exists for a reason.

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

[jadavis]

That's one thing that's always intrigued me about perl, the $_, particularly in the case where it's assumed to be the variable you're acting upon.

It's common when speaking to make certain assumptions, like when someone says "Get me that screwdriver", then you assume that he means for you to get the screwdriver. I don't see it as inherently bad when communicating with computers.

Is there some unwritten law among perl writers now not to use those semantics? It's been a while since I've done much perl; now I always use python. I'd be disappointed if I went back to perl and it looked just like python with curly braces. That would be no fun, I'd just stick with python in that case :)

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

[aled]

Less lines doesn't means clearer. Most programmers will understand what the program does with little knowledge from Java, would it be as obvious with the Perl 5 liner?

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

[haystor]

The current style of java "in the industry" is to provide multiple layers of abrstraction.

Go to a webpage lookupData.do

This looks up a class LookupDataAction verified by LookupDataForm.

This calls LookupDataSessionBean.

Which uses a JNDI interface to find the proper classes for "lookupData". This turns out to be LookupData.

This looks up the data, returns the results to be displayed in LookupData.jsp.

This is the verbosity that people complain about with Java. The defense is always that it is great for abstracting out parts of a project to different levels of people.

The truth is Java is more about misdirection than abstraction. But hey, a lot of code gets written, so they must be productive.

There is no need to defend Perl though. There are lots of people getting work done with it that don't know better.

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

[Hezaurus]

public static void main(String[] args)
{
Scanner sc = Scanner.create(System.in).useDelimiter("(\\W|\\d)+ ");
final HashMap<String,Integer> map = new HashMap<String,Integer>();
while (sc.hasNext()) {
String word = sc.next().toLowerCase();
map.put(word, (map.containsKey(word) ? 1 + map.get(word) : 1));
}
ArrayList<String> list = new ArrayList<String>(map.keySet());
Collections.sort(list, new Comparator<String>() {
public int compare(String s1, String s2) {
int c = map.get(s2) - map.get(s1);
return (c == 0) ? s2.compareTo(s1) : c;
}
});
for (String word : list)
System.out.printf("%7d\t%s\n", map.get(word), word);
}

How is it now? I ripped all the annoying comments to give it a more 'perlish' look? There're 12 lines of code. 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. (Even if the Java's original clarity is seriously obscured by these 'new' bells'n'whistles like static imports and templates. I like the new for loop though..)

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

[xteddy]

But it's absolutely unclear what it does if the reader doesn't know what compareTo and compare are supposed to return. This program is so horrible: lots of unecessary comments and the comments that are required to understand it, aren't there.

The funny thing is, that it uses generics and the new for (a : b) construct, otherwise it would look even more horrible with casting and iterator verboseness. That's one of the main weak points of Java: It requires lots of unecessary keywords to do the easiest things. It doesn't support codeblocks, so the programmer has to define an anonymous inner class and declare the variables final if they are to be used in the closure. And the stupid comments make the purpose of the program even more unclear.

That's an example of clear and short code (in Ruby of course):

count = Hash.new(0)
ARGF.read.scan(/[A-Za-z]+/) { |word| count[word.downcase] += 1 }
# Sort words most frequent first, than lexicographic order and print
# the results.
count.sort_by { |word, count| [ -count, word ] }.each do |word, count|
printf "%7d\t%s\n", count, word
end

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.

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

[doom]

jadavis wrote:

That's one thing that's always intrigued me about perl, the $_, particularly in the case where it's assumed to be the variable you're acting upon.

It's common when speaking to make certain assumptions, like when someone says "Get me that screwdriver", then you assume that he means for you to get the screwdriver. I don't see it as inherently bad when communicating with computers.

Is there some unwritten law among perl writers now not to use those semantics?

No, not that I've ever run into. Using $_ as the default variable to operate on doesn't cause problems as often as you might think. I was stung by that just once, about ten years ago -- I went back to something I'd written and inserted some lines of code, forgetting that I'd decided to pass some information from one chunk to the other by just leaving it in $_.

Mostly the solution is you just don't do it that way: you use $_ to hold information locally, within a small chunk of code, to keep from repeating yourself a lot ("do this to *that*, do this other thing to *that*, now do *this* to *that* again).

The linguistic analogy you bring up still holds... you use pronouns only when it's clear what you're referring to. You don't come back a day later and say "How's it going with that?" and expect to be understood.

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

[doom]

JInterest wrote:

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.

So, I'm just curious here... do you know for yourself that this is true, e.g. you've been handed off a Java project written by someone else and you've had no trouble dealing with it? (Note that this hypothetical presumes that someone is capable of finishing a project written in Java, and that's not so clear to me either, but I'll grant it as a premise.)

(I hear things like this repeated a lot, it would be nice if someone would prove it. Would it be too much to ask for a "computer scientist" to study the issue, and present some data that shows their claims are correct?)

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

[rgmoore]

I can't speak for anyone else, but the reason that I avoid using $_ is because of scope problems. $_ is made local when perl automatically substitutes something into it (i.e. with map, grep, foreach without explicit variable asignment, etc.) but otherwise it's global. The worst thing is that it's a global variable that careless programmers are especially inclined to use without a second thought about the consequences. After spending a few hours tracking down a bug caused by this exact kind of carelessness (exclusively my own; I can't blame anyone else) convinced me to avoid using $_ except in the narrowest cases.

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

[ahdeoz]

until indentation is visible, it will be hard to read. Granted, there are editors that can distinguish a tab from a space, but not a tab from an indent that isn't really there,

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

Re:ruby! ruby!

[metamatic]

I'd have switched to Ruby too if it had innate support for Unicode.

Re:ruby! ruby!

[chipace]

Ruby is to Perl what AAC is to MP3. It's certainly better, but is it worth the switch? There is just so much work (documentation,libraries) already done in Perl.

I don't mind switching, but Perl has yet to let me down.

Re:ruby! ruby!

[davegaramond]

I agree. Basically, of all the projects/subprojects for Perl6, Parrot will be the most successful and useful. Perl itself has lost many of its mindshare, and Perl6 isn't helping. It's more complex, weird in many aspects, even more obfuscation-friendly, etc. But I can't wait for Parrot either...

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

It's Not Assembly Language

[Anonymous Coward]

Programming in assembler allows the programmer to create machine instructions tailored to a specific processor. This allows her to do things that are beyond the capabilities of any JIT optimizer or bytecode interpreter. If it assembles to VM bytecode, it's not assembler.

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.

Re:C++ is object oriented high level assembler

[sholden]

In that it rapidly spreads destroying C completely?

Re:C++ is object oriented high level assembler

[Michael Woodhams]

Older quote:

"C is a language that combines all the elegance and power of assembly language with all the readability and maintainability of assembly language"

Re:C++ is object oriented high level assembler

[bmckeever]

C combines the power and speed of assembler with the maintanability of assembler.

Re:C++ is object oriented high level assembler

[awol]

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

No, C++ is a high level assembler with object oriented features.

Re:C++ is object oriented high level assembler

[armb]

Have you come across C--, which is actually designed as a portable compiler target language?

Lower level than C in some ways (since it doesn't bother with things that the higher level language should be handling), but supports other things that C doesn't, like exceptions, and optimized tail recursion.

Still experimental, but interesting.

One of the things that it isn't is a virtual machine like Parrot.

Re:C++ is object oriented high level assembler

[GuyWithLag]

C++: an octopus made by nailing extra legs onto a dog -- Steve Taylor, 1998

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

[beware1000]

The language itself never really appealed to me and
I have also found everything I have run/created to run unneccessarily slow. This may be a mistake of some kind on my behalf.. But the amount of resources combined with the speed were unbearable. Parrot sounds like a nice alternative though, although isn't the benefit of most of the languages above the fact that they *are* scripting languages?
and this also means it could benefit a language like PHP right?

Any more insight into VM's would certainly be appreciated :)

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.

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

[ask]

Actually, developing Parrot in parallel with Perl 6 is speeding up development!

- ask

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

[Joff_NZ]

Indeed. The PHP 5 Beta 4 was released in mid-Feb, and they expect it to be the last beta before the final release - which can't be very far away...

The proper OO language constructs are going to be a huge boon, as well as all the other stuff.. and PHP *is* very easy to use ;)

I don't code perl myself.. and at this point don't see any need to learn, especially with the threat of version 6 out there... it'd suck learning a language, and then potentially having to re-learn it a year later (or however long it ends up being)

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

[Junks Jerzey]

I agree, this is a huge concern. Reading the apocalypses, it feels like the language is expanding in every possible direction at the same time, and in the most complex 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). There are some gems in there, but do we really need it *all*? Perl 6 is already coming across as much more complex than any language I've seen, including Ada, PL/I, and C++, and I'm an experienced Perl 5 coder.

I'm much less concerned with Parrot. I'm still concerned, mind you, because 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. 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.

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.

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

[10am-bedtime]

hmm, i just read the regex explanation page linked by some poster above. if that is representative of the forthcoming design (i dunno, i am a perl ignoramus due to other pressing Problems :-) it seems to me that the only thing that will be happening in 20 years time perl-wise will be "legacy systems migration" w/ perl being the legacy system in question. why? because, despite whatever elegance the expert may be able to glean from the new regexp design, shoehorning proper grammar construction (and hence proper grammar construction tools) into a dilletante programmer's already-exploding head will result in mostly badly copied snippets from some google page that works 90 percent of the time, fails 5 percent of the time w/ error, and fails 5 percent of the time w/o error.

this will be enough to "get a project rolling" straight into the ditches from a maintenance standpoint. experts being more expensive than ever, the wily cya-mindset hiring manager will avoid this scenario at all costs. so, for those refining their perl chops, if you are not successful you will be the source of these future headaches, and if you are successful you will be the underling of a stressed not-so-wily ninny who wishes he/she had stuck w/ java like the other ninny, and in projecting that latent wish (stemming from the desire to be wily THIS time), he/she will make your life hell. that which you know will be used to delete that which you know and love.

i read other comments stating things along the lines of "perl 6 design represents a paring of inessentials". that sounds a lot like scheme if you ask scheme heads (you can't beat "read" implemented in 64 bytes or less). syntax is surface. if you want to parse, learn the parsing algorithms beneath. attachment is the root of suffering.

Here's some perl for you to look at

[Anonymous Coward]

#!/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?$v<10?'00':$v<100?0:'':$ e<10?$v<10?0:'':'').$v++,for 1..$_}
warn"@$_\n"for@l

Re:Here's some perl for you to look at

[No_Weak_Heart]

Thanks for posting that code. It's yummy. I'm going to use it for my Desktop Wallpaper.

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.

Re:Yeah, but...

[bunnyman]

In Perl, the airbag is off by default. You have to type "use Airbag;" at the top of the code to activate it.

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.

Re:We need an alpha in 2004

[smittyoneeach]

Or, like me, you take a look at Perl, say, 'Great ideas, but rather colloquial; I wonder if Perl6 will tidy that up?' and just enjoy the summaries over on O'Reilly.

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!

[TimToady]

Well, the Python folks thought it was a joke, but the Perl folks have been taking it seriously for some time now.

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!

[Matchstick]

Parrot is being designed to accept all dynamic languages. OSCON 2004 will be when we discover who wins the Pie-thon competition; in it, we see whether parrot is faster at running _python code_ than the current cpython.

You can bet that Dan wouldn't be risking a pie in the face if he didn't care about whether or not parrot could host python.

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

Ugh, just to clarify...

[Fiona Winger]

Not once did I ever say I had Perl6, which I assume you're implying.

Being an experienced coder, I was able to determine what this update would allow me to do, and I listed those. I don't need the program to know what it means for my coding.

So,please, hold your tongue before calling "troll" on my posts. =P

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

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

[bahwi]

Moved on to What?

I think since .NET and Java are the only byte-code languages out there, and that it takes time to develop things like this, and the speed at which they are moving, we will have a good product out when it is ready. The Perl spirit pretty much demands that you move on to the newest and best.

People do not understand that Perl is losing a lot of its base(which is now going to PHP). But there are hard-core perl devs out there who will still be around.

Perl has a habit of filling in where other things simply do not fit. From CGI(Which before was only done in C, Perl got wind of it and fill it up nicely. Seriously, with mod_perl, and now PHP with mmcache or Zend Accelerator, C is the slowest language you can do CGI with. It's pre-compiled? So what? Perl and PHP with those above are pre-compiled, optimized, both CPU wise and code wise, and In Memory. C is on the hard drive, gotta access it each time. Even if it was stored in memory, it is missing a lot of optimizations. It is easier to optimize a high level language sometimes than a lower-level language).

Now PHP is taking up where Perl was. Perl is moving to other things, as well as staying in its more traditional roles. That's all. It won't be people moving from P5 to P6. It will be people moving from anything else to P6.

P6 will be a pretty good language, and parrot looks great already. I can't wait to compile python or lisp to parrot assemby and mess around in there. Should be enough to make my head explode.

Java and C have their place, but I promise you Java's acceptance was pushed back about 5 years because of applets. It was a great language, then I saw applets and decided not to learn it. I've learned it now(a few years ago, I didn't wait 5), but I know I am not the only one who ignored it because of applets. I hate to see a web page take up 100% of my cpu! C, well, you gotta love C. =) But I like Obj-C. =) Thank you GCC for compiling it too!

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

[ajs]

"I realize that Perl is a good glue but not very "industrial"."

You're wrong, but that was kind of my point. You've learned a sort of pigeon dialect of Perl and THAT is not "industrial" (whatever industrial means)... I assure you that Perl is as robust a language for small and VERY large-sclae projects as any other once you really understand it.

One of Perl's greatest strengths AND weaknesses however is that people who don't know the language that well can write a hell of a lot of working code in it. Compare this to C++ where your code will break A LOT until you really understand the language, and you begin to see why Perl gets a rep as a toy language. It's a poor craftsman, however, who blames his tools, and just as you would expect someone who only knows the basics of carpentry to misuse a hammer in building a house, so too you expect someone who only knows the basics of Perl programming to misuse THAT tool.

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

Rexx is a great systems toolish language, but it was proprietary and fairly platform bound. Its failing was not that it was "fun".

"And all the Perl 6 fuss with smart ass names (apocalypse, exegesis, jeez ...) isn't going to make me feel more confident about it !!"

I'm sorry that those names make you uncomfortable, but I assure you that Larry (who is a linquist by training) does not use words lightly, and he means exactly what he says. To quote from A1:

"People get scared when they hear the word Apocalypse, but here I mean it in the good sense: a Revealing."
-Larry Wall, Perl 6 Apocalypse 1

I think you need to actually look at Perl 6, and not just at your preconceptions about the names of the specification documents. Look at the code in the languages/perl6 subdirectory of the Parrot distribution. That gets you some good grounding in where Perl 6 is going and where it's remaining the language that you have found "fun" all along.

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

[doom]

How many coders will follow the new syntax and features?

I already do follow Perl6 syntax, sometimes. They keep back-porting Perl6 ideas to perl5: Bundle-Perl6-0-0.05

And when "Perl 6" is finally released, I expect to continue mixing and matching perl5 and perl6 constructs, gradually shifting over to 6, without throwing away any existing libraries written for perl 5.

I expect that this process is going to be a hell of a lot easier than switching to any other language would be...

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

[straybullets]

You've learned a sort of pigeon dialect of Perl

Actually my perl is perfectly kosher : it is sometimes proof read by someone in the know and i usually stick to what i know is ok.

I actually apply the TMTOWTDY, and that is a good thing for my company (generating on the fly excel files et al).

The problem is that if you really want to know the innards, it feels that you must understand all the C code that's behind ...

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

Re:Ewwwww

[malloc]

But that's the whole point, in assembly language the compiler doesn't do any guessing, it just does what you told it to do (right or wrong).

-Malloc

I did RTFA

[SharpFang]

and I can say I love the new stuff. No less powerful than regex, and no less obscure, easy to learn, use and abuse. Slightly easier to read and understand, though still tricky. Eh, if we had that in the pre-ncurses times! :)

And for those who hate Perl, it's still worth reading, for great texts used in the "text formatting examples" like a recipe for 2 doomed souls or 10 reasons why you didn't do your English Lit. homework.

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

[highwindarea]

me 2

But seriously it parrot does sound like a good idea, for instance I prefer to write python than write perl, but there's a bunch a useful cpan modules, also having a single c->hiigh level language interface would be great.

Imagine writing a game and being able to do the rendering engine in c, the game logic in python/perl/ruby and the AI in scheme or lisp.

Re:Me either ...

[timeOday]

I was about to mention Microsoft's CLR (common language runtime), but it turns out it's only for compiled languages, by design.

The JVM might work better, but I'm not sure. You can get other languages compiled for Java, but Java lacks support to invoke scripts (AFAIK). Seems like a shame. Java's 2 step process of compiling PLUS interpreting is annoying.

Re:Me either ...

[MourningBlade]

More than that, parrot gives people the ability to quickly implement experimental or highly specific languages.

Want a language custom built for the analysis that your lab boys do? Want to use some old code from another language? You can do that quite quickly. Your compiler is written in Perl (or whatever you want), targeting Parrot.

The speed with which people have been able to implement new languages is astounding (the python-on-parrot project made huge strides in a week or so).

And since these languages will eventually start out with fully-functional libraries (better than most languages will ever get, in fact: everything Perl has to provide, and possibly Python and Ruby later), they will be usable.

I think Parrot will see more experimentation with languages than we've seen yet. And that will be a good thing.

Re:Me either ...

[Anonymous Coward]

Imagine writing a game and being able to do the rendering engine in c, the game logic in python/perl/ruby and the AI in scheme or lisp.

You can do this already. Go talk to some game developers...most of the rendering engines seem to be written in C++ these days though.

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

[ajs]

Yep, all good stuff. I respect Java quite a lot, though I don't enjoy programming in it.

I look forward to the Java port to Parrot for many reasons, not the least of which is being able to provide all of CPAN (or CP6AN or whatever we end up calling it) to Java, Python, Ruby, Scheme, etc., etc.

Imagine being able to grab a piddle from PDL (Perl Data Language), sub-class it in Java to add some interesting network abstraction, and then pass it to a Python class that someone else wrote. No more choosing the language for anything other than your personal preferences for semantics, grammar and syntax. Total programming freedom....

I thought this sounded like a rather unrealistic pipe-dream until I went to a talk by Parrot's author. Dan made it clear that he wasn't interested in just producing Perl 6's back-end and demonstrated in fairly amazing detail how he felt it could be accomplished.

From looking at the source, and having tested it out a bit, I'd say he's about 2/3 of the way there (that is: to producing a viable 1.0 release that accomplishes is basic goals). There's a LOT of work to do, but it's now at the stage where I feel he's to be taken seriously. The Pie-Thon should show us clearly how much we can really expect from Parrot.... I'm pretty psyched about OSCON this year, for that very reason.

I have nothing against Guido, but if he has to take a pie in the face to demonstrate the power of Parrot to the world, I'm happy to see him get creamed ;-) Dan has made some very interesting comments about Guido's confidence including,

" Parrot is an order of magnitude faster than perl 5 doing equivalent things. Without enabling any extraordinary measures.

You know how Python's performance rates against Perl 5.

Do the math."

It will certainly be interesting....

Re:Me either ...

[Trejkaz]

I too am a little upset they didn't just use an existing VM instead of going and inventing another. IMO both the JVM and the CLR would have worked well enough for their needs. In fact at some point they were actually talking about using the JVM, I wonder where they went wrong... ;-)

Interestingly there is a language they are writing for Parrot called Cola, which looks a lot like Java but runs as Parrot.

Re:Me either ...

[Trejkaz]

Wait a second... they didn't write the compiler for Perl in Perl, did they? Oh dear, another language with infinite recursion to break brains.

Re:Me either ...

[rgmoore]

If you look at the Parrot FAQ, they explain exactly why they chose to write their own VM instead of using JVM or CLR. To quote:

Why your own virtual machine? Why not compile to JVM/.NET?

Those VMs are designed for statically typed languages. That's fine, since Java, C#, and lots of other languages are statically typed. Perl isn't. For a variety of reasons, it means that Perl would run more slowly there than on an interpreter geared towards dynamic languages.

The .NET VM didn't even exist when we started development, or at least we didn't know about it when we were working on the design. We do now, though it's still not suitable.

FWIW, it looks as though Parrot will give very good performance as VMs go. Python for Parrot (at least the parts that work already) is faster than the existing implimentation of Python, and there's every reason to think that the same will be true of Perl, Ruby, and whatever other languages they impliment.

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.

Re:Me either ...

[mrogers]

Your question is answered in the Parrot FAQ. Sun's JVM isn't free software, there's no other JVM out there that compiles on as many platforms as Perl 5, and all JVMs as well as the CLR use a stack architecture, whereas Parrot uses a register architecture which appears to be much more suitable for Perl (ie faster).

Re:Me either ...

[chromatic]

It's NCI, the Native Call Interface, and it's immensely easier than Perl XS. (Admittedly, XS isn't bad for simple things, but it's nasty for tricky things.) You do have to know Parrot assembly fairly well to get things done, but parameter handling is all done for you.

I've been working on SDL bindings for Parrot. They're reasonably straightforward and easy -- and you don't have to have a compiler to make them work! See examples/sdl/* for examples.

Either Dan or I will have an article or two on ONLamp.com about NCI in the near future. If you're really curious, send me an e-mail and I'll tell you more.

Re:Me either ...

[pavon]

Yeah, as other people mentioned, the main reason is that these languages aren't statically typed, and so they have to to much of their typechecking at runtime. If you were to implement this in a VM like Java or .NET, you would have to generate byte code to do all that checking - in essence you would basically have to have half an interpreter implemented in byte code. As you can imagine, this would be quite slow. Parrot is designed to support all the features that exist in late binding languages, and they looked a ton of them (perl, python, ruby, lisps, smalltalk, basic, etc) before they started to make sure that the bytcode was an efficent superset of all the general features of those language.

Re:Me either ...

[pavon]

True, but the difference is that java and .NET, didn't implement high level constructs in their bytecode, like parrot will. They are basically just a portable assembly sets (i am of course simplifying things a bit here), so in terms of linking different languages they really didn't have anything more to offer than the C ABI did - except that theoretically you didn't have to recompile. Thats a very minor advantage, since recompiling isn't that hard. All the advantages that these languages have comes from the fact that they have managed code - garbage collection, bounds checking, and what not - and the execution machine just happened to be the most efficent way to implement that.

The only ones that survived (so far) are the ones that target a single language.
No you know of any that were designed from the begining to target more than one existing language? (.NET doesn't count it created languages aound it's bytecode) I don't. Perhaps this is a reason that they haven't been as popular, not the reason they are successful.

At the same time it would be really exciting to see the birth of the first SUCCESSFUL cross-platform execution machine...
One application that works identically on all platforms will never be all that usefull because an application is not an island. If it doesn't work well with the system then users will not like it. And execution machines really don't solve any problem when it comes to cross-platfrom development. Distributing 3 binaries as opposed to one bytecode is not that big a deal. What is a big deal are all the look and feel changes that have to be done, and execution machines don't help that. IMHO, this is why execution machines have not been successful - because they are attempting to solve a problem that doesn't exist. Parrot is attempting to solve a real problem - how to create effecient highlevel system interfaces (like windows .NET, or Next Obj-C), without locking yourself into one language. Of course whether they succeed is entirely up in the air, but it is certainly much higher on my radar than java was.

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:Conclusion/Highlights

[frostman]

formatting text using variable-width fonts

ooooh!

of course i'm too tired to RTFA (it's 8am where i am) but i have to say, there have been many times when i had some great idea for a perl-based doodad to summarize a buncha info for print, but i was always too lazy to grok word-wrapping variable-width fonts... i sure hope this comes to pass.

Aw geez...

[bersl2]

And I just started learning Perl 5...

Camel book :]

[Xenographic]

I don't expect to make much sense of these writings just yet. Sure, they're fun to read, so that I have some idea of all the new things they're doing, but beyond that *shrug*

I intend to buy the new camel book from O'Reilly (just like I did for Perl 5), which will surely help me learn all the new bits (and, quite probably, help me relearn the bits I only thought I knew).

I wonder if they'll do anything new with regular expressions? (I haven't RTFA just yet, and I don't remember anything from the past exegesises just now.) They always were my favorite bit of Perl for some reason... :]

Re:Camel book :]

[dpuu]

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

Re:Camel book :]

[Xenographic]

Ahh, very nice. Thank you :]

In the mean time, I must say that I hope, now that I RTFA here, that Larry Wall & co. haven't been appropriating any of SCO's IP. I mean, just look at the following bits of code and judge for yourself if they look like something SCO might have written... ;]

print form
'Name Bribe (per dastardry)',
:under("="),
'{[(11)[} {]],]]].[[[} ',
@names, :lfill('*'), :rfill('0'),
@bribes;

[...]

# X out any doubleplus ungood words
$nextline ~~ s:ei/(@proscribed)/$( 'X' x length $1 )/;

module Ministry::Of::Truth {
# Double-plus good contents omitted, RTFA
}

Heh, I just had to modify some of that code slightly to bypass the damn lameness filter, because of the junk characters. At least it's an excuse to test my knowledge of Perl 6 :]

We HAD an alpha IN 2003 !!

[hummassa]

get Parrot. Perl6 is there. Alpha, not beta. Good riddance.

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.

Re:OO Assembly?

[ajs]

Furthermore, the Java VM instruction set is easily flexible enough to support other programming languages, although the VM performs some safety checks that might make things like out-of-bound memory references hard (not that you'd want to). Computationally, it's complete.

vi is computationally complete (in the turing machine sense), but that doesn't mean it's the right platofrom on which do develop code in a certain style. Java's VM is aimed at running Java, and that means that doing MI, deferred finalization and many other things that are commonplace in modern programming techniques require bulky emulation in the JVM. In Parrot, you will be able to choose your programming paradigm to a much larger extent. Its stack management is also much more condusive to implementing a wide variety of exception-handling techniques.

When you have to drop down a level and write code in Parrot (and you will sometimes, mostly in order to interface to C without imposing any given language's calling convention overhead), I guarantee it will be a night-and-day difference from suffering through interaction with the JVM directly.

As for your other points:

being widespread -- matter of time. Parrot is pre-release right now, so of course that's true, but if all of the Perl installations in the world upgrade to Perl 6/Ponie/Parrot in the next 10 years, then I think you'll see more Parrot than JVM in the world.

machine-specific optimizations -- The JIT for Parrot is pretty damn good about being portable to multiple platforms and yet hand-tunable, so I don't think that'll be a problem for more than 6 months to a year while people discover what sort of optimizations they need.

The JVM was a great step forward and really changed people's minds about how efficient a virtual machine could be. That's a good thing, but it also had some serious design limitations that CLR and Parrot are addressing.

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

[jfdawes]

I didn't indend to get into a GUI/command line debate. It's more to do with generating displays and the use of fixed width fonts. Even if you're not generating HTML, most of the things supplied by the form function are irrelevant when you're using fonts that aren't monospaced/fixed width. I'm under the impression that most applicances/devices/applications these days tend to display in true type/outline fonts.

(Not to mention that most HHDs/appliances don't even give you anything even vaguely resembling a command line by default)

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.

Re:Is text formatting relevant

[jfdawes]

Good point. I'm still not convinced that it was worth the effort. Sure, there's problems with the format function and he's fixed a lot of them, but I'd much rather have him spending his time writing any number of powerful modules that are as well thought out and flexible.
[Sentence using the phrase "Cost Benefit Analysis" elided]

One that comes to mind is an extensible module I can use that lets me send exception reports as an XML attachment via email (or whatever other fun system you like) with as little trouble as you can use this form function.

OO assembly anyone?

[captainclever]

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

No.

Deja vu all over again ....

[Anonymous Coward]

The new Perl "form" stuff sure seemed familiar for some reason, but I couldn't figure out why. Then I figured it out .... anyone else remember the "print using" statement in BASIC ????

Re:Deja vu all over again ....

[TimToady]

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

Object assembler goes back to ~ 1985

[Anonymous Coward]

Real object assembler is almost twenty years old:

Object Assembler

Object Assembler is a set of macros for the Motorola 68000 assembly language that provides easy access to the MacApp class library and to class-definition facilities. It is built on top of the macro assembly language provided by the Macintosh Programmer's Workshop assembler. Object Assembler was developed by Apple expressly for the Macintosh and it will be officially shipped late in 1986. The Object Assembler macros let you define new classes, define method bodies, instantiate objects, easily reference instance variables by name, and invoke methods, incl uding inherited ones.

See more.

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

Re:'Weak vs. Dynamic': Type Systems

[PissingInTheWind]

Thanks bud, people are so confused about types.

One ought to write a basic type theory guide.

Re:'Weak vs. Dynamic': Type Systems

[voodoo1man]

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.

I never claimed the opposite. I consider Java's type system weaker than that of Python and Lisp - explicit conversion or not, casting to Object still loses type information. I wouldn't have a problem with this if Java didn't make it a necessary programming technique.

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

[metamatic]

Parrot will perpetually be 6 months from doing anything useful. [...] Parrot is too complex and bloated for what little it does. It already has over a thousand opcodes - talk about simplicity! What moron designed this thing?

There's this CPU that has clearly been designed by a complete bunch of morons... can you believe the documentation listing the opcodes is 566 pages long?

Obviously this x86 thing will perpetually be 6 months from doing anything useful.

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

[Ender Ryan]

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

Where oh where do you get that? Perl 5 is a live and well, and has seen quite a large boost in support and development in the last several years. Right on the heels of the overdue perl 5.8, we've got 5.10 coming down the pike(still a ways off).

There have been nice improvements in the perl 5 core, stable threading support, more useful core modules, major updates for unicode support, etc.

Then there's POE (poe.perl.org), and other stuff.

Perl 5 is far from being "end-of-life'd".

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:"end-of-life'd" perl 5?

[Ender Ryan]

Exactly. And, what's more, not only will there (eventually *grin*) be a perl 5 that targets Parrot, Parrot has a JIT, meaning Perl 5 on top of Parrot should be faster than the current perl 5.

And BTW, the Parrot project is coming along pretty nicely. It still has a ways to go before it's feature complete and where they want it, but it's already a very useful VM, ie. people are already doing some cool things with it, eg. there is initial support for several languages at this point.

Parrot is not vaporware, you can download it and play with it today.

Sure, it'll be a little while before it's ready for production use, but people brushing it aside are doing themselves a serious disservice.

Cheers.

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.

to be a pedant

[Ender Ryan]

I hate to be a pedant, but there is no such thing as "PERL." The language is properly written as "Perl," and the interpreter is called "perl."

Don't ever write "PERL" in correspondence with a diehard Perl programmer.

Only perl can parse Perl.

Re:Meanwhile PHP surges ahead

[chipace]

You are comparing a specialized tool to a general one. I wouldn't use PHP to parse my log files and do heavy file comparisons. I believe that web professionals using Perl are a minority of the total user base.

Parrot didn't configure for compile

[imnoteddy]

Downloaded the Parrot source code. No README or INSTALL in the top-level directory, but there is Configure.pl, with comments that seem to indicate that you run this first. OK, run it but it barfs on line 405:

use Parrot::BuildUtil;

there's no file with 'BuildUtil*' name in the source distro.

Conclusion: not ready for prime time.

Re:Parrot didn't configure for compile

[chromatic]

Hmm, that's really odd. I just grabbed 0.1.0 from the CPAN and it has a README and a lib/Parrot/BuildUtil.pm. The configurator also works just fine here.

OO assembly language

[jonadab]

An object-oriented assembly language -- what, you mean like zasm?

Comparing to other templating implementations

[aled]

How does Perl templating mechanism to other templating implementation like Velocity? I would like to know what pro/cons has each one or others that /.ers may have used.

Yeah, back when Assembler was all we had

[ynotds]

It's intriguing how the social significance of assembler programming has drifted over the decades.

When I met my first computer, an IBM 1440, Assembler was the only thing they taught us and we developed some very useful application software to run within its 12,000 characters of decimally addressed magnetic core memory.

Even through the transition to System/360, assembler was it, though there was Fortran on the 7044 at uni and PL/1 was coming as a promised advance on both Fortran and Cobol which others had started to use but our place did not touch.

Then Ed Dijkstra came to town and I was an immediate convert. Nowadays we would call in "professional development". But still we programmed in assembler, and I could not see any reason that my assembler code would not benefit from following the principles of structured programming.

Years later, a job interview became quite confused when the interviewer did not understand that assembler programming and systems programming had not always been synonymous and that there were application programmers who had also used assembler, especially back when any of the functionality we might now expect to find in an operating system was basically hard wired.

Now, I do know that "structured programming" is not strictly synonymous with "object oriented" but they are also the major then and now approached to encapsulation, which remains a good thing. I also know that Parrot is "byte code" rather than a true assembler language, and don't expect any of this will convince me to take Parrot up in preference to the real thing (Perl of course) at this late stage of my programming life.

perl can do text/plain at last

[Ragica]

Am i missing something, or is what people are so excited about in this thread just a slightly improved plain text formatting engine?

Is it just my imagination or are the two tops of this article linking perls extended new plain text rendering capabilities with perl 6 and the parrot vm? Is that what Larry has been working towards all this time? Better faster plain text reports?

Ouch. (-:

Re:perl can do text/plain at last

[WWWWolf]

From what I understood, the Apocalypses and Exegesises (eh, however the heck it's pluralized) will each cover a chapter of the Camel Book. This was number 7; chapter 7 in Programming Perl is Formats.

Formats are marjor boring stuff, and as noted not even part of the core language anymore... but they need to be covered.

So, I take the next ones will be References, then Data Structures (hmm, I suppose there aren't that much to add here?), and then we get to object-oriented topics, which should be very interesting. (Shall it be Revealed that there indeed shall be "$foo is private"? Shall the Snake be slain and the Gem cut?)

There's 33 chapters, so there's a lot of stuff to cover, but I don't think they're going to spend much time on some chapters (particularly Perl as Culture (ch. 22-27), which covers just basic theory of good coding practices and portability, and the Reference Manual (ch 28-33) - though I hope Damian shows off some stuff when they get to Chapter 27, subtopic "Perl Poetry"...)

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.

Re:Meanwhile PHP surges ahead

[Anonymous Coward]

You know whats worse than object oriented assember? A large PHP project. Dont you love global() and lack of scope?

Perl is more maintainable, and faster than PHP when comparing apples to apples. Perl has more available modules, and they actually work! PEAR had admirable goals but fails miserably because of the terrible code quality and documentation.

mod_perl lets you write apache modules in perl, thats an unbelievable win over writing PAGES in php. Then again, most web professionals dont seem to understand that distinction.

I think PHP is a dying language, almost everyone I know that worked with PHP when version 3 came out has moved on to other languages. The language is broken by design and everyone realizes it sooner or later.

Best things about Perl are...

[Anonymous Coward]

Perl made us productive and inspired new languages like Ruby which took some great features from Perl and made a language actually a pure joy to use. http://www.ruby-lang.org

Perl6 will finally cleanup a lot of baggage to make it more competitive with newer/cleaner/easier languages (like Ruby). If done right, it will recapture the former Perl users who migrated to Python and/or Ruby.

Parrot will give us an alternative to the single-language Java VM and the multi-language Microsoft CLR. We can only hope that it leverages the mistakes and successes of both JVM and CLR to provide something that is better than both.

While it shouldn't be limited in a particular CPU, it should take reality into consideration and make it easy to aggressively optimize for AMD/Intel (98% of desktops) and IBM PPC97x (Macs, XBox 2, Playstation 3, future IBM Linux workstations).

Re:Meanwhile PHP surges ahead

[spauldo]

Actually, IIRC, slashdot's coding started before PHP was ever a contender. I'm not sure if mod_perl was out before PHP3, but I do remember rob singing the praises of mod_perl way, way, way back in the day.

I agree with you though - I wouldn't want to write slashdot in PHP - perl's much more flexible (by itself anyway - never ran mod_perl myself).

funny :)

[kinsoa]

just note you can write very well formated code in perl. Really. It just give you the liberty to write oscured code, but you have the choice.

and at least, you can write *short* code that is well formated too - unlike programing languages like java who force you to write long code - but long doesn't mean "clean"...

The problem with "more than one way"...

[devphil]

...is exactly that: Perl supports ten ways of doing X, so you're free to choose #3 for your code.

And your coworker is free to choose way #7, and the sourceforge project whose code you're extending chose way #2, and they're all incomoatible.

So even though you're free to choose which way you want to do something, you still have to learn and understand all ten ways if you plan on completing the project and getting paid. And then maintaining it.

Yeah, you could pick one way and enforce it with corporate coding standards (and hope you pick the right one), but then there goes the advantage of ten different ways. Or the sourceforge project could document the choice in its HACKING.README file, but then the coders who only know six of the ten ways are locked out.

All the coders I know at big companies tell me that this is exactly why Perl is banned -- at each of those companies -- for official work. There's too much variance between each way of doing X for large scripts to remain maintainable across multiple serial coders.

(I suspect most of the people who are going to post followups flaming me have only ever had to maintain their own Perl scripts, without ever inheriting a pile of mission-critical scripts from somebody whose choices were all different from yours, and who's not available for questioning.)

Re:The problem with "more than one way"...

[Luyseyal]

Right, so your argument is that: Perl encourages learning and broadening your programming vocabulary whereas Java and corporate standards encourage conformity and stagnation?

???
-l

Re:The problem with "more than one way"...

[devphil]

My argument is that Perl is too sloppy for anything other than small, one-shot, on the fly jobs.

I don't think Java and corporate standards are the way to go either.

Re:The problem with "more than one way"...

[TimToady]

I think your argument is that Perl 5 is too sloppy for programming-in-the-large. Perl 6 will make it a lot easier not to be sloppy.

Re:The problem with "more than one way"...

[krog]

Comments, comments, comments.

You can do whatever you want within a subroutine, use whatever style you want, and as long as you **DOCUMENT** exactly what the subroutine expects as input and returns as output, future users of your code are in the clear.

99% of complaints about Perl programs disappear completely if the code is properly documented. If not, then yeah, you're fucked -- but you'd be just as fucked in Python, Java, C++, Lisp, Fortran or VB.

Re:The problem with "more than one way"...

[devphil]

We can only hope. :-)

Exegesis

[mabu]

I wish I had something inciteful to say, but I don't. However, I have to jump at the chance to type, "exegesis". It's just such a cool word. I wonder how long it will be before Fox News claims they own it.

You couldn't pick a better name for such a utility.

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

Unicode operators!

[PhilK]

I was prepared to keep an open mind about Perl6 until this choice quote:

Note that each ellipsis is a single, one-column wide Unicode HORIZONTAL ELLIPSIS character (\c[2026]), not three separate dots.

Sure, lets add operators that can't even by !@#$% typed. Yes, you can add :is ASCII(!@#$%) but that kind of misses the point.

Not only does Larry get the colon, he gets the entire unicode set!

Re:Unicode operators!

[TimToady]

Eh? No, Perl 6 is limiting itself strictly to Latin-1, even though many of these Unicode characters are easily typable in, say, vim. But forms are not a part of core Perl 6, so they can do whatever they like (or more precisely, whatever Damian likes).

Re:Unicode operators!

[PhilK]

Note true.

Refer to this newsgroup thread:
http://groups.google.com/groups?selm=2004 020208352 6.GF31998@cat.ourshack.com

Larry is personally in favour of adding Unicode operators.

Re:Unicode operators!

[TimToady]

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

Re:Parrot progress

[pacc]

I just read an article about this,
the x86 design was all based on minimizing chip real estate and not in on providing the best way to do every function. RISC and now IA-64 is a consequence of this philosophy where all tough problems and complexity is pushed onto higher level compilers. On the higher level it becomes to complicated to take care of the problems and it is pushed further up to the operating systems and script languages of today.

Four principles that will inevitably lead to a failed project:
PRINCIPLE 1. If you can't solve a problem, give it to someone else.

PRINCIPLE 2. If you can't choose an alternative, let the user get access to all.

PRINCIPLE 3. If there's an adaptable tool, use it rather than developing a new one.

PRINCIPLE 4. If a bug is found during implementation, try to get around it instead of solving it.

These were formulated in 1976 and translated from the article in Swedish

Not knowing anything about Parrot, there seems to be some support for identifying what programs really does and solve the problems at a really low level. Redundant OP's was a bad thing by the same principles, but an underlying hardware implementation might be able to divide the problem even further.

Other work by Bud Lawson Proper function distribution in computer system architectures, Open complex based systems, (I might even read them some time...)

Re:Parrot progress

[metamatic]

Yeah, and you're probably one of those idiots who thought I was attempting an analogy.

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 ?

WTF?

[dash2]

Uh, +4 interesting?

"now that Perl6 is out". It isn't.

"Perl6 is now a subroutine" Beg pardon? Do you mean form is a subroutine in Perl6? Or what?

"stream the formatting through the test" What???

Mods, clue up!

Re:WTF?

[e-Motion]

"stream the formatting through the test" What???

The point is that the format of the test aids in the streaming of the Perl 6 syntax, thus improving the programmer's experience when he/she is using "exception-handling"-like development in the customary fashion and enabling him/her to use OO-style methodologies in a RAD-enabled, but somewhat I/O-bound, manner.

Duh.

Mods, clue up!

Definitely.

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.

Ouch!

[Hezaurus]

..and it doesn't actually look that bad. =)

Re:What Perl6 needs

[babbage]

Maybe so, I can't say. But from the way I understand the design of the system, getting Perl6 to run on Parrot is "only" going to be a matter of writing an interface wrapper to bootstrap it. They have a reasonable idea of what the basic functionality needs to be, so Parrot has been written to meet those needs -- and the needs of other languages (esp. Python) as well. [1]

From what I understand, the Parrot group wanted to wait for a reasonably complete Perl6 before they started, but when it became obvious that this was going to take a while, they decided to just get started. Surprisingly, work ended up happening very fast, and we've ended up in the strange but possibly useful situation of having a roughly complete Parrot engine available today, two or three years after development started, even though the Perl6 design is still evolving.

This isn't necessarily a bad thing though. No one wants to throw out the expertise that thousands of people have built up in learning Perl5, so even when Perl6 is available, Perl5 is still going to be around -- if only to run the huge number of Perl5 scripts that will never be rewritten for the new version of the language.

With that in mind, one of the design criteria for the Perl6 project is robust Perl5 support, and with Parrot at the level it's at now, it should be possible to write a Perl5 interface to the VM without waiting for Perl6 to be finished. Because the design of Parrot is so much cleaner -- and faster -- than Perl5's current internals, this might actually speed up existing code, and could even make the painful process of developing with XS a thing of the past. It could be a benefit to Perl5 in the near future separate & apart from Perl6's progress, if & when this interface comes to fruition (which, according to the last plans I took a look at, it definitely will).

So yeah, this is probably the reverse of how things "should" have been developed, but there are some positive things about the current situation... *shrug*

******

[1] Python needs support for certain things -- I think co-routines was the example Dan Sugalski used in his talk -- that Perl doesn't currently care about, so they've gone in to Parrot. If anyone wanted to expose this functionality to Perl, it would be easy enough to do so, and sooner or later someone probably will.