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

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

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

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