Slashdot Mirror

IF programmers want to "prove" that computer languages are like any other language used by people, then I would not show them this code. Now that I think of it- don't ever show any Perl!

See Tom's object-oriented tutorial for an example of clear perl writing. Perl is quite like a natural language. You *can* write obfuscated perl. But then again, you *can* write obfuscated English. Try this one:

The horse raced past the barn fell

I've been playing with the perl API to the Rijndael encrytion scheme and have found it easy to use and speedy. The module is very new, and does cause a segfault it you feed it data of an improper length (instead of throwing an error), but it is interesting to experiment with this emerging technology. Read about the module here: http://search.cpan.org/search?mode=module&query=Ri jndael

There is some code on cpan that can give you a good start with a voice modem for this.

hmm. Can we say CPAN?

Mason is pretty nice, I checked it out when it was just getting started. They've done a lot since then.

The high-level features are outlined on their site. Among them are: caching of HTML and data, use of the Perl debugger, and staging vs. production execution modes.

The CPAN repository is chock full of mind-bogglingly useful code, so it's nice to see more tools coming of age that allow you to take advantage of all of that through the Web. mod_perl is very nice, but for some tasks, it's just too cumbersome to work at that level. Mason nicely abstracts that away.

First of all perl is much older then php and is by far better tested and supported. The minimum php has to do is to port/support most of the CPAN (http://www.cpan.org) modules, which really help to provide fast and easy application development.

Secondly, why should one learn two different languages to do two different things? ;) Take for a example, standalone (data/system-maintainence scripts) and a web application. Why should I do web part in php and, say, db-to-files-dumping-from-cron in perl? Why should not I use perl for both? You may say that one can use php for those "standalone" scripts, but how convinient that is?

Thirdly, I have not seen any particular advantage of php that is not present in perl. Niether did I see anything which is easier in php. But that is subjective imho ;)

Perl is also easily run in both CGI mode and HTML embedded (http://perl.apache.org). Perl is installed on lot's of systems and it comes with the distributions of most UNIXes. There is even a popular perl interpreter for Windows (http://www.activestate.com/Products/ActivePerl/).

Anyway, php has no chances to make perl obsolete, since perl has million of other appliences except the web. And even to make perl obsolete for web development, php has a long road to go, though I am following the development a bit, and I like just having another alternative in the future ;)

ActivePerl has all the problems you'd expect from a Microsoft-oriented product, requring forced upgrades of Microsoft software. (Requires NT Service Pack 5, Internet Exploder 5, Microsoft Installer 1.1, etc.) The pure Perl release for Win32 seems to have been killed off, unless you build it from the sources. No current pure Perl binary distribution for Windows is available from the main Perl site or from CPAN.

Now the "ActivePerl" books will start to appear, seducing programmers into using the Windows-only features. It's Microsoft's "engulf and devour" as usual.

