Exegesis 4 Out

BorrisYeltsin writes "perl.com has Exegesis 4 from the Damian, in repsonse to Larry's latest Apocalypse. This installment covers news of the new flow and block control changes, fully integrated exceptions and some other cool stuff!"

Comments

Re:perl is for freaky people

[LinuxOnHal]

Alright, I'll stick up for good 'ol perl.

I started out with my admin career with perl, and I'll tell you, it takes a minimal amount of time to be able to read it, and with a little practice, not very much more time to actually create good time saving tasks with it. I'm sure others can vouch for it better than I can.

just so you non-greek speaking people know...

[gTsiros]

..."exegesis" means "explanation"
pronounced exIgisis with vowels having their so-called cardinal (?) values (pat-pot-pet-pit)
x like in example
g like the y in yes/year
exercise for the reader: find the etymology yourself ;)

Re:just so you non-greek speaking people know...

[Wee]

exercise for the reader: find the etymology yourself ;)

From dictionary.com:

Exegesis comes from Greek, from exegeisthai, "to explain, to interpret," from ex-, "out of" + hegeisthai, "to lead, to guide." Thus an exegesis is, at root, "a leading or guiding out of" a complexity.

And for the record, I think Mr. Conway might want to re-think the use of the term in trying to explain the new features of Perl. His RPN calculator sample code didn't lead me anywhere except into a headache... :-)

-B

Re:just so you non-greek speaking people know...

[gTsiros]

"exegesis" is not an english word derived from the greek word exegeisthai. "exegesis" is an exact greek word which is used as-is in english. It is a feminine noun. As for the etymology, it seems a bit flakey to me... (i'm greek, by the way)

funny, that word was word-of-the day on my birthday, heh 17th july!

Re:just so you non-greek speaking people know...

[CrimsonDeath]

According from the dictionary.com page, the word was directly adopted from Greek. It said 'exegesis' (in Greek) was derived from exegeisthai. So, it's not really a Greek word that's used as-is ... check the pronounciation. In English, it's not as you described, as the g has an English sound.

It's the same thing with many other words. For example, the word tort (as in Law) comes pretty much directly from French, but it's not pronounced the same.

But this is pretty off topic, now...

Re:just so you non-greek speaking people know...

[Anonymous Coward]

Damian's not particularly well known for his practical code, I'm not entirely sure he writes any.

Re:perl is for freaky people

[saveth]

I knew C, C++, Assembly, and a few other languages before I learned Perl. I found parts of Perl that are very, very similar to other languages, and that's what made learning it so easy for me. I haven't really put my Perl skills to use for anything large, but they're nice to have when I need to hack something up quickly. The design concepts behind Perl are similar to those of C++ and even (*gasp*) Verilog. The API and modules are a bit wonky, but I guess that's to be expected when so many people work on them. Anyway, just my $0.02. Back to work.

What?!?

[carm$y$]

perl.com has Exegesis 4 from the Damian, in repsonse to Larry's latest Apocalypse[...]

This sounds like chinese to me. What the hell... maybe I'm reding the wrong section... :)

Re:What?!?

[bbh]

It sorta sounded like a reference to "The Omen" to me.

bbh

Re:What?!?

[Anonymous Coward]

Perl's all about being unreadable, so I think it's kind of fitting.

What about my old perl code?

[nickyj]

I only glanced at the article, and there are some serious changes. Am I going to have re-write my code all over again? (and what about my editors syntax highlighting patterns?) ;P

Re:What about my old perl code?

[Jouster]

No, you won't. Although I forget what it is at the moment, there is a command-line switch for the interpreter to target a specific release.

Of course, should you rewrite your code to take advantage of the new improvements? Yes. If nothing else, improved block structure parsing will probably locate errors you didn't even know existed.

Jouster

Re:What about my old perl code?

[Anonymous Coward]

I believe there was an article in the most recent perl journal in which damian tries to tell us that we should not be afraid, and that perl 6 will come with some sort of autoconverter thingy.

Re:What about my old perl code?

[CaptainPhong]

No, you won't have to rewrite your old code - there are so many changes and so much Perl5 code out there - it would be impossible. Likely, there will be a separate Perl5 parser/compiler on top of Parrot (largely separate from the Perl6 parser/compiler).

If you are a Perl person, or have any interest at all in Perl, I recommend setting aside some time to read the current 4 (and the future) Apocalypses and Exegesises at dev.perl.org.

Re:What about my old perl code?

[Masem]

The way that Larry has planned to separate perl 5 from perl 6 code is that all perl 6 scripts will have a certain keyword that must be the first non-comment line in the file. Lacking that, the script is assumed to be perl 5 and interpretes it this way. Otherwise, the perl 6 interpreter is activated. Note that this doesn't not mean that upgrading to perl 6 may not break some perl 5 code; there's always a few limited cases of broken backwards compatibility, but these are typically few and far between in the case of perl.

Re:What about my old perl code?

[amarodeeps]

Where are you getting this? He talks about such an idea in Apocalypse 1, referencing RFC 16: Keep default Perl free of constraints such as warnings and strict. and says specifically that it is not good:

Now, there are right ways to do this, and wrong ways. I was peeved by the approach taken by DEC when they upgraded BASIC/PLUS to handle long variable names. Their solution was to require every program using long variable names to use the command EXTEND at the top. So henceforth and forevermore, every BASIC/PLUS program had EXTEND at the top of it. I don't know whether to call it Bad or Ugly, but it certainly wasn't Good.

Furthermore he goes on:

A better approach is to modify something that would have to be there anyway. If you go out to CPAN and look at every single module out there, what do you see at the top? Answer: a ``package'' declaration. So we break that.

I hereby declare that a package declaration at the front of a file unambiguously indicates you are parsing Perl 5 code. If you want to write a Perl 6 module or class, it'll start with the keyword module or class. I don't know yet what the exact syntax of a module or a class declaration will be, but one thing I do know is that it'll set the current global namespace much like a package declaration does.

And if you continue to read this section it sounds like the issue has not been completely resolved.

I've not read much more of the Apocalypses or Exegesises in depth...but what I've skimmed doesn't seem to address this in greater depth. Is there a more definitive answer to this question?

Re:What about my old perl code?

[Anonymous Coward]

pls read this :
http://www.samag.com/documents/s=4075/sam101301 918 9971/sam0203h.htm

Re:What about my old perl code?

[Snibor Eoj]

Yes. This is the p52p6 program that Damian references briefly in the Exegesis. It will know how to convert all the perl5 constructs into the equivalent perl6 code.

Re:Question

[istvandragosani]

Both of your friends are correct. :-)

Me, Personally....

[Anonymous Coward]

I love the band, "Perl Jam"

Perl 6 will be a painful, but necessary move ahead

[Ars-Fartsica]

