Exegesis 6 (Perl 6 Subroutines) Released

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

Comments

There's a long way to go

[Dancin_Santa]

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

Where's $\space and $\tab ?

Re:There's a long way to go

[TedCheshireAcad]

Oh lord, variable names/function calls with whitespace.

That would truly make perl executable line noise.

Re:There's a long way to go

[luugi]

Check this out. :)

New Whitespace-Only Programming Language

Re:There's a long way to go

[szap]

whitespace hasn't even been made meaningful yet.

Funny you should mention that, because Damian Conway, the author of the article here, is also the author of Acme::Bleach, the perl code to whitespace only code convertor.

Check it out if you haven't already -- Acme::Bleach showcases the best and worse of perl: very short code (83 lines, including documentation you see in the link above), humorous (with subroutine names like whiten, brighten, dirty and dress) and does absolutely nothing Useful(tm). It's a cool perl hack.

Keywords

[Gortbusters.org]

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

Re:Keywords

[Anonymous Coward]

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

Python syntax is close enough to C, C++, Java et cetera not to cause most people any problem - except in the few places where it isn't, of course!

John Roth

Re:Keywords

[ajs]

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

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

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

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

Re:Keywords

[TheFlyingGoat]

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

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

The way I see the development of Perl is that they're making it backward-compatible enough for people to make an easy transition, while having it advance enough to make the transition worthwhile. They've even switched to calling Perl regex's "rules" so people don't confuse true regex's or even what other computer software refers to as regex's.

Re:Keywords

[smallpaul]

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

Re:Keywords

[grennis]

Having a weakly typed language is not an advantage. Apparently, script programmers cant deal with specifying that something is an 'int' or 'float' or whatever. .NET has really solved this problem, but making it strongly typed, but every typed is derived from 'object', which has a pure virtual 'ToString' which allows you to easily convert anything to a string suitable for printing. Can you see the advantage here?

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


The beauty of it is when you translate the text. The translator now has option of moving parameters around inside the text. Awesome.

Now go ahead and mod me down for saying something positive about .NET :(

Re:Keywords

[ajs]

You gave the example:

vtime = time()

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

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

Re:Keywords

[jandrese]

I thought the point was that most of the time we don't care if it is an int or a float, we just want it to work correctly. Obviously if you try to do something like (note, the . operator concatenates strings):
$foo = "bar";
$foo++;
Perl is still going to stop you, but when you do:
$foo = 123;
$bar = "Foo is $foo";
Perl does the right thing and automatically stringifies the number for you. You don't have to worry about converting your numbers to strings and back. You can even do things like:
$foo = 123;
$foo = $foo . "456";
$foo++;
print "$foo\n";
Perl will print out 123457, just like you'd expect. When you do stuff like that in a strongly typed language, you spend a whole lot of time converting types manually, which is annoying.

Re:Keywords

[Anonymous Coward]

ToString is not a pure virtual, it has a default implementation. The default implementation returns the fully qualified name of the type.

And it is even more powerful than you mention, for example, for an instance of the Double class whose value is zero, the implementation of Double.ToString might return "0.00" or "0,00" depending on the current UI culture.

Re:Keywords

[Waffle Iron]

Can you see the advantage here?

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

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

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

or with your positional parameters:

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

The same string conversions happen. 'a' is still an integer, and the language knows it. You just don't have to keep typing 'int' and 'toFoo()' over and over.

Re:Keywords

[ajs]

Having a weakly typed language is not an advantage

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

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

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

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

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

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

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

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

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

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

Re:Keywords

[smallpaul]

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

Re:Keywords

[grennis]

I assume you mean C#, since .Net isn't actually a language

I meant any language that .NET supports... VB.NET, C#, J#, etc. Can you see the beauty in THAT?

Anyway, it looks like *somebody* is getting defensive about being a script programmer ;). Sorry I touched a nerve there ;)

Re:Keywords

[chromatic]

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

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

Re:Keywords

[ajs]

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

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

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

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

You're sort of thinking about this backwards. The question is not "when a new keyword is added, will my variable name be one of them", but "in my giant project and all of the myriad libraries on which it depends, will any of that code break, when a new version of C introudces a keyword." From my prior experience in fixing code with exactly this problem, I can say "yes" with a high degree of certainty.

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

Bad metaphore, and again, you're looking at it upside down. How dangerous is it to add a keyword in C? Pretty huge, right? So the result is that you don't add keywords very often.

In Perl however, it's much less painful because of this "baseball bat", so Perl adds keywords where they are needed, rather than where they are unavoidable.

Keep in mind, I'm a fan of C (not C++) and Perl both, so this is not a language war, I'm just pointint out a relative merit of Perl's way of doing things. C has its own merits in sufficient quantity to make it the single most widely use language in history.

Re:Keywords

[Q2Serpent]

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

Re:Keywords

[Horny Smurf]

ok, so perl variable will never conflict with keywords, score 1 for perl.

But if/when you switch to perl 6, $hash{'key'} is now %hash{'key'}. And it gets uglier for arrays of hashes, etc. And $length = @array is now $length = @array.length;

But at least keywords won't conflict with variables!

Re:Keywords

[ajs]

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

Not at all. I'm simply not.

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

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

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

Then you are incorrect, since .Net also supports many languages which do not share this typing system. The .Net libraries may use that typing system internally, but that's because they are written in, or at least primarily written for C#.

Again, you are making a broad an inaccurate comparison between vastly different scopes.

Re:Keywords

[nograz]

Just for the sake of completeness: The concept of a "single rooted hierarchy" is not new. We can find the most prominent implementation in Java and the .NET implementation is almost a "clone" of it (including the toString() Method). What's new in .NET is that they include primitives ...

Re:Keywords

[moonbender]

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

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

Re:Keywords

[los furtive]

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

Sounds like a good solution to me!

Re:Keywords

[Anonymous Coward]

There is no advantage. You're carrying type-information around everywhere you go, because you think it allows you to add keywords. Do you know why C doesn't add new keywords? Take a few guesses, and it has nothing to do with any difficulty you presume there to be.

Re:Keywords

[msuzio]

Actually, the following code (in Perl 5):

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

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

Re:Keywords

[grennis]

You modded yourself up didn't you ;).

Anyway, you are totally wrong, every object in C# is derived from 'object'. Same as VB.NET. Same as Managed C++. Etc., etc. How can you argue this point? It is a fact. I still stand by my statements.

Re:Keywords

[Billy the Mountain]

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

BTM

Re:Keywords

[Anonymous Coward]

Yes, that's great! I'd much rather spend large portions of my day worrying about manual type conversions, instead of actually writing the business logic for my application.

Re:Keywords

[Simon]

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

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

A couple of points:

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

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