To reduce bloat, the Linux distros should look at another Open Source success: Perl and the CPAN (Comprehensive Perl Archive Network). With the CPAN module (or ActiveState's PPM - Perl Package Manager), installing a Perl module is a piece of cake. With http://search.cpan.org, finding a module from among the gajillions of Perl modules available is a piece of cake. All the distros would need to do is include sufficient documentation that the average unsophisticated Linux user knows what's out there and how to install the free software that's available.

To reduce bloat, the Linux distros should look at another Open Source success: Perl and the CPAN (Comprehensive Perl Archive Network). With the CPAN module (or ActiveState's PPM - Perl Package Manager), installing a Perl module is a piece of cake. With http://search.cpan.org, finding a module from among the gajillions of Perl modules available is a piece of cake. All the distros would need to do is include sufficient documentation that the average unsophisticated Linux user knows what's out there and how to install the free software that's available.

________________________________

NOMEN

Lingua::Romana::Perligata -- Perl in Latin

DESCRIPTIO

The Lingua::Romana::Perligata module makes it makes it possible to write Perl programs in Latin. (If you have to ask "Why?", then the answer probably won't make any sense to you either.)

The linguistic principles behind Perligata are described in: http://www.csse.monash.edu.au/~damian/papers/HTML/ Perligata.html

The module is used at the start of the program, and installs a filter which allows the rest of the program to be written in (modified) Latin, as described in the accompanying documentation.

EXEMPLUM

#! /usr/bin/perl -w
use Lingua::Romana::Perligata;

adnota Illud Cribrum Eratothenis

maximum tum val inquementum tum biguttam tum stadium egresso scribe.
vestibulo perlegementum da meo maximo.
maximum tum novumversum egresso scribe.
da II tum maximum conscribementa meis listis.
dum damentum nexto listis decapitamentum fac sic
lista sic hoc tum nextum recidementum cis vannementa da listis.
next tum biguttam tum stadium tum nextum tum novumversum
scribe egresso.

SCRIPTOR

Damian Conway (damian@conway.org)

IUS TRANSCRIBENDI

Copyright (c) 2000, Damian Conway. All Rights Reserved.

This module is free software. It may be used, redistributed and/or modified under the terms of the Perl Artistic License (see http://www.perl.com/perl/misc/Artistic.html)

MUTATIONES IN EDITIO 0.01

Initial release.

ADITUS

Lingua::Romana::Perligata has been uploaded to the CPAN and is also available from:

http://www.csse.monash.edu.au/~damian/CPAN/Lingua- Romana-Perligata.tar.gz _____________________

There you go. Isn't that a much saner, much more legible language? :-)

Want to see some good Perl? Check out Randall's WTR columns. And his UnixReview columns which are more tutorial.
Of course the biggest collection of Perl is CPAN. I disagree with the previous assertion that modules on CPAN are sloppy. The one's I've bothered reading are really clean and nice.
You cite slashdot as an example of sloppy Perl. Please realize that it tracks a moving target. Code that powers web sites tends to be sloppy because web sites change in unpredictable ways. Want to see clean code? Look at Net::Ping for example.
I guess we live in two different worlds. The kind of projects you work on are the ones I avoid like the plague. I would never work with idiots or work under strict arbitrary rules, not when there are so many great places to work. Maybe your workplace has a vicious cycle - the barriers you've erected to keep the 'sad wankers' at bay scare off the more talented programmers.

I've been to a couple of his talks and $55k USD is easily worth it to get this guy writing perl full time.

Who else is going to write Lingua::Romana: :Pe rligata, Quantum::Superpositions, Class:: Mul timethods and Coy.

This guy write the funniest, most intriguing perl modules around. And he gives really funny presentations. If you ever get a chance to see him give a lecture in person be sure not to miss it.

I've been to a couple of his talks and $55k USD is easily worth it to get this guy writing perl full time.

Who else is going to write Lingua::Romana: :Pe rligata, Quantum::Superpositions, Class:: Mul timethods and Coy.

This guy write the funniest, most intriguing perl modules around. And he gives really funny presentations. If you ever get a chance to see him give a lecture in person be sure not to miss it.

Dr. Conway is a coding fiend. A quick look through CPAN will reveal:

Parse::RecDescent
Coy
Text::Balanced
Lingua::EN::Inflect
Quantum::Superpositions

Just to name a few. He has also created a yet to be published module to write Perl programs in Latin (Lingua::Romana::Perligata)! On top of that he is a tireless lecturer.

He has also written a very good book concerning OO and Perl: Object Oriented Perl.

In fact, during this year's Perl Conference his series of talks was jokingly referred to as "Damian TV, all Damian, all the time." It would be very helpful to have Damian devote even just 1 year full time to Perl.

I hope this is enough to show you his value to the Perl Community.

I think you mean C-SPAN and not the Comprehensive Perl Archive Network

--

I am completely convinced that by version 8 or so, Perl will

• make "$", "%", and "@" optional

• Status: Withdrawn

• will have a decent object-oriented system

• It already has a decent object-oriented system i.e. an optional one (and what it lacks in syntactic sugar can easily be procured from CPAN). Personally, I hardly ever write non OO Perl (and, yes, I'd like to see it graduate from 'decent' to best-of-breed), but there's a bunch of areas - quick'n'dirty CGI, sysadmin scripts, optimizations and general gluing and mucking about - where OO is overkill. Don't forget Perl is a great Unix tool amongst many other things. You can munge the hell out of text with little more than a commandline salvo.

• will have useful threading

• Try version 6.

• will have a secure sandbox ala Java

• Er, you mean like Safe, which is as old as Java, offers vastly more control than the Java sandbox (it operates at the opcode level), and which, to my knowledge, has never met a script kiddie yet it couldn't politely but firmly kick to the kerb.

Perl has many fine and dandy features because it promiscuously and 'diagonally' soaks up good ideas (Larry has even been spotted flirting with C# of late). You don't have to be a hypocritical hobgoblin to want to make it finer and dandier: just another perl hacker.

I am completely convinced that by version 8 or so, Perl will

• make "$", "%", and "@" optional

• Status: Withdrawn

• will have a decent object-oriented system

• It already has a decent object-oriented system i.e. an optional one (and what it lacks in syntactic sugar can easily be procured from CPAN). Personally, I hardly ever write non OO Perl (and, yes, I'd like to see it graduate from 'decent' to best-of-breed), but there's a bunch of areas - quick'n'dirty CGI, sysadmin scripts, optimizations and general gluing and mucking about - where OO is overkill. Don't forget Perl is a great Unix tool amongst many other things. You can munge the hell out of text with little more than a commandline salvo.

• will have useful threading

• Try version 6.

• will have a secure sandbox ala Java

• Er, you mean like Safe, which is as old as Java, offers vastly more control than the Java sandbox (it operates at the opcode level), and which, to my knowledge, has never met a script kiddie yet it couldn't politely but firmly kick to the kerb.

Perl has many fine and dandy features because it promiscuously and 'diagonally' soaks up good ideas (Larry has even been spotted flirting with C# of late). You don't have to be a hypocritical hobgoblin to want to make it finer and dandier: just another perl hacker.

I am completely convinced that by version 8 or so, Perl will

• make "$", "%", and "@" optional

• Status: Withdrawn

• will have a decent object-oriented system

• It already has a decent object-oriented system i.e. an optional one (and what it lacks in syntactic sugar can easily be procured from CPAN). Personally, I hardly ever write non OO Perl (and, yes, I'd like to see it graduate from 'decent' to best-of-breed), but there's a bunch of areas - quick'n'dirty CGI, sysadmin scripts, optimizations and general gluing and mucking about - where OO is overkill. Don't forget Perl is a great Unix tool amongst many other things. You can munge the hell out of text with little more than a commandline salvo.

• will have useful threading

• Try version 6.

• will have a secure sandbox ala Java

• Er, you mean like Safe, which is as old as Java, offers vastly more control than the Java sandbox (it operates at the opcode level), and which, to my knowledge, has never met a script kiddie yet it couldn't politely but firmly kick to the kerb.

Perl has many fine and dandy features because it promiscuously and 'diagonally' soaks up good ideas (Larry has even been spotted flirting with C# of late). You don't have to be a hypocritical hobgoblin to want to make it finer and dandier: just another perl hacker.

I am completely convinced that by version 8 or so, Perl will

• make "$", "%", and "@" optional

• Status: Withdrawn

• will have a decent object-oriented system

• It already has a decent object-oriented system i.e. an optional one (and what it lacks in syntactic sugar can easily be procured from CPAN). Personally, I hardly ever write non OO Perl (and, yes, I'd like to see it graduate from 'decent' to best-of-breed), but there's a bunch of areas - quick'n'dirty CGI, sysadmin scripts, optimizations and general gluing and mucking about - where OO is overkill. Don't forget Perl is a great Unix tool amongst many other things. You can munge the hell out of text with little more than a commandline salvo.

• will have useful threading

• Try version 6.

• will have a secure sandbox ala Java

• Er, you mean like Safe, which is as old as Java, offers vastly more control than the Java sandbox (it operates at the opcode level), and which, to my knowledge, has never met a script kiddie yet it couldn't politely but firmly kick to the kerb.

Perl has many fine and dandy features because it promiscuously and 'diagonally' soaks up good ideas (Larry has even been spotted flirting with C# of late). You don't have to be a hypocritical hobgoblin to want to make it finer and dandier: just another perl hacker.

Actually, the thing to do there would be to write a spell-checker module for perl that didn't suck (I did a quick search on CPAN and didn't find anything, which doesn't mean there's nothing there, nor that there's nothing there that doesn't suck) so that it could be used in slashcode.

No, then it wouldn't be a quote from the story poster. It IS a good addendum warning about the status of the release. The story goes a little something like this:

Perl 5.7.0 Released (Devel Version) Posted by Hemos on 07:51 PM -- Sunday September 03 2000
from the makin'-time-with-the-camel dept.
qbasicprogrammer writes "The long awaited Perl 5.7.0 version has finally been released! Source code is available from CPAN. If you haven't upgraded yet, now is the time. In related news, development of Perl 6 is continuing swiftly as demonstrated by the Perl 6 Library." Check out the head's up story saying that it was coming - just a reminder this is *devel*. Don't play with it unless you know what you are doing.

Note, the stuff in italics is a quote from the story poster and the addendum on the bottom talking about it being *devel* is Hemos being a good journalist, actuarially quoting the story poster in it's entirety and informing the reader with a stern warning in the headline and the tagline.

If you want stuffy editors filtering your content, goto the nytimes. This is /. it ain't all right but it's allright.

reverse proxy can be done with Apache and mod_proxy, see the documentation for mod_proxy at http://www.apache.org/docs/mod/mod_pr oxy.html. To do name-based vhosting with it, you have two options: either have the <Virtualhost> directives on the rev-proxy and forward to different URL paths on the backend (i.e www.bletch.com/urf becomes backend.serverfarm.com/bletch/urf), or you pass the Host: field as Original-Host to the backend, and then setup a fixuphandler to put it back as the Host: header. There is an example module that does something similar (passes the original request's IP as X-Forwarded-For" at http://www.cpan.org/auth ors/id/ABH/mod_proxy_add_forward.c; it's originally meant for use with mod_perl, but there's no reason why it wouldnt work with anything else on the backend, with a tiny bit of C hacking.

Quantum::Superpositions

You can also pick up Damian Conway's Quantum::Superpositions module for Perl (http://search.cpan.org/doc/ DCONWAY/Quantum-Superpositions-1.03/lib/Quantum/Su perpositions.pm) that simulates QM-like superpositions. The documentation is an interesting introduction to quantum computing, and the talk he gave on this module at the O'Reilly conference was amazing. Now we just have to wait for Perl to be ported to one of these machines, and we'll be all set...

Anyone who went to the Perl conference and saw Damian Conway speak about this will appreciate the phrase "IN CONSTANT TIME!"...

If all you want is a pretty interface, then maybe all you need is a basic GUI client. If you want power, though, you should look into MH, which allows you to do anything you could possibly want directly from a terminal window, or within one of several front ends (including a fine GUI client). You can even chain together commands to do complicated things (or write shell or Perl scripts that do), search, sort, and filter messages, have custom commands for writing to or replying to mail from mailing lists, and so forth. The big downside with MH is that each message is its own file, and each folder is a directory, which can mean some wasted disk space. On the other hand, having every message be its own file means that you can manipulate each message separately with shell or Perl scripts.

The main front ends for MH (outside of the various shell commands) are mh-e , an Emacs interface, and exmh , a TCL/Tk GUI client (previously mentioned by Tet). (xmh included with the X Window System, is severely outdated.) Several graphical clients can also be used as front ends for MH (although that support mostly consists of being able to read from or write messages to MH-style folders). (The links in this paragraph are to sections of the on-line version of O'Reilly's MH & xmh: Email for Users & Programmers, now called MH & nmh: Email for Users & Programmers. How many other e-mail tools have an O'Reilly book dedicated to them?)

Emacs itself gives you several additional mail reading alternatives, including mh-e (of course), VM, rmail, MEW, and gnus, which is primarily a newsreader, but can also be used to read mail. (Especially good for very high-traffic lists, as it will do threading and scoring just like it does for newsgroups.)

Both exmh and mh-e (with mailcrypt) support PGP and GPG encryption, signing, and decryption.

If you don't just trust me and devote your life to MH, your best bet is to do a search on freshmeat and try all the mail clients that sound interesting. That's lots easier if you're using a Debian system or one with RPMs that will allow you to install packages, play with them, and then easily remove them and all their assorted fluff. As always, be sure to make a backup of your mail spool before you start messing around with it!

My first e-mail experiences were with VAXen and IBM mainframes. I started using MH with my first Unix account, and I've never found anything more powerful or flexible. I've tried lots of graphical clients, including Novell GroupWise 4, Eudora, Outlook, Communicator, Outlook Express, and NeXT's Mail.app, and found them all frustrating in one way or another.

My current setup uses nmh as the base system; exmh as my main reader; and mh-e for replying to mail. I use fetchmail to download my mail, and mailagent (from CPAN) to filter it, catching most spam and automatically filing real messages into the appropriate MH folders.

(To be perfectly fair, Outlook was the prettiest client I ever used, but it was still too complicated to set up and too limiting. Not to mention the nightmare that is Exchange.)

This is really great for Perl because hashes and arrays are easy to use.

With a simple cronjob and Perl's wonderfulLWP module package, not to mention the other implemtations of tracking web-pages, any relativly smart administrator should already be doing this. It comes down to this, programmers are lazy and that is good, but is this just too lazy? phooey. Maybe this should be done as an apache module .. hrmm... maybe i should write that one.. mod_url_validator
<Location />
Add-handler Check-Links
</Location>
or something like that... no i dont like it. too much overhead. well at least my first offer works, because i use it.

There is a Perl module written by Damian Conway called Coy which performs error handling in haiku. It has an extensible grammer...

• The presentation on Coy from The Perl Conferenct (TPC) 1999
• It covered extensively in the Winter 99 Perl Journal.
• You can pick up a copy from your local CPAN.

Coy.pm would be a good start. Damian Conway is my Perl hero.

First, there's POE which is almost an operating system in and of itself.

And then there's PerlOS here.

Be afraid, be very afraid.

:wq!

Only without the years of development, the thousands of freely available modules, the extreme flexibility, the massive cross-platform portability (you can configure perl for your toaster), integration with Apache, Database support, tens of thousands of existing experts and freely available sample scripts, a huge set of some of the world's best programming language documentation, and (let's not forget) its own poetry (what other language can claim that?), having the core built by one of the coolest people on earth (read and laugh!).

Maybe Pike is amusing, but next to a language like Perl, is it really needed? And can you really claim that Pike has "character" when you can't even write poetry? (Yes, I am a Perl bigot.)

BTW, Hello world in perl? perl -e 'print "hello, world\n";' on the command line will do the trick. Ha!

David E. Weekly

You can already send apple events to applications using perl with the Mac::AppleEvents and optionally the Mac::Glue modules.

Writing a command line program to send that information is possible. And those tools could be run by a shell.

You can already send apple events to applications using perl with the Mac::AppleEvents and optionally the Mac::Glue modules.

Writing a command line program to send that information is possible. And those tools could be run by a shell.

I didn't need the OOP theory (having written a book myself that taught OOP to people without any prior programming experience). I didn't need the Perl introduction (having just forced myself to learn perl after avoiding it for being the blight of a PL that it is (albeit useful) in order to change slash). So what did it it offer?

• Using Perl packages as objects? Nope. Got that from the Ostrich.
• Subroutines as methods? Nope. Second thing I did (after twinking a calendar package to use slash's user table and cookies) was create a Slash::Sql wrapper around the "do/execute/fetchrow" nonsense of DBI.
• Persistence? Nope. Third thing I did was make a Slash::Object class, which could read itself from an Sql database, and had an AUTOLOAD corresponding to the columns in the table.
• Multimethods? Okay, this was slightly useful. I caught from skimming the book that there was a multimethod package on cpan. Went there, did a search, then did perl -MCPAN -e "install Class::Multimethod" and I was done.

Perl's syntax is often opaque (especially if you didn't already know all the Unix utilities, shell scripting langs and programming langs it is based on). It ispowerful, but this book didn't quite seem to get it all. Closures, non-class-based inheritance (a la Self), or even some more useful examples? (the fourth thing I did was make a Slash::Handler class to interface to Apache, automatically placing query args or form input into fields on itself - subclass and override "handle" to decide what to do) (fifth thing was a subclass of Slash::Handler to use Text::Metatext to generate the page).

A nice enough book, but I think I'm gonna have to write one myself before I see one I really like :-)

If you write serious Perl modules, get this book. I cannot emphasize this enough. I am an author of a couple CPAN modules, most importantly GnuPG::Interface, and I must say that this book entirely revamped my object-oriented Perl module design.

It is the best Perl book I have (and I have quite a few). The most important thing I learned from this book was existence of a very important module, Class::MethodMaker, again available from CPAN. That module and this book will teach you how to write maintainable, powerful modules. It teaches tieing in a clear manner, what modules are available for use, and what pitfalls to avoid.

I have to repeat this again: if you are a serious Perl module writer, get this book!. You will not regret it!

If you write serious Perl modules, get this book. I cannot emphasize this enough. I am an author of a couple CPAN modules, most importantly GnuPG::Interface, and I must say that this book entirely revamped my object-oriented Perl module design.

It is the best Perl book I have (and I have quite a few). The most important thing I learned from this book was existence of a very important module, Class::MethodMaker, again available from CPAN. That module and this book will teach you how to write maintainable, powerful modules. It teaches tieing in a clear manner, what modules are available for use, and what pitfalls to avoid.

I have to repeat this again: if you are a serious Perl module writer, get this book!. You will not regret it!

I am not aware of any package that does exactly what you need, but HTML::Mas on could help you roll your own solution in Perl. You could also have a look at Perlfect::Template.

• are there any other ASP solutions for Apache? I've yet to find one

Hey, there sure are. Joshua Chamas' Apache::ASP, which runs under mod_perl, is probably the best solution. It runs exactly as IIS' ASP does, using the same constructs. It would probably be worth your while to check out.

The full Apache::ASP home page is at http://www.nodeworks.com/asp/, and there is tons of support for it on the mod_perl mailing list (including the author himself).

darren

What is the fascination with Perl in the *nix world?

What is the fascination with automation, quick development in the *nix world? I can do everything from send mail automatically, to parse my log files at 4:00 in the morning with a couple small scripts and crontab. Compared to other OS, *nix with perl/shell scripts can automate and build bigger applications from smaller ones in a quick and effective manner.

For example, say I want to dial-in to the Internet, download slashdot every morning at 4:00, parse out the crap, format it into latex and send it to my other computer and post it into an sql database. This could be done with *nix and perl in about 3 cans of jolt cola. Name one other OS/launage that could do it in that short of time, and have it work well.

Try that in .bat VB or VC++ and see how many cans of jolt cola it would take you.

I can't fathom it - after all it adds little to what awk and sed have been doing for years.

Uh, have you check out modules in Perl? Can awk or sed interact with a database? Can awk and sed combined send/get email/news? Also if I remeber correctly you can't do basic logic in awk+sed, like 'while' loops and 'if' statements. Also I think awk+sed lack support of things like OOP, arrays, hashes, sub routines, etc..

Perl is ALOT more then a word parser

For more complex tasks than a simple CGI script Perl seems unwieldly, and even now technologies such as ASP and JSP are taking over the server-side processing domain.

Yea Perl is hard, especailly if you look at C, C++, ASM, Java, Perl seems extremely difficult to use. (sacarism).

.ASP, now there is a winner, with it being all open and everything and not controlled by some greedy company, let me get on that bus (sacarism again).

I haven't check .jsp yet, so I won't make any comments on it

Perl is portable, can run Perl on %99.99 of all CGI enabled web servers, what does ASP run on, like 2 maybe 3 servers? Perl can do a hell of a lot more then ASP will ever be able to do, my freind once created a cgi interface to his coffee maker, not really usefull (to anyone but him), but I would have doubts of trying to do that in .ASP. Again, Perl is a REAL programming launage, that can interact with everything from C programs, other perl programs, other perl cgi scripts, coffee makers, databases, network sockets, other Internet services (smtp, pop3, nntp, irc, etc, etc), encrypted data (des, triple des, blow fish, etc, etc) and about any other thing you could possiablly think of

IMHO Perl has no real domain in which it is better than everything else - so why is it so popular? Can someone please tell me?

Have you even use Perl?

1) It is open source

2) It is Free software (as both in beer and speech)

3) You can quickly develop programs/scripts

4) It can "glue" together seemly random and unrelated compounds (ie. sql server and a pop3 email CLIENT, ie. coffee maker and the http protocol)

5) You can choose your "programming sytle". Hate OOPing? Don't use it. Love OOPing? Your in luck. Like OOPing but hate the rules and interactive between objects? Break the rules.

6) Does it have words in it? Does it need to be parse?

7) Does it need to be portable?

8) Does it have to be working before your jolt cola can goes empty?

9) Does it have to be fast?

10) Does it make you laugh when you have more or less "replaced" yourself as a system admin though the use of Perl/crontab?

11) Is it fun to randomly "glue" odd, unrelated and obsecure things together using perl?