perl6 is a total reset, and most people who claim to be perl experts are going to have to go back and relearn an almost entirely new language. That said, this is a healthy process. perl5 OO is horribly obtuse, and the perl internals are not inviting to modification as they should be.

Also, the perl6 project is introducing Parrot - a portable, language independent VM. As .Net and Java continue to evolve and prosper, the writing is on the wall - the next platform war will be in frameworks and VMs/JITs. There has to be a competitive open alternative in this market to keep the other players honest. Five years down the road I see Parrot as potentially more important than perl6 itself.

In any case it'll be nice to see how Larry and the gang put a perl twist on OO in the new language - knowing him there will be some useful enhancements for thinking programmers.

Perl isn't unreadable - some Perl programs are

[CaptainPhong]

Though it is true that by default, Perl does nothing to prevent a person from writing an unreadable program, it is unfair to say that Perl is inherently unreadable. It is quite possible to write unreadable C, or Java, or Javascript, or whatever. Nobody complains that "HTML sucks cause it's unreadable" even though the majority of HTML out there is badly written, unreadable, unmaintainable and full of errors.

It is true that there are lots of unreadable Perl programs out there, but that's the fault of the programmer when they don't make their throw-away script readable when it becomes a mission-critical script.

I've written lots of maintainable, easy to read Perl, and it's easy to do if you simply follow reasonable coding practices (i.e. documentation). If you aren't doing that, you're asking for trouble no matter what language you use.

Re:Perl isn't unreadable - some Perl programs are

[saveth]

Or INTERCAL, for that matter. Hail, Eris! Praise INTERCAL!

Re:Perl isn't unreadable - some Perl programs are

[cscx]

Like, um, say, the hardest to read Hello, World! program ever written?

Re:Perl isn't unreadable - some Perl programs are

[Anonymous Coward]

Is it possible to write unreadable Python programs? I bet it is, though I haven't seen examples. Is it easy, by default, to do so? I'm guessing that most folks would say ``no'', at least in comparison to pearl and intercal.

Maybe the real question would be `` Does that make Python superior to Pearl?"

I think that an obfuscated Python contest might be a real challenge.

Re:Perl isn't unreadable - some Perl programs are

[tswinzig]

You're assuming that the people who complain about Perl are talking about the script as a whole. I think they are talking about the language syntax.

I think the idea that 'Perl Is Hard To Read' comes from the heavy use of symbols to change the meaning of code, especially $variables, %variables, @variables, *variables, \$variables, \%variables, \@variables, \*variables, $$variables, %$variables, @$variables, and *$variables.

Now add filehandle names and assorted tricks, subroutines and references to subroutines and subroutine references stored in variables, anonymous arrays and hashes, and regular expres/si/on/s.

But Perl is not UNREADABLE. It's just HARD TO READ. Like learning a language that doesn't use a latin-based alphabet if that's what you're used to.

Re:Perl isn't unreadable - some Perl programs are

[Violet Null]

I'd rather read that than try to read, say, this, written in Brainfuck:

...

Oh, dear. That (unsurprisingly) set off the lameness filter. Oh well. Go here instead: http://www.sslug.dk/linuxbog/program/eksempler/sho w.php?file=hello&ext=bf

Re:Perl isn't unreadable - some Perl programs are

[tswinzig]

But Perl is not UNREADABLE. It's just HARD TO READ. Like learning a language that doesn't use a latin-based alphabet if that's what you're used to.

I left out something important -- a complex Perl script is HARD TO READ if you don't know Perl. However, Perl is not hard to LEARN. You can write a perl program without learning all the complex syntax rules very easily. The same cannot really be said for languages like C/C++ and Java, where you have to learn more about the language before you can even get something to compile.

Re:Perl isn't unreadable - some Perl programs are

[__past__]

Is it possible to write unreadable Python programs?

reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

Re:Perl isn't unreadable - some Perl programs are

[FortKnox]

To add a touch to your point: write a "well written" program in perl and a "well written" program in Java, and find a random non-programming person.

Which can he read easier?

Probably the one without the freaky symbol thingies.

Re:Perl isn't unreadable - some Perl programs are

[geoffeg]

Actually, I disagree and think just the opposite. In many cases, I find that perl is easier to read because of all the "symbols" at the begining of variables and such.

For instance, in Java "String foo;" and in perl "$foo". Now, later in the code, if I see "$foo" in my perl code, I know immediatly that I'm dealing with a scalar, or %foo is a hash, whereas in most other languages I have to either remember the variable declarations or go back and find the variable declaration in the file.

Also, I think alot the supposed unreadability of perl has to do with regex. Since regex is such a basic part of perl, it gets used alot and when you come across "$_ =~ s/^([^ ]*) *([^ ]*)/$2 $1/;" you may attribute the mess of characters to perl when in fact, most of the mess is regex, which exists in many languages.

This is not to say that I haven't see lots of ugly code, perl or otherwise but I don't think perl is really any more difficult to read than other languages.

Just my two cents,
Geoffeg

Re:Perl isn't unreadable - some Perl programs are

[CaptainPhong]

That's an interesting argument - by being easy to learn, any joker can start hacking out Perl code after learning almost nothing, and it ends up being unreadable because they haven't learned quite enough...

And it is also true that the @$%* stuff can make it difficult to read for those unfamiliar with the language. I would argue that Python goes to far in the other extreme - a dearth of punctuation (esp. curlies, semicolons, etc.) makes it difficult to read. overly rigid enforcement of the use of whitespace makes it (IMO) far too inflexible with respect to grouping related statements for readability.

The complexity of OOP in Perl, strange use of references, writing Perl extensions and weird stuff like typeglobs are admittedly quite bizzare, but most of these things will be fixed up and made all perty in Perl6.

I suppose Perl gives you enough rope to hang yourself with, whereas Python's rope is full of saftey features that make it very difficult to hang yourself, but it just ends up like childproof lighters and aspirin bottles - rather annoying and only marginally safer.

To each his own I suppose.

Re:Perl isn't unreadable - some Perl programs are

[brer_rabbit]

To add a touch to your point: write a "well written" program in perl and a "well written" program in Java, and find a random non-programming person.

Why would I do that? Since Joe Engineer is off for the day, is Mary from accounting doing my code review? Hell no! Readability by a "random non-programming person" doesn't mean jack about how one should write code, or what language should be used.

It's a nice goal to have programming languages be readable, and if they were stated in English that seems like it'd be nice. But English is so ambigous it can't make for a good programming language. You'd need a lawyer.

Re:Perl isn't unreadable - some Perl programs are

[NorthDude]

I know it isn't what sun recomend in there coding standards, but when I know that a method will be king of ugly, I always name my variable:

strVariable
intVariable
longVariable
and just variableName in the case of an object.

