Perl 6: Apocalypse 6 Released

data64 writes "The latest Apocalypse talks about subroutines. Looks like we finally get type signatures which are way more powerful than the rudimentary prototypes available with Perl5."

Comments

20-odd pages...

[albalbo]

... so unlikely to be able to be whored for karma in it's entirety without a lot of work :o)

Perl6 is looking amazing, though. It's looking a lot less crufty than perl5 in a number of ways, and actually looks a very modern language now. Plus, it's still Perl. Woo!

So long as we get a foreach() mechanism with in-built index into the array it's looping over, I'll be happy. That's my biggest problem at the moment..

Re:20-odd pages...

[data64]

So long as we get a foreach() mechanism with in-built index into the array it's looping over, I'll be happy. That's my biggest problem at the moment.

You mean something like:

foreach my $elem (@list ) {
print "$elem\n"
}

This works in Perl5.

Re:20-odd pages...

[terraformer]

It won't need a mirror. It is hosted by O'Reilly and they are hardly schlubbs with a beat up pentium 200 running RH 6.2 or a Vic 20...

Re:20-odd pages...

[albalbo]

No no no no no. I know that :) I mean:

foreach (@list) { $list[$i] = 'No jam today!' if ($_ =~ /jam/); }

... where $i is an index into the array. Like a for() loop, but without the gatepost error possibility. Yes, you can do it yourself with my $i=0 and $i++ in the loop, but it's a mess, especially if you next or last anywhere in there - it means you have to put the $i++ at the top, and start at $i = -1, which is bizarre.

Re:20-odd pages...

[wirelessbuzzers]

No. He means he wants to:

foreach my $elem (@list) {
do something with $elem;
do something with the index of $elem;
}

Right now, that looks like:

foreach my $index (0..$#list) {
$elem = $list[$index];
do something with $elem;
do something with $indexd;
}

Re:20-odd pages...

[zephc]

python rules:

for i in list:
do something with i

Re:20-odd pages...

[Paul Cameron]

Yes, indexing would be great, but what you want (modifying the current element being iterated over) is possible without indexing, as 'foreach' aliases the current element to the actual element in the list being processed.

Relevant text from perlsyn:

The "if" and "unless" modifiers have the expected seman tics, presuming you're a speaker of English. The "fore ach" modifier is an iterator: For each value in EXPR, it aliases "$_" to the value and executes the statement.

Illustrative code examples:

perl -le 'my @a = qw(1 2 3 4); $_++ for @a; print "@a"' perl -le 'my @a = qw(1 2 3 4); for my $x (@a) { $x++ }; print "@a"'

Both output "2 3 4 5".

So, your code, and another possible way of achieving it (without over obfuscation), would be:

foreach (@list) { $list[$i] = 'No jam today!' if ($_ =~ /jam/); } vs foreach (@list) { $_ = 'No jam today!' if /jam/; }

Re:20-odd pages...

[sumengen]

and the index is where? is i the index or the element?

Re:20-odd pages...

[smallpaul]

The Python you gave doesn't solve the problem illustrated. Here's the real solution. It's a new Python 2.3 feature.

Re:20-odd pages...

[Istealmymusic]

You can omit the condition in a while() loop if its always true.

Re:20-odd pages...

[tramm]

albalbo wrote:

foreach (@list) { $list[$i] = 'No jam today!' if ($_ =~ /jam/); }

While I understand your desire for the array index in question, it is not necessary in your example. $_ is an alias to the current list element and is writable. You can do your example as:

foreach( @list ) { $_ = 'No jam today!' if /jam/ }

You're correct that tracking the index on your own will be confusing due to last, next, redo, etc.

Re:20-odd pages...

[KilerCris]

First Post? Redundent? Did I miss something?

Re:20-odd pages...

[zephc]

ah, missed the part about wanting to use the index value too, so then yeah, those short and clear examples are good. btw, thanks for pointing out the enumerate() function... tis handy.

Re:20-odd pages...

[LBArrettAnderson]

who says it's always true? multi-tasking is still an issue. if the string $i changes instantly (and magically), it won't be true.