12)Sometimes a 5 minute Perl script can save you 120 minutes of boring, manual work

as the saying goes (in the voice of the comic book store owner in the simpsons)

NOW GO AWAY OR I SHALL REPLACE YOU WITH A 10 LINE PERL SCRIPT USING THE ENGLISH MODULE

:)

What is the fascination with Perl in the *nix world?

What is the fascination with automation, quick development in the *nix world? I can do everything from send mail automatically, to parse my log files at 4:00 in the morning with a couple small scripts and crontab. Compared to other OS, *nix with perl/shell scripts can automate and build bigger applications from smaller ones in a quick and effective manner.

For example, say I want to dial-in to the Internet, download slashdot every morning at 4:00, parse out the crap, format it into latex and send it to my other computer and post it into an sql database. This could be done with *nix and perl in about 3 cans of jolt cola. Name one other OS/launage that could do it in that short of time, and have it work well.

Try that in .bat VB or VC++ and see how many cans of jolt cola it would take you.

I can't fathom it - after all it adds little to what awk and sed have been doing for years.

Uh, have you check out modules in Perl? Can awk or sed interact with a database? Can awk and sed combined send/get email/news? Also if I remeber correctly you can't do basic logic in awk+sed, like 'while' loops and 'if' statements. Also I think awk+sed lack support of things like OOP, arrays, hashes, sub routines, etc..