Usually, if you properly design your application, variables and object declaration isn't far at the top of what you are actually working on.

Re:Perl isn't unreadable - some Perl programs are

[Camel Pilot]

Agreed. I like to think of the prefix char as a sort of Hungarian notation short hand

instead of pchFoo you have $foo

once the $%@ are part of your mental character set then reading Perl is natural and simplified.

Also helps to efficiently indentify naked strings from variables. This convention makes possible the ability to perform variable interpolation within strings. This feature greatly enhances readablity.

For example

$foo = "Good morning $name it is $time $zone";

instead of something like:

foo = "Good morning " + name + " it is " + time + " " + zone;

Re:Perl isn't unreadable - some Perl programs are

[Anonymous Coward]

LMAO! If only you knew that the "$" and "%" come from BASIC.

BASIC did have a number of things going for it, such as a plethora of string replacement functions.

Re:Perl isn't unreadable - some Perl programs are

[amarodeeps]

I don't understand your point...that program is in C!

Re:Perl isn't unreadable - some Perl programs are

[mikec]

1. As of Perl5, I disagree. The prefix is not very useful because it applies to the expression, not the variable. E.g., you
write "my @foo = (1,2,3); $foo[3];". I don't see how that's an improvement over "my foo = (1,2,3); foo[3]." In both cases, the type of foo is obvious from the context; the prefix characters don't add anything. In Perl6, the symbols will actually be useful.

2. Interpolating in strings is not a good reason for forcing every variable to start with a funky character. You could instead simply use "$" in strings to mean "replace the following expression with its value". Python does something like this, if I remember right.

Re:Perl isn't unreadable - some Perl programs are

[Camel Pilot]

Dear ACLMAO

Correct me if I am wrong ( I am not that long in the tooth) but I think the use of "$" to signify a variable came from shell script, which predates BASIC. Also, I do not believe BASIC used "%" or even had a hash datatype.

Re:Perl isn't unreadable - some Perl programs are

[tswinzig]

For instance, in Java "String foo;" and in perl "$foo". Now, later in the code, if I see "$foo" in my perl code, I know immediatly that I'm dealing with a scalar, or %foo is a hash, whereas in most other languages I have to either remember the variable declarations or go back and find the variable declaration in the file.

Wrong. In Perl, $foo could be:

- A scalar string
- A reference to ANY TYPE OF VARIABLE, subroutine, filehandle, etc.
- A filehandle
- etc...

So the symbols don't really help as much in readability as you claim. All they do is give you three namespaces for three basic variables (scalar, array, hash). So if you want three variables called foo, you don't have to say scalar_foo, array_foo, hash_foo, you just say $foo, @foo, %foo.

Don't get me wrong, I love Perl and don't have a problem reading it (because I know it already). But these symbols are what make Perl hard to read.

Also, I think alot the supposed unreadability of perl has to do with regex.

Yes, that is why I included it in my list of things that make perl hard to read. ;-)

I don't think perl is really any more difficult to read than other languages.

That's just not true. You can't see it because you know Perl already. If you know how to read/write only one language, English, you would have a very hard time learning Chinese when compared to learning Spanish.

Perl has a vastly different alphabet than most common languages (C/C++/Java/Basic/Python/etc).

Re:Perl isn't unreadable - some Perl programs are

[dietz]

I always use curly braces or the -> when dereferencing. It makes things so much clearer. Then you're down to just four variable types (and most people will never use the typeglob variables), a referencing operator ('\') and some dereferencing operators that are pretty clear.

Compare:
@$foo[0] vs. $foo->[0]
%$fark{snark}{mcgark} vs. $fark->{snark}->{mcgark}

Not only does it make things clearer, but you're much less likely to forget "is fark a hash or a hashref"???

Re:Perl isn't unreadable - some Perl programs are

[rgmoore]

I suppose Perl gives you enough rope to hang yourself with, whereas Python's rope is full of saftey features that make it very difficult to hang yourself, but it just ends up like childproof lighters and aspirin bottles - rather annoying and only marginally safer.

I think that's essentially Larry's point about Perl and programming in general. Forcing programmers to do things the right way seems like a really good idea, but suffers from two problems. One is that many, if not most, problems with programming aren't solvable that way. Nothing can force a programmer to use intelligent variable names, use a proper level of abstraction, write good comments, or do any of the semantic level parts of good programming. That means that the enforced good style can't solve a lot of the bad programming out there.

The other, and deeper, problem is that forcing programmers to do things the right way assumes that the language designer knows better than the programmer does. This is true far more often than most programmers would probably like to admit, but sometimes the programmer really does know what he's doing. In that case, giving him enough rope to hang himself also gives him enough freedom to come up with better and more elegant solutions.

Re:Perl isn't unreadable - some Perl programs are

[raytracer]

For instance, in Java "String foo;" and in perl "$foo". Now, later in the code, if I see "$foo" in my perl code, I know immediatly that I'm dealing with a scalar, or %foo is a hash, whereas in most other languages I have to either remember the variable declarations or go back and find the variable declaration in the file.

Let me guess, you are one of those perverse people who thinks that Hungarian notation is a really good idea. Honestly, if you have to work THAT hard to remember what type a particular variable name refers to, you are well on your way to writing impenetrable code anyway.

Of course real programming languages are strongly typed anyway, so you really don't need to carry the type along encoded in the variable name. Your interpreter/compiler should tell you that you have a poorly typed program.

Re:Perl isn't unreadable - some Perl programs are

[Coppit]

Though it is true that by default, Perl does nothing to prevent a person from writing an unreadable program, it is unfair to say that Perl is inherently unreadable.

Amen, brother. I think Perl's reputation of being unreadable is because in the beginning people were treating it like a scripting language.

"I'll just hack up a little script to automate these backups"

"Hm... Need another feature"

10,000 lines later, you have a horrible mess because the developer never anticipated that the script would be anything that big.

I've gotten burned on this a few times, so I start with the assumption that it's going to be big, and use good structuring and syntax from the outset. (Down with $_!)

Re:Perl isn't unreadable - some Perl programs are

[Anonymous Coward]

BASIC used "%" as an integer and "$" for strings. They were used as suffixes rather than prefixes like Perl does. I do believe the idea of tying data type into variable name does come from BASIC (or a predecessor).

Larry Wall's idea might have came from bash, but I believe shells using "$" came from the same general ideas that BASIC came from. BASIC was created before UNIX and before there were even "shells." Whether they had "$" and "%" notation back then I don't know. I do know all of the various Microsoft BASICs used this notation (as did other vendors). Shells are based on the same principles as BASIC. If you ever have used a c64 or a very old PC then you boot right into BASIC and use it as a pseudo-command processor, like a shell. I'm willing to bet that shells are a close descendant of BASIC (they are both imperative interpreters designed for non-programmers or beginning programmers to get things done quick).

