Slashdot Mirror

I can't believe the article did not mention ACME::Bleach which just bleaches your program. Run it once and your code magically disappears... but still runs!

ACME::Buffy is similar, except your program is turned into a Buffy mantra that can be chanted or executed.

In fact the whole ACME name space is reserved just for silly and incredibly useful modules.

I can't believe the article did not mention ACME::Bleach which just bleaches your program. Run it once and your code magically disappears... but still runs!

ACME::Buffy is similar, except your program is turned into a Buffy mantra that can be chanted or executed.

In fact the whole ACME name space is reserved just for silly and incredibly useful modules.

I can't believe the article did not mention ACME::Bleach which just bleaches your program. Run it once and your code magically disappears... but still runs!

ACME::Buffy is similar, except your program is turned into a Buffy mantra that can be chanted or executed.

In fact the whole ACME name space is reserved just for silly and incredibly useful modules.

http://www.cpan.org/src/unsupported/4.036/

One of the coolest things about the Perl 6 development is that it leads to lots of improvements available right here, right now with Perl 5.

Attribute for example have been incorporated in perl 5.7.2, and a whole unch of new modules by Damian and others use them in tons of creative ways.

I am not sure this would have been done without the Perl 6 process. It forced the whole community to re-examine the language, take a step back and think of new ways to improve it. This would have been much more difficult if we had not had license to do it freely under the Perl 6 RFC process. This is the kind of things that keep a community alive and creative.

And BTW Perl 6 will still let you write quick'n dirty one-liners, and the first goal of the design of the interpretor is Speed (Larry mentionned "and it'has to be fast" about 25 times in 60 seconds in his last State of the Onion0.

One of the coolest things about the Perl 6 development is that it leads to lots of improvements available right here, right now with Perl 5.

Attribute for example have been incorporated in perl 5.7.2, and a whole unch of new modules by Damian and others use them in tons of creative ways.

I am not sure this would have been done without the Perl 6 process. It forced the whole community to re-examine the language, take a step back and think of new ways to improve it. This would have been much more difficult if we had not had license to do it freely under the Perl 6 RFC process. This is the kind of things that keep a community alive and creative.

And BTW Perl 6 will still let you write quick'n dirty one-liners, and the first goal of the design of the interpretor is Speed (Larry mentionned "and it'has to be fast" about 25 times in 60 seconds in his last State of the Onion0.

Most languages make error checking very hard. In particular, C and Perl, two of the most used langs in OSS development, lack good mechanisms for sane error checking.

Although you wouldn't believe it from looking at the average Perl script (given the kind of weenies that think that because they've read the Llama, they know everything about Perl), Perl does actually have exception handling which works in a similar fasion to C++ and Java:

If you prefer the names try, throw and catch rather than eval, die and $@, then there's modules on CPAN that can fake the more traditional syntax for you.

Of course, you knew you could do Design by contract in Perl, right?

If you've had a bad experience with PERL, give Perl a try!

If you've had a bad experience with PERL, give Perl a try!

Not that far actually... Damian Conway, author, amongst many other wonders, of Lingua-Romana-Perligata which lets you program in Latin, uses a module that does computation in Klingon in his OO classes and has written a module that let's you program entirely in Klingon!

The most interesting point in both Latin and Klingon is that the order of words in a sentence is not significant. Instead declensions are used to determine the role of the various tokens in an instruction: 9 declensions are used to mark whether the variable is a scalar (nextum), an array (nexta), a scalar being assigned to (nexto) etc...

BTW Damian also wrote Acme::Bleach, which turns your code into a file that apparently contains the single instruction use ACME::Bleach... but that still runs!

Not that far actually... Damian Conway, author, amongst many other wonders, of Lingua-Romana-Perligata which lets you program in Latin, uses a module that does computation in Klingon in his OO classes and has written a module that let's you program entirely in Klingon!

The most interesting point in both Latin and Klingon is that the order of words in a sentence is not significant. Instead declensions are used to determine the role of the various tokens in an instruction: 9 declensions are used to mark whether the variable is a scalar (nextum), an array (nexta), a scalar being assigned to (nexto) etc...

BTW Damian also wrote Acme::Bleach, which turns your code into a file that apparently contains the single instruction use ACME::Bleach... but that still runs!

88I'd find it more interesting just to see where I have driven over the past twelve months.