* Having manditory prefixes for all variables is a terrible price to pay in terms of readability (and not to mention typing). It's overkill on a massive scale.

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

It's just a really bad trade-off allround, and like program line numbers, it's a concept that should be left to die.

--
Simon

Re:Keywords

[ajs]

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

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

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

Like I said before, this is not a unique feature to one, or even a dozen toolkits, languages, etc in the last 10 years. You're not citing something that originated with the example that you are citing. I was responding to an assertion of yours that you seem not to really be talking about any more, so I'm going to drop this thread.

Re:Keywords

[Anonymous Coward]

3 - 1 for you! Brilliant!

Re:Keywords

[beat.bolli]

C has its own merits in sufficient quantity to make it the single most widely use language in history.

Are you really sure about this? I mean, how many lines of Fortran and Cobol do you think have been written in the 20 years before C even existed (and are still being written today!)?

Not that I wanted to speak in favour of these languages, but I can't let your statement stay as is...

Re:Keywords

[bnenning]

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

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

Re:Keywords

[n1vux]

Tiny chance? Try certainty.

C99 added the keyword 'boolean'. Very carefully.

No matter how carefully, it still breaks a lot of libraries which had been using that word as a typedef with that or similar spellings. It's not a tiny chance, it's guaranteed ... unless you've already upgraded your compiller and all libraries to full ANSI/ISO C99 compatibility, which some vendors only started shipping recently, and aren't adding any 3rd party libraries in the next 5 years. (I'm hoping to finish the C++98 conversion soon. People keep discovering legacy code!)

Sigils/prefixes is a religious issue. Mentioning them with line numbers in the same graf suggests someone hasn't fully recovered from initial exposure to BASIC back before we had lower case. Dijskstra overstated the perniciousness of Basic, but ... branching out into other languages _early_ combined with _early_ theory exposure seems to be the best predictor for a full, healthy recovery.

Re:Keywords

[Anonymous Coward]

(defun description (obj)
(format t "Object ~A is of type ~A.~%"
obj (type-of obj)))

Keep trying. You guys will have a language as nice as Common Lisp in a few decades.

Re:Keywords

[jbolden]

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

Re:Keywords

[Lozzer]

You do realise that cockroaches can put themselves back together after a good pasting with a baseball bat. Napalm does a far better job, so I've been told. Liquid nitrogen stops older models.

Re:Keywords

[Anonymous Coward]

P# == Parrot of Perl or Python in .NET?

hehehehe

open4free

Re:Keywords

[RevAaron]

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

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

That said, I enjoy perl on occasion, to that I'll admit. However, I have a big number of annoyances with Perl 5. Part of it is with Wall's assertions about perl being postmodern- not a mess; how it naturally follows the way the human mind thinks- perhaps his, but not mine and a great many others; that perl resembles english- no more than most languages concieved by english speakers.

Ok, done ranting. :)

Re:Keywords

[ajs]

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

Oh so?

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

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

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

which would be an array of 4 elements, of which the fifth element is a hash of two elements, the values of which are themselves arrays. Not that hard is it?

There is the container-access syntax that I find rather messy, but even that's not so bad, and it goes away in Perl 6 entirely, again without impacting that very clean way of identifying variables that lets you do things like

$foo = "dogs";
$bar = "cats and $foo";
$baz = qr{($bar)+};
while(<>) {
if (/$baz/i) {
print;
}
}

with one, uniform syntax.

Re:Keywords

[ajs]

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

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

But, no. C has become SO widely used in the world that it has eclipsed even COBOL at this point. Just your avergage Open Source distribution has more C code than what was produced at 90% of the banks out there (of course, those 10% cranked out some amazingly vast code). The various C-based software for embedded systems, etc keep the pace going, and then you have other free operating systems, proprietary OSes, content management systems, telementry data managers for satellites, elevator control systems, mathematical simulation systems, payroll management software, etc, etc.

About the only think I could imagine coming close at this point is JavaScript, and that's only because there are so many page generators out there that spit out HTML with JavaScript embedded....

Re:Keywords

[ajs]

There is no advantage

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

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

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

For example:

$x = 1;
$y = [ 1, 2, 3];
$z = new IO::Socket::INET
PeerAddr => 'yahoo.com',
PeerPort => 'http(80)',
Proto => 'tcp';

Here you have three variables. One is a simple scalar. One is a reference to an array. One is an object that represents a socket, connected to the HTTP port of a remote server. The $ doesn't tell you a whole lot about type, it just indicates a scalar access-mode.

Do you know why C doesn't add new keywords

*I do*, but I wonder if you do....

C does not add new keywords because it is a syntactically simple language, and that's part of its attraction. Any attempt to change that (e.g. the way C++ did) would destroy that, and would need to justify such a change against the benefit.

I think that Perl does justify this increase in complexity, though to most outsiders that's not obvious. You really need to be able to think in Perl before you understand just how valuable all of that syntax is.

At one point, I knew C so well that I thought in it. That was long ago, but I still remember how powerful that was.

When I learned Perl well enough to think in it, I was introduced to a new kind of programming. I was suddenly able to write in a few lines of code, what would have taken pages and pages of C, even with a good set of libraries. Just the ability to say:

@foo = sort map {"$y{$_} $x{$_}"} grep {$_ > 0} @bar;

dwarfs the abilities of C.

That's not to say C is useless. I still use it from Perl all the time, via XS. If I had to write a device driver or any other low-level code, I would still use C. But for your run-of-the-mill software, Perl is leaves low-level languages, and even most high-level languages far behind... at least from my, admittedly limited, point of view.

Re:Keywords

[ajs]

No, you're mis-reading A1.

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

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

#!/usr/bin/perl -6
use syntax::bash;
if [ -e /etc/passwd ]; then
echo "passwd looks good."
else
echo "erorr: no passwd" 2>&1
exit 1
fi

Re:Keywords

[ajs]

You're comparing apples and oranges.

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

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

Re:Keywords

[ajs]

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

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

Re:Keywords

[crucini]

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

$time = time;

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

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

Re:Keywords

[crucini]

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

It's pretty easy, actually. If @x is a list of hashes of objects of class foobar, which is what I think you mean, you can:

• Get one element: my $local_foobar = $x[21]{ purple };
  
• Invoke a method on one element: $x[1]{ green }->print();
  
• Index an element by variables: $x[$n]{ $color };
  
• Get one complete hash of foobar: my %h = %{ $x[3] };
  

Far from being a nightmare, the ease of such manipulations is one of the nicest things about Perl.

For those who don't know....

[ajs]

The way Perl 6 is being developed is thus:

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

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

ok

[Anonymous Coward]

Why would someone who is reading an article about Perl 6 Subroutines need a copy of Learning Perl?