Perl is ALOT more then a word parser

For more complex tasks than a simple CGI script Perl seems unwieldly, and even now technologies such as ASP and JSP are taking over the server-side processing domain.

Yea Perl is hard, especailly if you look at C, C++, ASM, Java, Perl seems extremely difficult to use. (sacarism).

.ASP, now there is a winner, with it being all open and everything and not controlled by some greedy company, let me get on that bus (sacarism again).

I haven't check .jsp yet, so I won't make any comments on it

Perl is portable, can run Perl on %99.99 of all CGI enabled web servers, what does ASP run on, like 2 maybe 3 servers? Perl can do a hell of a lot more then ASP will ever be able to do, my freind once created a cgi interface to his coffee maker, not really usefull (to anyone but him), but I would have doubts of trying to do that in .ASP. Again, Perl is a REAL programming launage, that can interact with everything from C programs, other perl programs, other perl cgi scripts, coffee makers, databases, network sockets, other Internet services (smtp, pop3, nntp, irc, etc, etc), encrypted data (des, triple des, blow fish, etc, etc) and about any other thing you could possiablly think of

IMHO Perl has no real domain in which it is better than everything else - so why is it so popular? Can someone please tell me?

Have you even use Perl?

1) It is open source

2) It is Free software (as both in beer and speech)