Just get a GPS with a 12VDC adapter and leave it running in your car. Periodically download your track log to your PC -- voila!

Your GPS manufacturer probably has software to do this. I have a Garmin; there are shareware utilities for managing the tracklog and waypoint database. Alternatively, there are open perl modules that talk the Garmin protocol -- very nice for owners of the cheap etrex.

(Personally, I think the etrex antenna sucks but it is otherwise a sweet little box that works fine in the car where you don't have to worry much about tree cover.)

Alternatively, I'd like to see what cell phone cells I drive through. That'd be neat, and perhaps more nerdly than the purpose-built paths of the site.

The really alpha-geek thing to do would be to hack your cell phone to tell you. Otherwise, you could approximate this by plotting the centroids of the cell as waypoints and downloading them to your GPS.

An even nicer thing would be to do a PDA application that talks to your GPS so you could have a more sophisticated database. I've toyed with several for the palm: the Magellan unit for Vx form factor and the Rand-Macnally unit for the III form factor (These are somewhat obsoleted by the new form factors). Both of these work by sending standard NMEA strings with position, heading and speed information over RS232, so acquirign fix information and parsing it is a snap. The Magellan unit is excellent; it locks on fast and comes with first class software that turns your palm pilot into a handly little GPS with a full GUI.

The Rand Macnally unit is pretty much junk: the mapping software that comes with it is very crashy on the palm. However the desktop software is fine and very useful for street mapping and the hardware unit is acceptable: it takes a long time to lock on, but it performs acceptably thereafter if you have good coverage. The big advantage is that if you look in the store specials bin it can be got really, really cheap: the III form factor is gone and because of the crappy software the Streetfinder/GPS for palm package has a very high return rate. This makes it good for experimenting if you have a III* palm, or can get your hands on one. The most important strings for position, heading, signal quality etc. are standard across all manufacturers.

There are some clip on units for WinCE too; I expect the also work by sending serial signals. In any case, your other choice is to make a null-modemish cable for your GPS to connect it to your PDA or laptop. The connectors on GPS's are non-standard (they have to be water proof) and very expensive: a cable with the GPS connector on one end and bare wires on the other cost about $40. There was a guy who had molded some connectors for a couple of Garmin units and was selling them for a reasonable price over the internet -- try a google search.

There used to be a Rand-Macnally package with the streetfinder package and a small, puck like GPS unit with a DB9 DCE wired connector that plugged straight into your laptop to transfer data and to get power. This cost me under $100, for which I got the GPS (sans any hardware user interface which was fine for my purposes) and street maps of the entire US (albeit windows only). This might make a good experimenter's unit if it's still available. If you want to use it with a PDA, simply make a little straight through dongle that separates power leads and runs them to a small battery pack.

By the way, interfacing with GPSs and other NMEA capable equipment is one fault I found with the Linux PDA discussed a few days ago. Sure, USB is better for desktop integration, but you have to get a CF format serial card (such as the Socket corp I/O card) to interface with this kind of equipment. Hopefully, there are drivers for serial cards, otherwise they're useless for many kinds of apps you'd particularly want an open software based platform for.

Several CPAN modules have been written to allow Perl 6 syntax in Perl 5. More will certainly follow.

Several CPAN modules have been written to allow Perl 6 syntax in Perl 5. More will certainly follow.

Well I suppose now somebody is going to have to update the Quantum modules so they use this stuff :)