Why did you post the Amazon review without giving credit?

Why will your post be moderated up nonetheless?

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

[CoolVibe]

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

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

oh yeah

[tomstdenis]

sub Fahrenheit_to_Kelvin (Num $temp is rw) {

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

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

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

But I suppose whatever floats peoples boats.

Tom

Re:oh yeah

[chromatic]

Signatures and types are completely optional. If you're writing a small utility to parse text, you don't have to use them.

Re:oh yeah

[tomstdenis]

Yeah, it's skeeball!

Tom

Re:oh yeah

[Anonymous Coward]

Is that some sort of fisting reference?

Re:oh yeah

[Anonymous Coward]

Skeeball is a carnie sport. Why not ask your parents [er. cousins, er...sibblings, ah they're all the same]?

Fuck ass. I hope you die in a car fire! [well since you probably don't own a car, a tricycle fire!]

Asshat loser!

Re:oh yeah

[Anonymous Coward]

Somebody woke up on the wrong side of the FUCK OFF AND DIE.

Re:oh yeah

[Anonymous Coward]

umm... uhh...
cat? can? canning!
Canning the mangoo!
Wait... right, I remember it now.
CANNING THE MANHAM!

Re:oh yeah

[Anonymous Coward]

That gives me an idea!

Tom stdenis bottles the mangoo!

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

[Anonymous Coward]

• Eventually, this will lead to the Design Documents

And everyone will then use Python.

Perl6 is a mistake

[keesh]

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

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

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

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

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

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

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

Re:Perl6 is a mistake

[Ed Avis]

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

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

Re:Perl6 is a mistake

[Anonymous Coward]

I just wish they were *Turing* complete... *hmm* ...

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

[absolut_kurant]

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

Perl floats *all* boats

[flicken]

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

sub Fahrenheit_to_Kelvin (Num $temp is rw) {

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

sub f2k ($temp) {

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

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

Re:Perl floats *all* boats

[Marx_Mrvelous]

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

Re:Perl floats *all* boats

[groomed]

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

Troll-by-reference

[BigGerman]

It seems like any posting that is NOT pro-Linux, pro-Perl or IS pro-Java, pro-Mono is automatically moderated as Troll recently.
Now, the guy:

obviously knows what he is talking about (even if he (horror!) pasted from his own posting from other website).

has something to say

Why don't you people listen and learn even if you do not agree with the poster?

Re:Troll-by-reference

[Anonymous Coward]

He posts it on every Perl story, unchanged, without evidence of reading anything beyond the world "Perl" in the blurb. That's not insight. That's obsession.

Re:Troll-by-reference

[Anonymous Coward]

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

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

For instance, @var for the array slot, $var for the scalar slot, %var for the hash slot, &var for subref, etc.

Each "variable type" does NOT have its own prefix. The prefixes specify the context that the variable is being called in.

By the way, *var references the entire "typeglob" at once, allowing you to do things like:

$var1 = "name";
@var1 = (1,2,3);

*anothervar = *var;

print $var1
name
print $var1[1]
2

Maybe if the person actually knew anything at all about perl, then his post would actually be worth paying attention to.

Re:Troll-by-reference

[Ed Avis]

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

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

At least, that is the terminology almost everyone uses.

Re:Exegeis

[Anonymous Coward]

i went to #SHAA and found that it was empty, damn you

seems like

[butane_bob2003]

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

Re:seems like

[chromatic]

the language is becoming more obtuse if thats possible.

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

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

See the Inline modules on the CPAN.

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

See Perl Design Paterns, an article on Perl.com.

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

See the CPAN.

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

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

Re:seems like

[jandrese]

No, once a Perl programmer notices a design pattern they codify the whole process into a CPAN module. :)

Actually, design patterns are the kind of thing you think about on large projects with groups of coders, design documents, and managers, not on smaller text parsing scripts.

Re:seems like

[Aadain2001]

Exactly. I'm currently doing a very nice sized project in Perl (currently over 3,000 lines of code, inline documentation(thanks POD!), and debug lines), and I am adhering to a very strict design pattern because I know that I am not going to be the one to maintain this for the next several years. Perl is great at quick little hacks that help make your life simpler without thinking too hard. But that doesn't prevent Perl from being used in a full blown project just like any other language such as C, C++, Java, etc. It all boils down to what the programmers are like. If they were the kind that would make variables names like "hg56sss_str", then they will continue to do so in Perl, and to an even more maddening extent since Perl gives them greater freedom to be creative.

Re:seems like

[RelentlessWeevilHowl]

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

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

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

Re:seems like

[chromatic]

That's a fair concern.

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

I think he suceeded, but it's also possible that I'm too close to the material to judge this accurately.

Re:seems like

[Anonymous Coward]

there's a saying... 'only perl can parse perl'.

Re:seems like

[mshiltonj]

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

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

Re:seems like

[chromatic]

Heh, true. I meant the Exegesis, though.

Re:seems like

[jdavidb]

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

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

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

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

Re:seems like

[Anonymous Coward]

So, basically, you know some lousy programmers who use Perl and you are making generalizations based on that. I know some truly awful programmers who use Java, but I don't go around blaming Java for this. At my current job, we build tests for every component, use CPAN modules extensively, refactor when appropriate, and follow established principles of good OO design, all in Perl. You need to get out more.

Re:seems like

[n1vux]

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

Maybe you need to get out more? The intersection of Perl-fanatics and readers of Alexander (not just GOF, but the original, architecture of bricks and mortar) is not a null set. I'll be happy to be met next time you're in Boston. You're buying the beer.

[SOJ] Why would Perl programmers need to learn a new language, when Perl is a living language that will always be new? [EOJ] :-)

Hmm. Why am I answering a troll from someone named "butane bob"?

Writing a Perl parser without YACC should be reasonable with Perl 6. ;-)

require sig 1.3

Re:seems like

[Angst Badger]

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

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

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

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

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

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

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

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

Re:seems like

[Magius_AR]

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

Then would you like to go out for a beer?

A design pattern is basically a code solution engineered to solve problems that occur over and over in software design.
It's a basic precept of reusable object-oriented code.

In fact, most people use them while they code without even realizing it. I own a copy of the Gamma/Helm/Johnson/Vlissides Design Patterns book. I'm fully versed in C++/C (it was my first language). I use design patterns extensively in my C++ code, which I love coding in btw (my favorite object oriented language)...oodles and oodles of Singletons, Flyweights, Prototypes, and Abstract Factories just to name some of the primaries. Additionally, I consider myself a Perl veteran. Given the choice between the two, I prefer Perl for both readability and flexibility. Somehow it just makes more sense to say:

&parse if ($is_true) or exit(1);

then it is to say

if ($is_true) { parse(); } else { exit(1); }

The first flows, like poetry, like reading a book.
The C code is choppy and mechanical.
You may have whatever presumptions you want about the language, but a good Perl programmer can write some amazing code. It's just alot easier to write spaghetti Perl code than C. That doesn't mean you can't make Perl code look and perform nice.

As for code re-use, ever heard of CPAN?

Oh yeah, since Perl I've learned 3 new languages, including Java, Javascript, and SQL. And no I don't believe it was any harder learning them.

I'm shocked how many Perl hating trolls can get modded up on Slashdot.

Re:seems like

[larry bagina]

Actually, C allows:

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

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

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

Re:seems like

[bsartist]

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

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

I will grant you this - I don't think we've met. ;-)

Re:seems like

[Dog and Pony]

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

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

Then, like someone else pointed out in some other post up there, you can always be sure that $vtime is a variable, while you never know if vtime might be a reserved keyword in the next version of the language.

But one of the greatest wins are the ease of use that comes with:

print "My name is $name.\n"

Ruby does this like this:

print "My name is #{name}.\n"

(though most use puts) - I find this not really as clear, and a bit more typing. But it allows any expression, which is nice. That kind of magic exists in Perl too, but not easier.

Compared to Java (and others)

System.println("My name is " + name + ".");

It is a winner hands down.

2. I think the complex data structuers are really easy to read and grok in Perl. It is easy to obfuscate these parts of course, but really, there are only a few short rules, and once you have those down, you only need to read left to right. See References quick reference. And creating them is really easy. Just write the structure as you want it.

Writing large applications in Perl depends totally on intense self-discipline as a programmer, and everything about Perl actively encourages you to break that discipline.

This is almost total bullshit. Only bad programmers write bad Perl code, and bad programmers can write bad code in any language. Badly disciplined, inexperienced or just "bad lazy" coders write unmaintainable messes in any language, and I can tell you that they are no easier to untangle in Java or other languages either. I worked in a Java shop for a bit over two years, and the unholy mess some people could create in a coffee break is worse than most things I ever seen in Perl. And at least in those days, Java was the be-all hype language where everything would be so nice, because it was OO. Bullshit.

The thing is that you need to know what you do in any language. And you need discipline in any language. The difference is that the mess does not look the same when you mess up in Perl as in for example Java. But the long compact blocks of code that some people is a Perl trademark is not one of those, I've seen those in most any language. I've seen people write almost complete applications in one method, in one class in Java.

Take advantage of your language, whichever it might be, know what you are doing, and don't cheat (other than in good ways ;-) and you'll be fine.

Re:seems like

[Magius_AR]

Honestly, I wonder why if/else/elsif blocks need to be enclosed with {}

I've always preferred it...I hate "if" one-liners. Aside from being a pain in the ass to modify if you need to turn it into a multi-line block, it makes reading coding even more annoying, can't even do searches on braces to move between blocks.

Re:seems like

[butane_bob2003]

That's an interesting bit about yacc and Perl. I had forgotten that perl could probably only be parsed by perl itself. One thing I have found perl good for is writing quick and dirty hard coded parsers, which is close to it's original intent in the first place.

Re:seems like

[butane_bob2003]

Thanks for the info, esp. the design patterns page. (I'll have to forward that on to some folks I work with)

Perl does have clear ways of expressing things, it's just the 9 other ways of expressing an idea that can make an it unclear (well, at least until you have seen them all a few times).
Quoting from the last page:

The vast majority of [new features and alternatives] are special-purpose, power-user techniques that you may well never need to use or even know about.

So everyone who is just getting their feet wet will have No Idea what the Power Coders are thinking, right? Maybe the intent is to build out every limitation.

The last time I wrote perl, it was to re-write portions of Bugzilla to add functionality and clean up the interface a bit. (this was 3 or 4 years ago) The state of the Bugzilla sources at the time might have _something_ to do with my apprehension to perl. Since then I think Bugzilla was re-engineer'd at least once. It seems like constant change in a language would be a bad thing, right?

Re:seems like

[butane_bob2003]

True, these are generalizations. We have two camps here at work, the perl guys and the OO guys. There are some who walk the fine line between, but for critical projects and rapid development, they stick to Java. I agree that it's not the fault of the language, it's the choices a programmer makes that can make code stink. Perl just gives you many more choices to choose from. I'd get out more if I didn't have to work all the time...

Re:seems like

[butane_bob2003]

Maybe, like me, you are avoiding work? I can think of no other reason why I would choose to troll on an article about Perl. I really have no hard feelings toward the language or its honorable users, as long as I'm not duty bound to use it myself.
The name 'butane_bob', for anyone interested, comes from a favorite song of mine by Aphex Twin, "Laughable Butane Bob" from the 12" titled "Hangable Autobulb". which can be heard somewhere in this mix: http://www.brucewang.com/071501.jsp

Re:seems like

[butane_bob2003]

Oh no! I dont hate Perl. I have no strong religous beliefs at all! I was trolling a bit. I was expecting to get modded off into oblivion. Just trying to start trouble.

Re:seems like

[butane_bob2003]

Just be glad it does not require closing if(coditions) with an 'fi' statement. Christ. I could complain all day about shell languages.

Re:seems like

[chromatic]

So everyone who is just getting their feet wet will have No Idea what the Power Coders are thinking, right?

That's true of any programming language. The question is where you put the simplicity and where you put the complexity. (I've written about this before -- though see Schuyler's take for a better explanation).

Unless you have a really, really simple language that has no libraries and no chance to grow, odds are you'll have to adapt to something that's different in someone else's code, if you ever read code from someone else. Larry's really good about hiding complexity and allowing people to be productive while knowing a small fraction of what's available in Perl. I believe Perl 6 will make it easier to encapsulate this complexity where you don't have to see it unless you really really need to see it.

What you describe sounds like a standard maintenance program. I don't write Perl code that anyone off of the street can read without knowing Perl. I write code that competent developers can maintain. A big part of that is self-discipline, which no language worth using can enforce.

It seems like constant change in a language would be a bad thing, right?

It certainly can be. I'm willing to go on record that the problems in Bugzilla were more lack of discipline on the part of its developers than any systemic problem. Consider how often any open source project is rewritten and redesigned (not refactored). This is a problem that afflicts every language.

Re:seems like

[butane_bob2003]

Have to agree. Libraries are one thing, and more will always appear to provide solutions to new problems. One of the fundamental differnces in philosophy between Perl and (more or less) OO languages is the desire to allow globalized access to variables and functions. There are many arguments for and against this. I dont LIKE it, but I think in the context of a scripting language it's acceptable. You probably use namespace imports and keep everything fully qualified and readable for your own sanity and mercy towards others. This is good practice, but the language does not enforce it. Therein lies another difference: Perl enforces almost nothing. If something can be done, folks are going to do it.

Re:seems like

[chromatic]

I fear this thread is about to die, but you might be interested in a Lamba the Ultimate thread about macros in Java. Designing a language well means finding a balance between power and flexibility. I'm personally very much against taking out features that might confuse new programmers or that can be misused, but I do believe in managing complexity well.

Very few languages that completely prevent beginners from doing stupid things allow experienced users to do very clever things. I hate that.

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

[ajs]

And everyone will then use Python

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

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

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

Release on the long road to nowhere

[amightywind]

This guy is not trolling. He makes several valid points. Perl 5 is a good thing if you need to transform text or write a CGI program. For anything longer than a few hundred lines you should probably use something else. That is the way its been and the way it will be. Perl reached the limits of its usefulness a long ago. Perl 6 and its rabid following are on the long road to nowhere.

Re:Release on the long road to nowhere

[keesh]

This guy is not trolling

Erm, yes I was...

Re:Release on the long road to nowhere

[Mike Schiraldi]

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

Re:Release on the long road to nowhere

[Ed Avis]

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

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

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

Re:Problems

[mr_luc]

Or, to paraphrase:

The ridged top surface and the nondescript gray color will ultimately make this the final revision of duct tape before it dies a slow death. Execution will be drastically slowed by the difficulty in ripping the tape by hand, and the gray color will make it blend in with metal components, making interoperability harder and harder.

I mean, come on. Everyone whose job description involves building entire apps in Perl, please raise your hand. Then bring it down sharply into your groin, because you should not reproduce.

Perl is still the best damn duct tape money can buy, and will be for years to come.

Holy syntax overload batman!

[jtdubs]

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

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

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

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

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

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

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

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

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

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

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

Justin Dubs

Re:Holy syntax overload batman!

[MagikSlinger]

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

See? My Modified Godwin's law is right!

On a serious note, you could always write Lisp like programs in Perl and thus get the flexibility of Lisp (including having Perl build functions which are then called by the code). I've done it.

It's just that Larry is using syntax to provide ever more expressibility and pre-defined cases. Whether or not this is a good thing depends on your biases.

I always feel like my head is going to explode after reading an Apocalypse.

Re:Holy syntax overload batman!

[ajs]

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

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

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

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

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

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

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

Re:Holy syntax overload batman!

[CanSpice]

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

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

Re:Holy syntax overload batman!

[imnoteddy]

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

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

Execute data, not code.

Re:Holy syntax overload batman!

[MoxFulder]

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

Wo betide the fool who still wants to use * for multiplication!

Re:Holy syntax overload batman!

[ajs]

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

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

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

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

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

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

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

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

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

Re:Holy syntax overload batman!

[Fastolfe]

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

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

Re:Holy syntax overload batman!

[Ed Avis]

Fppt. C has * for multiplication, pointer dereference, and as part of the comment syntax, but it doesn't seem to be confusing. It all depends on the context in which the operator appears. There's nothing wrong with context-dependency in a language, provided it doesn't get counterintuitive.

Re:Holy syntax overload batman!

[Ed Avis]

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

Re:Holy syntax overload batman!

[Anonymous Coward]

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

Muhahaha, hilarious! Try 59%. But argue away, man.

Perl 6 leap-frogs Lisp by presenting Lisp's flexibility in a package that is far easier to use

Nah, they just took a small step closer.

Re:Holy syntax overload batman!

[Trilaka]

Ok, I must clarify a few things:

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

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

Secondly, this Exegesis covered Perl6's macro capabilities. It works very much like lisps, actually. Granted, my personal feeling is that it is easier to have a program write a program that is written in s-exps than in Perl 6, but Perl 6 does provide the capability.

The options mentioned in this Exegesis point out that macros in Perl 6 can return either blocks or strings. If a block is returned, its syntax tree is injected into the place occupied by the call to the macro. If a string is returned, it replaces the macro call, and then the resulting expression is parsed and compiled. All of this is done at compile-time, of course.

Secondly, and very interestingly, macros can define their own syntax using Rules (regexps) to pull parameters from free-form program text, rather than relying in the comma-separated Perl6 expression default.

All in all, if this can be implemented as they have described, in an efficient manner, I will be impressed. It seems very lispy to me, they've just moved the parsing code from the programmer's brain (since you are effectively writing parse trees rather than syntax when programming in lisp) to a parsing module within the code.

Remember though folks, if you don't want to deal with this complexity, you don't need to. But if you do need to, its good to know that its there.

Re:Holy syntax overload batman!

[Anonymous Coward]

Any day over fucking Perl, man. Any day!

Re:Holy syntax overload batman!

[sig cop]

Don't forget that '*' is used in C for pointer declarations, which is distinct from pointer dereferencing. Also, '*=' which is related to '*' as multiplier, but distinct, too. 5 different uses for the same character, 3 uses for the plain '*' operator.

Re:Holy syntax overload batman!

[Anonymous Coward]

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

--jwz

Re:Holy syntax overload batman!

[jtdubs]

Having multiple functions that do the same thing is not the same as having more syntax. You could view the amount of syntax a language has as a parallel to how hard it is to describe its tokenizer. That's a rough generalization, but gets the point across.

In Lisp the only way to define a function is with lambda. The other ways are all macros that expand to include a call to lambda.

(defun foo (x y) (+ x y))
is a macro that expands to something similar to
(set (symbol-function 'foo) (lambda (x y) (+ x y)))

Perl uses {} for blocks, () for lists, [] for arrays, {} for hashes, ; to delimit statements, $ for scalars, @ for arrays, % for hashes, & for functions, \ for references, <== and ==> for pipelines, -> for anonymous subs, => within hashes, = for assignment, := for binding, ::= for compile-time binding, m// for matching, s/// for substitutions, tr/// for translations, . for member access, :: for package access, {...} for function declarations, <<>> for labels, * for other kinds of lists, <> for file reading, [] for array slicing, and # for comments.

And I haven't even mentioned the plethora of keywords in Perl, such as my, our, of, sub, ....

Lisp has () for lists, #() for vectors, ' for quoting, ` for backquoting, , and ,@ for unquoting, #. for read-time processing, : and :: for package access. The semi-colon in Lisp is used for comments, not for making pairs.

That's all I can think of for Lisp, offhand.

Justin Dubs

Re:Holy syntax overload batman!

[ajs]

lisp is actually more of a truly compiled language than perl

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

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

Hence, my comment about Perl 6 (not Perl, BTW, which I use generically to refer to any version of Perl that has actually been released, and I say Perl 5 when I mean Perl 5) getting as close as any truly compiled language reasonably can. Perl 6 will not retain its syntax tree post compilation, and *that* is why I call it a truely compiled language. There *may* be byte-code, but that's a function of the back-end depending on if you're using a VM like parrot or compiling to machine code.

If you re-read my comment, you'll find that it was not a slam against Lisp. I like and respect Lisp. If you can only see languages as polar extremes, then I don't think you'll enjoy Perl 6.

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

No, not really. It looks similar, and in as far as most people will use them, they will be similar.

I had not actually realized that A6 had snuck macros in. I thought that Larry said he was defering them for later. Then again, I've been off the list for a while, concentrating on work, so it's good to see so much happened.

Still, macros in Perl 6 are a feature of Perl 6's built-in parser generator features (the replacement for regular expressions, and a first in general purpose programming languages, as far as I know, but there may be an expert system shell that provided something like this level of integration with the core language).

In Lisp, macros are expression constructors that return a lambda. Very, very different, though similar in application.

All in all, if this can be implemented as they have described, in an efficient manner, I will be impressed. It seems very lispy to me

Not really, like I say, it's more like SNOBOL or Prolog than Lisp.

The ability to say

rule comment {
/\* .*? \*/
| \s+
}
rule expression {
<comment>?
(\d+ | <expression> \+ <expression> )
<comment>?
}
rule program {
<expression> ( \; <expression> )*
| # Nothing....
}
while <>->$_ {
if /^ <program> $/ {
print "Valid code\n";
}
}

Will be quite interesting....

Re:Holy syntax overload batman!

[ajs]

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

Re:Holy syntax overload batman!

[Anonymous Coward]

Of those, only LAMBDA, CONS, and QUOTE are truly axiomatic; all that other stuff is merely syntactic sugar. Lisp is particularly good at letting you make your own more appropriate syntax, which is actually how things like QUASIQUOTE/UNQUOTE came about (for those who haven't heard of these, think of interpolating an expression's value into a data structure instead of into a string).

Re:Holy syntax overload batman!

[_ska]

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

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

Perl has some real strengths (and real weaknesses, of course), but it is pushing it to claim it even approaches 50% of the flexibility of lisp. I would put it closer to 20%, but perhaps could be argued upward a bit. We are talking about *flexibility* here, not best-language-cause, so
here are just a few of the reasons perl is way behind lisp (let alone 20 years ago lisp (cltl1)) in flexibility:

'defmacro (there goes 30% right there)

'defgeneric & 'defclass (don't talk to me about perls alleged object system.)

'compile

closures
introspection
semantic sanity
read/write symmetry
applicative programming that works
decent numerics

the list goes and on....

Re:Holy syntax overload batman!

[Anonymous Coward]

"Consider it a "live" language, instead of a dead one. Pity Larry is the only native speaker... I think...

At some point, I'll probably write something that looks like line noise and yet is a functional program. Or something.

" =~ s/p?[to](b).?a\1ly/will/

Re:Holy syntax overload batman!

[smallpaul]

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

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

Re:Holy syntax overload batman!

[jasoegaard]

> Lisp is never truely compiled.
Yes it is.

> It can be compiled down to machine code, but you > always have to keep the S-expressions around,

No.

> In Lisp, macros are expression constructors that
> return a lambda.

No. A macro rewrites one expression to another.
No need to talk about lambda here.

Re:Holy syntax overload batman!

[_ska]

That's the part that Perl does not have, and never will (though Perl 6 comes as close as a truely compiled language reasonably can)

Ah. ajs, you do know that most lisp's compile to machine code these days (actually, they have for decades), don't you? In fact there are some very, very good optimizing lisp compilers.

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

This is probably not true. Many languages have tried, and failed. I don't know enough about perl6 to be sure, but it is probably just another in a long line of attempts...

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

A fair bit of lisps flexibility and power comes from the macro system, so your statements are fairly reasonable; however there is no a-priori reason to accept that perl6 will be as flexible or as powerful as lisp --- perl5 isn't even close.

Re:Holy syntax overload batman!

[Anonymous Coward]

Just keep in mind that Perl6 regexes will have the /x behavior by default, so that last line could be less line-noise-ish. :-)

Re:Holy syntax overload batman!

[ajs]

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

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

As of Perl 6, I don't think Perl and Lisp will have any major differences that don't result from the choice of syntax. The flexibility and functionality is all there.

Re:If you're looking for a good Perl book...

[Anonymous Coward]

$IR HAXALOT IS A MONEY TROLL. He posts book links all day long because HE HAS A REFERRAL PARTNER ACCOUNT WITH AMAZON. $irHaxalot should be MODDED DOWN ON SIGHT. He DOES NOT READ the books he is recommending.

P.S. -- sorry.

[mr_luc]

oh, and sorry about the Perl applications thing. That is for my friend, who has stopped responding to instant messenger or email because he's mad at me. I'm pretty sure he Slashdot, though. ;)

He was always talking about how he would be a Perl application developer, because Perl was so leet. I think it's leet, but only really shines for duct tape work.

Jeremy, if you are reading this -- stop being such a little bitch and respond to my emails, dammit! :) We gotta set something up the next time I'm in the area, a LAN or something.

bleh - *cough*moron*cough*

[Ender Ryan]

j/k :P

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

Someone else already posted an example.

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

The beauty of it is when you translate the text. The translator now has option of moving parameters around inside the text. Awesome.

I admit, that is pretty cool.

great

[imipak]

there goes my evening...

perl?

[trybywrench]

they have perl on computers now? thats unpossible!

Any Sufficiently Advanced Language...

[Vagary]

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

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

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

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

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

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

Forgot Currying!

[Vagary]

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

Dear gods, they've finally done it...

[then, it was nigh]

"all(<<your base>>) are Belong("to us");" is now a legal Perl 6 statement. I'm fairly certain that's one of the signs of the impending Apocalypse (umm... pun not intended).

Hahaha... um... no.

[mobileskimo]

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

There's more than one way to do it?

[MoxFulder]

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

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

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

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

[rmohr02]

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

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

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

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

[Anonymous Coward]

I agree, but I'm not sure Perl has "normal syntax" :-) Have you ever tried to use ()'s for arithmetic precedence, and then had to track down a bug due to the fact that you induced list context?? That kinda thing...

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

[embobo]

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

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

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

[Fastolfe]

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

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

The World Needs Idealised Perl

[Vagary]

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

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

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

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

Re:The World Needs Idealised Perl

[axxackall]

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

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

I think the length of the language report won't help Perl either. People are already re-writing Perl code to Python. Why? Perhaps because they don't like to hack, they rather wanna design their programs. Perl coding style is hacking.

Perl 6 \not\in Perl ?

[Vagary]

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

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

Re:Perl 6 \not\in Perl ?

[chromatic]

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

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

Re:Perl 6 \not\in Perl ?

[Ed Avis]

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

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

Re:Perl 6 \not\in Perl ?

[Anonymous Coward]

What facts do you base your estimates upon?
Why do you have so much blind faith in Parrot considering it still can't run Perl after 3 years of effort?

Re:Perl 6 \not\in Perl ?

[chromatic]

Would that everyone were so blind!

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

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

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

Re:Perl 6 \not\in Perl ?

[Anonymous Coward]

You failed to answer why doesn't Parrot run Perl code after 3 years of effort?
As for the money spent on Parrot development - I won't bother with that statement. I see no evidence of Parrot advancing the Perl 6 cause at all. It is just a distraction.
Mono and DotGNU/Portable.Net in the same time frame have concrete results. No external money funded Rhys' work on Portable.Net, as far as I know.

Re:Perl 6 \not\in Perl ?

[chromatic]

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

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

Paying one developer to work on Parrot for a year and a half would double the amount of full-time contributions.

The parallels to Mono and DotGNU are inappropriate. Not only are they reimplementing something that's already been designed and implemented once by legions of funded developers at Microsoft, Ximian pays people to hack on Mono.

Re:Perl 6 \not\in Perl ?

[Anonymous Coward]

What's with all this talk of paying people to work on open source? If the Parrot/Perl6 project were compelling enough to work on - a multitude of developers would gladly freely work on it. The original Python, Perl and Ruby languages were written in exactly this way - and all of KDE, GNOME and CPAN, for that matter. So please give that tired "someone should fund Perl6 development to get a timely quality release" argument.

Re:Perl 6 \not\in Perl ?

[Anonymous Coward]

- So please give that tired "someone should fund Perl6 development to get a timely quality release" argument.
+ So please give that tired "someone should fund Perl6 development to get a timely quality release" argument a rest.

Re:Perl 6 \not\in Perl ?

[chromatic]

I'm answering the question why hasn't Parrot made more progress?. I believe the answer to that is, because it's been mostly a volunteer effort. There are lots of people who contribute what time and skills they have, and I think they've done a fantastic job. There are also more people contributing all the time.

As for Perl 5, Python, and Ruby, you should check out how many of the original developers are or were paid to work on those languages full-time. I'm not sure about Matz, but I know Guido has been doing half- or full-time Python development for several years now. Until a couple of years ago, so had Larry.

I'm sorry if you don't like the answer, but finishing software takes time. Sure, volunteers help, but I'm not sure that forty people giving one hour a week is even half as useful as one of the top people giving forty hours a week.

Please don't misunderstand. I'm happy to see people who can give an hour a week. The pay is lousy, a few people on Slashdot will take every chance they can get to gripe about your work, and it's a big project, but you'll be helping build software for millions of people to use. There's lots to do, though, and plenty of room for anyone who'd like to help.

A sharp detour from past Perls

[Junks Jerzey]

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

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

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

Re:A sharp detour from past Perls

[Jerf]

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

This thought keeps occurring to me. Actually, without any intent to devolve into a Perl vs. Python flamewar, I've been thinking that a lot with quite a few of these Exegesises. Python certainly doesn't have all of what's supposed to go into Perl 6, but it has a lot of it already there, and a lot of the other stuff isn't necessary because that's just not the way things work in Python.

To be fair, Perl is letting you limit the incoming parameters via code, whereas Python limits them via philosophy ("Better to ask forgiveness")... but for all that verbiage, that's about all Perl 6 can do with parameter passing that Python can't.

(Anyone adding pipelines to code I have to subsequently maintain will be shot without trial. I don't care how nifty the feature is, you're better off writing it longhand under nearly all circumstances for maintainability.)

Some nifty ideas here, though; I'm tempted to see if I can't implement "any" and "all" in terms of Python, at least for in-program comparisions. (Although Python is clean... I wonder how many of the cute tricks would subsequently propogate correctly and work correctly as well...?)

Re:A sharp detour from past Perls

[demi]

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

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

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

The reason people get into flamewars over Python vs. Perl is because of this philosophy: if Python doesn't do (or doesn't do well) what you want it to do, there must be something wrong with you. I use both, and I can't tell you how many times I've pointed out something I didn't like in Python, only to be told by a Pythonista that therefore I must be doing it wrong. Can't find the block end? Your blocks must be too long! Want more than a simple statement in lambda? That's not its purpose! Want declarative syntax? You don't need it!

To be fair, Perl is letting you limit the incoming parameters via code, whereas Python limits them via philosophy ("Better to ask forgiveness")... but for all that verbiage, that's about all Perl 6 can do with parameter passing that Python can't.

Could you clarify? Because I can't grasp what you're saying here. Are you saying that the only thing you can do with parameters in Perl over Python is "everything Python doesn't want you to do"? Or what?

Anyone adding pipelines to code I have to subsequently maintain will be shot without trial.

I actually think Damian's article does a pretty good job of showing the opposite: sometimes, a pipeline would be much easier to read than rabid nesting.

I'm not 100% on board with all the Perl6 stuff either (in particular, I'm not sure I'm down with all the punctuation-based modifiers to the parameter list--there are a lot of them in the Apocalypse that aren't covered in the Exegesis).