3) You can quickly develop programs/scripts

4) It can "glue" together seemly random and unrelated compounds (ie. sql server and a pop3 email CLIENT, ie. coffee maker and the http protocol)

5) You can choose your "programming sytle". Hate OOPing? Don't use it. Love OOPing? Your in luck. Like OOPing but hate the rules and interactive between objects? Break the rules.

6) Does it have words in it? Does it need to be parse?

7) Does it need to be portable?

8) Does it have to be working before your jolt cola can goes empty?

9) Does it have to be fast?

10) Does it make you laugh when you have more or less "replaced" yourself as a system admin though the use of Perl/crontab?

11) Is it fun to randomly "glue" odd, unrelated and obsecure things together using perl?

12)Sometimes a 5 minute Perl script can save you 120 minutes of boring, manual work

as the saying goes (in the voice of the comic book store owner in the simpsons)

NOW GO AWAY OR I SHALL REPLACE YOU WITH A 10 LINE PERL SCRIPT USING THE ENGLISH MODULE

:)

after all it adds little to what awk and sed have been doing for years.

Try checking CPAN out.

For more complex tasks than a simple CGI script Perl seems unwieldly

Perl is insanely powerful, especially with CPAN, and for CGI use mod_perl. For simple CGI script's to complex ones. For more complex tasks is seems unwieldly? Production times are much more when using something like Java/C/C++ and many others. Perl also comes on most OS'es these days. It has a long history of being a CGI language. One CGI I have which is about 1,300 lines right now is simple to debug, add new features, and speed up parts of it. We're using mod_perl, so it runs much faster than before, despite some bottlenecks I have in there still, since it's still in development. I also decided to change the program into an OO program so we could customize it for our clients, that took about 10 minutes, and now I have all the advantages and disadvantages of object oriented programs. I can change it back simply too, if I ever wanted to.