if (any(@value) is very useful, but the inclusion into Perl 6 is (AFAIK) currently under RFC . The thought of quantum Perl on a quantum computer makes me feel all tingley...

-- Dooferlad

Reuven Lerner, the author of Linux Journal's nifty At The Forge column, wrote a really cool Apache module in perl named Apache::CodeRed and available from cpan here. This helped out with my codered hits and made me feel like I might be helping get rid of the stupid thing.

I modified (search and replace..hehe) Apache::CodeRed by inserting "Nimda" where "CodeRed" had been and put it in perl's @INC. I also had to change the Apache config file to pass requests for /scripts to Apache::Nimda by adding the lines:

PerlModule Apache::Nimda
<Location /script>
SetHandler perl-script
PerlHandler Apache::Nimda
</Location>

As soon as telocity's mail server comes back up (another nimda victim?) I'll email Mr. Lerner and see if he is interested in making a more general perl Mod to deal with all these annoying exploits. Maybe if the people who admin these rouge boxes got as many emails as I get breakin attempts they'd get on the ball and fix their machines...but I kinda doubt it.

The problem I have with it is that it doesn't respect a DTD. This places too much dependence on a specific XML file. If I have a node that is allowed to have more than one child, XML::Simple will return different results depending on how many children are in the node. If it is just one, then the data in that node is placed as a scalar. If there are more than one, then the data is put into an array(an arrayref, actually).

Personally, I think it should always be an array if there is a possiblity for more than one element. If there is just one thing in there, then it should have just one element. But you can't tell if there would ever be more than one element inside a node just by looking at the XML file, because that is just one instance. You have to look at the DTD.

XML::Simple would be extremely useful if it returned the same data structure for the same DTD, every single time. Each XML instance would have different data filled out, of course, but the structure of the data would be the same. Maybe this isn't quite possible in perl.

I think a lot of the XML development I have seen really ignores the usefulness of DTD's. If you want to make nicely structured data, XML is great. But if you really want to provide something robust and extensible, you have to provide a DTD and test that you will be able to handle anything that DTD provides. Otherwise you are just kidding yourself.

-Mike

It's true that perl is getting more and more of the capabilities of Lisp (as has Python) recently, but while it is becomeing *possible* to do many things, it's rather ugly. Perl doesn't even have a decent syntax for naming the arguments of a function, and Lisp programming is *full* of functions.

Perl datastructures (arrays and hashes) also aren't very well suited to implementing lists, which are likely to turn up in your tasks. Of course you r can *do* it, but it's likely to be more ugly in than in a proper Lisp.

These are mantras that I've heard regularly from Lisp and functional language users, but I've yet to see them thoroughly backed up.

Perl coders use functions *all* the time. Even OO method calls are implemented as simple functions. If you need named parameters, use a hash or hashref. There are even modules that validate parameters
so you can have a call signature.

As far as arrays not being lists, I don't get this one either. In what way are Perl arrays not lists? With functions like pop, push, shift and unshift, and array is treatable exactly as a list. Now, I don't know if lisp does lazy evaluation, if so that's something Perl doesn't do, and would be a very valid point against it. But you didn't mention that...

Seriously, I'm not trying to flame. I'm geniunely curious about these points.

Matt.

It's true that perl is getting more and more of the capabilities of Lisp (as has Python) recently, but while it is becomeing *possible* to do many things, it's rather ugly. Perl doesn't even have a decent syntax for naming the arguments of a function, and Lisp programming is *full* of functions.

Perl datastructures (arrays and hashes) also aren't very well suited to implementing lists, which are likely to turn up in your tasks. Of course you r can *do* it, but it's likely to be more ugly in than in a proper Lisp.

These are mantras that I've heard regularly from Lisp and functional language users, but I've yet to see them thoroughly backed up.

Perl coders use functions *all* the time. Even OO method calls are implemented as simple functions. If you need named parameters, use a hash or hashref. There are even modules that validate parameters
so you can have a call signature.

As far as arrays not being lists, I don't get this one either. In what way are Perl arrays not lists? With functions like pop, push, shift and unshift, and array is treatable exactly as a list. Now, I don't know if lisp does lazy evaluation, if so that's something Perl doesn't do, and would be a very valid point against it. But you didn't mention that...

Seriously, I'm not trying to flame. I'm geniunely curious about these points.

Matt.

It's true that perl is getting more and more of the capabilities of Lisp (as has Python) recently, but while it is becomeing *possible* to do many things, it's rather ugly. Perl doesn't even have a decent syntax for naming the arguments of a function, and Lisp programming is *full* of functions.

Perl datastructures (arrays and hashes) also aren't very well suited to implementing lists, which are likely to turn up in your tasks. Of course you r can *do* it, but it's likely to be more ugly in than in a proper Lisp.

These are mantras that I've heard regularly from Lisp and functional language users, but I've yet to see them thoroughly backed up.

Perl coders use functions *all* the time. Even OO method calls are implemented as simple functions. If you need named parameters, use a hash or hashref. There are even modules that validate parameters
so you can have a call signature.

As far as arrays not being lists, I don't get this one either. In what way are Perl arrays not lists? With functions like pop, push, shift and unshift, and array is treatable exactly as a list. Now, I don't know if lisp does lazy evaluation, if so that's something Perl doesn't do, and would be a very valid point against it. But you didn't mention that...

Seriously, I'm not trying to flame. I'm geniunely curious about these points.

Matt.

I developed a system like this for a previous job. We started with a source browser and then began checking engineering documents into our repository and (thus) making them browsable on the web

It can be really be nice. The hardest things were social issues; it requires a bit more discipline to maintain documents in a repository than by file sharing and email. Establishing the taxonomy so that people know where to put things and where to look for them is critical; but getting a good search engine up[1] can help there. Using small documents to redirect browsers to the "right" place can also help, since you can take a document that spans categories and put it in multiple places. I also wanted to get a Wiki in place, but left before we got there.

Having the revisions of design docs and test specs (which always change as implementation proceeds) tied to the appropriate revs of the software and other documentation using CVS tags, perforce change #'s/labels, or whatever is really nice.

As far as linking, HTML and MSOffice links were always made relative to the current document, so you could browse them when you'd checked them out on to your local machine. That was another social issue: educationing people to be careful, since most HTML editors and MSOffice HTML manglers of that vintage needed a little extra care to create relative links.

Since this was software engineering, we also implemented in-browser diffs (a lot like CVS web) and source code browsing as research tools. Having the design and discovery ("hey! so that's how this code works!" "Quick write it down before you forget!") docs that can link to the source code means that a new team member can read through a design doc and jump in and see the source code (where we kept implementation documentation).

You can modify your server-side source code browser to find things like file:../../design/index.xml in source files and convert them http: links when browsed, then use an editor or xterm that activates embedded links and be able to refer to design docs in soruce code. This also allow developers to link out to web sites, though we slurped anything that important in to the repo to protect against bit rot.

Since you've choosen XML a priori, you should definitely look at AxKit (Perl-based) or Cocoon (if Java's your fave) as delivery vehicles. Both are ASF official projects, though AxKit is a recent addition and hasn't made it to an Apache webserver.

