Slashdot Mirror

Well... no, but of course Perl already has Acme::Bleach which covers that quite nicely ;-)

So, just looked Whitespace up. Pretty funny :-) I already knew about Brainfuck though; you gotta love the kinds of things programmers do with their free time :-P

-chris

You must be talking about Lingua::Romana::Perligata.

From the docs:

The Lingua::Romana::Perligata 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.)

Perl 6 is currently a serious development project. But since you must ask, check out the first CMS written in Perl 6:

http://search.cpan.org/~brentdax/WWW-Kontent-0.01/ WWW/Kontent.pm

Perl is compiled every time you run a Perl program. It causes an annoying slowdown in my programs.

It doesn't have to be... you should look into SpeedyCGI/PersistentPerl or even PPerl. I use the former for various web cgi's that are hit constantly (including one framework where all hits are rewritten to execute a single index.pl script) as well as for various scripts that need to execute very quickly as part of a qmail/vpopmail shell chain.

As long as it's already use strict compliant, neither of these options require any changes to your code (unlike mod_perl), but should give you a significant increase in speed... for exactly the reason you specified.

In fact, when you remove compilation from the equation, I've seen well-written perl code that executes faster than almost any other language... (your opcodes are basically boiling down to C anyway).

Of course for CGI-only usage you can use mod_perl, but that does bring in some added complexity. The solutions above work from the command line as well, and require nothing more than a shebang line change.

Here's a list of Perl implementations for Windows. I don't know very much about most of them, but I've heard good things about PXPerl.

Especially OS/390 on which none of the other languages mentioned in this discussion will even run

Not true. Perl runs on every platform mentioned in the above thread, including OS/390.

(off-mic:) Isn't Perl a fable, these days?

Not sure what you mean here. Perl doesn't enjoy the "hip" factor that Python and Ruby have. But Perl has an overwhelmingly larger community than either of those two languages.

I like both Python and Ruby, and think they are better-designed languages. But Perl has a huge advantage over these other languages: CPAN. You can be more productive in Perl because 80% of your code is written for you, ready for the taking. Visit http://search.cpan.org/ to see just how much stuff is there. But here is what the Python folks don't get. CPAN is much more than a repository. It's an automated distribution system. On any Perl system, type, for example, "cpan Spreadsheet::ParseExcel" and voila, you've got a class that can read binary Excel files. Any module you install may have other CPAN dependencies, which are installed automatically. These modules have a test suite and won't install unless they pass the tests. You can also, via CPAN, view the test results on many different platforms, see module ratings, the automatically extracted docs, discussions, the bug tracker entries for the module, etc. Because this is all standardized and centralized, you can write a module that depends on other modules without having to worry about inconveniencing your users--everything will install for them automatically. So the barrier to code reuse is very low, and people build modules by subclassing or otherwise extending and combining the functionality of other modules, simply writing the glue code. In other words, one of the basic tenets of the OO concept, encapsulation and code reuse, is being very elegantly played out in a place you wouldn't expect.

Ruby is getting a good start at emulating some of the CPAN functionality with their RubyGems. Python doesn't have anything like this yet. I have no doubt they will someday, and there's been brought up many times on the Python groups, and usually gets knee-jerk reactions that don't show an understanding of what CPAN has to offer. The vaults of parnassus, etc are certainly not even close to the same thing.

So, I am currently more productive with Perl, and it is certainly not because of the language or syntax itself--its despite it. I just find myself writing a lot less code and getting more accomplished. I look forward to being able to do the same in Ruby or Python someday.

But what about this?

use Coy;

Runs on X11, works for CGI scripts as well as locally-executed scripts, and is very, very nice.
just install Devel::ptkdb from CPAN, or here, on the CPAN site.

It uses Tk and is very much usable over an 11Mbps wifi link, is fast, understands perl objects, hashrefs, etc.

Best of all, it doesn't impose a monolithic IDE on your development process.

use Smart::Comments;
### Expected: "a bunch o stuff" Got: $stuff

. . . and have debugging statements that are easier to write, can be turned off in one place, and don't waste efficiency checking a bunch of conditionals.
see http://search.cpan.org/~dconway/Smart-Comments-1.0 .1/lib/Smart/Comments.pm

