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

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

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