Re:Perl isn't unreadable - some Perl programs are

[clintp]

Having used BASIC since I was a child and having just ported BASIC to Parrot, I can tell you:

• It predates "modern" Unix shells by a decade and Unix itself by at least 5 years.
• BASIC used $ to indicate string variables (LET A$="HELLO") and the lack of a type indicator to mean a number.

Re:Perl isn't unreadable - some Perl programs are

[Atrus5]

Ruby uses #{} within a string to indicate that the expression, brackets, and '#' should be replaced with the value of the expression within the brackets. So 'put "Hello, #{foo}"' would print "Hello, world" (assuming foo=="world").

Re:Perl isn't unreadable - some Perl programs are

[tswinzig]

Of course real programming languages are strongly typed anyway, so you really don't need to carry the type along encoded in the variable name.

So the language that powers the web is not a real language? And the only thing that separates a real language from a fake language is strong typing? Hmmm...

Your interpreter/compiler should tell you that you have a poorly typed program.

Was it watching me type it? Oh, you mean my interpreter/compiler should tell me I have loosely-typed language.

I don't need a compiler to tell me that, I already know it, that's what makes Perl cool.

Re:Perl isn't unreadable - some Perl programs are

[Anonymous Coward]

yeah I agree with that, tell me how many other languages have something like POD...
So if u want documented programs blame yourself as being lazy not the Perl for that..

I'm pissed to read all ppl complain Perl is ugly, it is ugly if you are "ugly"... it is cool if u are cool, it is maintainable if u are "mantainable"...and so on...
It is a language that can match your temperament.
And all ppl that blame Perl5 for not being a OO language, go and read Damian "Object oriented Perl"
end of story..

Re:Perl isn't unreadable - some Perl programs are

[Anonymous Coward]

Wrong. In Perl, $foo could be:

- A scalar string
- A reference to ANY TYPE OF VARIABLE, subroutine, filehandle, etc.
- A filehandle
- etc...

If u read "Programming Perl" AFAIK it is mentionaed that $ comes from "Single"-value, did u see the "S$".
Similar was for "@" which means "many"..
All three symbols had meaning.. just read the book(i cant remember the other two in the moment, "%" do u see the two-"o" and "/" i.e. "key/value%")

Re:Question

[bbh]

On April Fool's Day, I might have modded this up as one of the purest forms of troll bait I have seen. The only way you might have made this statement better is if you had added a reference to Python somewhere in there.

bbh

Re:Perl 6 will be a painful, but necessary move ah

[saveth]

Great. So, now, I'll have to learn another Perl, in addition to another VB, J#, and C#, just to keep up with what's going on in the computer science world. Why does everyone think rewriting their languages and pulling new ones out of thin air is so cool, all of a sudden?

Last line of Damian 4: The Exegeisis...

[Anonymous Coward]

>>Hmmmmmmm. I know which version I'd rather maintain.

Would that be the Python version?

Re:Last line of Damian 4: The Exegeisis...

[Anonymous Coward]

Didn't you hear?
Perl 6 is being written in Java, with
a smattering of Python and C#

A lesson learned from Perl5

[FortKnox]

I think you're seeing a lesson learned from perl5.

Before perl5, Larry was told "people want OO in perl", so Larry slapped OO onto perl, instead of resetting and adding OO elegantly. You've already mentioned the result( *wince* ).

Now stuff like Parrot and exception handling needs to be added to perl. But Larry says "Woo! Lets do it right this time" and resets the language.

I think its just a lesson learned (for all language developers, I hope), and hopefully the last reset in perl.

Re:Perl 6 will be a painful, but necessary move ah

[Anonymous Coward]

What makes you think that the language of the month (or I should say, language flavor of the month, since they're all incredibly similar to someone who knows the underlying concepts) has anything to do with Computer Science?

If you don't care for rapid change...

[Anonymous Coward]

...you're probably in the wrong field.

Who let the Java dude in?

[Wee]

Things like this:

return %var{'$' _ $i} = pop(@stack) but true;

and

class Err::BadData is Exception {...}

Make me weep for the future. Although I kind of like the new switch-ish stuff. And the expanded for functionality looks like it could be very handy. But it's messing up my Perl, you know? It's like your teenage kid coming home with blue hair and five earrings (not all of which are in an ear, and only three of which you can readily see). What you thought once was is not what now is.

I know, I know...

• It's going to be painful.
• But it'll get me cool new stuff.
• And so I'll have to learn and use it.
• Then once I do:
  • I won't ever want to go back
    - or -
    
  • I'll wonder how I ever got along before
• And Perl will somehow magically become a "real" programming language that "real" programmers won't laugh at anymore.

OK, I might have been stretching on that last one...

-B

Re:Who let the Java dude in?

[Anonymous Coward]

And Perl will somehow magically become a "real" programming language that "real" programmers won't laugh at anymore.

Actually, real programmers don't laugh at perl. The last place I worked at the only people who laughed at perl were the ones who had never learned it (and they had a far higher opinion of their java skills (the company was a java shop) than anyone else in the company did as well). These days I tend to associate a bad opinion about perl with ignorance, not that I actually even use perl very much. To that kind of idiot its more of a religious bigotry than anything else. (They also tend to get annoyed when it takes you 10 minutes to write a quick program to dis/prove something which they've spent an hour bickering about)

Perl 6 will be a painful (tiny little troll :)

[ctp]

OR.....drumroll.....

Just learn Python and don't worry about how many more times Perl ends up needing to be reset.

Re:Perl 6 will be a painful (tiny little troll :)

[ichimunki]

Or Ruby for that matter. Ruby is pretty cool as well. So many of the "improvements" to Perl for Perl 6 are things Ruby seems to already have (or have an easy way to get around).

Re:Perl 6 will be a painful, but necessary move ah

[babbage]

Well if it makes you feel better, one of the hopes for Perl6 is that it should be able to process Perl5. With Parrot as an abstract backend, Perl6 is just going to be one of several available frontends for the Parrot engine. In principle, there's no reason why a Perl5 frontend can't also be written, just as there is interest in Python frontends, PHP frontends, Scheme, Forth, Tcl, etc.