Never used Cocoon, but AxKit can easily back-end to CVS and apply whatever transformations you like. AxKit can apply it's own XPathScript and XSP (language="perl") style sheets; various C-based XSLT engines (Sablotron and libxslt come to mind); and, of course, 100% Pure Perl to thoroughly munge your docs. Then it caches the results (if you like) and optionally GZips them (which is nice for dial-up or VPN use).

AxKit's main drawback at the moment is that it's web site is down due to sluggishness of British Telecom in installing a new data line, but you can find out more by searching cpan for the AxKit module.

If you do it right, you will have a very cool system.

HTH,

Barrie

[1] We did this before XML was all the rage, and getting meaningful searches of MSOffice files checked in to a reposiroty was a right pain. We ended up sharing out a directory tree that was updated nightly with the head revisions and letting people search with MSOffice's built in File Find.

Could be some ritual thing, but he doesn't seem that harmful, except to himself...

Anyway, it seems that KenShan is also the writer of a superb multiplexing output Perl module.

How did you get Perl to accept the apostrophe as a letter, instead of treating it as a quote mark?

Apart from being a string delimiter, apostrophe was also the package name separator in Perl 4 and has been kept on in that role (for backwards compatibility only) in Perl 5.

That is, the following are synonyms in Perl 5:


sub Phroggy's_Question { return "???" }

sub Phroggy::s_Question { return "???" }


So I could have used an apostrophe in any Perl identifier, so long as I didn't care which package the corresponding referent ended up belonging to.

However, Klingon has a very different grammatical structure from Perl -- Klingon imperative verbs are RPN, whereas Perl subroutines use a prefix notation.

So I needed to use a source filter to translate the grammatical structure. Since I was translating anyway, it was quite easy to include specific handling of glottal stop apostrophes as word characters.

Of course, that also meant I couldn't use apostrophes as string delimiters. But that was okay, since I had already decided that the pach ("talon") and pachmey ("double talons") delimiters:


<qo' nuqneH> yIghitlh!---> print 'qo\' nuqneH';

<<qo' nuqneH>> yIghitlh!---> print "qo' nuqneH";


were more in keeping with the Klingon mindset anyway ;-)

Damian

Ought to work.. anybody tried using it?