I love the debugger -- my background is BASIC, assembler, C and finally Perl, so it fits right in with all those "programmning down to the bare metal" tools.

However, a way cooler method is to use logging. The one I use these days is Log::Log4perl, a terrific logger that you can turn on and off at will. Thus, if you have a bit of disk space, you can turn the knob up to 11 (DEBUG) and let the application go until you get to the Weird Bug. Then it's just a matter of pawing through the log files to find all of your excellent messages. Print statements sprinkled through the code? Please.

And the bit about having to print the variable value every step in the debugger is a bit of a red herring .. you can set up commands that get executed before and after each step. Yes, it's a geeky thing to do .. that's why they call it Engineering.

http://de.lirio.us/rubric

is powered by Rubric: http://search.cpan.org/dist/Rubric

I'm surprised that Perl's CPAN archive doesn't have structured searching at smaller granularity than module name or freeform metadata. Maybe once the archives let us find code by content, we'll get version control databases that store each line in a record, each block as references in a separate table, maybe even referential integrity of variables as foreign keys. I'd love my editor to pull code from DB storage, padding whitespace only in the presentation layer per my preferences.

I'd really love to see datamining techniques for factoring, optimizing and profiling code. Not to mention the enforcement efficiencies for source license "due diligence" comparisons beyond grep. It's bizarre that programs are still so united with a hierarchical directory filesystem that scopes are enforced per-file, while class scopes have only lexical (not purely structural or referential) implementation. Relational math is rigorous enough that its direct combination with a compiler ought to produce even more revolutions than it would with an editor.

Yes. Look at CPAN.

http://search.cpan.org/search?query=barcode&mode=a ll

CPAN has almost everything :-)

About a year ago I created a system which accomplishes the same thing. We use it to run the television station for BayCon. It's called Video::PlaybackMachine, and it's available on CPAN:

http://search.cpan.org/~stephen/Video-PlaybackMach ine-0.03/PlaybackMachine.pm

I haven't examined the code, so I'm basing this post on a quick read of the white paper.

The (known) differences are:

1. PlaybackMachine is based on Xine, while VideoKeg is based on MPlayer.

2. PlaybackMachine uses a postgres backend database, so it's impossible to schedule overlapping programs. (I'm not sure what VideoKeg uses.) It's also possible to reschedule programs while PlaybackMachine is running.

3. In addition to being able to play video short commercials, PlaybackMachine can play slides with accompanying background music.

4. There's a web interface to PlaybackMachine's scheduling system.

There are probably things that VideoKeg can do that PlaybackMachine can't, but I don't know about them yet. I'm very glad that VideoKeg is out there-- just having the hardware specs for the VIA EPIA box is a wonderful thing, and in this space the more the merrier.

While Im unsure if Gallery allows you to create, edit and query 'meta' fields with each image I do know that it reads, stores and can query the EXIF fields of all imported images. One way to be able to store (once)/query (many) your custom data fields would be to initially fudge those values into the EXIF fields of each scanned image. Yes it would be weird to search for 'last name' with a 'camera model' query, but it would work.

Anyway this is probably how you'd want to go about this:

1. Scan doc to file
2. use an app or library to OCR the fields you want
3. Add EXIF fields/data to the image with perl (CPAN EXIF modules)
4. dump image into gallery. Gallery parses out and stores your crap in query-able EXIF fields.

This is all conjecture though - good luck. Seems like a pretty shitty task if you ask me.

I draw out a UI before writing a line of code. Depending on the problem at hand, I then draw (again by hand), implementation details like class hierarchies, interfaces, callbacks, etc.

When you're sitting in front of a computer, it's too easy to just start writing code. When you lose your train of thought, though, you'll end up throwing it all away because you won't know how it works. If you go to your local coffee shop with a notebook and a pencil, and start prototyping, you'll have a good plan on paper. It will be much easier to implement from a fixed plan that's written down than from some idea that you have. It will also be easier to come in the next day and start where you left off, rather than going off on some other tangent because you forgot your idea that seemed good yesterday.

My usual successful development strategy is this:

1) plan UI, interactions, structure, etc. on paper.
2) design reusable modules to do the grunt work.
3) write the documentation and unit tests for said modules. This is where you get the chance to play test your modules before you've committed to an interface. The SYNOPSIS section of your documentation (where you show example use of your module), is a great place to experiment with how your code is going to work and interact with other pieces of code. Once you know what the interface is going to look like, document the methods. Then write unit tests for them. If your interface is no good, you'll know by now, and you won't have wasted any time writing code that you're just going to trash.
4) go home and relax. you don't have to think about your code anymore because "perldoc My::Module" is going to tell you everything you need to know when you come in tomorrow morning.
5) write the actual code
6) move on to the next piece, knowing you have a well-designed, documented, tested module to build on!

I'll throw in a link to a module I developed like this. It's not particularly good in the sense of using amazing algorithms or being incredibly useful, but the documentation and tests are decent.

http://search.cpan.org/~jrockway/File-CreationTime -1.01/lib/File/CreationTime.pm

Note that every interaction the module has with the outside world has at least a little blurb to refresh my memory about what happens. That's the important part. (It's an added bonus if some random person on the Internet can understand how your code works too ;)

But perl has Test::Class which does a whole xUnit type thing inside the Test::Harness framework. Nice. However it also tells me on that page, not to bother with it unless I'm reduplicating the same code over and over in my tests -- which I usually do not.

I guess Test::Harness is plenty for average joes like me.

Acme::DonMartin is the way to go.

"The first time you run a program under Acme::DonMartin, your source code is magically transformed into Don Martin cartoon sound effects. [...] This can also be construed as a security feature. It is expected that a hacker will be laughing too hard to be able to recover the source code."

But Acme::Bleach and Acme::Eyedrops can at least make it a pain in the ass to work out what it's doing.

However it could be copied verbatim and it would still work.

As with all other things perl, see CPAN and perlmonks for more information.

- Paul

But Acme::Bleach and Acme::Eyedrops can at least make it a pain in the ass to work out what it's doing.

However it could be copied verbatim and it would still work.

As with all other things perl, see CPAN and perlmonks for more information.

- Paul

But Acme::Bleach and Acme::Eyedrops can at least make it a pain in the ass to work out what it's doing.

However it could be copied verbatim and it would still work.

As with all other things perl, see CPAN and perlmonks for more information.

- Paul

You could use this module to convert your code to Morse code.

:wq

How about this (primality-testing in O(1) - on a quantum computer, at least)?

use Quantum::Superpositions;
chomp($n = <>);
print "prime!" if($n % all(2 .. sqrt($n) + 1) == 0);

I didn't test it, but it's pretty much just ripped from the Quantum::Superpositions docs, so I suppose it should work, modulo any bugs I might have introduced.

[boggle]

I think you want Perl Packager with the --filter option...there are a few filters that can be used with that (specifically PAR::Filter::Bleach), but if one of these won't work, then I'm afraid you are asking for something that simply doesn't exist...no security through obscurity and all of that...

Have you seen this? It's just scary!

hmmmm... let's see:
an order of magnitude the performance of C++: this depends. If we're talking about regular expression-based parsing and general string manipulation, perl5 is already there. Hard math? 3- and 4-d matrix manipulations? not yet. Maybe perl7, who knows?
generic programming: perl5 has this, sort of. lots of stuff can be done in compile time. perl6 has generic types, I think even pugs have them already, but I don't recall exactly.
bazilion libraries? here, actually, this is one of the things the world (including c++) could learn from the perl community. really. including c and c++-written libraries that you can call from inside your perl programs.
I am still reading about this ITK thingie, so I won't comment, but looks good for starters.
Mind you, I work with C++ myself. But I don't think it's a perfect language (nor I am saying you said that), and I think each tool has its trade (but, seriously, I loathe Java).

Something like this?

Run that in Perl. Was apparently created with Acme::EyeDrops.

Perl's reputation for being impossible to read isn't really deserved... but as long as it's got the reputation anyway, we might as well have fun with it!

How many times did Larry Wall win the IOCCC? Consecutively?

