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

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

[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

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.

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

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.

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

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