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

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?

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

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

[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

[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

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

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.

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

Everytime I read one of these things

[nosferatu-man]

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

(jfb)

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

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.