Slashdot Mirror
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!"
..."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
Looking for people to chat about multicopters, coding, music. skype: gtsiros
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.
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.
"And like that
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... :)
DO NOT LEAVE IT IS NOT REAL
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.
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.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
And Perl will somehow magically become a "real" programming language that "real" programmers won't laugh at anymore.
Actually, real programmers don't laugh at perl. The last place I worked at the only people who laughed at perl were the ones who had never learned it (and they had a far higher opinion of their java skills (the company was a java shop) than anyone else in the company did as well). These days I tend to associate a bad opinion about perl with ignorance, not that I actually even use perl very much. To that kind of idiot its more of a religious bigotry than anything else. (They also tend to get annoyed when it takes you 10 minutes to write a quick program to dis/prove something which they've spent an hour bickering about)
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).
I do not have a signature
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).
"And like that
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
All well and good- but perl is actually very similar to lisp, particularly common lisp. The CL independence of the symbol-variable and symbol-function namespaces is VERY like perl's scalar/array/hash/etc independent namespaces - remember $,%,@ are resolution operators like ' and #' in lisp, and you're away.
Also, perl has Lambda. It boils down to yet-another-lisp-with-funny-syntax - like Dylan, or TCL.