(and yes, i'm kidding)

Re:20-odd pages...

[thoughtstream]

# Perl 6 code

for @list.kv -> $index, $elem {
# do something with $elem
# do something with $index
}

Re:20-odd pages...

[ajs]

foreach my $ele (map {[$list[$_],$_]} 0..$#list) {
local($_,$i) = @$ele;
$list[$i] = 'No Jam today!' if /jam/;
}

Though, I suspect you meant !/jam/

Re:20-odd pages...

[fanatic]

python blows because:

for i in list:
do something with i

is probably different from:

for i in list:
do something with i

which is also probably different from:

for i in list:
do something with i

Syntactically significant whitespace! No fucking thank fucking you! Never in a million million years will I make this my primary, secondary or tertiary language (e.g. I will only learn it if I need to debug some killer app [like TDMA], and only after all other options have failed).

Re:20-odd pages...

[Anonymous Coward]

Except that your 2nd and 3rd examples are sloppy.

Do you not indent any of your code?

I can't think of any reason to write sloppily formatted/indented code other than to be a prick to anyone who has to read your code.

Re:20-odd pages...

[fanatic]

I can't think of any reason to write sloppily formatted/indented code

Except that what if it's not (intentionally) sloppy? What if I used different editors (or the same editor with different settings) to produce these, and they look right but are wrong or vice versa? Problems like this are not unknown in the land of Python.

I'm sorry, but whitespace is partly invisible. It doesn't deserve syntactic significance. Period.

Re:20-odd pages...

[gorilla]

The major problem I have with python isn't that the indention is required, but that there is no way to understand the code without the indentation. It's not terribly uncommon for indentation to be lost on code. Perhaps I accidentally run the 'undend this code' function on my editor. Perhaps I only have a printout, instead of machine readable. Perhaps I paste the code into an environment where the indentation is lost, for example, a slashdot entry box. Once the indentation is lost, then that code is unrunable and useless. With a language which has syntax indicators of the blocks, then the indentation can be recovered.

Re:20-odd pages...

[Anonymous Coward]

I've written a few hundred lines of Python and consider myself a novice. I've spent two afternoons out of about a dozen trying to find block endings. Blocks should end, goddammit!

Apocalypse Now

[nizcolas]

I love the smell of sub routines in the morning

Re:Apocalypse Now

[rob-fu]

I love the smell of sub routines in the morning

...and it smells like unwashed, dirty programmers.

Re:Apocalypse Now

[$$$$$exyGal]

Kurtz: We train young men to write Java and C code, but their commanders won't allow them to write "perl" on their airplanes because it's obscene!

Re:Apocalypse Now

[Anonymous Coward]

BO, the programmer's natural defense against women.

Re:Apocalypse Now

[gnovos]

...and when you put your hand into a pile of goo, and that goo used to be your best friend's user interface... you'll know what to do...

Re:Apocolypse Now Redux

[caluml]

Gaaaad. I knew it didn't look right. Apoc_a_lypse. Apoc_a_lypse.

Re:Will this work on Debian?

[Anonymous Coward]

Doubtful... The Debian crew has always held that simplicity is best (Occam's Razor). They typically do all their scripts in Python.

More Information

[Anonymous Coward]

The Previous Apocolypses as well as some more info (who's who, list summaries). Read up!

On another note, is Perl 6 even going to be relevant with next-generation languages like Ruby and Python already fairly mature? ;-)

Re:More Information

[jbolden]

I don't know the other two but fro what I've heard:

Python --
Similar to Perl. Tighter syntax, slightly less flexable

Ruby --
Much better OO implementation much smaller library.

So Perl 6 should be way more flesable than either of the other 2. We have to wait another 4/6 apocylopses to see about the comparison of the object orientation.

Re:More Information

[Anonymous Coward]

What does "flesable" mean? Does it mean major syntax changes every new major version?

Re:More Information

[jbolden]

I typo for flexible. As far as major syntax changes I'd guess so. There were pretty large changes from 4 to 5 as well so I'd assume Perl 7 will be big.

As for what it means its the ability to code the way you want, the "there is more than one way to do it" that makes Perl special.

Re:More Information

[Jerf]

Actually, my experience is quite the opposite. Python is much more flexible then Perl. I keep trying to do things in Perl that are easy in Python, and they are either difficult, impossible, or too dangerous due to other side effects. One biggie I wanted recently was to wrap a method in an object with something else. In Python like this:

o = SomeObject() # with method "method", let's say
def method_wrapper(self, *args, **kwds):
print "I'm a wrapper!"
self.method_orig(*args, **kwds)
o.method_wrapper = o.method
o.method = method_wrapper

Perl wouldn't let me do that. So I went a different route with anonymous subs and it's fine, but this is just an example of a general principle, which is that in the (useful!) tricks department, I'm usually stuck in Perl when in Python it'd be easier. (Metaclasses, anyone? I'm not even certain it could be done correctly in Perl.)

Now, that shouldn't be a shock. There is a price to pay for Perl's flexibility, as well as gains. There is a price to pay for Python's "tighter" syntax, but gains as well. (Python is also much easier to mentally model, for what it's worth; I feel I could re-implement Python in a reasonable amount of time, I don't feel like I could ever quite match Perl's quirks.) Both languages have their place.

Re:More Information

[tuffy]

Python is also much easier to mentally model, for what it's worth; I feel I could re-implement Python in a reasonable amount of time, I don't feel like I could ever quite match Perl's quirks.

That, I think, is Python's greatest strength. In spite of Larry Wall's cute quotations about language design, Perl's numerous quirks simply don't conform to my way of envisioning a language or program. The result is lots of book-checking to manage its "unique" syntax. OTOH, I can build virtually any Python app with O'Reilly's pocket reference and the PDF library reference.

I'm sure a lot of folks dig Perl, but I don't believe it's a language for everybody.

Re:More Information

[Skald]

On another note, is Perl 6 even going to be relevant with next-generation languages like Ruby and Python already fairly mature? ;-)

If Perl6 goes according to plan, absolutely. In fact, it'll be particularly relevant to Ruby and Python.

More than any other thing, in my opinion, Perl has CPAN going for it. Other languages have tried similar code sharing projects, and none of them have come close to matching CPAN's breadth and (despite the occasional wonky module) usefulness.

More than any other thing, in my opinion, Java has the JVM going for it. Not that it's the only virtual machine out there, but it's the only one which really has broad distribution. The ability to distribute compiled bytecode, and to run it in a "sandbox", are two of Java's biggest selling points.

If Perl6 succeeds, neither of these languages will keep their greatest advantages. Perl6 is merely to be a Parrot compiler... and where Sun has actively tried to keep other languages off of the JVM, the Parrot developers want to entice other languages onto the Parrot. Any languages rewritten to target the Parrot, then, should (given some hooks, perhaps) be able to take advantage of the CPAN modules which are the wealth of the enormous Perl community.

To the extent that Perl6 succeeds, Python, Ruby, Scheme, O'Caml, and who-knows-what other languages stand to find themselves able to "write once, and run anywhere". Potentially, this could lower the bar for new and interesting languages to compete, since they'd primarily be competing as languages, with the runtime environment issues (more or less) abstracted away. In the same way that Mozilla allowed for today's proliferation of browsers, Parrot could be a very good thing for languages.

But while Perl6's progress will certainly be relevant, in the long term it risks obsolescence by virtue of its own ambitions. Frankly, if that were the case, I don't think it'd bother Larry all that much... however the Perl community doesn't seem to be ready to go gentle into that good night. A lot of Perl6's remarkably ambitious agenda seems to me an effort to stave off the possibility of the danger that Perl will become a victim of its own, and Parrot's, success.

Re:More Information

[jbolden]

I don't agree with you about less flexible. I'll certainly agree that Python notation is less confusing but that is a different issue.

Anyway I'm having a little trouble understanding what you wanted to do. It seems like you wanted to temporarily replace a function with another function with the same name. The easiest way to play these sorts of games in Perl is by using globs.

Re:More Information

[geniusj]

I agree.. Parrot is really what I'm waiting for in Perl 6. Parrot seems to promise for all platforms what .NET is promising for windows. I know there is currently work being done as we speak to make a parrot bytecode compiler for ruby.. It will also probably be done before Ruby's implementation that Matz is working on called 'Rite'. I really hope that parrot gets lots of community support and wide adoption, because it could really play a major role in the future of scripting..

Re:More Information

[khuber]

Perl is, was, and always will be a huge hack and hacks on top of hacks. Why is it so hard to create data structures in Perl? Python is more logical and orthogonal. Ruby is a bastardized Python with a bunch of ugly Perl-like syntax.

-Kevin

Re:More Information

[jbolden]

What datastructures are hard to create? Most of the more common ones are built right into the language as native data types.

Re:More Information

[khuber]

In the olden days, Perl 4 didn't let you do complex data structures and Perl 5 added that. Well, it was a big hack job.

I'm thinking about things with references where you have to know the difference between and when to use

percent, precent$, \percent { ...}, at{ ... }, [ ... ] (sorry - lameness filter isn't letting me put real Perl code, heh heh)

, and so on or the idiotic context sensitive meaning of variables (list vs. scalar) and when you need to use the scalar keyword to override it.

Python doesn't need the equivalent of Tom Christiansen's Perl Data Structures Cookbook / man perldsc because everything's a reference and it's more straightforward.

-Kevin

Re:More Information

[jbolden]

OK so in other words you can't think of any datastrctures that are hard. So please stop throwing this claim around.

As for using a reference vs. variable that's something people from C. They also can learn by example. Finally trial and error doesn't take too long. I agree that Perl is harder to learn than Python because in many ways its lower level. Python doesn't expose the intermediate program nearly as much to the "how a scripting language works behind the scenes" details.

As for context sensitive, that's considered a feature a Perl; its quite deliberate. That's not a failure of the language in any sense rather its taking polymorphism and automatic conversion much further than its gone almost anywhere else.

As for Python supporting all of Perl's datastructures:

lets assume I have an Oracle database with:
last_name, first_nsame, address, zip
last_name is the primary key. I want a heap structure so I can read/write to this table naturally; do things like:

$table{'Weinter'}->{zip}=92347 and this is a database write; i.e. the Oracle acts like a native datatype.
That takes about 6 lines of Perl to setup how about in Python?

Mirror

[zachlipton]

It wouldn't be slashdot without a mirror:

http://www.zachlipton.com/apocalypse6.html

Re:Mirror

[Anonymous Coward]

It also wouldn't be slashdot without a karma whore like you, who mirrors a page sitting at a fat pipe that has no risk of getting slashdotted to earn karma points.

Re:Mirror

[Anonymous Coward]

Speaking of fat pipes, how wide is your bunghole, Mr Goat?

Re:Mirror

[Second_Derivative]

But then it doesn't use O'Reilly's brainfucked CSS so it's actually useable under Konqueror. So, I dunno, I'm thankful at least.

The Last Apocolypse...

[Anonymous Coward]

... was 9 months ago! I knew Perl was slow, but that's just bad! 8^)

Just kidding, great work guys!

Re:Python is better.

[MisterFancypants]

There you have it. Proof positive that Python is much better than Perl.

subroutines

[zephc]

In Star Trek, they always call new functionality as 'subroutines', which leads me to think that the LCARS system was written in Perl (Perl 2000 Xtreme?). A scary thought indeed...

Re:subroutines

[CoolVibe]

Other languages have subroutines too, you know, like BASIC? LCARS in Visual Basic, now _THAT_ is a scary thought. I'd rather debug it in C or in perl.

Perl is turning into a completely new language

[siewsk]

I remenber the days of perl 5.004 and boy was that good and compact! Then as time so pass, more and more "features" are added into perl 5.004 and the result is that now you have too many features spoils the broth. As perl 5.004 it is PERFECT for replacing bourne shell, sed and awk. But instead of being stable (and not changing), it kept on changing. This is bad from a system admin point of view because you want to be sure that the script you wrote in 1999 will work in 2019 without any changes (just like bourne shell).

Instead if Perl kept on changing then you can't be sure and when you have literally thousands of little perl scripts everywhere this is intolerable.

Perhaps they should have kept Perl 5 as /usr/bin/perl5 and make sure that it stays static for all eternity. There are values in things which do not change, things you can depend on year after year without fear.

Re:Perl is turning into a completely new language

[wirelessbuzzers]

There is something like this in perl 6, although I don't remember what it is. Probably something like require Perl5;

Re:Perl is turning into a completely new language

[terraformer]

Then as time so pass, more and more "features" are added into perl 5.004 and the result is that now you have too many features spoils the broth.

No, most of these "features" as you call them are not added into perl, they are added in as bundled modules. Perl's core is kept small for this very reason. As for Perl 6, that is going to be radically different but perl5 will be able to live on the same machine as perl 6 and I would imagine that a great deal of people will keep both around and maintain both for a great while.

Re:Perl is turning into a completely new language

[Enoch]

Then as time so pass, more and more "features" are added into perl 5.004 and the result is that now you have too many features spoils the broth.

I'm sorry. I think you are looking for this every-feature-is-in-the-core language.

Glad to point you in the right direction!

enoch

Re:Perl is turning into a completely new language

[antis0c]

You obviously aren't aware of exactly what Perl 6 is. It's more than just a language, it's a whole runtime environment similar to .NET or Java. When Perl 6 comes out you can continue to use your Perl 5 scripts with it, or write scripts in Pascal, or in C, or in Java, or in BrainFuck. The compiler and runtime are completely separated.

Re:Perl is turning into a completely new language

[Istealmymusic]

I'm reminded of a quote:

We biologists have a special word for stable. It is "dead".

Re:Perl is turning into a completely new language

[jbolden]

The default on perl 6 is to use perl 5 compatability mode. So you won't need both.

Re:Perl is turning into a completely new language

[jbolden]

Why did you start using Perl in the 5.4 days if you wanted a highly stable language? Perl was undergoing rapid change at that point, and there was talk of much more (like the merger with Java, and getting rid of many Unix dependencies so Perl on Win32 worked well). Whoever told you Perl was stable in the "we don't intend to change it sense"?

Re:Perl is turning into a completely new language

[drunkToaster]

Instead if Perl kept on changing then you can't be sure and when you have literally thousands of little perl scripts everywhere this is intolerable.

You quack! if you don't want perl to change, don't fucking change it. Seriously if all your scripts are 5.00xx centric, fine. If newer features of the language don't shine your apples, fine. If you want to bitch about your scripts breaking when you roll perl forward, you might want to investigate "man ln" or maybe "configure --prefix=/head/up/arse/sysadmin".

Re:Perl is turning into a completely new language

[Anonymous Coward]

in Pascal, or in C, or in Java, or in BrainFuck.

I am so looking forward to Microsoft BrainFuck.

Re:Perl is turning into a completely new language

[andy@petdance.com]

We biologists have a special word for stable. It is "dead".

Interesting that that quote is Jarkko's sig. Jarkko is the Perl 5.8 pumpking.

Re:Perl is turning into a completely new language

[bm_luethke]

That's why they are biologists instead of computer scientists.

Re:Perl is turning into a completely new language

[kisielk]

I am so looking forward to Microsoft BrainFuck.

It's called Visual Basic ;)

Re:Perl is turning into a completely new language

[Anonymous Coward]

You obviously aren't aware of exactly what Perl 6 is. It's more than just a language, it's a whole runtime environment similar to .NET or Java.

That is incorrect. Parrot (parrotcode.org) is the runtime engine that will replace the Perl 5 interpreter. Perl 6 is one of the languages that will use it.

ughgh

[Anonymous Coward]

This is why I hate Perl

multi *caller (?$where = &CALLER::_, Int +$skip = 0, Str +$label)

my brain can't grok that

Re:ughgh

[stratjakt]

This is why perl will disappear.

I can understand some obscurity in lower level languages, like C, or as low as ASM itself. But a higher level scripting language should be as close to english (or another human language) as possible.

I dont see the inherent advantage in desinging a language thats hard to read. Frankly I'd rather see scripts written in VBScript than perl.

Re:ughgh

[Anonymous Coward]

Like C has disappeared? I agree with the sentiment, but I doubt it will become reality.

And once you've been doing it long enough you become mentally deformed and it starts to look completely natural...

Re:ughgh

[wdr1]

The problem with the English language is that it's too ambiguous. While that makes for wonderful poetry, literature, and stories, it makes for horrible programming syntax or anything relating strictly to logic. Think of why mathematicians had to create the word "iff."

It can also make things *harder*. The grammar and syntax of English is very fast and loose, but well known to it's speakers. Most likely the English-based programming language won't be able to mimic every little natural-language nuance, leaving the developer the headache of remember what rules are followed in which and when. When one says "or" in common, everyday conversation, it generally means an exclusive "or." When I say "or" in just about programming language, it means an inclusive "or." In an English language development language do you worry about conjugating verbs? What about tenses? Etc. You get the drift.

Using English keywords is great & helps simplify the problem, but as someone way smarter than me said "Things should be made as simple as possible -- but no simpler."

-Bill

Re:ughgh

[Kaa]

But a higher level scripting language should be as close to english (or another human language) as possible

No. That's conceptually wrong.

A (programming) language should make it easy to construct solutions for problems it has been designed to solve. Natural languages, such as English, are good for certain sets of problems and quite bad for other sets of problems.

Would you like to replace math notation with sentences in English?

Re:ughgh

[SuuSt]

Heres the thing though, sure I have no idea what that says, but that's just because somebody decided to be very clever/brief/or both. Half my job is to write Perl scripts and sure there are about a million neato tricks that I could use to make my code really short and impossible to read but I never learned them and have no intention to. If you want, Perl can look more or less exactly like C, or if you want it can look like the above. It's all a matter of what you want out of perl.

When they say theres more than one way to do it, syntax is included in there too.

Re:ughgh

[Anonymous Coward]

This is why you will disappear.

I can understand some obtuseness in lower level geeks, like my freshmen, or as low as high schoolers. But a higher level geek should be as close to the programmer efficiency (or another real performance measure) as possible.

I dont see the inherent advantage in talking to you. Frankly I'd rather beat the bishop than read your posts.

Re:ughgh

[Anonymous Coward]

You can write readable code in perl. It's just that a lot of scripters like to make their code as compact as possible, sacrificing readability for...I don't know what. When I write perl scripts, I write them so that I'll understand what I was doing when I look at it 6 months later.

Re:ughgh

[maugt]

Mathematicians created iff because we're lazy. Thats it. Nothing to do with the english language.

Oh, and we like confusing people who know nothing about math by having our own syntax.

Re:ughgh

[tinrib]

there are plenty of situations where legibilty and maintainability are not as important as fast results (i.e. quickly coded). In this area perl SHINES and is not going anywhere. Myself, I would think very carefully before writing anything more than a few hundred lines at most in perl, but for short scripts etc. where the most important thing is getting the thing written ASAP, perl is unbeatable. To say that perl will disappear is naive at best.

Re:ughgh

[Anonymous Coward]

And other abreviations like QED, and the three-dots 'therefore' are the same. It's shorthand for english, not an obfuscation of the language.

Re:ughgh

[vadim_t]

I think I have been trolled, but I'll reply anyway.

Once I was bored and wrote one line of C code that iterated over an array, and printed its elements separating then with commas, and printed an "and" instead of a comma for the last element. The code consisted of a for, a printf, and ? :'s in it.

Now, don't try to tell me it was readable. Every language can be used to write horrible code.

Besides, that doesn't even look as Perl. "?$where" makes no syntactical sense, variables have names like $where and that's it, "Str + $label" makes no sense either, unless Str is a constant, and "Int +$skip = 0" makes about as much sense as in C, because supposing it's comparing an addition with 0 it should be using ==.

Re:ughgh

[Guppy06]

"Would you like to replace math notation with sentences in English?"

I'll go for the one that actually has keys on my keyboard. Until I start seeing Cyrillic on my QWERTY, I'm stuck with "the partial derivative of..."

And the last thing I'm going to do is make up new symbols just because they're not on my keyboard.

Re:ughgh

[Guignol]

well, it's a shorthand for latin actualy,
but yeah :)

Re:ughgh

[wdr1]

You're saying that one has to clarify between "if" and "if and only if" has nothing to do with the English language? That's at the heart of it.

-Bill

Re:ughgh

[fanatic]

your objection might have some legs if you had at least used vlid perl code.

I can make ANY language look bad if I can break the rules.

Re:ughgh

[jbolden]

There is a language called COBOL which was designed in the 1950s to resemble logical english syntax as much as possible. The problem is sequences of instructions and human languages don't map very well. So surfacey kinds of simarity create languages that are neither good computer languages nor terribly understandable.

Actually from a grammer standpoint Perl is far closer to a real human language than almost any other language. For example the use of pronouns (implied variables) in Perl is very much like a human language and very unlike most computer languages.
The inventor of Python agrees with this assessement but since he considers this a bad thing he didn't emulate it in Python.

Re:ughgh

[Eimi Metamorphoumai]

If you'd read the Apocalypse, you'd know that that line was taken directly from it (although it was an example of a possible implementation of a bit of the internals of perl).

Re:ughgh

[etcpasswd]

Mathematicians use all sorts of symbols for a good reason - and that is not because they want to confuse everyone else. Imagine complicated equations being expressed in English. The purpose of a computer language is also very similar - to reduce your intent to a well known set of symbols.

Re:ughgh

[vadim_t]

It's ugly indeed. But internals are rarely pretty. Just take a look at files in /usr/include, stdlib.h, for example. I wanted to paste here an example, but darn slashcode asks me to "Please use fewer 'junk' characters".

Re:ughgh

[wideBlueSkies]

Yeah, but you don't have to write that way.

There's more than one way to do it.

You can write totally obfuscated/clever crap in any language. Or not. It's up to you.

Re:ughgh

[kmellis]

"Actually from a grammer standpoint Perl is far closer to a real human language than almost any other language."

And let's not forget that Wall's education is as a linguist, and not as a computer scientist.

To my mind, the best computing language designer would be someone with extensive education and experience in: computer engineering, computer science, linguistics, mathematics, engineering and business processes, maybe psychology, and perhaps some other things I'm forgetting at the moment. My point is that a good designer would have a very strong comprehension of the problem space (the problems this tool is intended to solve), how the tool is likely to actually be used in the real world, how the problem space will evolve over time, all coupled with a very strong comprehension of the most efficient method of implementing this tool in the technology available. That's asking a lot.

In Wall's case, I think that he has a fair amount of experience as a practical coder, which is the impetus for his extremely strong emphasis on pragmatism in his language design. This would be a disaster for most designers, probably, but Wall's education in linguistics probably tempers that pragmatism with some comprehension of higher-level abstraction and some imposition of rigor. You can most clearly see this aspect of Wall's world-view coming through in the Perl 6 design.

However, even though in some sense the scientific view related to linguistics is an abstraction similar to the scientific view of computer science, they're fundamentally dissimilar. Linguistics is an attempt to comprehend and formalize a very complex and exquisitely functional system--human language. In contrast, Computer Science is not a descriptive science; it tends to be proscriptive--looking for the best way to do things, often from an ahistorical almost-Platonic perspective. As a result, it tends to be overly ideological. I chose the word "proscriptive" with some care, as in the realm of human language it identifies a fault line. Linguists tend to be notoriously relativist, asserting that what is "correct" is simple what exists. Proscriptivists, such as one's fourth grade English teacher, insist that there's truly "correct" and "incorrect" usage. In this sense, Wall's background in linguistics clearly has influenced his philosophy of computing language design; and, I think, computing language purists really are psychologically akin to the proscriptivist grammarians like the aforementioned fourth grade teacher.

For my part, in the realm of tools, I prefer aesthetic purity or elegance only when it serves utility (or, at least, doesn't interfere with utility). Perl is well-matched to its problem space, and in this it actually does have, in my opinion, some beauty. I mean, from one perspective a Swiss Army knife is god-awful ugly; but from another, its compact and wide-ranging utility is attractive. Because Perl is intended to operate in such a large problem space, I believe that simplicity, and the form of beauty that is a function of simplicity, is largely denied to it. So? We can't have everything. Ideally, there'd be a wide range of computing languages each perfectly and exquisitely engineered for their respective problem spaces. But, right now, computing isn't even close to being mature enough to support such a thing. In other engineering and science disciplines, there are a variety of tools and methods and specializations each well-suited to the problem domain they serve. And it works because a civil engineer isn't expected to do nuclear engineering work, nor an astrophysicist to do nuclear physics. But programmers are still expected to be jack-of-all-trades, and thus their tools are required to be as versatile--but also as unoptimized--as they are.

Re:ughgh

[geniusj]

It seems to work pretty well for Applescript.. If you have never tried it, I recommend looking at it (just for curiosity's sake).. Granted, it doesn't offer the same flexibility as perl, but it's great for easy automation.

Re:ughgh

[CProgrammer98]

Thats the whole point - it IS valid perl (6) code!!! it was pasted from the apocolypse.

I think Mr Wall knows his perl syntax :)

Re:ughgh

[fanatic]

Oops. I was using perl 5 to validate. If that's truly valid perl 6 code, it is ugly. On the other hand, it has always been possible to write ugly, incomprehensible perl code. That doesn't mean it has to end up that way. Good variable names and use of parentheses and braces beyond the absolute minimum needed for parsing go a long way for improving readability.

Re:ughgh

[jbolden]

I agree most everything you wrote. I do think its worth adding something though: the organic vs. the constructed. Most languages start off constructed and they are:

a) highly consistent
b) easy to learn
c) very well fitted to the problem space