This may be painful, yes, but it had to be done because the existing Perl codebase was such a mess that a reimplementation was seen as the only way for the language to keep evolving. In return from starting from scratch like this, the Perl community gets a lot of benefits: there will be lots of tasty new syntactic sugar (which you're welcome to ignore by writing Perl5 style code, but which will make a lot of tasks easier if you get used to the syntax), it should be easier to develop extension libraries (no more evil XS hackery, and PDL becomes much less necessary), it will be easier to port Perl to new platforms (like say Palm Pilots), and you get this great language engine out of Parrot.

Plus, the only reference implementation of Perl the language has been Perl the interpreter, and this bothers a lot of people for a lot of reasons. With this reworking, the language specification will be fleshed out in much better detail than has ever existed before, and the official reference implementation should be much easier to understand & work with, with actual abstraction of different working layers that should be replaced just as TCP/IP layers can be replaced. Ideally, this will allow others to come in and develop their own implementations of Perl the language, and that competition could stand to benefit us all.

Still, the funny thing to me is that all this Parrot work was born out of an April Fools Joke last year. Not only was it a funny joke -- unlike say everything that was posted here the other day -- but it has evolved into quite an interesting piece of software architecture. Be careful what you joke about, you just might get it... :)

Re:Perl 6 will be a painful, but necessary move ah

[__past__]

You mentioned both Perl and VB in one sentence with computer science. You lose.

New to Perl

[Tadrith]

Just thought I'd place a little comment in from a newbie to Perl, seeing as a lot of people are discussing the readability of Perl.

First off, I've been writing a database application with SQL Server 2000 and Visual Basic for the last year. Recently, I had to do some nasty work with some text documents. I understand the Visual Basic isn't the most popular language, but it has it's place... parsing text documents isn't it.

Long story short, I decided to try using Perl for it, instead, seeing as Perl is very well suited for the task. It only took me about 4 hours to complete what I needed to do with Perl, and that includes learning the language. So far I've found it very intuitive and it's certainly not any more difficult to read than anything else. If anything, I think Perl simply requires the reader know a bit more about the language, which isn't a bad thing, in my mind.

Maybe I had a better time with it since I've already done extensive work in C/C++, but I still think it's quite useful, and certainly not unreadable if the programmer takes the time to program it properly.

Re:New to Perl

[MisterBlister]

I think Perl is great for what it is, yet I still claim that it is harder to read in most cases than any other commonly used language.

Being easy to learn and hard to read aren't mutually exclusive.

Even if you are familiar with the ins and outs of Perl, it can often take a few seconds or more to parse one of the more complex lines of code contained in your average Perl program, especially if the programmer likes to do 'clever' things with regexps. With C/C++ programs of similar complexity and a programmer as skillful in C/C++ as the Perl programmer is in Perl, on average I find the C/C++ code much easier to do a quick scan and determine what the code is doing even if all the code is uncommented.

Re:New to Perl

[Anonymous Coward]

Need another hit mods?

A well crafted troll, but still a troll! And a troll in the classic sense.

Re:New to Perl

[Tadrith]

I can agree with you, in that sense. As far as reading goes, probably the worst part to me is the amount of symbolism involved. C/C++ are certainly fairly far removed from the english language, but it seems to me that Perl takes that one step further. ;)

Like most things, it falls in between, not necessarily in one extreme or the other...

Re:New to Perl

[wedg]

So far I've found it very intuitive and it's certainly not any more difficult to read than anything else.

Sure, it's certainly possible to write very clear, distinct perl code. It's also incredibly easy to write very obfuscated, near impossible to read perl code. Here's a good example of how bad Perl can get. It's a pretty picture though.

Re:New to Perl

[Anonymous Coward]

I'd hate to use any language that deliberately makes it impossible for me to write obfuscated code at the expense of some of the languages power. My favorite languages are :

Common Lisp, Scheme, ML, Perl, APL, Forth...

Re:perl is for freaky people

[Anonymous Coward]

Perl is for humans in general, and a good first language to learn if you get off on immediate results/feedback/reinforcement. Problem is when you move on to a language like java it seems cruel and inhuman. So the argument could be made that you should start with java, because perl doesn't represent the real world. It's an idealization, and perl 6 will likely only be more ideal, so best to avoid it. Perhaps start with C++. That way you won't be deluded into believing that programming is easy and fun.

Re:Perl 6 will be a painful, but necessary move ah

[Anonymous Coward]

Could you please explain with few words what Perl has to do with computer science.
I rather think that Perl is to CS what witchcraft is to quantum physics.

New cars look the same too

[A Pressbutton]

Don't know if it is me getting old or what, but it seems like there is a gradual convergence of 'mainstream' languages, especially in the core functionality set. (I do not count lisp / scheme / z as mainstream)
There was a comment somewhere in this months PC Plus (uk edition) on the ease of transferring from VB to their version of c# (or was it j#).
I think that this is a good thing. You can use a telephone / car / toaster in any country (that has wires / roads / bread), why not have a common core for computer languages?

Re:New cars look the same too

[babbage]

You can use a telephone / car / toaster in any country (that has wires / roads / bread), why not have a common core for computer languages?

It's a mapping problem. At the core of all these common languages are some implicit ideas about what should be possible, what should be easy, and what just can't be done. Any interface/language built on top of this core has to reflect those assumptions. As long as the core assumptions are sufficiently broad, and map well enough onto your way of thinking and solving problems, then there is no problem here. Sooner or later though, the more you use this system, the more you realize that it does have boundaries and that they will come to restrict you.

The same idea holds in lots of areas. Compare & contrast the tasks you can solve -- and how easily they can be solved -- when using DOS/cmd.exe on one hand and one of the Unix shells on the other. Even plain old /bin/sh is more versatile than modern NT command shells. On the other hand, compare the graphical environments for Windows and X11, and for that matter MacOS. Each of them has different "easy" situations and "hard" situations. I won't get into which of them is better (well ok I will, MacOS9 was best), but suffice to say that they implicitly force a certain mindset.

And again this holds up with more traditional human cultural situations. The French phrases "il y a" and "je ne c'est quoi" [surely that's spelled wrong] just don't translate fully into English. English cars don't 'translate' well onto European or American roadways, and vice versa. Not every piece of bread fits into every toaster (try putting a nice big slab of foccaccia into one), and that's a good thing. A lot of people feel that these little cultural rough edges are what make culture interesting in the first place.

And in a general way, that all comes up again in computer languages. VB is highly optimized for writing Windows applications, and I'd suffer if I tried to do the same things in Perl. On the other hand I can do sophisticated text analysis in a Perl one liner that would be almost impossible to do in VB. Likewise, it might be possible to run a wide variety of dynamic scripting languages on top of Parrot, but it looks like they won't necessarily be able to run on Microsoft's CLI (and thus won't necessarily be able to do .NET or Windows GUI stuff); and at the same time code written in relatively static, compile languages for the CLI might not perform so well on top of Parrot and might not run well on Free Software platforms.

There are good & bad & deep & subtle reasons for all this, but the end lesson is that a certain degree of non-conformity makes the software "ecosystem" richer and healthier. The benefits of a one core engine runs all approach are eventually offset by the restrictions in the types of problems that can be solved by such a system in the long run. Those non-mainstream languages are a valuable source of ideas & direction for the more standard languages to move in. A lot of Perl's best ideas are brazenly stolen from SmallTalk, APL, Scheme, and other obscure but clever languages. I might not use those others -- hell I don't even know how to code in any of them at this point -- but the fact that they're able to demonstrate new ideas in practice propels the development of the languages that I am interested in. I have little doubt that that development would stagnate without this kind of cross-pollination, and I worry that increased language homogenization & core-engine-standardization could strangle this sort of evolution in the future.