Increasingly difficult tasks...

[MoxFulder]

(1) Draw a complete operator precedence chart for C.
(2) Draw a complete operator precedence chart for C++.
(3) Draw a complete operator precedence chart for Perl 5.
(4) Draw a complete operator precedence chart for Perl 6.

Perl's ability to express complicated things concisely is nothing short of astonishing, but it's gotten to the point where I can hardly parse code written by someone else...

Re:Increasingly difficult tasks...

[Ed Avis]

(5) Profit!!!

Seriously, though, the 'someone else' surely ought to take care to express things in the simplest way possible so that other people can read it easily. The choice of whether to use

f() if $cond;

$cond && f();

if ($cond) { f() }

is a matter of style and what part you want to emphasize as important. Just as in English you have a choice of how to arrange a sentence and normally put the more important things last.

Plenty of minimal languages make it just as easy to write unreadable code... I've seen plenty of obfuscated Java. A richer language like Perl lets you write code in the style that is clearest for the task at hand, and that can only be a good thing.

Good god...

[Anonymous Coward]

What a monster of a language!

YHBT, YHL, HAND (n/t)

[Anonymous Coward]

Speaking as a Perl programmer...

[metamatic]

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

Re:Speaking as a Perl programmer...

[GnuVince]

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

Re:Speaking as a Perl programmer...