assuming the language is succesful the language gets applied to larger and larger problem areas and features get added that were originally considered in the design. The language moves towards becoming

a') inconsistent
b') complex
c') highly versitile over a wide range of problem spaces

If Perl were only still used mainly as a replacement for awk and sed it wouldn't be controversial. But over time Perl became a replacement for shell scripting and finally the "duct tape of computer science". To do this its added a tremendous number of libraries and these were developed independently of one another.

Since computer scientists are more reasearch oriented they tend to use "younger" tools; conversely people in the field are often using older tools for a variety of reasons.

___________

Finally one area I disagree with you is:
Ideally, there'd be a wide range of computing languages each perfectly and exquisitely engineered for their respective problem spaces. But, right now, computing isn't even close to being mature enough to support such a thing.

I actually think there are languages that are highly specialized for individual fields. In practice though the general purpose languages tend to be used much more often because these tools are too specialized. For example in math there are languages for:

-- number theory over finite fields
-- number theory over abstract fields
-- sparse matrix problems
-- crack based pde
-- ring theory ....

But in practice most people just Maple, Mathematica or Matlab because they don't want to have to learn a wide range of tools and these other languages are missing important features in other areas (like TeX export or GUIs).

Re:ughgh

[Tassach]

it has always been possible to write ugly, incomprehensible perl code

[sarcasm]
You mean it's possible to write Perl code that is clean and comprehensible? And here I thought that any sufficently advanced Perl script was indistinguishable from line noise.
[/sarcasm]

Don't forget Parrot

[Ars-Fartsica]

The VM is showing 10x speed improvements in preliminary tests. Couple that in with Moore's law and Perl (or any languages that compiles to the Parrot VM) becomes a very attractive language for more types of problems.

Re:Don't forget Parrot

[taliver]

However, you'll always be sacrificing speed for readability. Even if you think it's 'good enough', you should still hope that noone wants that extra order of magnitude in performance you can get with a truly compiled language.

Just look at what happens everytime someone goes about writing an OS in Java. Someone invariably points out that the same thing would run 300% faster if C had been used instead.

And, I'm sorry to say, there will always be a need for performance.

Always.

Re:Don't forget Parrot

[data64]

Perl (or any languages that compiles to the Parrot VM) becomes a very attractive language for more types of problems.

I guess this is becoming something like the CLR.

Re:Don't forget Parrot

[mlinksva]

10x speed improvement over what?

Re:Don't forget Parrot

[Anonymous Coward]

CLR is for statically-typed langauges. Parrot solves a different set of problems (and has an interesting register-based approach a little reminiscent of the deeply proprietary Tao/Amiga VM)

All that said, I'd still rather use a Common Lisp native compiler like CMUCL.

Re:Don't forget Parrot

[evronm]

I agree. When parrot comes out, there will essentially be 4 development platforms:

• JVM
• MS.NET
• Parrot
• low level (I'm lumping C and ASM here for the sake of brevity)

The fourth will be used for applications where speed is really key (real time, database engines, OS's, etc.)

For all other apps, it will be a matter of choosing one of the other 3 environments, and a language.

This choice will be particularly interesting given the fact that some languages (e.g. perl) will work with more than 1 of these environments (.NET and Parrot).

It's going to be an interesting world...

Re:Don't forget Parrot

[jbolden]

Maybe, maybe not. During the transition to Win32 people have finally given on hand coded assembler for business apps. In this decade people seem to be willing to use more high level API calls and even Java...

Even more dramatically think about how few problems use custom hardware anymore. Even the "custom" hardware like graphics chips are pretty generic.

Re:Don't forget Parrot

[Anonymous Coward]

Yes, but it will be interesting to see which VM gets ported more.

The JVM is interesting because it's ported to many platforms AND it's ported by many vendors. .Net is mildly interesting because of Mono.

Parrot will be interesting because it Has To Be Ported (tm) in order get Perl 6 as prevalent as it is today.

It will be nice to see if Parrot will be a good choice for embedding as a VM (versus embedding as a scripting language).

Why just embed the VM? Perhaps for folks who want to ship binary versions of their systems.

Re:Don't forget Parrot

[wdr1]

Maybe, maybe not. During the transition to Win32 people have finally given on hand coded assembler for business apps. In this decade people seem to be willing to use more high level API calls and even Java...

That also probaby stems from the fact that compilers got much better at generating optimized assembly code. These days the average programmer problably isn't going to be able the beat the compiler, so why take make the implementation much more difficult?

-Bill

Re:Don't forget Parrot

[jbolden]

Exactly. And the advocates of high level languages would say that in practice an easy to understand high level business app + good compiler will do well against a low level language implementation even in terms of performance. Compiler algorithems will be more effecient than human ones....

Re:Don't forget Parrot

[taliver]

However, interpretted code (Java or Perl) will always run slower than natively compiled code. Even assuming JIT compiling.

And as far as algorithms go, I was unaware that high level languages had gotten to the point of "sort and store this information in the best possible way for this application" being an acceptable form of instruction.

Now, this being said, I can certainly see the day where the norm becomes Most code in Java/Perl + some of the more numerical or the body of tight loops being in C + some instructions hand optimized. (If this isn't he common practice already).

Re:Don't forget Parrot

[god]

I disagree. It's fully possible for interpreted code to go faster than natively compiled code as you have far more information at runtime than at compile time. You can specialise for the currently-common case and do lots more clever JIT tricks.

Recently some JIT improvements have made interpreted Parrot faster than GCC-compiled code for a simple primes benchmark. See, it's entirely possible ;-)

Re:Don't forget Parrot

[taliver]

I'm assuming you're referencing this:

The primes.java test used in the article is a bit tricky because they
used "long" for all the calculation instead of "int", and GCC doesn't
produce particularly efficient code for the 64-bit mod operation. After
changing "long" to "int", gcj beats both IBM and Sun Linux JDKs. With
"long" we are slightly faster than Sun, but a lot slower than IBM - so
obviously their JIT must have better optimized "long" operations.
From here.

So, it seems that the JIT compiler knew the underlying architecture and was able to use a better represenation of integers in it.

Specifically, my problem is the following:

Every Java program is really two (or more) programs running at the same time: something to compile it, and the program itself. Once it's run long enough, you may be able to assume that the program is fully compiled and runs just like native code-- except for all the bounds checking and possible garbage collection.

Now, it could be that this added amount of security is well worth it. However, it's going to take some really creative run time optimizations to gain back these losses.

Re:Don't forget Parrot

[Anonymous Coward]

a 10x speed improvement over other vaporware VMs.

Re:Don't forget Parrot

[jbolden]

And as far as algorithms go, I was unaware that high level languages had gotten to the point of "sort and store this information in the best possible way for this application" being an acceptable form of instruction.

a tied_array is a database:

my @tied_array = sort {optional sort definition} ;

Yep they are that high level. More importantly a lot of things happen automatically:

tied_array uses the high level database features so the programer is unlikely to make as many mistakes.
sort uses the system sort routine ....

Re:Don't forget Parrot

[jbolden]

after the option sort definition came &lt INPUT_RECORDS &GT

in other words a perl file handle. I forgot that would get mangled.

Re:Don't forget Parrot

[taliver]

And how do you know that's the most efficient way to store the data? Is it a B-Tree? A Fib. Heap? A stack? A sorted list? There are very large and detailed books on algorithm and data structure selection.

Now, one or two might do for most cases, but if you really care about efficiency of your sort and storing(and I mean _really_ care), then you'd have to look more closely at the algorithm you're choosing, and not just say, "Oh, Perl, do this."

Re:Don't forget Parrot

[jbolden]

B-Tree = perl hash
A stack = perl array
Heap = perl array
sorted linked list = perl array after a sort
If you need lots of control and the data is complicated: Perl DBI -> Oracle.

The native datatypes in perl are pretty complicated and include the functionality. Its easy to create datastructures that have multiple features and so unless the person picks really badly they will be fine. A person who would pick really badly isn't going to do better in a low level language.

Really the only place native Perl falls down is for indexed datastructures (i.e. organized on one variable indexed on another); but for that you have direct access to databases. I don't see how C offers anything nearly as good much less better.

Re:Don't forget Parrot

[taliver]

However, you have somewhat proven my point. I was stating that high level languages had not reached the level of "put this data in the most efficient manner possible" problem. Sure, Perl is great. But notice that you, the programmer, still had to know which type you should be using.

Don't get me wrong, my only statement is that high level languages now, and quite possibly will always, require a deep understanding of the associations of the data they are maintaining.

The main thing that C offers over Perl is speed(always), and a more efficient use of memory, (generally).

Re:Don't forget Parrot

[IpalindromeI]

I think he means a 10x speed improvement over Perl 5.

Re:Don't forget Parrot

[khuber]

The JVM is very limited. There's no bytecode goto, for example. Parrot looks like a better general purpose VM.

-Kevin

Re:Don't forget Parrot

[Anonymous Coward]

Wrong. goto is a bytecode in the JVM.

Re:Don't forget Parrot

[khuber]

Oops, you're right. Brain short circuit.

-Kevin

Re:Python is better.

[Anonymous Coward]

lol

Perl, the new ADA

[ajm]

I used to think that perl might become the new COBOL. Now it looks like it's going to be the new ADA. Lots of nice features but such complexity and cleverness that even the people who use it don't like it. ADA's a good language, but no one uses it. It would be a shame if perl 6 went the same way.

Perhaps the cleverness of the ideas are not being tempered by real use at this point. A language does not become great by adding new syntax and semantics for each feature but by refining it to the essential units needed to express all the rest. We should not celebrate the fact that "will" and "is" are very similar ways to express traits in perl 6. We should ask instead why do we need both? Further, is it possible for me to define a new "wont" statement in perl, or are "will" and "is" special things only language designers can implement?

Re:Perl, the new ADA

[TimToady]

The entire syntax is redefinable, including removing will if you hate it.

Re:Perl, the new ADA

[j3110]

and that's a good thing?

I don't know about you, but I like my languages to be pretty static. You can't really learn a language that's different everyday. Also, I don't like languages that let you do things 80 different ways. There are enough fights over where the curley braces go. Perl is not a team sport. Open source perl scripts are slightly less open than open source programs.

Now, if Parrot has only one instruction for things like "until" and "while", and someone wrote a decompiler that supported each person's own style of programming, then we may be in business :) (assuming it saves as much info as Java does in the byte-code)

This is kind of like the whole .Net issue. If the program can be converted between the languages that the CLR supports, it would be infinitely more useful. If Perl can convert between any of the million dialects that any given user will use, then it stands a chance of making it much easier for people to share perl code.

Re:Perl, the new ADA

[wayland]

Ha! We now have Unicode and operator overloading. Just wait until I get to it. Perl6 will be the new APL! :)

Re:Perl, the new ADA

[James Lanfear]

Lots of nice features but such complexity and cleverness that even the people who use it don't like it.

IME, Ada is exceptionally well-liked by the people who know it (note: use != know). I've seen far fewer complaints about it from Ada programmers than I've seen from, e.g., C++ or Perl programmers about those languages.

ADA's a good language, but no one uses it.

Right, just like how no one uses Linux on the desktop.

Re:Perl, the new ADA

[gse]

Ada is, in fact, a really great language. It's not really that complex (though Ada compilers are) or clever; in fact, it reads more naturally than most languages I've used. (and much more naturally than most perl -- talk about cleverness.)

I attribute Ada's glorious failure to a few things, and none of them are the language itself:

• It was developed by the gov't. Nobody likes the gov't.
• The compilers are, like I said, really hard to write. So it took a long time for them to get implemented right, and there sure weren't any free (or even "affordable") ones for a long time.
• And the big one: no standard set of class libraries. No Java-like API, no STL, nothing. If you wanted a linked list you had to write it yourself. The Java API is half the reason that Java is so great to work with, and IMO has a lot to do with the language's success.

I really liked programming in Ada. I hated it at first (coming from being a C hacker in college) but in hindsight, it's the only language I've used that left me a better programmer.

php.net does documention like no other

[apachetoolbox]

I'd love to see perl documented in the same manner as php.net documents PHP. How about it www.perl.com guys?

Re:php.net does documention like no other

[Anonymous Coward]

What's wrong with http://www.perldoc.com?

Re:php.net does documention like no other

[__past__]

If PHPs syntax and semantics weren't that broken, and if they wouldn't introduce incompatibilities with every minor version, the annoteded docs wouldn't be as neccessary as they are now.

Then again, you just compared it to perl, so I probably shoulnd't bitch about syntax and semantics right now...

Re:php.net does documention like no other

[Christianfreak]

I seriously hope you are kidding. Perl provides documentation right at my finger tips on the command line (and other help files espeically on windows). Try typing 'man perl' to see how many different man pages will show up directing you to the correct man page for your specific need.

Also if you want information on a specific function perldoc -f . (I believe a previous poster mentioned that).

Plus if you are on the web there are tons of resources all over the place. My favorite is http://perlmonks.org/ and if you want something like PHP.net there is http://perldoc.com/

Contrast that to PHP.net. I'm a programmer, and my job required me to learn PHP. No resources are availiable except for PHP.net. Finding specific info on PHP.net is a nightmare unless you know the name of the function you're looking for. There is no 'man php' that will give a good list and a description. Couple that with the fact that PHP has so many useless functions for such specific tags (come on haven't you people heard of regexes) it makes it very difficult to learn quickly.

IMHO of course.

Is this a joke?

[nosferatu-man]

What, Perl didn't have ENOUGH syntax before?

Sweet creeping zombie Jesus. At least the world of computing can take comfort in the fact that this trainwreck of a project will never ever see the light of day.

'jfb

But where does Elmer Fudd fit in

[Anonymous Coward]

Every damn time I see that movie, in the scenes that lead up to the infamous "I love the smell" line where the helicopters attack to Wagner, I see:

An image of Elmer Fudd dressed as a female Viking singing "Kill da Wabbit! Kill da Wabbit!".

It's open. You can do whatever you want...

[Wee]

Perhaps they should have kept Perl 5 as /usr/bin/perl5 and make sure that it stays static for all eternity.

Here's your solution:

[siewsk@hostname siewsk]$ tar zxvf perl-5.0.0.4.tar.gz; cd perl-5.0.0.4; rm -f config.sh Policy.sh
[siewsk@hostname siewsk]$ /bin/sh Configure --prefix=/usr/bin/perl5.0.0.4
[siewsk@hostname siewsk]$ make; make test
[siewsk@hostname siewsk]$ sudo make install
[siewsk@hostname siewsk]$ sudo ln -s /usr/bin/perl5.0.0.4/bin/perl /usr/bin/perl5

You now have /usr/bin/perl5 forever and ever, as long as you use #!/usr/bin/perl5 at the top of your scripts.

-B

Re:OT: Kudos for France

[Anonymous Coward]

dont forget about the 5000 people killed with nerve gas, or the 2200 gallons of anthrax.

Perl 6: Replacing old cruft with new cruft!

[wackybrit]

I am a Perl fanatic. I love Perl. But what is going on with Perl 6? The guys working on the Parrot VM for Perl 6 are doing such an amazing job, but I'm pretty dismayed about the language development on Perl 6 itself.

Perl 6 was meant to be a total rewrite. Nothing was meant to be sacred, cruft could disappear, and we'd be left with a mean language, true to its roots, and working on a hot new VM.

Instead we get stuff like this:

sub *print (*@list)

Talk about confusing! * signifies a glob, but in the above example the first * signifies a sort of 'package wildcard' meaning that the subroutine is global! The second *, however, is a glob, as in Perl 5. WTF? Perl 6 looks almost as inconsistent as PHP already, and it's only in draft!

Each page of this Apocalypse presented me with a new piece of cruft to look horrified about. Slurpy arrays!? Oh my god. Wall even goes on about 'psychological reasons' for syntax! 'Default values' and 'Rules' are things that are easily done with existing code.. it's not even as if they result in particularly crufty code in Perl 5.

I'm still looking forward to Perl 6, but it really does seem as if Parrot is where the true action is. Perl 6 really does look as if it is being designed by committee.

Re:Perl 6: Replacing old cruft with new cruft!

[gmuslera]

Instead we get stuff like this:
sub *print (*@list)
Talk about confusing! * signifies a glob, but in the above example the first * signifies a sort of 'package wildcard' meaning that the subroutine is global! The second *, however, is a glob, as in Perl 5. WTF? Perl 6 looks almost as inconsistent as PHP already, and it's only in draft!

Perl is more based in natural languages than in "traditional" programming languages. In natural languages, what you are saying depend on the context, the same words say different things if they are used in diffeerent situations or positions inside a phrase.

Well, in perl that also happens (in perl 5 you'll find a lot more examples of this, starting with the "$" in $a, $a[1] and $a{"red"}).and I think that it was more common in the previous versions (at least in Perl 6 I believe you'll have $a, @a[1] and %a{"red"})

Re:Perl 6: Replacing old cruft with new cruft!

[Anonymous Coward]

The second *, however, is a glob, as in Perl 5.

No it's not, you insensitive clod! That's the slurp operator (similar to Ruby's *). Try reading all relevant parts of the apocalypse before posting. Globs have long since been declared dead.

Re:Perl 6: Replacing old cruft with new cruft!

[angel'o'sphere]

The interesting thing about Larry Wall is: he is a linguist. That is a scientist researching how the human mind works with language, how language is structured and how language works.

I have heared that he explained in his first books how perl works from natual language point of views.

In the Apocalypses I saw also a lot of reasoning about how something is seen by a the human mind.

I can not help myself. But PERL transforms even more into a unreadable language.

I wrote a lot of perl scripts in Perl 4, about 300k LOC. After not looking at them after 1 or 2 years C++ coding, most of the tricks I used I did not understand anymore ... erm, thats 6 years ago, Perl4 is nealry 10 years ago.

Every time when I see a post about a new language I jump on it as I was a language geek when I started programming.

As soon as I see more than one $ or % or # sign in a sinlge line of code, I just trash the language.

I simply can not get why this is needed. I fully agree with the one who said programming languages should approach english. (probably because I learned Pascal as first true programming language, after BASIC and assembler)

I think a programmer should be able to read any program in any language. Or at least should be able to get a clue about what a program does, and how it does it.

Thre are so few constructs: variables, declarations, definitions, statements, structures, arrays.

Around that some programming concepts are woven .. imperative, declarative, functional ....

Why to make that more complex by silly abreviated keywords? (sub in perl, def in python) By useless and meaningless (for a uneducated reader) $ and # and % signs?

Perl is a language you an not learn by examining perl programs. You need a geek explaining it or time to read ALL docs. Thats a true draw back .... everybody who knows Pascal, C, C++, Ruby, Python, Ada can read Java.

Thats basicly why I stopped using perl. When Perl4 emerged I thought, better than C-shell definitly ... now I write bash ...

Well, and I left C++ and went to Java :-) With Java 1.5 I have all a language needs, except multiple inheritance :-/

angel'o'sphere

Re:Perl 6: Replacing old cruft with new cruft!

[Anonymous Coward]

I think a programmer should be able to read any program in any language.

Just like a writer should be able to read a story in any language?

Re:Perl 6: Replacing old cruft with new cruft!

[Ed Avis]

I think that typeglobs have been removed in perl6. So that * does not signify a glob. It signifies taking all the arguments into a single list, I think, so you can call print(1, 2, 3) and @list will have three elements. A similar syntax with * is used in Python and probably other languages.

I don't see similar comments saying how it's incredibly confusing that '(' and ')' mean different things in different places, or comma, or backslash. The same character in two different contexts can mean different things. If you had to invent a new character for every possible language construct you'd soon run out of keyboard space.

Re:Perl 6: Replacing old cruft with new cruft!

[Anonymous Coward]

Or program in APL... :-)

Re:Perl 6: Replacing old cruft with new cruft!

[Pelam]

(disclaimer: I'm not sure about any of this... Just some random soft arguments...
Feel free to blast them away ;)

I tend to think my self as visually oriented person.
I have a somewhat working pictographic memory (far from photographic:)
and I also find it helpful to sketch pictures and diagrams
while I'm thinking about something.

The fact is that plain alphabetic symbols tend to
look alike (in some stylistic sense)... I guess that's one of the things font designers are after...

For me it is really helpful to have punctuation in
code that jumps out and is easy to asssociate with
different things.
I guess that's the whole point of any punctuation...
to stand out from the wovels and consonants.

Do try to read english without punctuation (you could find it here on slashdot :)

I also don't think there is any inherent "limit of acceptable punctuation".
I find it easy to ignore most punctuation when reading code.
Well written perl code often makes sense that way.

Sometimes it is useful and easy to scan for some specific characters.

You also said that abreviations like "sub" and "def" are silly?

I think they serve a purpose for me at least...
I can fit more code in a screenful if the keywords are short.
This seems to help a lot somehow.
(Same goes for syntax, indentation and identifiers. (One of the reasons I don't like Java))

Maybe it helps to utilize all those
parallel processing visual neurons at the back of my brain.

Perl way is also faster to type...
Now that I have a real (US layout) keyboard,
I can also type most of those special characters much faster :D

-----

I hope all this helps you to understand why perl
is at least worthy of existence and why it might
be useful for some people.

Anyway you can probably redefine perl syntax
with simple macros to please the people who like to think the pascal way :)
(With no runtime overhead of course)

Perl obit?

[pongo000]

Looks like we finally get type signatures which are way more powerful than the rudimentary prototypes available with Perl5.

If I want function signatures, I'll reach for the C compiler. Otherwise, I don't want to be encumbered with having to keep track of data types. That's the (former) beauty of Perl: Powerful yet simple.

I think Perl 6 will be the end of the Perl dynasty as we know it. What a shame.

Re:Perl obit?

[erikdotla]

Then don't. The types are optional.

$x = 1;

Will still work. These three paragraphs should be reread:


The important thing is that we're adding a generalized type system to Perl. Let us begin by admitting that it is the height of madness to add a type system to a language that is well-loved for being typeless.

But mad or not, there are some good reasons to do just that. First, it makes it possible to write interfaces to other languages in Perl. Second, it gives the optimizer more information to think about. Third, it allows the S&M folks to inflict strongly typed compile-time semantics on each other. (Which is fine, as long as they don't inflict those semantics on the rest of us.) Fourth, a type system can be viewed as a pattern matching system for multi-method dispatch.

Which basically boils down to the notion that it's fine for Perl to have a type system as long as it's optional. It's just another area where Perl 6 will try to have its cake and eat it too.


(Bold added by me.)

perldocs already far beyond php.net docs

[Ars-Fartsica]

perldoc -f $FUNC

Does php provide anything like this?

What I typically hear and feel myself is that the php site documentation is sparse to a fault, with a great deal of useful information simply left out. Check out how many holes are filled in by contributors at the bottom of each page of the php.net site docs. These are glaring ommissions.

Re:perldocs already far beyond php.net docs

[L7_]

http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF -8&q=php+FUNC&btnG=Google+Search

Re:perldocs already far beyond php.net docs

[ChaosDiscord]

While perldoc (especially perldoc -f functionname) is keen, for those of us who like scroll bars, proportionally spaced fonts, and links, check out perldoc.com. It has documentation for multiple versions and a solid search engine. It also documents almost everything in the insanely useful CPAN.

Re:perldocs already far beyond php.net docs

[ProfKyne]

What I typically hear and feel myself is that the php site documentation is sparse to a fault, with a great deal of useful information simply left out. Check out how many holes are filled in by contributors at the bottom of each page of the php.net site docs. These are glaring ommissions.

$your_comment =~ s/omm/subm/;
Those are glaring submissions! And a very integral part of said PHP documentation!

Re:perldocs already far beyond php.net docs

[Koschei]

Only if the pages are frequently revised to incorporate said "submissions". Otherwise it's just a mess.

well...

[Anonymous Coward]

G.W Bush is nearer to make Apocalyse than Perl is!

Backwards support is a key Perl6 requirement

[Ars-Fartsica]

Your perl5 scripts will not be stranded. There are many ways this will be accomodated - by force or by detection of certain perl 5 tokens (like the package keyword).

Perl breaking Greenspun's 10th rule?

[Anonymous Coward]

Most scripting languages tend towards lisp in the end (just look at python - replace the whitespace with parens and whammo! 90% lisp).

But perl...

Perl is the first direct violation of Greenspun's 10th!. Perl 6 is the ANTI-LISP...

Just look at that syntactic MESS, just look at the wilful misunderstanding and abuse of Computer Science concepts and terminology.. or don't, because it will BURN OUT YOUR EYES. AAAAARGHHHH!!!.

Will Perl 6 lead to Slashcode 3?

[mhesseltine]

Considering all the features available, it seems like this would be the ideal time to freshen up slashcode. Then, maybe we'd see valid HTML 4, CSS support, layout without n-level deep tables, etc.

Why perl will survive:

[mcc]

I dont see the inherent advantage in desinging a language thats hard to read.

This is what's great about perl 6. Yes, it has so many insane features and rediculous complex rules and bizarre exceptions to its rules that when reading code with someone else's programming style, you may as well be reading a different programming language (Quick! What's the difference between "sub foo will do { something() }" and " { something() } " ?).

But the real strength in perl 6 is that it's just about infinitely configurable. You can redefine the grammar to fit your needs or whims. This is going, naturally, to cause 17 year olds who load their grammars up so much with wierd macros that their programs will become literal line noise that ceases to function if you change one character, but it will also mean that in the "enterprise", you can be completely shielded from the messiness. All it takes is defining a specialized version of "use strict" that reduces the language down to what you need, and suddenly perl 6 is some very simple, simple, easy to understand language. As long as the speed's OK, people enforce standardized coding within an organization and the default -w is really careful to warn you if you say { 1, 2, 3 => "a" } and it looks like what you probably meant was hash { 1, 2, 3 => "a" } , i don't see it being a real problem. And from a compatibility stndpoint, having one language with EVERYTHING and the ability to cut out what you don't need in wide swaths is way better than recurring situations where people go "well.. i want to use java, but i need feature X" and wind up using some funky third-party jvm compiler that produces huge executables and requires funky tricks to incorporate into my build cycle."

Perl 6 is as hairy as you want it to be, and no more.

Perl 6 is going to be the bestest second system ever! ^_^

Re:Why perl will survive:

[Anonymous Coward]

But the real strength in perl 6 is that it's just about infinitely configurable. You can redefine the grammar to fit your needs or whims.

Yay lisp! er, I mean perl!

Re:Why perl will survive:

[mcc]

Yay lisp! er, I mean perl!

As far as i can tell, perl 6 is supposed to evoke four main reactions:

• Whoa.. It's Scheme, but I don't have to deal with the pervasive suffix notation and all those parenthesis!
• Whoa.. It's Smalltalk, but less heavy on the Everythings-A-Message pounding and without all those wierd hard brackets!
• Whoa.. It's K, but without the need to completely rethink how i program!
• Whoa.. It's Perl, but the object system isn't an eyesore and the reference system doesn't make your head explode!

Or, alternately:

• Whoa.. It's a language with all the neat functional-flow-control bits of ML, but I don't actually have to write in ML!
• Whoa.. it's Objective C, but everything's an object, and no need to muck about with C types and baggage unless i really want to! or Whoa.. It's Java, but everything's an object, and there aren't any rules!
• Whoa.. It's APL, but without the need to completely rethink how i program and buy a new keyboard!
• Whoa.. It's a programming language I can trick into acting exactly like Java/LISP/ML/K/APL/Smalltalk/Ruby/Python/Prolog/C# /Mercury, and still use the Perl string manipulation tools!

Really.. it steals from everyone. I think it's even kind of the point. Of course, maybe I'm completely confused and wrong and have inserted Perl 6 here; but, well, these were the reactions i had :)

Re:Why perl will survive:

[Fastolfe]

All it takes is defining a specialized version of "use strict" that reduces the language down to what you need, and suddenly perl 6 is some very simple, simple, easy to understand language

And I'm not so sure I agree with this approach, since new developers would need to be trained first on Perl6, and then on the "enterprise"'s special enhancements to the language meant to reign it back.

Everyone should keep in mind that all of Perl6's new complexity, its new features and grammars are optional. You can very easily continue to write very simple, very readable scripts (and in many cases, even simpler and more readable than Perl5). The extra "stuff" is there for when you actually do need it, for when you're trying to do tricky stuff or trying to optimize your script by providing hints to the compiler. I wouldn't want some enterprise language layer mucking those abilities up for me.

Perl 6 is as hairy as you want it to be, and no more.

Exactly.

When did obfuscated code kill a language? Never

[Ars-Fartsica]

Gee, they hold an obfuscated C contest every year. You think C would vanish by now given the disgusting crap the coders write for the contest.

The original poster simply pulled something similar. There is no requirement that your perl look anything like that, nor is "powerful" perl more obfuscated than plainish looking perl. This is total FUD drummed up by someone who has presented a corner case....which I can assure you can be done for any language. In fact, I wouldn't touch a language for which this didn't hold.

Re:When did obfuscated code kill a language? Never

[Phroggy]

Gee, they hold an obfuscated C contest every year. You think C would vanish by now given the disgusting crap the coders write for the contest.

And the guy who wrote Perl usually wins.

Seeing the forest through the trees

[RichDice]

On first glace, the P6 syntax looks... scary. And I'm even someone who's been into P6 (at least marginally) for a few years now.

What I think though is important to remember is that if all you look at is the syntax, you won't appreciate the power -- and simplicity -- of the idioms. Taken out of context and put into cooked up examples meant to show off the new syntax, it looks bad... really bad. But once you actually start programming in it, you'll find that most of what you want and need to do will actually come quite simply.

That vast majority of all this new syntax will be applied in the vast minority of programming cases. Much of it will get sucked up into modules, classes, etc., that you'll use without worrying about what's actually going on under the hood. And "the rest of us" will just have an incredibly powerful language that is actually easier to program.

Cheers,
Richard

Re:Seeing the forest through the trees

[YellowBook]

Taken out of context and put into cooked up examples meant to show off the new syntax, it looks bad... really bad. But once you actually start programming in it, you'll find that most of what you want and need to do will actually come quite simply.

Probably so...though a lot of this is because individual Perl programmers will each learn their preferred subset of Perl6, and will use it. Woe, woe unto the maintenance programmer who has learned a different dialect of Perl6! Woe unto the maintenance programmer when you have redefined the language syntax for your own convenience!

And "the rest of us" will just have an incredibly powerful language that is actually easier to program.

Easier to write, harder to read once written. Languages with a lot of syntax are the Dark Side of the Force.

Use what you need

[Ars-Fartsica]

Perl 5 already contains enough crap to confuse even perl "experts", yet this doesn't stop adoption. Take Bjarne's advice and only use the parts of a language you need, ignore the esoterica. Something else confuse you? Ignore it. Chances are you don't need it anyway.

Perl has always had a lot of esoterica. Don't let it bog you down. You can be amazingly productive in perl without ever knowing what a typeglob is.

Re:Use what you need

[Anonymous Coward]

Until you have to use someone else code. Then you must know what they liked from the language.

Re:Use what you need

[Anonymous Coward]

well thats why you're getting paid. stop whining and open a book.

Re:Use what you need

[Shardis]

Or you can just look it up and go, "Oh! Of course." Jeez.

Re:Use what you need

[Anonymous Coward]

Too late! While you were scratching your head and reading books, your boss has subcontracted the rewrite to 10 Indian Java guys for half the price. So much for perl.

Write Only Language

[Opiuman]

This is not meant as flame-bait -- I've really tried to learn Perl. Even though I'm a 'real' programmer, I am not biased against scripting languages -- in fact, I think that the so-called 'duct-tape' languages are super-useful and important to technology in general.
Having said that, IMHO:
a) Perl, in the quick-and-dirty sense, is too dirty and not quick enough.
b) Have you ever seen C-obfuscation championship code? Now have you seen a Perl program that does anything more than "Hello World"? Notice the similarities?
Now I know that you can write bad code in any language, but bad-code in Perl is what I call 'job-security encryption' as you will never be able to fire the person who wrote the code, no matter how bad it is, because no one else will be able to read it. Either you re-write completely it or you keep that hacker...
On a side note, speed optimization in Perl tend to create spaghetti code with weird symbols for meat-balls. And I love meat-balls.

Re:Write Only Language

[Anonymous Coward]

Every language appears as obfuscated to non-speakers: C look horrible
to Basic programmers, and Lisp looks horrible to
Pascal programmers. And Perl looks horrible to
the non-initiated.

I have probably studied at least 15 langues in my time, complains of obfuscation usualy is much do do about nothing.

Re:Write Only Language

[dubl-u]

Now I know that you can write bad code in any language, but bad-code in Perl is what I call 'job-security encryption' as you will never be able to fire the person who wrote the code, no matter how bad it is, because no one else will be able to read it.

I've seen job-security code written in quite a number of languages. Even Java, which was clearly put together with the idea that a compiler could force conformance to 'proper' approaches.

If you are worried that somebody is writing crappy, unmaintainable code, the solution doesn't lie in tools. If you want to be sure that code can be maintained by other people, then you should have other people try to maintain it. Extreme Programming's practice of collective code ownership is one great way to do that. Other ways include mandatory rotations, code reviews done by people who will have to maintain the program, and code audits done by trained auditors.

There are also some automated design and code analysis tools that can help (like SmallWorlds or the handy copy/paste detector). But tools and audits are never a perfect substitute for the real thing.

Willard and Kurtz discuss refactoring...

[Dan-DAFC]

Willard: They say your methods are unsound.
Kurtz: Are my methods unsound?
Willard: I don't see... any method... at all, sir.

GCC Larry.pl -Wall

[smittyoneeach]

I'm waiting for Perl6 before I get too serious about Perl, as I don't want to have a lot of unlearning to do
Got about 10 pages into it before the /.ing. What a provocative language.

Question regarding:
my %pet is Hash of Array of Array of Hash of Array of Cat;

why not:
typedef my Hash of Array of Array of Hash of Array of Cat %pet;
IMHO, without typedef, C++ would be lost, particularly when the STL is on the loose...

Larry, your Boss is as good as mine... ;)

Re:GCC Larry.pl -Wall

[interiot]

I'm a thorough perl evangelist, but I usually end up telling coworkers to wait on Perl 6. As soon as they start dipping their toes in the water, they run across some weirdness that's not very intuitive to them. Invariably perl6 has changed that feature to be the way the newbie initially thought it should be.

The shortest distance to a solution

[Ars-Fartsica]

Perl provides syntactic shortcuts and people use them. You do not need to use them. You can write Ada/Java-like incredibly verbose muck in Perl if you like. No one is forcing you to take the shortcuts....yet people do. Why is this? Because time is more valuable than code to many people.

Perl 6 is easier than Perl 5. Really.

[ChaosDiscord]

But a higher level scripting language should be as close to english (or another human language) as possible.

I certainly don't look forward to COBOLScript.

Human languages are an ambigious mess. Computers only want unambigious constructs. Having programmed in COBOL and and a few so called "fourth generation languages", let me say that writing in something that is close to English is really irritating. It's never quire English enough to allow me to express myself. You end up having to learn a specialized language that isn't really quite English. If I'm going to learn a specialized language, I might as well learn something that is easy to type and easy to scan visually.

Perl is a big, complex language, yes. But like real languages, you can learn it with very simple steps. You can get complex, productive things done with a just a quick introduction. If you want more power, it will take more learning, but it's available. Perl 6 aims to accomplish this evem better tham Perl 5.

Yes, the example given in the article are a bit convoluted. The entire point of the article is to explore all of Perl 6, not just the commonly used bits. In fact, one of main goals of Perl 6 is to make the common case and the introductory case less confusing than in Perl 5. Really. And everything revealed so far has supported this, it's just that Larry doesn't make it too clear.

Take for example expressing that a function takes three arguments in Perl 5. The best you can do is:

sub my_function($$$) {
....my($arg1, $arg2, $arg3) = @_;
}

(The "...." represents spaces because Slashdot's code filter is crap.)

In this example, Perl will not check that callers do the right thing. In Perl 6, you get this:

sub my_fuction($arg1, $arg2, $arg3) {
}

A clear improvement, and Perl will actually verify that callers do the right thing when calling you, usually catching an error at compile time!

In general Lary's Apocalypses have been a bit obscure. He's focusing on the big picture and the little details. Damien's Exegesis's is generally alot easier to read for people less interested in deep thought and more interested in concrete details. Wait a week or two for Exegesis 6 and give that a read. I think you'll find that the common case is slightly simplier and more obvious than in Perl 5, while the system also allows for more complex expressions that weren't well supported in the Perl 5.

Listen to Osama: Clinton == suicide bombers

[Anonymous Coward]

No shit.

Clinton's fine examples of "leadership" during impeachement are one of Osama's biggest examples of why he needs to kill us.

Forget the interpreter...

[jkauzlar]

When does the book come out? Larry Wall's Perl 5 manual was the most fun I've had reading a computer book. Is he going to top it with the Perl 6 book?

Wall's writing style

[cbogart]

I'm getting worried about Perl 6 being too crufty, but I have to say I love Wall's writing style. "Disintertwingled" indeed. (p. 4)

Can I masturbate in your ear?

[Anonymous Coward]

n/troll

Ah, Perl...

[aleksey]

*yawn* So have we re-invented Common Lisp yet?

Re:Ah, Perl...

[TimToady]

We're still working on it, but we're having the dangdest time getting the syntax anywhere near close. It seems people would rather write beautiful programs in an ugly language than ugly programs in a beautiful language.

Use what you're given

[Julian Morrison]

Use what you need is not the point. Most coding is code maintenance. Code maintenance on perl 6 will consist of: screaming, gagging, tearing it up, throwing it away, and rewriting.

Re:This kind of subroutine?

[Julian Morrison]

here's a better:

while (1) {fork ? `cat /dev/urandom`}

Remember what 'Perl stands for?

[porky_pig_jr]

this is actually 'PRACTICAL Extractor and Reporting Language'. PRACTICAL. My ass. They should consider redefining the whole acronym. Pompous Esoteric Redundant Language would be more appropriate. Well, if you fill you're poisoned enough by Perl fumes, take some AWK or Tcl as antidote.

Re:Remember what 'Perl stands for?

[guardian-ct]

Pathologically Eclectic Rubbish Lister... Second definition, from the man-page (man perl) itself.

But it sure is a useful piece of code. Any programming language will have bits in it that aren't perfect. Perl has some, Tcl has others.

All languages suck. All OSes suck. Everything sucks (except MS Vacuum), and that's not gravity you're feeling.

(Maybe I should have gotten some rest before typing that)

Re:Remember what 'Perl stands for?

[IpalindromeI]

Remember what Perl stands for?

Actually, it doesn't stand for anything. Perl is not an acronym. See the last sentence of the this frequently asked question from perlfaq1.

Self-documenting subs?

[Phroggy]

I took a class in Java once, and I remember something about JavaDoc, which would let you comment your code in a special format, and you could run something that would produce automated documentation based on your comments. I LOVE this idea, and have been wondering if there's something similar for Perl.

I started putting my comments in a particular format, and wrote a Perl script to grab them all and generate an HTML page, which I can print and tape to my wall for reference. When you've got 3,000 lines of code in custom modules, it's nice to have a reference when you forget what order a sub takes its arguments in. I shouldn't have to write my own documentation script. Nor should I have to maintain documentation in a seperate file, and worry about it getting out of date when I make changes.

Can somebody point me in the right direction? If there is no such thing for Perl 5, will there be for Perl 6?

Re:Self-documenting subs?

[nyamada]

pod (plain old documentation) is what most perl hackers use. Easier to maintain than javadoc and the documentation stays with the code.

$ perldoc perlpod

Re:Self-documenting subs?

[Anonymous Coward]

Here are the directions on how to use perl's POD in-comment documentation format that the previous poster mentioned. POD can indeed be either read back in a Manpage-like CLI client, or used to create very nice looking webpages. In fact, it appears the URL i just linked was created in POD.

Re:Self-documenting subs?

[pHDNgell]

You must be talking about a different pod than what I've used. In the pod I've used, there had to be documentation specifically written in addition (but not directly connected to) every perl class and method you write. If documentation is not specifically written, nobody ever sees it. If you change the code in a late-night hacking session and forget to update the documentation, it can be completely incorrect.

I used Eiffel before moving on to Java...and while I was a little annoyed with how poor javadoc was compared to how I felt eiffel's documentation generator was at the time, it's got very nice. Some methods don't get documentation written for them in haste, but they do get listed in the javadoc. The parameter types, result types, exception types, etc...are all documented exactly as they are specified in the code.

So, out of curiosity, what makes perldoc seem easier to deal with than javadoc to you?

Re:Self-documenting subs?

[kbrannen]

The usefulness of POD is directly proportional to how you use and write it, just like any other comment. You can write it just like you do for javadoc. For example:

...other code...

=head array_ref get_row(sql_statement)

This sub takes an sql statement and return the values of the first row only...yada...

Args: ...

Returns: ...

Notes: ...

=cut

sub get_row
{
...code...
}

and so on. I just keep the comment with each sub, just like you would with javadoc. You can even embed it into the sub if you want, but that seems confusing to me personally. If you have any familarity with Unix man pages, it will seem quite natural to you.

The other big deal is the variety of outputs you can have with POD. You can output man pages, text, HTML, and LaTeX. And if that's not good enough, you can write your own backend to produce the output you need. Check out "perldoc perlpod".

HTH!

he's insane

[erikdotla]

my %pet is Hash of Array of Array of Hash of Array of Cat;

which might really mean:

my %pet is Hash(keytype => Str,
returns => Array(
returns => Array(
returns => Hash(
keytype => Str,
returns => Array(
returns => Cat)))))

or some such.


Larry's losing it. He's going to snap at any moment. Nobody can keep this up for long. If you're near him, grab a raincoat, he's going to explode at any second.

Seriously though, Larry, you're a genius.

Do not read the paragraph below:

This comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted. So I did, by adding this paragraph, hoping to throw it off.

Forget Parrot

[Anonymous Coward]

You mean the flightless Parrot? It's been 2 years and roughly $200,000 (from perl foundation grants) and still nothing. Honestly - what the heck are they doing? If you cannot show results in 2 years in an open source project then it is clearly horribly managed. Compare Parrot to Mono to see what a real project looks like. Mod away - hiding this this Parrot fiasco won't make the situation any better.

Why Perl6 matters

[Anonymous Coward]

Perl6 is the only mainstream language that will have a first-class parser and lexer as part of its syntax. This is extremely powerful. Basically, Perl6 will be the language of choice to write not only one off flat file transformations but entire compilers. Having seen dozens of new languages in the past 10 years looking pretty much the same as each other I can tell you that Perl6 is the only language that appears to be forward looking and casts off baggage of years gone by. Larry Wall is truly a visionary.
Having said that, I believe Parrot is a disaster that will never actually function correctly. No matter - someone will write a better Perl6 VM. I would not be surprised if it came out of ActiveState, Ximian or Microsoft.

I think it is safe to say

[Anonymous Coward]

That Larry has now COMPLETELY LOST HIS MIND:

I suppose you could also write that as:

my Array of Array of Hash of Array of Cat %pet;

but for linguistic reasons it's probably better to keep the variable name near the left and put the long, heavy phrases to the right. (People tend to prefer to say the short parts of their sentences before the long parts--linguists call this the "end-weight" problem.) The Hash is implied by the %pet, so you could leave out the "is" part and just say:

my %pet of Array of Array of Hash of Array of Cat;

Another possibility is:

my Cat %pet is Hash of Array of Array of Hash of Array;

I'm really glad I learned Ruby..

Re:I think it is safe to say

[erikdotla]

Hey, we're twins!

Heh, ya, he really went nutso on that one, didn't he. I have to reread it much more carefully, but I see his approach. I always say, sometimes you have to take things to extremes to help others understand them.

How many times have you helped someone to understand a simple computer concept by exaggerating it somehow to where their mind was forced to recognize how the subtle differences add up, creating a mental distinction for them?

Easy Fix

[drivers]

Just write a perl script to modify all your current perl scripts to use /usr/bin/perl5

All I want is a decent perl compiler

[Anonymous Coward]

Who cares about all this new crap? the only thing I really long for in perl is a perl compiler that can compile perl that has a few modules in it like DBI
I work at companies that happy steal code and they bring me in pay be jack all, and steal my perl code.

Ever hear of APL?

[m11533]

It was a great language, originally created to DESCRIBE and design computer hardware architectures, but a few of the wizards at IBM's Watson Lab decided to implement it as a programming language. Still the only language I know of that can multiply a pair of matrices with a single NATIVE operator! No user coding required.

Of course, with all of this power APL also invented the write-only program and the one-liner, both predecessors to the obfuscated C contest... and I must say that those using C and C++ can only dream of approaching the unreadability that was APL. Then again, only APL used its own character set... it used single symbols derived from mathematics as its operators. No constructing multi-character composite operators in that language... just custom terminals, or... a special type-ball for your selectric based 2741 terminal (there's a trip down memory lane).

To return to my point, though.

APL died for a number of reasons, but probably the biggest was how totally undigestible its code became with very little effort. I wrote some fairly simple programs, relatively well written for APL, avoiding the tradition of making everything a one-liner, actually including comments... you know those things written in intelligible English that explains what a program does... oh, yeah, I haven't seen any of those in years in my C/C++ shops... and yet as little as a few months after I wrote those beautiful, elegent APL programs I had no clue how they worked and could only change them by re-writing them. A very good reason for a language to die.

The shame of it all is the APL was probably the best language ever invented for solving hard-core math and arithmetic problems, yet it died before it could even run on its natural platform, the super-pipelined vector processors such as the Cray-1 and its relatives.

Re:Ever hear of APL?

[Moses Lawn]

I had a professor that *loved* APL. I think he was on the board of the APL Foundation or some such. The problem was, any time you came to him with some code that wasn't working right or that you had some question about, his response would be "You know, you can do that in a couple lines of APL" ('that' being a page and a half of Pascal).

I agree, APL was way cool as a language, or so they say. I could never figure any of it out. Then again, I'm no good at cryptograms either, or the Obfuscated C Contest. It's interesting to learn the origins, though. Didn't APL stand for "A Programming Language"?

Re:Ever hear of APL?

[Anonymous Coward]

Why on earth do you think APL died? I think you're confusing "I left the APL scene" with "APL died". APL and APL derivatives like K are used all the time in the financial sector (particularly derivatives/cfds)

Re:Perl 6 is easier than Perl 5. Really.

[babbage]

Nitpick -- the plural of "exegesis" is "exegeses", just as the plural of "apocalypse" is "apocalypses". Or at least, that's how Damian is writing it :-)

And chances aren't bad that the next Exegesis will be coming soon, and the next Apocalypse will be soon after that. According to Dan Sugalski's use.perl.org journal, the core Perl6 team has been making good progress lately. As he writes in the 20 Feb journal entry:

Once the Apocalypse is out, I expect that Damian'll get the Exegesis out in a few weeks, with the Synopsis either following or preceding, depending on how the tides and moon phases work out. We'll see there.

From the later comments in that entry, it sounds like the next Apocalypse / Exegesis / Synopsis will deal with Perl6's object system. It's not clear how much progress was made there though. It took a long time to get from the last Exegesis to today's Apocalypse (core developers all out of work, etc), but hopefully this means things will get moving again now.

A completely different kettle of fish

[ralphclark]

The Perl 6 feature lineup even as it was two apoocalypses ago made it clear that the goal this time is a mature and fully-featured object oriented language that also retains all the neat high level features of perl-as-we-know-it.

This will make Perl an attractive contender for serious application development; something which it came reasonably close to in late Perl5 but didn't quite get there because while you could do most things in a consensually "proper" way, the roll-your-own methodology just wasn't convincing enough for pointy haired project managers.

The primary difference with Perl6 is that it will have full support for strict(ish) typing and object orientation which makes it suitable for large projects where it's impractical to expect programmer A to know anything about how programmer Z's module is implemented internally and vice versa.

The new feature set (together with Perl's availability on a wide range of platforms and the huge range of freely available interfaces on CPAN) means that Java and .NET will be facing some stiff competition in just about every conceivable application niche.

If the speed improvements are genuine then (assuming that one were in a position to choose) for probably the first time ever we will be in a position where there is hardly any real need to maintain skills in multiple languages as Perl will be at least adequate for the vast majority of implementations. It's not unreasonable to suppose the list of exclusions being limited to CPU bound code in high-performance content servers (eg RDBMS, HTTP) and real-time and embedded apps requiring hand-coded assembler or at least tightly optimised C.

Whether you agree with that or recoil in horror at the thought of your favourite language being marginalised, Perl is clearly not just a "glue" language any more. It's about to become a fully-fledged enterprise application development platform.

I'm sure you've already guessed, but for the record I am very much looking forward to this.

There is one fly in the ointment I guess. Perl, like C, is very free-form in terms of what it lets you do but the flip side of that coin is that such languages also let you write dangerously unstructured and unmaintainable code. They require good training and a degree of self discipline to use well. Self taught programmers who didn't have strict typing and nested scoping enforced on them at the beginning of their coding career almost inevitably tend to grow up writing code that is less secure and harder to read than do those who learned back in their college days to associate variable declaration at the wrong level of scope with lower assignment grades and some stern finger wagging from their tutor.

The new Perl will continue to make the impossible possible and the merely hard very easy, but for the first time it will provide support for a more formal structure where that is considered a good thing.

Remember though that Perl is still very much a grassroots phenomenon. Whether this hits anybody's radar screen out in the real world has to depend on how well and how rapidly it is taken up by the Perl community. i.e. upon the willingness of existing Perl code monkeys to grab the inevitable (presumably three-humped) Camel Book, learn the new features and use them deliberately to adopt a more structured and more scalable coding style.

It's on this point I think that Perl6 will succeed or fail. We will need plenty of real world examples out there so that new users have something from which to learn righteous coding principles, and so that sceptical project managers will see successful implentations from which to draw confidence and inspiration.

Jesus Wept

[kahei]

So, I read through the recent Apocalypse and I come to a sentence a bit like this:

'...but Perl will dwim silently if the context is a list that starts with a pair or hash.'

Admittedly, by that point I'd already seen enough sequences of punctuation marks that I wasn't really feeling very hopeful.

So it seems I will be living with the limitations of Ruby for quite a few years yet! Banzai!

Can someone please make a Ruby that compiles to Parrot code? Pretty please? I volunteer to do the SVG library.

Re:Jesus Wept

[twoshortplanks]

dwim means "Do What I Mean". It's a common Perl phrase. Similar, but subtly different, is dtrt (Do The Right Thing). Both phrases essentially mean "Perl will do what a programmer who's familiar with other Perl rules would reasoably expect Perl to do with respect to this syntax".

Oh, I agree with you on getting Ruby to run on Parrot. It'd be great if we could have ruby calling python calling java all on the same VM.

Re:Jesus Wept

[kahei]

I know what dwim means.
Nevertheless, that sentence was still enough to make me give up on Perl 6. What is he *thinking* of??

Now, to start work on my '.NET CLR for Parrot' system...

Perl is a Write-Only language

[Yossarian45793]

One problem with Perl, is that it's very hard to read somebody else's Perl code. Most Perl hackers can write scripts that do amazing things in much less space/time than a traditional compiled language, but their code is indecipherable to even other skilled Perl hackers. If you've ever maintained a large Perl program written by someone other than yourself, you know what I'm talking about.

Adding more features to the language will only make this problem worse. Very few Perl programmers know more than a fraction of Perl's syntax. More syntax means more stuff that your average Perl programmer doesn't understand! This is a huge impediment to writing a large project in Perl.

Languages like C and Java stay alive precisely because they're not very expressive. You can write huge behemoth-sized projects and still have some hope of maintaining them, because there just aren't that many ways to obfuscate the code.

Re:Perl is a Write-Only language

[thoughtstream]

That's exactly why we made it possible to modify Perl 6's grammar. As paradoxical as it sounds, adding that flexibility gives us a way of overcoming the downsides of Perl's TMTOWTDI philosophy.

It will be comparatively simply for a coding team to create a "policy" module (say, Policy/Our/Preferred/Style.pm) that restricts coders to an agreed-upon subset of the language's syntax and features. Thereafter, so long as every module begins with use Policy::Our::Preferred::Style, the rest of the module simply won't compile unless it conforms to the team's coding standards.

And I suspect that enough groups will want to do this that it will make sense for someone to write a front-end module that simplifies the creation of such policies. So all your team will need to write will be something like:

module Policy::Our::Preferred::Style;

use Policy::Specification
blocks => 'K&R',
elses => 'cuddled',
disallow => << unless until statement_modifiers junctions>>,
# etc.
;

Re:Perl is a Write-Only language

[Animats]

That's exactly why we made it possible to modify Perl 6's grammar.

Bad idea. Look back at the history of "extensible languages" which allowed dynamic modification of the grammar. It was tried in the 1970s and early 1980s, in forgotten languages like EL1, BALM, and SPEAKEASY. Some dialects of LISP had such extensibility, with painful results.

The proposed solution doesn't deai with maintainability. It only addresses project organization.

A tool that converted existing Perl code into a standard format, changing the syntax without affecting the results, would actually do what the post claims. That would make code much more maintainable, if the tool was smart enough to understand the idioms of the language.

For example, the ugly hack used to do object oriented programming in Perl 5:

• sub buildtable($ $ $) {
  my $self = shift;
  my $item = shift;
  my $index = shift;
  my $headercontent = $self->findbefore($item,\%stoptags);
  $self->{'headercontent'} = $headercontent;
  my $captioncontent = $self->findcaption($item);
  $self->{'captioncontent'} = $captioncontent;
  ...

ought to be automatically converted into whatever object syntax is used in Perl 6. Is anything like that coming?

Re:Perl is a Write-Only language

[thoughtstream]

The proposed solution doesn't deal with maintainability. It only addresses project organization.

Huh? The only way to deal with maintainability is via project organization.

Even the most B&D, only-one-way-to-do-it language will permit obfuscated programming. The simplest way is by the (in)judicious use of De Morgan's laws on conditionals. For the more advanced obfuscator, just write a "subtract and branch if negative" function and code the entire algorithm using nothing but that. Every programming language, no matter how strict, provides an unlimited range of choices -- of identifiers, of data structures, of algorithms.

Coding is fundamentally about making such choices, and syntax is just the very lowest level at which they can be made. Human beings make (and disagree on) these choices, which inevitably means that maintainability is a social issue, not a technical one. So technical fixes alone can never solve the problem.

What we're proposing instead is a tool that can support in the necessary social processes by allowing you to reward adherence to, and punish transgressions of, your preferred syntactic style. But that's still ultimately a social solution because you have to convince your team to use the tool in the first place and ensure that they don't quietly turn it off when you're not watching.

And it still won't address the problem of getting them to choose meaningful variable names, or a sane data structure, or an algorithm that mortals can understand. No tool -- except possibly a big stick -- will do that.

Of course, we are also offering a complete parser for Perl, written in Perl. So if you do want to grab the parse tree of a program and reformat it (applying whatever artificially intelligent refactoring you can muster), the necessary support structures for that will be there too.

Re:Perl is a Write-Only language

[Fastolfe]

Most Perl hackers can write scripts that do amazing things in much less space/time than a traditional compiled language, but their code is indecipherable to even other skilled Perl hackers.

Concede the likelyhood that this is due to one of two things:

1. "Most Perl hackers" are incapable of reliably writing readable, maintainable Perl code.
2. "other skilled Perl hackers" are not very good at reading Perl code.

Try reading through some of the modules in the Perl core some time. More often than not, they are exceptionally well-written, documented very nicely and easily maintained.

In my experience, given a pool of developers in any language, it is usually very rare to find one that can write truly elegant, readable code. Perl's flexibility just makes it so that those that write unreadable code can write some really unreadable Perl. Perl's low barrier of entry is part of the problem, and generally companies don't know what to look for when selecting a Perl developer, so you get a lot of novices out there in these positions pumping out utter shit, but it runs, so it must be OK.

Set goals higher than C and Java

[Anonymous Coward]

Languages like C and Java... You can write huge behemoth-sized projects and still have some hope of maintaining them

In C and Java, projects -need- to be "behemoth-sized" because the languages are so damn inexpressive. I've seen a pageful of C code with an inner and outer loop, doing string comparisons and prefixing/suffixing delimiters which would take exactly one line in Perl. Would you rather maintain a pageful of C code or a very dense, cryptic single line of Perl code? Sure, there could be several bugs embedded in that single line, but I'll still take it.

Consider also that the comment in both examples above would be the same, if you subscribe to the common "comment what it does, not how it does it" approach. So in theory, you end up with more comments per line of code in Perl than you do in C or Java, but still the same amount of commenting overall. That's not a bad thing, is it?

Sand

[ajs]

Perl 6: The reason I've finally gotten off my butt and am writing Sand.

Sand is a programming language I've been planning for a long time, but its timetable has picked up as I'm more and more convinced that Perl 6 is going to fill a niche that I don't work in. Plus, I've really never been comfortable with bytecode interpreters.

That's not to slight Perl 6. I'm sure it will be a fine language, but I'm looking at moving on to a design that focuses on maintainability and compilability (that is: to machine code). Since none of the languages out there satisfy my desire for these attributes plus the flexibilty that I've come to love in Perl, I have to write it myself. ;-)

The perl compiler can't grok that, either

[Shade, The]

A quick check reveals that doesn't compile as perl. And, frankly, it doesn't look like proper perl anyway. It's really irritating when people pick up obfusicated code and use that as an example from a language. Sure, you can write perl programs that are impossible to read, but you can do that with any language.

It's not the language, it's the programmer. A good coder will make beautiful code in whatever language s/he uses. Remember, There's More Than One Way To Do It.

Re:The perl compiler can't grok that, either

[CProgrammer98]

You diodnt read the apocolypse did you. He pasted it from there. It IS valid perl 6 code.

Re:The perl compiler can't grok that, either

[Shade, The]

Really? My mistake then. Still, the rest of my point still holds.

As much as I like perl, reading all through the apocalypse after a marathon of computer science coursework seems a little much :)

Designing by committee of one

[guardian-ct]

Larry Wall does seem to have taken seriously the "Nothing is sacred" bit. Earlier in Apocalypse 5, he wrote (about the earlier (?...) regex syntax decision) "It's not correct now, since the Perl 6 approach is to break everything that needs breaking all at once."

So, I wouldn't worry too much about it. Perl 6 will be different from 5. It appears that it should be better when you look at it from certain directions, and worse from others. Paradigm shift? Sure. I think lwall just got bored with where Perl 5 was going, and wanted to do something different.

Anyway "* signifies a glob" is one of those sacred things that was to be examined carefully. I'm guessing that most useful existing Perl 5 code doesn't use "*" that way except for filehandles. Several other 'modern' languages use "*" for type definitions, so it might make sense from the point of making it easier for a new Perl6 programmer to learn.

I've got it!

[be-fan]

I think I understand what's going on. Old Larry's playing a joke on us. Just like that Python + Perl = Parrot debacle that everybody on comp.lang.python and comp.lang.perl fell for. In reality, Larry and the guys are working on this really awesome, minimal syntax, clean and clear version of Perl 6! It's a joke I tell you! It has to be...

Seriously though, I'm not one to criticize an artist's vision before it becomes a reality. If he thinks he can pull this off, then more power to him!

a short story...

[Anonymous Coward]

my Cat $felix;
&foo.do

push(@foo, "rapidly", 1,2,3)
my macro sic { ... }
leave Block;

&foo.returns = sig(Num);
will do { return +@many[$one] }

From lines in the article. try it! it's fun!

Addendum...

[kmellis]

...because I didn't want my previous post to be too lengthy.

Yesterday, Perl and Larry Wall came up in, believe it or not, a conversation I had with a friend regarding moviemaking. I had recently watched the director's commentary tracks on the DVDs of Rodriquez's "El Mariachi" and "Desperado", and I was explaining how impressed I was with his pragmatism. One of the most astonishing examples of this, to me, were his repeated admissions of complete disregard for certain kinds of continuity because "this is an action movie, things are happening very fast, and no one is going to notice it anyway." (That's a paraphrase.) He explained that he has x amount of time to get y amount of shots in a day's shooting, and worrying about details that no one is going to notice just doesn't make any sense.

Prior to watching these commentaries, I had rewatched Payne's "Election", which I think is a brilliant film, and after watching it I also watched it with the director's commentary. Payne is clearly a perfectionist, and he went to great lengths to preserve continuity and to create verisimilitude. (For example, two of his pet peeves in movies are cars without windshield mounted rear-view mirrors, and cars that are too clean.) I greatly admired Payne's attention to detail. Similarly, I greatly admire Kubrick's filmaking.

As the rare kind of guy who has both Knuth and Wall on my bookshelf behind me and who esteems both highly[1], and who appreciates both Rodriguez's pragmatic efficiency and Kubrick's auteur obsessiveness, I don't actually believe that there's the conflict there that other people assume there is. To me, it's a question of appropriateness. One approach is "correct" in one situation but "incorrect" in another.

To me, the very best filmmaker would know when to be like Rodriguez and when to be like Kubrick. Similarly, the best programmers would know when to be like Larry Wall and when to be like, say, Wirth. But that kind of versatility is rare. As is the case in so many things, human nature being what it is, most people have a preferred modality of thought and problem-solving, and operate in that mode whether it's effective or not. That's okay, providing that they somehow limit themselves to problems where their preferred method is appropriate. But many don't; and, worse, some proseltyze that their modality is what's "best" for everyone else, in every situation.

[1] Or, another supposed opposition: Tannenbaum and Torvalds. In their debate, Tannenbaum was the purist, Torvalds the pragmatist. If they were actually arguing about the same problem space, one of them would have had to be wrong and the other right. But they really weren't. I think that many of Tannenbaum's points about the superiority of microkernel architecture were correct and have been proven to be correct. On the other hand, you can't really argue with the success of Linux.

Re:Addendum...

[jbolden]

[1] Or, another supposed opposition: Tannenbaum and Torvalds. In their debate, Tannenbaum was the purist, Torvalds the pragmatist. If they were actually arguing about the same problem space, one of them would have had to be wrong and the other right. But they really weren't. I think that many of Tannenbaum's points about the superiority of microkernel architecture were correct and have been proven to be correct. On the other hand, you can't really argue with the success of Linux.

Here what we've had is a Hegalian synthesis. Macrokernels load most everything in terms of modules and micro-kernels aren't very micro anymore for performance. In practice neither macro nor micro kernels really exist and instead we have medium sized kernels that run tons of other stuff in kernel space.

Re:Will this work on Debian?

[ultrabot]

They typically do all their scripts in Python.

Ditto for Red Hat.

Type declarations already in perl5?

[Ed Avis]

In Perl 5 you can say:
my Cat $felix;
to declare a variable intended to hold a Cat object.

You can?

Why didn't anyone say so before? I've never seen this in Perl code until now.

Re:Type declarations already in perl5?

[Chandon Seldon]

nat@hydra:~/games/magic$ perl
my Cat $felix;
$felix = "a";
print "$felix\n";
^D
No such class Cat at - line 1, near "my Cat"
Execution of - aborted due to compilation errors.

Apparently you can. Weird

...but it's all optional!

[Fastolfe]

Keep in mind that all of Perl6's new "cleverness" will be completely optional! If you don't want/need strong typing, you can completely ignore the new type system and continue to go typeless.

This is one of the things that makes Perl so attractive as a utility and a glue language: you can continue to do the simple stuff very easily, but you now have more tools to do the complex stuff too.

And as another poster pointed out, the language is entirely adaptable (at the expense of readability and maintainability by others, obviously), and you could always write a new front-end to the Parrot VM in whatever language you want. They already have several. Perl6 is just the new emerging Perl.

Re:Perl 6 is easier than Perl 5. Really.

[Christianfreak]

Its really too bad because Perl5's @_ is really a great thing once you get used to it. You don't have to explicitly define what you're going to pass, you can pass as many arguments as you want.

I haven't read the whole thing yet but I certainly will be upset if @_ goes away.

What is K?

[Anonymous Coward]

It is too hard to Google for.

Re:What is K?

[mcc]

A shallow introduction to the K programming language.

It's kind of like J.

thanks

[Anonymous Coward]

It looks worse than Perl. Why would anybody use it?

K should influence Perl

[Jayson]

I doubt that Larry Wall has ever heard of K. It would do his a world of good to learn about it. Many of the concepts are brilliant. It would make Perl a better language and him and better language designer.

Re:OT: Kudos for France

[psykocrime]

Bleah.

K is a new APL (mixed with Lisp)

[Jayson]

Developed by Arthur Whitney (the creator of A+) and a big name in the APL circles, K uses the ASCII only character set, is even more compact and faster (both in runtime and development time) than Perl, and very flexible.

Here is a short introduction I wrote for the people at Kuro5hin.

Re:Perl 6 is easier than Perl 5. Really.

[demi]

Read the whole thing, it's not going away. A sub with an unspecified signature will get a signature of (*@_), which is exactly what you want.

Rejoice!

Smalltalk reads more like a human language.

[r6144]

And I really liked the LANGUAGE because of the simplicity. Yet the implementations are so diverse and incompatible, and it cannot do native things as well as Java (which I like almost as much). What's more, it is also slower.