Re:New cars look the same too

[ryanflynn]

not true... Very few cellphones and services allow you to use your cellphone around the world (though it is possible), Brits and Americans drive on different sides of the road, Europe and the US use different amperages (or something... i know next to nothing about practical electricity).

'tis like a summer night...

[dghcasp]

The real reason Perl is getting a facelift is because it was getting to be hard to write stories and poetry in Perl 5. Fortunatly, Larry brings us a new language that will compile and execute things like:

given $beer {
when 'empty' { next beer; }
when 'budwiser' { die; }
when ... err 'drunk' { throw up; }
}

Re:Perl 6 will be a painful, but necessary move ah

[Anonymous Coward]

what advantages does the Parrot VM have over the .NET or Java VM?

Arhg, running out of namespace!

[SirSlud]

Ahhh, more control keywords! Good thing most perl code I've seen doesn't bother with the trouble of readable variable names, or running out of variable namespace would be an issue! ;)

(BTW, I like perl. Like a big brother you just can't stop teasing ... :)

Re:Arhg, running out of namespace!

[Anonymous Coward]

Uhhh, variables in Perl have sigils that distinguish them from keywords.

"for" example, this is perfectly valid Perl:

for $for (@for) { &for }

Dear Editor,

[jbennetto]

I am 8 years old. Some of my little friends say there is no Perl 6. Papa says, "If you see it in Slashdot, it's so." Please tell me the truth, is there a Perl 6?

Everytime I read one of these things

[nosferatu-man]

... it just ends up making Lisp look better.

(jfb)

Re:Everytime I read one of these things

[NonSequor]

There are very few languages that don't make Lisp look better.

Re:Everytime I read one of these things

[Anonymous Coward]

All well and good- but perl is actually very similar to lisp, particularly common lisp. The CL independence of the symbol-variable and symbol-function namespaces is VERY like perl's scalar/array/hash/etc independent namespaces - remember $,%,@ are resolution operators like ' and #' in lisp, and you're away.

Also, perl has Lambda. It boils down to yet-another-lisp-with-funny-syntax - like Dylan, or TCL.

Re:Question

[alvar-f]

Short answer: your friends suck.

Long answer: learn perl, read "Programming Perl" and you'll know if it sucks YOU or not ...

You should rewrite as little code as possible

[Wee]

Of course, should you rewrite your code to take advantage of the new improvements? Yes.

Respectfully, No. In fact, a resounding "No."

Existing, running, production code is mature code, by and large. It works, it's had revisions, people have added little bug fixes here and there, and at very worst it has passed the "live QA department's" BFT. Many eyeballs have seen it. And it's harder to read code, even well-commented code than it is to make new code (that old "easier to plant a garden than take care of a garden" analogy fits in here, I think). So translating existing stuff into new code will probably introduce errors.

I found a good article about Netscape 6 which touches on why rewriting code is usually a bad idea. The article says it better than I can. I especially liked the comments from Lou Montulli (creator of Lynx) about the rewrite which took place for Netscape 6:

There was good reason for a large change, but rewriting everything was a bit overboard to say the least. I laughed heartily as I got questions from one of my former employees about FTP code the he was rewriting. It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked.

If nothing else, improved block structure parsing will probably locate errors you didn't even know existed.

Of course, there are times a rewrite is needed. But to decide to do rewrite purely because there are new constructs of a new language (which is essentially what Perl 6 is going to be) seems like a real good way to introduce bugs, not find them. Finding bugs is what good design and QA is for...

-B

Re:You should rewrite as little code as possible

[SamHill]

On the other hand, Joel's in favor of refactoring, which is certainly an option with Perl 6.

Re:You should rewrite as little code as possible

[rabidcow]

If you properly document all the fixes as you added them to the old code, you should have a nice little guide to exactly what you need when you rewrite it.

If you didn't properly document it, it'll be hell to deal with either way.

Now if there's no reason to rewrite the code other than "we didn't use such-and-such fancy language feature" than sure, that would be nuts. Code should be made to fit the problem, not all the shiny edges of the language.

Re:You should rewrite as little code as possible

[Wee]

Yeah, I noticed that as well. However, I don't think what he describes in that article is really refactoring, per se. He made -- from what I could tell -- semantic changes. For example, he changed his app so that it spits out xhtml instead of plain vanilla html. That's about as far from a programmatic change on you can get. He admits he didn't make "the kinds of changes that introduce bugs". I assume that means that when he made a change to something code-like, he only did stuff like make all occurrences of a variable name more descriptive.

I still maintain that this is miles away -- idealogically speaking -- from something as drastic as modifying an existing, working perl script(s) to use the new switch statement in Perl (for one example). Now, if he would have rewritten his app in PHP (from ASP) then I would see that as more analogous to "migrating" from Perl 5 to Perl 6. Or maybe PHP3 to PHP4. I'm not sure. Rewriting someone's code (even your own) in the same language is bad enough, IMHO.

My point is, I'm all for cleaning up code so that it's easier to add features or make it easier for others to maintain (although I'm not a fan of it myself; I'd rather have the luxury of being able to do things The Right Way from the get-go). But I'm not a big fan of throwing incalculable amounts of "genetic memory" in the form of old code just to scratch an itch for newness.

But I think we're on the same page... :-)

-B

Re:You should rewrite as little code as possible

[Anonymous Coward]

And now Mozilla is the fastest HTML renderer out there. QNX has been rewritten 3 or 4 times now - eac time better than the last. Rewrite now and get free Kittens along with better software!

It's cruddy articles like Joel's that makes me sure that everyone wants a simple answer from a loud bloke that they can tell others to listen to. When will you kids grow up? ;)

Re:You should rewrite as little code as possible

[Anonymous Coward]

Hell. Yes.

Re:Perl 6 will be a painful, but necessary move ah

[Anonymous Coward]

Additionally, with the parrot back end, the .net implementation will be more tightly integrated.

PS - I predict within 3 years, linux will need to be overhauled since the existing code base is such a mess.

mod_perl

[Ender Ryan]

I have a question. How will Perl 6 affect mod_perl? I assume mod_perl will have to be rewritten, considering the Perl internals are completely different.

Will there be a mod_parrot that makes mod_perl redundant?

Re:mod_perl

[Anonymous Coward]

there is a mod_parrot, and its in the cvs repository where parrot is.

#parrot irc.infobot.org

Hey, I thought Ruby was Perl 6?!