[metamatic]

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

Re:Problems

[ekidder]

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

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

[n1vux]

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

• Synopses, which are shorter and quicker to market.

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

require sig 1.3;

...and in Ruby

[MenTaLguY]

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

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

Re:...and in Ruby

[Anonymous Coward]

Can you read that string out of a message file (for localization) and still interpolate the values of expressions involving local variables?

Re:...and in Ruby

[MenTaLguY]

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

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

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

Please take the time to read the WHOLE article

[Anonymous Coward]

Before folks die of heart failure, or start using this to praise the superior abilities of their favourite language over perl.

Read and understand the WHOLE article.

My initial reaction to most of the apocalypse/exegesis articles has been "WTF, this is so complicated they're going to destroy perl".

BUT, when you read the articles carefully and think about them, it becomes clear how powerful, and easy to read (yes, really) most perl 6 code will be in comparison with perl 5.

The apocalypse/exegesis articles by their very nature tend to dwell on difficult and complex issues and, true to its history, perl 6 will be taking ideas from many other languages which may be initially alien to perl 5 programmers. So, yes, we'll need some effort to get the hang of the new syntax, but I'm now 99% convinced it will be very similar to work with.

Lets also not forget the work on parrot - having an open source, fast VM should benefit other languages such as Ruby, Tcl and Python - it's been built with that in mind from day 1. If it comes off - yes its slow going, but the signs are still good - I hope this will help to silence the endlessly purile "my language's better than yours" that clutter up these pages (ok, I admit it wouldn't be as much fun!).