even now technologies such as ASP and JSP are taking over the server-side processing domain.

I'll go ahead and forget that you didn't mention PHP. ASP is proprietary, for NT, unless you use a commercial program, or an ASP interpreter, written in Perl by the way. JSP is based on Java, which still does not have as much territory as Perl, and is much harder to debug. With mod_perl running, and a properly create program, you have the speed of ASP and JSP, more flexibility(excluding JSP, which is based on a full language).

IMHO Perl has no real domain in which it is better than everything else - so why is it so popular? Can someone please tell me?

Again, see CPAN. With Perl you can create anything from a simple text-processor to a fully featured web application using mod_perl, to a powerful workstation application using QT, GTK, both, or more. With a little knowledge of C/C++ you can create perl modules out of C/C++ libraries, and with C/C++ you can use perl code in your application. Need to make some graphs? There are several modules that'll help you, most of the work is done, just feed in the data and how you want it to look like. Check out CPAN for what is available, and check out perl.org for more information.

For answers to this and all of your other Perl questions that have been answered a quadrillion times before, see the Perl FAQ here, look in your distribution, or man perlfaq.

ok, small thing, but its perl ( not pearl )
and you should link to http://www.cpan.org if anything
not http://www.python.org for crying out loud..

---
i mean really

When embedding perl into applications, libperl as a shared library starts to look attractive. (1MB isn't as bad when its shared across everything linked to libperl.so.

But I think that a perl built into the browser is a very bad idea. There are things that perl can do on my computer that I don't want some random web page designer to do. I once thought that the Safe module would be the answer to untrusted perl code, but there are some flaws in it that don't seem to be easily resolved.

I believe that the problems with Safe.pm caused a halt in Penguin (At the time that there was a big interest in Penguin, Felix was dismissing the advantage to embedding it into a browser. He wasn't saying that it couldn't be done, but just that it was the best use of network transported code.)

When embedding perl into applications, libperl as a shared library starts to look attractive. (1MB isn't as bad when its shared across everything linked to libperl.so.

But I think that a perl built into the browser is a very bad idea. There are things that perl can do on my computer that I don't want some random web page designer to do. I once thought that the Safe module would be the answer to untrusted perl code, but there are some flaws in it that don't seem to be easily resolved.

I believe that the problems with Safe.pm caused a halt in Penguin (At the time that there was a big interest in Penguin, Felix was dismissing the advantage to embedding it into a browser. He wasn't saying that it couldn't be done, but just that it was the best use of network transported code.)

Are there ever rpm's of Perl modules? Does it even make sense? Is this an unsolvable problem with Perl modules? CPAN only goes so far in solving this problem.

I gave up dB work a year or two ago. Maybe it was starting with MS Access and enjoying its compact, RAD, toy quality. Unscaleable and inapproriate for Enterprise stuff of course (and making no pretence to such garlands), but fast, small (well, the .mds were small if you compacted them) and fun.

The problem was the inevitable upgrade lead me to MS SQL Server 6.5 (I was stuck on NT at the time). SQL Server had a lot of stuff I was missing in Access - triggers, stored procedures, scaleability - but it also brought a lot of frustrations. The domain aggregate functions were poorer than those offered by Access, which was a pain as I was trying to roll my own OLAP before it all got proprietarized into a Babel of different buyouts and skill-subsets. Its big-iron feel didn't stop it having a ludicrous 255 byte limit on varchar fields. For bigger you had to futz about wastefully amalgamating BLOBs of text with READTEXT/WRITETEXT. Plus it was grotesquely high-maintenance. I didn't want to become a DBA. I just wanted to hack SQL. And wasteful. The 'devices' ('Honey, I bloated the database') were huge and couldn't be shrunk, no matter how svelte the actual data.

By the time I escaped the NT shop I was naively looking to Oracle to save me from these frustrations. Unfortunately, I'll never know the joys or horrors of that particular 'platform', because at 600 Mb for the Linux installation I just bailed out and cried 'Enough of this grotesquely bloated crap!' and pursued XML or BerkeleyDB solutions to anything remoteley persistence-flavoured thereafter. I knew that fast and small were synonyms, but the vendors were growing fat on the antonym line and there was nothing I could do about it. Even MySQL and PostgreSQL were part of the problem. They're all emacs. None of them are vi.

Recently I ran my periodic, wishful, wistful Google-grep for 'fast', 'small' and 'rdbms' and found myself, after rejecting Brian Jepson's TinySQL as ridiculously small and cute but strictly pedagogical, finally discovering The One.

Hypersonic SQL, a tiny Open Source Java database weighing in at less than 100K, supports correlated subqueries, transactions, referential integrity, indexes, stored procedures and JDBC - everything basically, but GROUP BY, cursors and triggers. I never used cursors myself. I'd rather iterate in Perl. The other two, admittedly are fondly missed, but not life-threatening. It doesn't support failover. But with such a small, developer-friendly codebase anything's possible.

Did I say 'Perl'? 'But it's a Java database', I hear you cry. How can this beast talk Perl? Well, it can't, which is why I'm working on a Perl DBI interface to it talking to a native driver over TCP/IP. If anyone wants to contribute (I wouldn't need to hack it if some brave soul wants to polish up the languishing JNI module in JPL to support embedding Java in Perl on Linux (currently it only works for Win32)), please get in touch. I'm almost certainly way out of my depth and entering a world of pain.

Oh, did I mention? It's 7 times faster than SQL Server.

Another thing you have available with perl that isn't anywhere else I'm aware of, is the ability to create a crippled interpreter that does not have access to certain classes of functions (forking or command execution for instance) to use to run an untrusted script. Here is a quote from the FAQ for the Penguin module on CPAN: it can act just like java does, except with a vastly improved security model

See the perldelta doc at search.cpan.org

/Alex