Perl, of course, is the ideal language for such a thing, and you would be looking for Acme::Smirch, which does a fabulous job of taking any perl script and producing a perfectly functional perl script that uses no alphanumeric characters or whitespace. The results of applying smirch to the smirch module are... well they're impossible to get past the lameness filter, but I think it is safe to say that it is fairly obfuscated.

Jedidiah.

You can read the bug report about Class::Std to get a handle on the problem. You could probably implement inside-out objects manually and save yourself the problems that Class::Std has. If you read through the Class::Std documentation, you can get enough of a handle on what's going to choose your own implementation.

You can read the bug report about Class::Std to get a handle on the problem. You could probably implement inside-out objects manually and save yourself the problems that Class::Std has. If you read through the Class::Std documentation, you can get enough of a handle on what's going to choose your own implementation.

I do agree that pointing out how invalid some criticisms of Perl are does not solve the perception problem. We're trying to figure out a good strategy to deal with this and suggestions are always welcome.

As in: Perl, unique among all other scripting languages doesn't yet have useful parameter lists in function definitions Every time I type somehing like my ($foo, bar, $baz) = @_; I think to myself "lame lame lame".

And later you wrote: I have been a Perl programmer for 14 years now ...

I sometimes hear the criticism about Perl's argument handling, but I don't hear that as much as the line noise issue. The fact that you've been a Perl programmer for 14 years means that you are probably more keenly aware of this than most. I've released a module named Sub::Signatures which helps to deal with this (and allows multi-(?:method|function) dispatching (MMD) based on the number of arguments) but because it's a source filter, people are afraid to try it. Frankly, given the reputation of source filters, I can't say I blame them.

In any event, this criticism is perfectly valid and it's one of my strongest complaints about the language. It's inherently tied to the MMD issue so the latter cannot be resolved easily without the former. Another major issue is lack of encapsulation in standard object creation. Class::Std helps to minimize the problem, but it has problems running under persistent environments such as mod_perl, thus limiting its usefulness in the sort of environment which is designed to scale and thus truly needs that encapsulation. These issues combined with a lack of proper introspection capabilities are my strongest complaints. Solving them would go a long way to making Perl a truly robust language.