Parrot progress

[Anonymous Coward]

Two years of Parrot development and it still cannot run Perl. And as for this talk of Parrot running Python and Ruby - it's just talk.
Here is what a Python guru said about Parrot when he tried to port Python to it:

Parrot development is stalled

The VM hasn't yet been shown to be useful as a language target. The main list for Parrot development, perl6-internals, was started in September 2000. Over two years later, in March 2003, there are still no real languages running on the VM. There are only a few toy languages such as Befunge and Jako, and fragments of Perl, BASIC, and Scheme compilers that are far from being able to run any percentage of the Perl and Scheme programs out there. (They're at about the same level as parrot-gen.py; if you pick a random example from a book or a random program found on a web page, the chance of being able to successfully run it is essentially zero.) To some degree this is because Parrot is closely tied to the development of Perl 6, and Perl 6 development is also proceeding very slowly.
No obvious benefit from using Parrot

What new possibilities does Parrot provide for Python? Stacklessness? Better GC? A new I/O layer? Interoperability with other languages? None of these is more than mildly interesting to me, and none, I suspect, will be viewed as a killer application by the Python community in general.

Most of the claimed benefits, such as better performance, haven't been actually demonstrated at this point. There are no real languages running on Parrot, so you can't compare the standard implementation of language X to the Parrot version of language X. Instead it's simply stated that Parrot will be faster than existing language implementations, but proof-by-assertion isn't very convincing.