Oh, whoops! I typed before I thought. Mea Culpa.
I meant modules . I get giddy hard nips to plug my two favortie free languages. So sorry.

I think as long as it's use is based on it's usefullness (which has been the case with most scripting languages), it's only a matter of time.

Ruby has been as much of a pleasent surprise to me as Perl was back when I first learned it. No, it's not "Perl with Objects"; Perl itself does that quite well. It's more like Smalltalk, only readable, pragmatic rather than idealistic, and as expressive and concise as Perl when you want it to be. Personally, i think Ruby is a much greater threat to Perl than Python is, in the long run. Rather than forcing you to do it Guido's Way, you can do it the Perl Way, or the Smalltalk Way, or the Functional Way... or any combination of the above. No wonder the Pragmatic Programmers wrote a book on it. It does TMTOWTDI better than Perl does TMTOWTDI; while remaining relatively simple and clean.

So just give it time. I think it's well on it's way to world domination.

Oh, and as for a CPAN-like code archive for Ruby, there's a somewhat embrionic one here. There is discussion currently going on at the RubyWiki on how to implement a CPAN-like system for Ruby only avoiding the problems that CPAN has.

--

Or 'who needs Linux when we have UNIX®', 'who needs Netscape when we have Mosaic', etc.

Don't write Ruby off until you play with it. And, having played with it, I've written it off. I was looking for something on the client side that was more powerful than JavaScript but not as hefty as Java. Perl moved across the wire would be beautiful and that was the goal of the Penguin module. Alas, it seems to have withered on the vine.

Be a little more open. It'll keep you young.

Take a look for your self here: http://search.cpan.org/

Seriously though, do we *really* need another scripting language? We've got perl, python, rebol, scheme, csh, bash, sh, ksh, [insert favorite scripting language here]...

Seriously though, do we *really* need another scripting language? We've got perl, python, rebol, scheme, csh, bash, sh, ksh, [insert favorite scripting language here]...

Well, you can get PERL and a Shell

Get it instead of the one linked to in the post. The tar file there is missing. Here it is: http://www.cpan.org/authors/id/RBOW/Date-DayOfWeek -1.13.tar.gz

In the "golden age" of radio, you were lucky to tune in a handful of stations, and some of them were not on 24/7... but lots of it was good.

Now, radio is filled with crap, but if you use a really good tuner, you can still find a handful of good stations. Small (often public) stations play really good jazz, radio plays, indie music, etc. Sure their signal is weak, and they don't have the money to put up billboards alerting you to their presense... but that was true of the "golden age" stations.

So, you see, nothing much has changed. Before there was a little good content. Now there is a little good content.

The only thing "lost" when a medium grows is the dream that it will somehow expand with nothing but high quality content forever. No matter what method it is delivered by, there are a finite number of people out there who are both willing and able to produce something better than the dreck that fills mainstream radio and TV. Therefore, all "growth" beyond that finite limit is the addition of useless crap. Because of this, when looking at a medium as a whole, the percentage of useful content drops... but that is a meaningless statistic when you stop and think about it. What matters is not the S/N ratio (if you know how to filter out the N properly). What matters is the actual ammount of useful content out there.

In other words, as long as CPAN and cool stuff like this is still out there, I really don't care what MSNBC is up to.

Actually C code can now be written in Perl using Inline::C module; it allows you to embed subroutines written in C inside your Perl code.

Improve Day Trading Skills with Peak Trader

Take a gander at the new RSS 1.0 syndication support. Slashcode make full use of the format's extensibility framework via Dublin Core and its Slash module.

Point your browser at http://slashcode.com/slashcode.rss and enjoy!

I mean think about it, if the teacher reads and remembers enough phrases that pay, you're going to get caught ... or in this case, if he GREPs your sorry lazy butt.

I've been in two situations where we had two separate developers, a VB and a Perl developer, work on the exact same project in the interest of getting it done as quickly as possible. (Disclosure: I was the Perl developer :-)

Perl won, by a longshot. Both in time and in size. But I can't take complete credit. Thanks to CPAN, everything you've ever wanted to do has been made into a module. All you have to do is load the module, initiate some objects, call a few methods, and you're done! Not that I tell the VB developers that. :-)