[Anonymous Coward]

Didn't Larry proclaim that Ruby is Perl 6? Read about it in: Ruby Weekly News

Re:Perl 6 will be a painful, but necessary move ah

[ryanflynn]

why would you want to learn any languages with '#' in the name in it anyways?

perl is being rewritten because the people that know it best think it's the best way to go. (try reading perl.com if you're actually interested, they tell you more than you want to know about the why's)

Parrot

[alvar-f]

One of the most interesting things of Parrot is (at least for me), that it is a register based VM, not a stack based one.

So it seems to be really possible to code in Parrot assembler directly, optimize (Perl-) code etc.

Dressing up the succubus..

[ProtonMotiveForce]

Great. Now sysadmins-cum-bad programmers will be even more tempted to use Perl for huge applications and God Knows What because they think it's a 'real' language. Seriously - Perl is greate for most day to day administration tasks, and has been since Perl4. Perl5 added some decent, usable features. Perl6 is a joke.

Enter the players. Fair succubus Perl cries out to the scraggly, geeky administrator in his cube...

Perl: Come to me. I'm not a language conducive to horrible, horrible code. I don't tempt system administrators to brute-force huge systems by way of overblown syntax! Really, the shorter and more efficient code makes it _better_ code!

Administrator: I can hear your call! I love your myriad randomly chosen operators! I love your flexibility, it means me and my colleague will never understand eachothers code! I can even pretend to be a 'real programmer' because I'm dabbling in your poorly designed OO features!

Perl: And don't forget the job security! Every Perl programmer thinks he can write good manageable Perl code! It's only the other poor slob who can't, and screw him!

Administrator: Very well. Let us begin writing our financial management systems in perl, our web applications, everything!

Why wait three years

[Anonymous Coward]

You can get the overhaul here.

Poking holes (in your argument)

[fm6]

It's like your teenage kid coming home with blue hair and five earrings (not all of which are in an ear, and only three of which you can readily see).

If I had teenage kids, I think I'd be quite happy if they contented themselves with a weird hairdo and a few piercings. Hair grows out, piercings heal over. More likely, I'd be trying to explain that no matter how cute that tattoo looks now, you're gonna be tired of looking at it in a few years -- especially after the ink has faded.

More informative material here:

[Anonymous Coward]

If you are interested in a more enhanced "bleeding edge" version of Perl,
with much more intelligent design,
look here.

Re:Perl 6 will be a painful, but necessary move ah

[elefantstn]

Perl 6 will be painful? What about Perls 1-5?

Wrong.

[Anonymous Coward]

For instance, in Java "String foo;" and in perl "$foo". Now, later in the code, if I see "$foo" in my perl code, I know immediatly that I'm dealing with a scalar, or %foo is a hash, whereas in most other languages I have to either remember the variable declarations or go back and find the variable declaration in the file.

• $foo : A string, number, reference, ...
• $foo[n] : The nth member of @foo (which is different from $foo)
• $foo{key} : The value associated with 'key' in the hash %foo (which, of course, is different from @foo and %foo).

The symbol syntax would help if it was at all consistent. But the rules are so complex and esoteric it's not worth learning them all.

Re:Wrong.

[Camel Pilot]

The rule is really quite simple.

$foo[n] is a scalar and therefore the $

if @foo[n] was a scalar then what would you do with @foo[1..5] which is a slice and not a scalar but multi-valued and hence the "@"

Re:Wrong.

[glob]

The symbol syntax would help if it was at all consistent

perhaps they should change that for perl 6.

hang on, they have :

$foo : a string
@foo[n] : nth element of @foo
%foo{key} : value associated with 'key' in hash %foo

Re:Perl 6 will be a painful, but necessary move ah

[rgmoore]

perl6 is a total reset, and most people who claim to be perl experts are going to have to go back and relearn an almost entirely new language.

People keep saying this, but it just isn't true. There will be a few obvious things that change (like using @foo[0] instead of $foo[0]) and a number of less obvious ones, but a lot of the language will be carried over unchanged. It's just that the discussions by Larry and Damian are focusing on the parts that are undergoing the biggest changes.

Re:Question

[volsung]

Heh. This was a first-time troll for me. I was killing time this afternoon and wanted to see how quick the moderators were. For the curious, the first Flamebait moderation took 2 minutes from post, the second took another 9 minutes, and the last one (bringing the post down to -1) took an additional 47 minutes.

But, you're right. I should have put Python in there somewhere... :)

Ahh

[Pussy Is Money]

Starts looking more and more like C++.

ummm... no, it's not

[Ender Ryan]

Oh... my... you... ARE FUCKING RETARDED!

mod_perl is NOT slow, not slow by any means at all. If used properly, mod_perl can be about as quick as serving up static content... like the websites of the company I work for...

mod_perl allows you to quickly, and very easily, write custom Apache modules, allowing you to incorporate anything and everything available on CPAN, which is just about the most comprehensive library of... stuff... anywhere.

I've used ASP, seen how java servlets work, fuck AOLserver, and in the end decided to develop a custom solution. Our site is composed of over 200,000 documents, much of it dynamic content now, served up using my custom ASP-ish mod_perl module. On a single server, it performs perfectly and will saturate our network before overloading the server, the bottleneck being our database.

So please, go fuck yourself.

How long until they release "The Camel" for Perl6?

[Anonymous Coward]

It wasn't long ago that I bought the Third Version of Programming Perl.. *sigh*..

Oh well, at least with its insistent bad humour I can sit down and pretend it's something Douglas Adams wrote on a bad day.

Larry Wall at SVLUG tonight

[doom]

If you happen to be in or near Silicon Valley, you can go bug Larry Wall in person tonight.

Wednesday, April 3rd., 2002, 7PM-9PM
Speaker: Larry Wall
at Cisco Building 9, the land of numbers.
Topic: An Evening with Larry Wall

And even if you're not in Silicon Valley, you should take a look at the directions they put up to this building: Cisco 9. Truly amazing, anal-geek overkill.

yeah, looks more and more like Java

[Petronius]

Keep going guys, in a few years you'll have a real programming language.
go ahead, mod me down, I don't really give a shit.

Re:yeah, looks more and more like Java

[Anonymous Coward]

he he, very far from java, and for good :")
what was the moto "java everywhere" when it started... doesn't look to me it is everywhere..
And now u have to fight C#.. (don't get me wrong i preffer Java to beat C#)..

You doesn't understand that there is no language that can suit all ... and I also don't give a s..t about Java

Don't panic...

[EvilGwyn]

We're defining the class, but using the new Perl 6 "yada-yada-yada" operator in a block immediately after the classname.

Any language that has a "yada-yada-yada" operator has nothing to worry about.

Re:Perl 6 will be a painful, but necessary move ah

[addaon]