Re:Parrot progress

[Anonymous Coward]

That quote is frankly pointless - folks are pi**ed that parrot is taking a long time to develop. By that kind of logic, if it only took 6 months to develop but was useless, would it be better?

Course not. I would be much happier if that "Python guru" had just said something like, "at the moment, its too early to say if Parrot will be useful" instead of bitching (albeit mildly).

Are there many Python, Ruby (favourite language) developers helping with Parrot? If the answer is, as I suspect, not many (any?), then there's no real justification for complaining about the speed of development.

The whole point is that if parrot works as expected, it will be a huge bonus to languages beyond perl 6, and folks should be grateful to the parrot developers for that instead of posting cheap comments writing Parrot off before its even arrived.

Re:Parrot progress

[Anonymous Coward]

You are missing the point entirely. In short: Perl 6 - good. Parrot - bad.
Perl 6 does not need Parrot to be implemented. Perl 6 can be prototyped in the original C-based Perl 5 and when it is done a module can be written to generate code for any number of existing backends and interpreters. Parrot is just a wasted exercise in premature optimization.

Re:Parrot progress

[chromatic]

Perl 6 can be prototyped in the original C-based Perl 5 and when it is done a module can be written to generate code for any number of existing backends and interpreters.

I look forward to seeing your Perl6::Continuations, Perl6::Rules, and Perl6::Types modules on the CPAN.