The fact that he took notice of Perl- and Python-using competitors is significant. He views those languages as being nearly as powerful as Lisp; their main deficiency is that their syntax isn't ``easily extensible.'' Both possess means of extending syntax, but the revealed expressive power is handicapped by the languages' definitions.

Lisp macros work directly on Lisp objects, which exist after parsing but before compilation. Perl mostly lacks that middle ground (or rather it has 12004782 different middle grounds, depending on how you look at it), and Python's AST system is terribly difficult to use (and somewhat non-portable). Both of those languages treat syntax extensions as black magic; Lisp makes them everyday tools.

Lisp does have its problems. The package system is slightly obtuse, and the inheritance scheme in standard CLOS is completely busted. And it's only as portable as its implementations. The free Common Lisp implementations that run on many platforms are interpreters. The compilers run on a very restricted number of platforms. And there's no equivalent to CPAN. But it's still worth a look.

A structure with backlinks, such as a tree in which each node has a back pointer to its parent, is a great use for weak links. If you do that in Perl now, you can get a memory leak, because it looks like a circular reference and the reference counts won't go to 0. If the backlinks are weak links, the tree will be deleted when all external references to it go away.

The Perl implementation of weak links turns weak links to an object into "undef" when all the regular (strong) links go away. It's not clear if this can result in an object being deleted while in use. When you dereference a weak link, does that bump the reference count? Unclear. Details like this really matter in threaded programs, where one thread might drop an object in use by another thread. The Perl documentation is hazy on this.

I'd like to use it, but my Perl code has to run on servers that don't run the latest Perl. It's going to be useful in future, once newer Perl implementations are widely deployed. Once it's standard, widely used tree structures like HTML::Element should use it.

Considering you can write ASP in Perl I would say that your not propelry informed. You can do ASP in JScript, Perl, VBScript etc.

LOL, I've got quite a few projects that use Perl to generate JavaScript to generate DHTML.

You can really tell that Perl was made to deal w/ text and data (hence the name: Practical Extraction and Reporting Language aka Pathologically Eclectic Rubbish Lister). It's one of the things that make the language so nice to work w/ in a web/database environment. This can have great benifits for reducing development time.

Another great strength of Perl is CPAN. Perl has a great community behind it.

Above all, I just think Perl is a fun language. It's not full of rules and restrictions. It's very loose and tends to let you find out what the best way to do something is. It's not always the right tool for the right job but it fits nicely most of the time.

What you really want is http://www.cpan.org/modules/by-module/Net/libnet-1 .0703.tar.gz.

-Gerard
http://www.lanois.com/perl/

It's nice to see that the folks at this Open Source Directory are modeling the software categories after Sourceforge'.s Software/application taxonomies typically vary from site-to-site and distribution-to-distribution. While I appreciate that all the site maintainers out there take time to organize information about software applications, the diversity makes it difficult to synthesize materials from multiple sources. I applaud this directory's deference to a previously-existing taxonomy.

A while back, I started creating a list of software categorization schemes/systems relevent to Linuxland:

http://freshmeat.net/browse/627/
http://apps.kde.com/na/2/categories&nav=f
http://sourceforge.net/softwaremap/trove_list.php
http://dmoz.org/Computers/Software/
http://dir.yahoo.com/Computers_and_Internet/Softwa re/
http://ftp.us.debian.org/debian/dists/potato/main/ binary-i386/
ftp://ftp.ibiblio.org/pub/Linux/
http://www.gnu.org/gnulist/production/index.html
http://www.userfriendly.net/linux/RPM/Groups.html
http://www.cpan.org/modules/by-category/
http://www.freebsd.org/ports/
ftp://ftp.isi.edu/in-notes/iana/assignments/media- types/media-types
http://www.pathname.com/fhs/
http://www.labs.redhat.com/gug/users-guide/main-me nu.html
http://www.linux.com/links/Software/

But thats what Weak references are for:

http://search.cpan.org/search?dist=WeakRef

Example: Perl's pitiful documentation compared to Python's rich, perfect, strait-from-the-mounth-of-god, Guido himself documentation.

Either you jest or you display ignorance. The perl distribution comes with tons of doc. Try issuing perldoc perldoc. You can use perldoc -f function_name_here to get information about any perl function and perldoc module_name_here to get documentation about any module for which the author has provided it (which is most of them if not damn near all of them).

More to the point, try man perl - each of the 70 sections is its own extensive man page, covering references, objects extensions in c - you name it it's probably there.