You mentioned both Perl and VB in one sentence with computer science. You lose.

If I understand the rules correctly... so do you!

Re:Perl 6 will be a painful, but necessary move ah

[Anonymous Coward]

Could you please explain with few words what Perl has to do with computer science.

As much as C, Fortran, LISP or Smalltalk does I guess. It's just a way to implement an algorithm to solve a problem.

Re:Question

[bbh]

Yep, why else do we collect Karma unless we're going to burn it sometimes. I once posted a comment in the middle of a KDE/Gnome/RMS thread. It spent all day getting ping-ponged back and forth between Funny, Insightful, and Troll depending on the allegiance or sense of humor of the moderators. It ended at +5 Funny, but was definitely worth a karma point or two to watch em' beat on the post all day.

bbh

Some format besides HTML?

[Anonymous Coward]

Are the Apocalypse and Exegesis documents available anywhere, in their entirety, in some format besides HTML?

I would love to be able to print them out to read during the day - the office doesn't give us net access, for the most part, so the HTML-linked version is practically useless to me.

Mark Edwards
Proof of Sanity Forged Uppon Request

no...

[emmons]

Referencing somebody else's text or talking about the rules concerning VB, Perl and CS in one sentence completely legal. Using them to refer to oneself, however, is not.

Go directly to jail, do not pass go, do not collect $200.

But perl is much more than a "product"

[Ars-Fartsica]

Yes your arguments (echoing Joel's) are apt for commercial software, where time is money and lost market share...but perl is more than this. Its a community. Its a group of hackers. Its an open environment for playing around with languages. They aren't in a rush and they aren't losing sales. They're doing what they want, which in this case was a rewrite. Thats the joy of free software- you are not encumbered by the market...or you are encumbered only as much as you want to be.

As for Joel, his former employer has made itself into the wealthiest software producer in history largely through continuous rewriting of code. Microsoft is famous for releasing an almost entirely new product by time its third revision is out. While I also agree that rewrites can be pointless exercises, it is not prudent to take Joel's argument too far.

Re:But perl is much more than a "product"

[Wee]

Ars, I've read some of your posts. I am going to guess that you are the type who knows what 'BFT' stands for. You know when rewrites should happen. And you know when junior guys should get the task of reading hairy code. You know from interns. But you know that rewrites are worse than than re-reads like 99.98% of the time, our great benefactor from Washington notwithstanding. You can draw your own conclusions. We're on the same page.

Having said that, I wish I had more gumption to respond. I just left my job today at a dot-com startup. I worked there for 18 months and I was recruited there by mutual friends/co-workers from our former Fortune 500 employer (I worked for them for 4 years, alongside many of my dotcomrades). I'm going to work on Monday for a large university system. Before Monday, I'm getting drunk. In fact: I am drunk right now.

My point is that I wish I had seen your post when I had the wherewithall (and the hand-eye co-ordination) to type out a decent reply. But you caught me at a bad time. I feel like I should buy you a beer and have a chat with you. But I probably shouldn't be drinking right now. What was I saying?

-B

Re:perl is for freaky people

[HeavensTrash]

Hm, I think I'll agree with you 100% on this. The first language I learned was Perl, and then I decided to move on to C - Big mistake.

Why can't all languages be as nice as Perl?

Description in name, not in easily twisted prefix

[Atrus5]

Good naming of variables, software design, and documentation should be what makes it clear what a variable is, not a symbol prefix that can be easily something other than what you think of first. A well named variable will allow you to make a good guess about how to use it. A variable called "userName" should be a string, "User" should be a class that represents users, and "users" should be an array of User objects.

You mention that you have to go to another file to find the decleration of the variable, no function should span multiple files and strongly typed variable like Java and C++ force you to place the variable type in the function header, decleration, etc. This tells you what the function is (informing/reminding you of paramater and return types as well) and if you haven't read it you really should to prevent altering the intended behavior.

Pre-6 perl does an excellent job of making it easy to write obfuscated scripts by stuffing so many interpretations into one symbol ($foo can be a scalar, refrence(which is a scalar but is not used the same way), or file handle)and having a list of inconsistencies so long that comprehensive documentation is insanely difficult. The language as it stands at perl 5 does little to help understanding of a script, and more to make the task difficult.

yes, jbennetto,

[beertopia]

jbennetto, your little friends are wrong. They have been affected by the skepticism of a skeptical age. They do not believe except they see. They think that nothing can be which is not comprehensible by their little minds. All minds, jbennetto, whether they be men's or children's, are little. In this great universe of ours, man is a mere insect, an ant, in his intellect as compared with the boundless world about him, as measured by the intelligence capable of grasping the whole of truth and knowledge.
Whatever, I thought it was funny.

Wake up Larry, God is dead!

[Anonymous Coward]

I wish Larry would shut his filthy hole about God and stop putting references to Him in everything he writes. Its really fucking annoying.

what is it with java programmers?

[Anonymous Coward]

They think java is the solution to everything. There's more to the world than java. And OO is a cruel joke played on the computing world.

Re:Perl 6 will be a painful, but necessary move ah

[Anonymous Coward]

please read this :
http://www.samag.com/documents/s=4075/sam101301 918 9971/sam0203h.htm

Re:Perl 6 will be a painful, but necessary move ah

[Anonymous Coward]

>Still, the funny thing to me is that all this
>Parrot work was born out of an April Fools Joke
>[perl.com] last year.

Parrot was not born out of the joke; only the
"name" Parrot. The VM was born out of a lot
of lessons learned from Perl5.

Re:Perl 6 will be a painful, but necessary move ah

[Anonymous Coward]

Because people ask for it; isn't that good
enough? The people that want to write larger,
more complex systems in Perl are the ones
who push the envelope, not the people writing
10 line scriptys.

This is all moot argument, Perl5 is not going
away and will be supported on the Parrot VM.

The second reason it is moot is 90% of the
base constructs aren't changing. If you don't
use OO features now, you'll see less of
the changes. If you DO use Perl OO then
you are probably one of the ones wanting
Perl6.

Thirdly, quite a few of the features are
*new* features that don't break existing
code, like the switch statement and tagging
variables and commutative =~ operator...

These are GOOD things. :)

Re:Perl 6 will be a painful, but necessary move ah

[Anonymous Coward]

Computer Science is an applied science.
Without the languages, its Philosophy.

That short enough? :)

More like C++, Python, Lisp, Java ...etc

[Anonymous Coward]

To all "more like ..." posters :
This simply means that Perl can do the job of all those metioned languages :")

I can say the same about virtualy any language that copied the good perl features..

U still dont get it, right! If you understand atleast a little bit Perl u will know that from the start Perl has copied all good features from other languages .. and Larry never shamed to tell that.
Stop doing simplified comparement ... if u don't like Perl just use other language. It is free world..