Re:Parrot progress

[Anonymous Coward]

That quote is frankly pointless

Yes, information countering your argument can be quite irritating.
Anyway, Portable.Net has also made an effort to also use Parrot without success.
Shouldn't Parrot simply concentrate on running some form of Perl?

Are there many Python, Ruby (favourite language) developers helping with Parrot? If the answer is, as I suspect, not many (any?), then there's no real justification for complaining about the speed of development.

Is there any point about bragging about Parrot's theoretical support for Python and Ruby if there are no people working on it?

Re:Parrot progress

[Anonymous Coward]

>Is there any point about bragging about Parrot's
>theoretical support for Python and Ruby if there are no
>people working on it?

Well, I wasn't bragging - my original statment was (excerpt):

"Lets also not forget the work on parrot - having an open source, fast VM should benefit other languages such as Ruby, Tcl and Python - it's been built with that in mind from day 1"

That's a pretty reasonable statement, and accurately reflects the fact that parrot has been designed with other languages in mind as well as perl - the fact that development has been slow does not change that.

I'm as frustrated as anyone about how slow the initial development work was, but perl6 and parrot combined are pretty ambitious, and we're just going to have to wait.

>Shouldn't Parrot simply concentrate on running some form of Perl?

Well what the heck do you think's going on - perl 6 is in development ATM, and I believe ponie is designed to get perl 5 running on parrot - these are works in progress.

So I'll rephrase my previous post - I therefore presume that if parrot is a success (and that's IF, not when), I assume all these folks bad mouthing it will put their money where their mouths are and NOT use it :)

blech - don't make perl syntax look like vb

[galacticdruid]

regarding this syntax:

--

(Num $temp is rw)

--

ick - this type of syntax is why I don't like VB. anyone with me here?

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

[Feztaa]

* Eventually, this will lead to the Design Documents

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

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

Flame War....

[Tsali]

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

I think it merits a poll.

My vote: Perl.

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

Note: Personal preference is Java, Python, and VB.Net in that order. I am now entering the bunker to avoid thermonuclear flaming.

(waits)

perl attack

[Anonymous Coward]

please see http://xahlee.org/UnixResource_dir/perlr.html xah lee

Perl 6 is a pantheon...

[LoveMe2Times]

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

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

Use what you need

[Prince Caspian]

There have been quite a few comments about Perl 6 gaining too much syntax, but I can't help but think that you could make the same argument about the English language. There are many words out there that most of us don't need, but for some people, they greatly simplify communicating within their field. I think Perl 6 will actually be easier to learn than Perl 5, because a Learning Perl book would not need to even touch on some of the more advanced areas, and the simple areas have been, well, simplified.