These issues aside, I specialize in building huge systems in Perl. I have worked on systems that tell Hollywood how much money their movies make while collecting and collating data from thousands of movie theaters across the USA. I currently work on software used by little-known companies such as the Rand Corporation, the World Health Organization and the Congressionally funded Radio Free Asia (they use my employer's software to publish their Web site in 10 different languages). The major requirement for building large systems such as these is having a robust test suite. Given the latter requirement, you can achieve powerful scalability with just about any language capable of it. Fortunately, because I choose to use Perl, I can roll out solid, robust code much faster than Java or C++ programmers. I have some amusing stories about destroying competitors using those languages because they couldn't keep up with our speed of development but NDAs compel me to keep quite :(

As for Parrot and Perl 6, they solve these problems and many more. However, Parrot is revolutionary in its approach and given that that we are a volunteer organization, it is difficult to get qualified full-time developers to solve truly unique problems. Fortunately, we're finally getting there. Perl 6 is worth the wait but those who haven't been following it closely (and perhaps those who have been following it too closely :) are getting frustrated. I don't blame them, but we don't have a huge staff on hand to crank this stuff out the door.

Patches welcome :)

I do agree that pointing out how invalid some criticisms of Perl are does not solve the perception problem. We're trying to figure out a good strategy to deal with this and suggestions are always welcome.

As in: Perl, unique among all other scripting languages doesn't yet have useful parameter lists in function definitions Every time I type somehing like my ($foo, bar, $baz) = @_; I think to myself "lame lame lame".

And later you wrote: I have been a Perl programmer for 14 years now ...

I sometimes hear the criticism about Perl's argument handling, but I don't hear that as much as the line noise issue. The fact that you've been a Perl programmer for 14 years means that you are probably more keenly aware of this than most. I've released a module named Sub::Signatures which helps to deal with this (and allows multi-(?:method|function) dispatching (MMD) based on the number of arguments) but because it's a source filter, people are afraid to try it. Frankly, given the reputation of source filters, I can't say I blame them.

In any event, this criticism is perfectly valid and it's one of my strongest complaints about the language. It's inherently tied to the MMD issue so the latter cannot be resolved easily without the former. Another major issue is lack of encapsulation in standard object creation. Class::Std helps to minimize the problem, but it has problems running under persistent environments such as mod_perl, thus limiting its usefulness in the sort of environment which is designed to scale and thus truly needs that encapsulation. These issues combined with a lack of proper introspection capabilities are my strongest complaints. Solving them would go a long way to making Perl a truly robust language.

These issues aside, I specialize in building huge systems in Perl. I have worked on systems that tell Hollywood how much money their movies make while collecting and collating data from thousands of movie theaters across the USA. I currently work on software used by little-known companies such as the Rand Corporation, the World Health Organization and the Congressionally funded Radio Free Asia (they use my employer's software to publish their Web site in 10 different languages). The major requirement for building large systems such as these is having a robust test suite. Given the latter requirement, you can achieve powerful scalability with just about any language capable of it. Fortunately, because I choose to use Perl, I can roll out solid, robust code much faster than Java or C++ programmers. I have some amusing stories about destroying competitors using those languages because they couldn't keep up with our speed of development but NDAs compel me to keep quite :(

As for Parrot and Perl 6, they solve these problems and many more. However, Parrot is revolutionary in its approach and given that that we are a volunteer organization, it is difficult to get qualified full-time developers to solve truly unique problems. Fortunately, we're finally getting there. Perl 6 is worth the wait but those who haven't been following it closely (and perhaps those who have been following it too closely :) are getting frustrated. I don't blame them, but we don't have a huge staff on hand to crank this stuff out the door.

Patches welcome :)

Perhaps CPAN::Mini could help you.

To you and your like minded responders: from the point of view of someone who stays current with perl, your question certainly seems like a troll.

Perl continues to be a one of the most advanced languages in existance (slashdot jokes about how horribly bad one can shoot oneself in the foot with it notwithstanding). There is every reason to start a new project in Perl today. I'm really not even going to try to run down a list of reasons why here, they're just too numerous. If you haven't given serious professional development in Perl a shot, you're missing out. Perl really doesn't have any equals. Python comes close to being an alternative to Perl where the rules are more strictly enforced (which removes a lot of interesting possibilities), whitespace matters syntactically (and that's just insane in a modern language), and the majority of CPAN is missing.

Take any paradigm, and method or way of developing, and unique and interesting feature of some other language, and it all can, will, and probably has been done in Perl. It is on some ways the ultimate metalanguage. You want OO? You have your choice of a wide array of completely different styles of OO (both in terms of internals and interfaces), whatever suits your needs. Are you a fan of functional programming ala Haskell? Try Language::Functional ( http://search.cpan.org/~lbrocard/Language-Function al-0.03/Functional.pm ). TheDamian even wrote a module that allows one to write perl code as correct sentences and paragraphs in proper Latin, even given Latin's lack of defined rules about word ordering. (see: http://search.cpan.org/~dconway/Lingua-Romana-Perl igata-0.50/lib/Lingua/Romana/Perligata.pm for the module, and http://www.csse.monash.edu.au/~damian/papers/HTML/ Perligata.html for the academic explanation)

Perl 6 + Parrot I suspect will be even stronger than Perl 5, but only time will tell. Perl 5 will of course be around virtually forever, even with what deficiencies it has.

BTW, there is recently a great new Perl book out called "Perl Best Practices", which goes about the business of telling you how to not write spaghetti unmaintainable broken perl code (of course, they way you do that isn't much different than how you do it in any other language, which just goes to show that the problem isn't neccesarily that Perl invites good programmers to program badly - the problem is that perl is so accessible and easy that it invites bad programmers to program at all).

To you and your like minded responders: from the point of view of someone who stays current with perl, your question certainly seems like a troll.

Perl continues to be a one of the most advanced languages in existance (slashdot jokes about how horribly bad one can shoot oneself in the foot with it notwithstanding). There is every reason to start a new project in Perl today. I'm really not even going to try to run down a list of reasons why here, they're just too numerous. If you haven't given serious professional development in Perl a shot, you're missing out. Perl really doesn't have any equals. Python comes close to being an alternative to Perl where the rules are more strictly enforced (which removes a lot of interesting possibilities), whitespace matters syntactically (and that's just insane in a modern language), and the majority of CPAN is missing.

Take any paradigm, and method or way of developing, and unique and interesting feature of some other language, and it all can, will, and probably has been done in Perl. It is on some ways the ultimate metalanguage. You want OO? You have your choice of a wide array of completely different styles of OO (both in terms of internals and interfaces), whatever suits your needs. Are you a fan of functional programming ala Haskell? Try Language::Functional ( http://search.cpan.org/~lbrocard/Language-Function al-0.03/Functional.pm ). TheDamian even wrote a module that allows one to write perl code as correct sentences and paragraphs in proper Latin, even given Latin's lack of defined rules about word ordering. (see: http://search.cpan.org/~dconway/Lingua-Romana-Perl igata-0.50/lib/Lingua/Romana/Perligata.pm for the module, and http://www.csse.monash.edu.au/~damian/papers/HTML/ Perligata.html for the academic explanation)

Perl 6 + Parrot I suspect will be even stronger than Perl 5, but only time will tell. Perl 5 will of course be around virtually forever, even with what deficiencies it has.

BTW, there is recently a great new Perl book out called "Perl Best Practices", which goes about the business of telling you how to not write spaghetti unmaintainable broken perl code (of course, they way you do that isn't much different than how you do it in any other language, which just goes to show that the problem isn't neccesarily that Perl invites good programmers to program badly - the problem is that perl is so accessible and easy that it invites bad programmers to program at all).

Probably the first one that everybody comes across is the difference in the integer primary key. In MySQL, it's auto_increment, in PostgreSQL it's a serial datatype with a backing sequence. If you want to know the primary key value after creating a new row, it's accessed in different ways. And this is just the tip of the iceberg.

Thankfully, because they're all based on a common standard language (SQL), it's possible. It's just still a lot of very hard work. But it's not impossible.

If it was easy, you'd see many, many more open source projects supporting something other than MySQL (which bugs me as PostgreSQL user :-)

-Dom

First, I must comment the article. Question goes What little known command performs just the right function for you? I hope all sane people here (haha) would answer "None". There's no command that does just the right function since there's no one The Function. It depends on the situation what the function is. And in that case, per Unix philosophy, where one tool does one simple job, but does it well, you should choose the tool accordingly.

Enough of that. If you really must name something, then, in my opinion, there's one gizmo above others. And that is

perl

Perl one-liners is a damn powerful concept when you get it. Say one of your boxen switches IP address. You want to replace all references in files under /etc to this new IP address. First you might think searching all the files under /etc with find(1), then passing the list of files to grep(1) and then manually editing the places where the old IP address was found with your $EDITOR. That's fine and will get the job done and all but what if you could just edit the files in place? With perl, you can.

perl -pne's/oldip/newip/g' -i `find /etc -type f`

and you're done (better be extra careful with commands like that for obvious reasons!). Of course you're able to do the same thing with other tools too, but I don't think it could be much easier than that. And naturally you're not just limited to simple search and replace of text, you have the full power of Perl (and CPAN!) at your disposal.

Besides being my number one choice for creating complex scripts and small applications, Perl has very special place in my command line toolbox just next to the old friends such as grep(1), cut(1), wc(1), etc. and a huge pile of pipes :)

The FoxNews hatchetjob on open document formats is written by the Exec Director of a Microsoft lobbyist. Anyone who gets any news from Fox needs to set their "taint" bit. As in "Fox News: 't ain't never true!".

Wow, I've been waiting for this topic to show up for, what, six years now? :)

What you want is a Davis Instruments station. These stations hook up, via serial cable, to any PC. If you're running some form of *nix, I highly recommend the Device::WxM2 Perl module. I've written various collection daemons that use WxM2 to pull weather data from the station and store it in RRD format or in a PostgreSQL database. I even wrote an AGI script that allows people calling my Asterisk PBX to hear the latest weather data. I also wrote a handy widget for Konfabulator that lets you watch the weather on your Mac/PC desktop in real-time.

Shameless plug: if you decide that the Davis station is right for you, stop by my employer's website, where we have a variety of Davis Instruments choices.

One word of advice: we sell cheaper stations than the Davis models but if you are planning on putting this up on a roof and leaving it for 5+ years, you really want to go with a quality peice of equipment, not a Radio Shack toy that will disintegrate after a year in the sun.

Questions? Ask and I'll be glad to answer.

Chris

I was going to joke about how long I've been waiting for Duke Nukem Forever and TeamFortress 2... then I looked at the Perl Release History. My god, I've lost my virginity, been engaged 3 different times, went through highschool, went through college, lived in 6 different houses, had about 15 different cars, had about 20 different jobs, and travelled to another continent in since Perl 5 first appeared. And I thought IE7 was a long time in coming!

Some fun facts about 1993, the first appearance of Perl 5 (from Wikipedia - 1993):

In Moscow, George H. W. Bush and Boris Yeltsin sign the second Strategic Arms Reduction Treaty (START).

Washington State executes Westley Allan Dodd by hanging (the first legal hanging in America since 1965)

For the first time, Martin Luther King Jr. holiday is officially observed in all 50 American states.

Bill Clinton succeeds George H. W. Bush as President of the United States of America.

Bureau of Alcohol, Tobacco and Firearms agents raid the Branch Davidian compound in Waco, Texas with a warrant to arrest cult leader David Koresh on federal firearms violations. Four agents and five Davidians die in the raid and a 51-day standoff begins.

Rodney King testifies at the federal trial of four Los Angeles, California police officers accused of violating King's civil rights when they beat him during an arrest.

A bug in a program written by Richard Depew sends an article to 200 newsgroups simultaneously. The term spamming is coined by Joel Furr to describe the incident.

The World Wide Web was born at CERN.

War on Drugs: Colombian drug lord Pablo Escobar is gunned down in Medellín when police tries to arrest him.

And, of course, Perl 5 alpha first appears.

revolutionary or not, "AJAX" is now used in lots of languages. and there are some good tools out there. there's ruby on rails with the prototype library which is also now available in perl. there's also CGI::Ajax which is pretty simple to apply... and it's perl!

...use JSON-RPC instead. XML is longer and hard for a javascript interpreter to interpret. Why does everyone want to use it as a wire protocol? I've never understood this. It makes a lot more sense to me to just store everything as a javascript hash.

Anyway, unlike the almost most ajax libraries, which are at this point almost totally devoid of docs, the guy who wrote a JSON-RPC library actually tells you how to use it. If you've got java, its the way to go, I think. Here it is.

Personally, I'm a perl monger, so I use this lib, which isn't nearly as good, as you have to do most of the javascript stuff yourself. Faster than XML though, and its still rather trivial to turn a DOM object into a plain javascript one for use with JSON.

One thing to be careful about is that Plucene and Lucene indexes are not compatible with each other. So if you were thinking about using Perl to crawl and using Nutch's Java-based index searcher, think again...

http://search.cpan.org/~tmtm/Plucene-1.24/lib/Pluc ene.pm

It would be great if they were compatible. I hate having to write my custom parsing code in Java.

You beat me to replying...

This [flash based thing] is the easiest form of captcha to crack. I bet it would take just a few seconds looking around a flash extractor on CPAN or something.

Also a couple for Perl...

http://search.cpan.org/~jzawodny/Geo-METAR-1.14/ME TAR.pm
http://search.cpan.org/~jbriggs/Aviation-Report-1. 02/Report.pm

Also a couple for Perl...

http://search.cpan.org/~jzawodny/Geo-METAR-1.14/ME TAR.pm
http://search.cpan.org/~jbriggs/Aviation-Report-1. 02/Report.pm

Can these monstrosities be generated algorithmically?

The quoted regular expression in the GP was generated algorithmically. It was originally a word list from the Lingua::EN::Words2Nums module (Check out the source if you want to see the list.) To generate the regex, the list was passed through the Regex::PreSuf module, which creates fast-running regular expressions out of word lists.

Can these monstrosities be generated algorithmically?

The quoted regular expression in the GP was generated algorithmically. It was originally a word list from the Lingua::EN::Words2Nums module (Check out the source if you want to see the list.) To generate the regex, the list was passed through the Regex::PreSuf module, which creates fast-running regular expressions out of word lists.