:-) -- ask bjoern hansen - <http://www.netcetera.dk/~ask/> more than 70M impressions per day, <http://valueclick.com> ---------- Forwarded message ---------- Date: Sat, 21 Oct 2000 17:40:54 +0200 From: Screamer <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Perl rocks Hi all, whoever reads this, one of the past few days, I was having a less purposeful look at the Perl docs, just browsing and reading around randomly, and happened to stumble across the note about [EMAIL PROTECTED] in the FAQs, so I spontaneously decided to express my gratitude for Perl... At first, it was just meant to be a quick 10-minute note, but I kept writing and writing. When I was finally "done", I had "wasted" 3 hours. I reread it and noticed it had turned out to be more of an advocacy ramble. It had already took entirely too long to write, so I thought "heck" and took more time to structure it better. As I happened to have no internet access for several weeks when I wrote it, the mail was lying around in my outbox for a long time and tempted me to go back to it several times. At first I just polished a couple sentences, then moved stuff around a little more extensively, and as I kept thinking about it I wound up totally rewriting some parts. In the process, my own understanding of a lot of the topics mentioned grew much more precise. 10 minute job? I think not, but after all, it turns out the extra time wasn't wasted: I refined my understanding a lot just by writing this mail. (Oh and - apologies for the lame Subject line, but I spent a ridiculous amount of time trying and still couldn't seem to come up with anything actually appropriate or Perl-esque.) I almost have to say thanks for [EMAIL PROTECTED] ... :-) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ First of all, to sum up my most important points: A million thanks to all who contributed to Perl itself, and another million times to all who contributed in whichever way to CPAN. Thank you very very much. You have made my hobby more fun and my profession easier, both at the same time. Things like these make life that tad bit more interesting. Thank you. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I've been using Perl for random tasks, usually small and mainly CGI ones, for quite a while now. (Ever since I bought the Camel book about a year ago, basically.) I recently decided to start a pretty big project (in my terms anyway): a suite of CGI scripts implementing a sort of file exchange board for the web, complete with a fully automatic setup script as well as an extensive adminstrative interface so that administration can (though doesn't necessarily have to) be done completely via a web interface, without ever having to edit a file. (Seems to sell better with people who are otherwise used to products of a certain obscure facility in Redmond.. ;-) I must say I'm baffled at the ease with which one can throw around deeply nested data structures in Perl; it's just amazing. You have to have used lists of lists of lists of hashes of lists <insert as many levels as you want here> to appreciate the ease you can do it with. I used hashes and arrays nested up to 10-odd levels deep for the script and very rarely ever lost track of what was where; when I did, I got myself back together in very little time. I know something like this would be a nightmare to do in C, or my (still) second favourite language after Perl, Pascal. (C sucks... bad.) The vast amount of pre-done work available from the CPAN has won me over; I used to be one of the most notorious reinventors of the wheel yet nowadays my first thought is "let's check CPAN"... You have to "be there" to appreciate it - people working with other languages can't even fathom the treasure a central repository with this amount of well written, "official" code is. And not only is the language so valuable from a utilitarian point of view - it also allows to express algorithms in a concise, compact and creative way, making it just downright FUN to work with. It's so much more satisfying to devise an elegant, clever way to solve a problem with minimum code. Perl is directly opposed to f.ex Java in this point - writing Java is just straightforward, predictable, uncreative, longwinded, tiring work. *My* Sun shines for *Perl*; pun fully intended. So again, I want to repeat my countless thanks to everyone involved. I will have to return the favor in one way or another someday. Contribution to CPAN? Maybe, I don't know... my pathetic, worthless programming skills may never suffice for that. In any case, I have to and will find a way to. Many thankful regards, Aristoteles Pagaltzis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you haven't yet picked up Perl and are still reading here, you might want to hear yet more details on the aspects of Perl that I only briefly outlined in the previously said. Let's start from the ground up, from Perl itself. Perl makes it easy to programmatically express complex algorithms, and it does so by the cumulative effects of a whole slew of details tied together. The key to Perl's efficiency is that variables aren't just names for addresses. Perl takes a step away from the machine, with astonishing results. Because in languages like C variables are just names for addresses, a list of vectors results in a vector pointing to an array of vectors. Perl however understands a list of lists as a request to create a list that contains the contents of the sublists instead of pointers to them. If you have a lot of experience with a more traditional, more machive-oriented language such as C, this at first feels very strange and awkard. However it turns out to be very powerful because you no longer have to implement the basic list operations anew every time you need them, using low-level functionality. Perl knows the operations typically performed on lists and offers them as native operators. No longer having to turn and tweak every nook and cranny yourself, a one-line consisting of a couple nested 'map's and 'grep's suddenly is all you need to do what you would take pages of to express in other languages. All memory being managed by Perl as the central instance also has the fringe benefit that lists are dynamically shrunk and grown behind the scenes, and that the only limit is the amount of available memory, two bonuses that usually require a lot of extra effort to add to programs written in a machine-oriented language. The concept of the "undef" value results in error handling working naturally with nearly no extra effort; instead of each module/library introducing its own means of signaling errors and forcing the programmer to learn new semantics, errors usually just result in an "undef" return value. The return value has to be examined anyway; adding a check for "undef" is just one more "if". Furthermore, the style of this check are defined by the programmer who uses a module, not by the author of the module. Yet another noteworthy detail here is that "undef" evaluates to 0 or the empty string (depending on context) when not specifically asked for, effectively allowing even programs that do not intercept to work anyway. I'm not advocating this practice here, however it helps a lot during development because code becomes meaningfully executable earlier and thus allows faster feedback. It takes so little effort to handle errors anyway that no matter how lazy a programmer is, he is not lazy enough to omit even a token error check. Thus in general, code is more robust. The 'die' and 'eval' combo makes exception handling a cakewalk, where in C++ it's loads of work to implement; and if you choose not to catch the exceptions, a Perl program will usually still work (or die) gracefully. You can always add some error handling later when you've got the big picture out of your mind and down into a file. With the two abovementioned issues, detailed error handling usually comes as an afterthought; it comes when the time is there for polishing details and smoothening rough edges, most usually shortly before the program is about to be let loose on unsuspecting non-programmers who cannot be expected to know in what way it was their fault that the program isn't doing what they thought they told it to. Of course mistakes *may* be harder to spot in huge Perl projects than huge <insert other language> projects because the language is a lot less neurotic about data types and the likes, meaning that hidden bugs may creep along undetected for a long time. This often leads to the typical "hacker tool" / "not a serious language" labelling of Perl. But such problems are attributable to the programmer more so than the language. In the grand tradition of the Unix culture, Perl leaves the leash hanging loose enough for you to strangle yourself with it. Just a little discipline puts you out of risk. Ask yourself how many bugs can potentially creep into 2 pages of code as opposed to 2 lines. That much and more difference is possible by fully utilizing Perl's programming idioms. It is a trivial truth that the less code you write, the less bugs you produce, and easier to correct any that got in. When bugs do get in, due to Perl allowing to express algorithms in such a compact and abstract manner, bugs are much more "localized": the "immediate neighboorhood" of a bug, which oftentimes is known beforehand or can be narrowed down quickly, usually consists of just a couple lines of code in Perl, as opposed to several pages in other languages. Let's swiftly sum up the important points: memory management (pointers, array bounds) is known to be the foremost reason for bugs in programs as well as a majority of security holes. Missing error checking/handling is second among the top reasons. Perl does the first for you and simplifies the latter. On top of that, it makes it easier to wipe out whatever bugs slipped in. It should be readily obvious that a little discipline makes for very robust Perl programs. Sounds good so far? Well, it's going to get even better. You see, Perl consists of more than just the language itself. By installing Perl on your system (or just deciding to use it - after all, it comes with the system itself for many flavors of Unix), you get free access to thousands of hours of manpower. You've heard the question more than a couple of times - why reinvent the wheel? Chances are you're not the first one to face a certain problem; in fact, chances are it's so common that someone has taken the time to write a solidly engineered Perl module for it, and contributed it to the CPAN, the Comprehensive Perl Archive Network. This repository simply is invaluable. There's no way to praise it enough. Among the most fundamental pieces in the puzzle of my script are DBD::File and DBD::CSV. These two drivers for Perl's generic database interface, called DBI, let you use plaintext files and run SQL statements on them in the same way you would run SQL statements on a real database server. I didn't want to require users to have a running SQL server to use my script; these drivers let me skip the trouble that writing my own database-alike library and with the additional abstraction layer to switch between it and a DBI-based driver would have meant. HTML::Template is also very noteworthy; it is the module I used to cleanly separate CGI code from HTML output. Its template syntax is easy enough to be understandable to non-programmers (so anyone may write their own templates for my script) and still powerful enough to keep HTML from spilling into the Perl code. This ready-made module rid me of another necessity of solving a common problem on my own. These are but two examples of how CPAN can, essentially, do your work for you, and do it better than you would have - the modules you find there are in nearly all cases better code than you'd have spent the time to write for your given problem. CPAN has been in existence for a long time now, and as a result, humongous amounts of code are there and ready to address just about any problem you could dream up. In a nutshell, Perl makes life easy, and makes life better. Programs can be written with less effort and bugs and more ease and fun than using a different language. Really the only reason I'd at all consider using a language other than Perl nowadays is need for speed; Perl beats sloppily written C(++)/Pascal/assembler (C/P/A) programs but of course, it cannot beat the speed of a carefully optimized C/P/A program. However, a carefully optimized C/P/A program is orders of magnitude harder to both write and maintain compared to a Perl program. The choice is yours... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Note on this ramble: Which poor creatures will *actually* read this? I don't know... but if any of those terrorized victims find this over-excited geek dribble or excerpts thereof interesting enough to publish anywhere, feel free to do so as long as you don't remove my name from this mess. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #!/usr/bin/perl print pack "b*",join '',map '0'x$_.'1',split m||,'1121110010200310062'. '4020010100010310041011202200661112022003010651014010301011011202200';