Oh, and how extensible is Perl? I never heard of an applet written in Perl.

What do these 2 sentences have to do with each other? many meabytes of perl extensions can be found at CPAN - I don't believe I've ever wanted to do something that wasn't made much easier by something that was already there. What does writing applets have to do with exensibility? perl is quite extensible in both perl and c. And there is a project to compile perl source to java bytecode, tho I'm not sure if it's still active. But client side applets aren't my main concern. I don't think they're flavor of the week anymore, anyhow.

--

What people are missing in this forum is that Python is probably the most extensible language out there

Is there something available for Python like the Inline:: modules for Perl? These are modules which make it possible to stick C, C++ or Python right in the middle of Perl code. What would be really cool is if there is a way to hook up Python with any of the thousands of Perl modules which exist out there. One of the nicest thing about Perl is CPAN, a huge online repository of Perl modules for doing just about everything. It would be cool if a Python script can access, say, Perl's Net::AIM module (which provides a nice class interface to AOL Instant Messenger protocol).

Python and Perl are both really nice languages. Anyone who's never used them should give them a try. For certain tasks, it's amazing how much faster you can do things in comparison to, say, C++ or Java or VB. (But every language has its place; I don't believe the "one language fits all" claims that people sometimes make).

Python vs Perl is largely down to personal preference, and what code/modules are currently available that you can build on top of.

But, FYI, Perl has a coupla thousand killer apps, most of which are available on CPAN.

Industry Standards include:

• CGI
• LWP
• DBI
• AxKit
• mod_perl
• and, of course, slash

The Beatles never flamed the Stones. The Stones never dissed the Beatles. And at no time did either party rip on Bob Dylan or badmouth Marvin Gaye. Language designers should celebrate their brethren. Particularly when the similarities so overwhelmingly outnumber the differences.

Perl is worse than Python because people wanted it worse. Larry Wall, 14 Oct 1998

Frankly, I'd rather not try to compete with Perl in the areas where Perl is best -- it's a battle that's impossible to win, and I don't think it is a good idea to strive for the number of obscure options and shortcuts that Perl has acquired through the years. Guido van Rossum, 7 Jul 1992

When I originally designed Perl 5's OO, I thought about a lot of this stuff, and chose the explicit object model of Python as being the least confusing. So far I haven't seen a good reason to change my mind on that. Larry Wall, 27 Feb 1997 on perl5-porters

If Perl weren't around, I'd probably be using Python right now. Tom Christiansen in comp.lang.perl, 2 Jun 1995

Python is an excellent language for learning object orientation. (It also happens to be my favorite OO scripting language.) Sriram Srinivasan, Advanced Perl Programming

But, FYI, Perl has a coupla thousand killer apps, most of which are available on CPAN.

Industry Standards include:

• CGI
• LWP
• DBI
• AxKit
• mod_perl
• and, of course, slash

The Beatles never flamed the Stones. The Stones never dissed the Beatles. And at no time did either party rip on Bob Dylan or badmouth Marvin Gaye. Language designers should celebrate their brethren. Particularly when the similarities so overwhelmingly outnumber the differences.

Perl is worse than Python because people wanted it worse. Larry Wall, 14 Oct 1998

Frankly, I'd rather not try to compete with Perl in the areas where Perl is best -- it's a battle that's impossible to win, and I don't think it is a good idea to strive for the number of obscure options and shortcuts that Perl has acquired through the years. Guido van Rossum, 7 Jul 1992

When I originally designed Perl 5's OO, I thought about a lot of this stuff, and chose the explicit object model of Python as being the least confusing. So far I haven't seen a good reason to change my mind on that. Larry Wall, 27 Feb 1997 on perl5-porters

If Perl weren't around, I'd probably be using Python right now. Tom Christiansen in comp.lang.perl, 2 Jun 1995

Python is an excellent language for learning object orientation. (It also happens to be my favorite OO scripting language.) Sriram Srinivasan, Advanced Perl Programming

.. it's so portable, it will even run under perl - Inline::Python ;-)

If you're interested in quantum computing, try to check out Damian Conway's talk on the Perl module Quantum::Superpositions. It's very funny and actually quite useful!

Damian is travelling around the world talking to perl user groups. Check out his schedule to see if he's due to talk near you.