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

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

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

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

[cscx]

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

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

[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

[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

[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

[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: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

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

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

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

'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; }
}

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

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.

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

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: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: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?

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.

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

[elefantstn]

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

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

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.

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.

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

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