Slashdot Mirror

That's why there's Mouse. And if that's still too large for you, there's Moo. And when even that's still to large, there's Mo

And you can select which one has the features you need, without the bits you don't care about ... but they've all got basically the same general API, so you can change it up as needed.

That's why there's Mouse. And if that's still too large for you, there's Moo. And when even that's still to large, there's Mo

And you can select which one has the features you need, without the bits you don't care about ... but they've all got basically the same general API, so you can change it up as needed.

when there's a perl module for that:

http://search.cpan.org/~jgamble/Games-Maze-1.08/lib/Games/Maze.pm

You cannot (last I checked) embed assembly snippets in any other major language.

Hooray for Perl's Inline::ASM module!

Take a look at Forks::Super. It's still a bit on the beta side, but useful enough for you to get real work done while you bang on the author to fix the remaining bugs. :)

Perl is very cumbersome in this regard.

It can be, yes. The last two times I needed multiprocessing, I used Proc::Fork and WWW::Curl::Simple. These worked very well for me.

A lot of people use AnyEvent quite effectively too.

Perl is very cumbersome in this regard.

It can be, yes. The last two times I needed multiprocessing, I used Proc::Fork and WWW::Curl::Simple. These worked very well for me.

A lot of people use AnyEvent quite effectively too.

Perl is very cumbersome in this regard.

It can be, yes. The last two times I needed multiprocessing, I used Proc::Fork and WWW::Curl::Simple. These worked very well for me.

A lot of people use AnyEvent quite effectively too.

The common::sense people claim it uses less memory than the combo, I'm currently using (mainly use strict; use warnings;), so I'm considering switching.

If anyone has any input about use common::sense; vs. use strict; use warnings;, I would like to hear it.

I can think of over 106,000 reasons to use Perl (and by the way, CPAN is still seeing very large numbers of both contributions and contributors).
     

Tell me: do you know of anybody working on compilers for Perl or PHP? When you do, let me know...

lol your Google-fu needs to improve. There is perlcc, available for a while although I have no clue if anyone is using it, but I do know Facebook is quite proud of their PHP compiler and they definitely use it. Yet another reason to not work at Facebook.

Also, it's not like compiling your code hopelessly obfuscates it. Several times over the last year I've had to disassemble C or C++ source code from an Android system to figure out how something works.

You're so wrong, it hurts. Perl 5* has had over 40 releases since 2009, count them: http://search.cpan.org/dist/perl/ Read the change documents for the supposed "frozen" language: http://p3rl.org/perl5100delta http://p3rl.org/perl5120delta http://p3rl.org/perl5140delta

Version 5.16 is coming next month, for FSM's sake!

* The name is not uppercased, see perlfaq1. With that misspelling, you just have revealed yourself as an outsider, or someone who did not pay attention what happened in the last 10 or so years. Ask yourself: If you cannot get the name of the language right, are you likely to have the correct perception of how Perl is developed, maintained and released, or insights into the community? Same with Rakudo.

Ruby is *not* basically Perl, I've used both for quite a while now. Ruby's concepts are much easier to comprehend and use in everyday coding.

That's a matter of opinion. I personally find Perl to be a better (more expressive) language for most tasks. Mostly I use Ruby (JRuby, specifically) when I have to write code that will run in a JVM, otherwise I default to Perl. RubyGems is nice, but it's still (at least) a decade behind CPAN. I'll grant you that Perl's learning curve is steeper than Ruby's, but I'll maintain that it's worth the effort.

Classes are not some weird afterthought that feels like it's falling apart every second now, they are first class members.

I'll give you that one for classic Perl OO. OTOH, Moose solves most of those complaints. Moose is basically a backport of Perl6's OO system, which is heavily influenced by Ruby's. This gives you pretty much everything you need to do serious OOP without having to drink the everything-is-an-object kool-aid.

The Perl interpreter is way quicker, which is nice,

Even nicer is the ability to use other (faster) languages inline once you've identified hotspots in your code through profiling. I am not aware of anything in Ruby that can compare to the simple elegance of Inline::C for this purpose.

there's sooo much unnecessary syntactic explicitness compared to Ruby.

Huh? Examples, please. "Syntactic explicitness" is NOT a complaint that's levied against Perl often.

You can write perl that looks like modem line noise, but you don't have to. Feature!

Specifically, it's a feature designed to let you write efficient one-liners. One-liner Perl is practically an entirely different language than 'application' Perl, and (IMHO) should be treated as such.

You don't have to make it hard to read or maintain, though some programmers do.

Even as a die-hard Perl programmer, I have to admit that Perl culture often encourages it. Perl Golf is an interesting intellectual exercise, but you shouldn't be playing it when writing production code. TIMTOWTDI is a powerful concept, but it gives you plenty of rope with which to hang yourself if you are undisciplined.

Adopting the mandatory use of perlcritic is a good first step towards managing Perl development. Perl Best Practices should be required reading for any modern Perl programmer.

I'm 15, I've been learning to program since I was 10 or so. I started in VB.net, and even though I kind of regret that now (ew, .NET) it was still a learning experience.
I've now moved on to Perl, and I absolutely love it. I'm teaching myself - I started with help from the great #perl channel on Freenode as well as my local LUG channel, and went from there. I'm still learning, and the best resource if you need to know something is definitely cpan.org.

Feel free to check out a little perl utility I wrote for creating aliases or shortcuts for remote ssh logins. If you have a lot of hosts to manage it can make your life easier:

http://www.cpan.org/authors/id/L/LD/LDAVIS/remote-ssh-access-1.7

Download the file, name it "remote-ssh-access". To read the perl documentation just use "perldoc remote-ssh-access"

No, I'm absolutely right.

Ok, these "problems" of which you speaketh:

1) No, only some map the model direct to disk. Oh, and except on one or two very primitive databases, views aren't mapped into a physical form on disk. MySQL only does so when you tell it to use a storage engine that allows you to map the model that way AND you configure it to. In the example you gave, you could use 1 table and 1 view (or, indeed, 1 table and 1 table-returning function) for almost every relational database out there. More sophisticated databases will let you generate an index from a function and order the table through an index. You still have the view/function, but you don't have to access anything through it for your example.

NoSQL databases can use any underlying structure (relational, hierarchical, flat file, object-oriented, etc), although they are more often coded as flat file. From Wikipedia:

Carlo Strozzi used the term NoSQL in 1998 to name his lightweight, open-source relational database that did not expose the standard SQL interface.

No, you don't lay them out. You have absolutely bugger all idea where Memcached or MungoDB has put your data - it could be in any file on any disk in any computer in the database structure.

2) SQL is nothing more than a wrapper. Not all existing relational databases use SQL. And those that do - well, which SQL are you referring to? ANSI? T-SQL? Some other kind?

SQL isn't, however, restricted to relational databases. Ingres is not a relational database, it is a star database. Ingres uses SQL. Well, at least as one option.

3) I've never had any problems refactoring a database live. But, then, I use design tools. Which prevent me from needing to refactor in the first place by making it easy to design things correctly to begin with. That's the great thing about being a software engineer/computer scientist/database admin/system admin -- I know all about the RASDIT methodology and know how to apply it in everyday activities. I pity the poor sods who try to code blind and have to do any refactoring at all. A good design is so easy to create, so easy to implement and a wondrous thing to maintain.

I thought I would share some info with you about how one team did this, what was cutting edge work at the time.
Not that I am saying you should use these tools although it seems they are one possibility.

Here are links related to a quite interesting software project developed by Christophe Mertz and others at CENA.

The Digistrips system was a user interface prototype demonstration system written in Perl for the design of new touch screen based air traffic controller systems that mimic the traditional system in which paper strips are used to represent aircraft in flight. The demonstration is said to have been successful, and there are a number of papers written about user interaction in the system.

It used Ivy (a cross platform message bus in Perl) and TkZinc (an OpenGL and 2d capable canvas).

Below are numerous links to papers and software sites although the openatc.org website is no longer in service itself. It is possible to download Ivy and TkZinc it seems.

keywords: cena france french aircraft controller prototype perl perl-anim gui prototyping tk-zinc opengl perl strips

Ivy Software Bus
http://www2.tls.cena.fr/products/ivy/
http://freecode.com/projects/ivy
http://www2.tls.cena.fr/products/ivy/download/desc/ivy-perl-deb.html
Ivy is a simple protocol and a set of open-source (LGPL) libraries and programs that allows applications to broadcast information through text messages, with a subscription mechanism based on regular expressions. Ivy libraries are available in C, C++, Java, Python and Perl, on Windows and Unix boxes and on Macs. Several Ivy utilities and hardware drivers are available too.
Ivy is currently used in research projects in the air traffic control and human-computer interaction research communities as well as in commercial products. It is also taught to CS students.

http://wiki.tcl.tk/9246
Christophe Mertz

Zinc.pm
http://search.cpan.org/~zincdev/tk-zinc-3.303/Zinc.pm
Patrick Lecoanet

http://search.cpan.org/~cmertz/svg-svg2zinc-0.05/svg2zinc.pl
though openatc.org is down.

TkZinc
http://www.tkzinc.org/tkzinc/index.php
http://freecode.com/projects/zincisnotcanvas
http://wiki.tcl.tk/2798
TkZinc is a Tk widget developed with Perl/Tk, Tcl/Tk and Python/Tk bindings. TkZinc widgets are very similar to Tk canvases in that they support structured graphics. Graphical items can be manipulated, and bindings can be associated with them to implement interaction behaviors. But unlike the canvas, TkZinc can structure the items in a hierarchy, and has support for affine 2D transforms. Clipping can be set for sub-trees of the item hierarchy and the item set is quite more powerful, including field-specific items for Air Traffic systems. TkZinc is fast enough to allow the implementation of 2k2k radar displays with smooth animations. It is structured enough to allow the implementation of direct manipulation desktop GUIs.

Since the 3.2.2 version, TkZinc also offers as a runtime option, support for openGL rendering, giving access to features such as antialiasing, transparency, color gradients and even a new, openGL oriented, item type : triangles. In order to use the openGL features, you need the support of the GLX extension on your X11 server.

Zinc Is Not Canvas!
Tkzinc has been developped at CENA to help building experimental user interfaces for Air Traffic Control. Tkzinc is a Tk widget, with Tcl, Perl/Tk, and Python/Tkinter bindings. Tkzinc is available as open source under the GNU Les

I thought I would share some info with you about how one team did this, what was cutting edge work at the time.
Not that I am saying you should use these tools although it seems they are one possibility.

Here are links related to a quite interesting software project developed by Christophe Mertz and others at CENA.

The Digistrips system was a user interface prototype demonstration system written in Perl for the design of new touch screen based air traffic controller systems that mimic the traditional system in which paper strips are used to represent aircraft in flight. The demonstration is said to have been successful, and there are a number of papers written about user interaction in the system.

It used Ivy (a cross platform message bus in Perl) and TkZinc (an OpenGL and 2d capable canvas).

Below are numerous links to papers and software sites although the openatc.org website is no longer in service itself. It is possible to download Ivy and TkZinc it seems.

keywords: cena france french aircraft controller prototype perl perl-anim gui prototyping tk-zinc opengl perl strips

Ivy Software Bus
http://www2.tls.cena.fr/products/ivy/
http://freecode.com/projects/ivy
http://www2.tls.cena.fr/products/ivy/download/desc/ivy-perl-deb.html
Ivy is a simple protocol and a set of open-source (LGPL) libraries and programs that allows applications to broadcast information through text messages, with a subscription mechanism based on regular expressions. Ivy libraries are available in C, C++, Java, Python and Perl, on Windows and Unix boxes and on Macs. Several Ivy utilities and hardware drivers are available too.
Ivy is currently used in research projects in the air traffic control and human-computer interaction research communities as well as in commercial products. It is also taught to CS students.

http://wiki.tcl.tk/9246
Christophe Mertz

Zinc.pm
http://search.cpan.org/~zincdev/tk-zinc-3.303/Zinc.pm
Patrick Lecoanet

http://search.cpan.org/~cmertz/svg-svg2zinc-0.05/svg2zinc.pl
though openatc.org is down.

TkZinc
http://www.tkzinc.org/tkzinc/index.php
http://freecode.com/projects/zincisnotcanvas
http://wiki.tcl.tk/2798
TkZinc is a Tk widget developed with Perl/Tk, Tcl/Tk and Python/Tk bindings. TkZinc widgets are very similar to Tk canvases in that they support structured graphics. Graphical items can be manipulated, and bindings can be associated with them to implement interaction behaviors. But unlike the canvas, TkZinc can structure the items in a hierarchy, and has support for affine 2D transforms. Clipping can be set for sub-trees of the item hierarchy and the item set is quite more powerful, including field-specific items for Air Traffic systems. TkZinc is fast enough to allow the implementation of 2k2k radar displays with smooth animations. It is structured enough to allow the implementation of direct manipulation desktop GUIs.

Since the 3.2.2 version, TkZinc also offers as a runtime option, support for openGL rendering, giving access to features such as antialiasing, transparency, color gradients and even a new, openGL oriented, item type : triangles. In order to use the openGL features, you need the support of the GLX extension on your X11 server.

Zinc Is Not Canvas!
Tkzinc has been developped at CENA to help building experimental user interfaces for Air Traffic Control. Tkzinc is a Tk widget, with Tcl, Perl/Tk, and Python/Tkinter bindings. Tkzinc is available as open source under the GNU Les

Here is the Perl shell documentation

Here is the documentation for Python's interactive shell

And let's not argue that there is a difference between a "shell" and an "interactive command-line interpreter".

Sorry I expected more than you prompted with the quote.

Running perl -Dx (perl must have been compiled with -DDEBUGGING ) dumps the Perl op code tree that perl compiles the script into. There is some discussion of the architecture, some discussion of the tree, a example walkthru and some documentation of the facility, as well as work using the system.

But it looks like (especially in the last several years) more "Perl call graph" work focuses on lexically parsing the Perl source. Which to me seems a great waste of this fascinating facility. Even though the graph is of a stack machine, not dataflow exactly, it seems like an interesting facility to target with a graph editor.

Unless of course his parents force fed him source code since he was an infant; which is probably the case if he is a real person.

Well, he is the son of this guy, who has been known to write some seriously gnarly code:

The source code is notoriously complex, a mark of the seriously ingenious Paul Kulchenko who created SOAP:Lite. As a result baffles most inexperienced Perl programmers, and indeed sends many of them running in shear terror. I myself am given the highest respect in my office for signing up to maintain the module for this fact alone - I work with some of the brightest and most experienced Perl programmers in the industry and they all look at SOAP::Lite in awe. And not the "good" kind of awe, the kind of awe that gives people a healthy, but fearful respect.

He didn't say he was inventing his own method at all. Your lack of education is showing; there are a plethora of cryptographically sound hashing libraries available. Please research the topic more thoroughly and review available resources such as Crypt::SaltedHash before attempting to dissuade others from following what was not only sound advice, but critical advice for folks who deal with legacy systems and don't even know about salting.

If you feel I'm somehow misguided on this topic, I'd encourage you to speak with folks like Schneier et al before attempting to mount a counter to the aforementioned statements.

There are some really good changes going into 5.14. Worth highlighting for anyone with Perl experience.

The Array/Hash reference mess has been greatly improved. You can now perform most builtin operations directly on array references. So no need to mess around with dereferencing things all over the place. This is a huge improvement in the syntax surrounding complex data structures.

The eval exception handling mess has been cleaned up so that error handling modules such as autodie can function properly without strange corner cases.

There are some really good changes going into 5.14. Worth highlighting for anyone with Perl experience.

The Array/Hash reference mess has been greatly improved. You can now perform most builtin operations directly on array references. So no need to mess around with dereferencing things all over the place. This is a huge improvement in the syntax surrounding complex data structures.

The eval exception handling mess has been cleaned up so that error handling modules such as autodie can function properly without strange corner cases.

A more readable changelog, with formatting, hyperlinks etc applied (rather than a raw pod file) can be seen here

If you're comfortable with Perl, it's definitely something you can bring with you to the Windows world. You can use Strawberry Perl with or without Cygwin. If you need to deploy code, you can use PAR::Packer's pp utility to wrap your script, its included modules, and the perl interpreter into a standalone executable.

Perl can do a ridiculous amount of stuff when you start using modules from CPAN. The Windows world is very GUI heavy, but a lot of things can be done using CPAN modules. Writing to Word docs. Controlling VMWare. Networking with just about every protocol you can think of. Creating GUI applications for others to use. There's also a nifty little module called Win32::GuiTest which will let you programmatically control GUI programs that don't provide a command line interface.

Good luck!

If you're comfortable with Perl, it's definitely something you can bring with you to the Windows world. You can use Strawberry Perl with or without Cygwin. If you need to deploy code, you can use PAR::Packer's pp utility to wrap your script, its included modules, and the perl interpreter into a standalone executable.

Perl can do a ridiculous amount of stuff when you start using modules from CPAN. The Windows world is very GUI heavy, but a lot of things can be done using CPAN modules. Writing to Word docs. Controlling VMWare. Networking with just about every protocol you can think of. Creating GUI applications for others to use. There's also a nifty little module called Win32::GuiTest which will let you programmatically control GUI programs that don't provide a command line interface.

Good luck!

DBD::WMI
Win32::OLE
Win32::WMIC
Win32::GuiTest
Win32::TieRegistry
Win32::Unicode
Win32::API
Inline::C
Perl::Dist::WiX
Win32::MSI::HighLevel
http://search.cpan.org/search?query=win32&mode=dist
http://roth.net/
http://books.perl.org/books
Perl Books - Book: Perl for System Administration
http://www.perl.com/
http://strawberryperl.com/
http://www.cava.co.uk/citrusperl/strawberry.html
google:// site:http://perlmonks.org/

DBD::WMI
Win32::OLE
Win32::WMIC
Win32::GuiTest
Win32::TieRegistry
Win32::Unicode
Win32::API
Inline::C
Perl::Dist::WiX
Win32::MSI::HighLevel
http://search.cpan.org/search?query=win32&mode=dist
http://roth.net/
http://books.perl.org/books
Perl Books - Book: Perl for System Administration
http://www.perl.com/
http://strawberryperl.com/
http://www.cava.co.uk/citrusperl/strawberry.html
google:// site:http://perlmonks.org/

DBD::WMI
Win32::OLE
Win32::WMIC
Win32::GuiTest
Win32::TieRegistry
Win32::Unicode
Win32::API
Inline::C
Perl::Dist::WiX
Win32::MSI::HighLevel
http://search.cpan.org/search?query=win32&mode=dist
http://roth.net/
http://books.perl.org/books
Perl Books - Book: Perl for System Administration
http://www.perl.com/
http://strawberryperl.com/
http://www.cava.co.uk/citrusperl/strawberry.html
google:// site:http://perlmonks.org/

DBD::WMI
Win32::OLE
Win32::WMIC
Win32::GuiTest
Win32::TieRegistry
Win32::Unicode
Win32::API
Inline::C
Perl::Dist::WiX
Win32::MSI::HighLevel
http://search.cpan.org/search?query=win32&mode=dist
http://roth.net/
http://books.perl.org/books
Perl Books - Book: Perl for System Administration
http://www.perl.com/
http://strawberryperl.com/
http://www.cava.co.uk/citrusperl/strawberry.html
google:// site:http://perlmonks.org/

DBD::WMI
Win32::OLE
Win32::WMIC
Win32::GuiTest
Win32::TieRegistry
Win32::Unicode
Win32::API
Inline::C
Perl::Dist::WiX
Win32::MSI::HighLevel
http://search.cpan.org/search?query=win32&mode=dist
http://roth.net/
http://books.perl.org/books
Perl Books - Book: Perl for System Administration
http://www.perl.com/
http://strawberryperl.com/
http://www.cava.co.uk/citrusperl/strawberry.html
google:// site:http://perlmonks.org/

DBD::WMI
Win32::OLE
Win32::WMIC
Win32::GuiTest
Win32::TieRegistry
Win32::Unicode
Win32::API
Inline::C
Perl::Dist::WiX
Win32::MSI::HighLevel
http://search.cpan.org/search?query=win32&mode=dist
http://roth.net/
http://books.perl.org/books
Perl Books - Book: Perl for System Administration
http://www.perl.com/
http://strawberryperl.com/
http://www.cava.co.uk/citrusperl/strawberry.html
google:// site:http://perlmonks.org/

DBD::WMI
Win32::OLE
Win32::WMIC
Win32::GuiTest
Win32::TieRegistry
Win32::Unicode
Win32::API
Inline::C
Perl::Dist::WiX
Win32::MSI::HighLevel
http://search.cpan.org/search?query=win32&mode=dist
http://roth.net/
http://books.perl.org/books
Perl Books - Book: Perl for System Administration
http://www.perl.com/
http://strawberryperl.com/
http://www.cava.co.uk/citrusperl/strawberry.html
google:// site:http://perlmonks.org/

DBD::WMI
Win32::OLE
Win32::WMIC
Win32::GuiTest
Win32::TieRegistry
Win32::Unicode
Win32::API
Inline::C
Perl::Dist::WiX
Win32::MSI::HighLevel
http://search.cpan.org/search?query=win32&mode=dist
http://roth.net/
http://books.perl.org/books
Perl Books - Book: Perl for System Administration
http://www.perl.com/
http://strawberryperl.com/
http://www.cava.co.uk/citrusperl/strawberry.html
google:// site:http://perlmonks.org/

DBD::WMI
Win32::OLE
Win32::WMIC
Win32::GuiTest
Win32::TieRegistry
Win32::Unicode
Win32::API
Inline::C
Perl::Dist::WiX
Win32::MSI::HighLevel
http://search.cpan.org/search?query=win32&mode=dist
http://roth.net/
http://books.perl.org/books
Perl Books - Book: Perl for System Administration
http://www.perl.com/
http://strawberryperl.com/
http://www.cava.co.uk/citrusperl/strawberry.html
google:// site:http://perlmonks.org/

DBD::WMI
Win32::OLE
Win32::WMIC
Win32::GuiTest
Win32::TieRegistry
Win32::Unicode
Win32::API
Inline::C
Perl::Dist::WiX
Win32::MSI::HighLevel
http://search.cpan.org/search?query=win32&mode=dist
http://roth.net/
http://books.perl.org/books
Perl Books - Book: Perl for System Administration
http://www.perl.com/
http://strawberryperl.com/
http://www.cava.co.uk/citrusperl/strawberry.html
google:// site:http://perlmonks.org/

DBD::WMI
Win32::OLE
Win32::WMIC
Win32::GuiTest
Win32::TieRegistry
Win32::Unicode
Win32::API
Inline::C
Perl::Dist::WiX
Win32::MSI::HighLevel
http://search.cpan.org/search?query=win32&mode=dist
http://roth.net/
http://books.perl.org/books
Perl Books - Book: Perl for System Administration
http://www.perl.com/
http://strawberryperl.com/
http://www.cava.co.uk/citrusperl/strawberry.html
google:// site:http://perlmonks.org/

My fave is the one for Perl.

http://www.cpan.org/

Have you considered hiring good developers and then teaching them OO Perl? If your workplace uses Moose, for example, writing good OO Perl 5 is surprisingly easy and effective.

Ruby has tools such as rvm which lets you manage multiple versions...

So does Perl, with perlbrew.

Ruby also has a lot of the OO built in that you need Moose for in perl.

I use plenty of Moose features that Ruby doesn't have (and I find Perl's module and importing mechanism far more powerful than Ruby).

Most of the language features can fit in the average person's head at all times, allowing you to focus on writing cleaner code.

I don't believe that. Count the number of methods on core classes sometime.

Blocks make a lot of code less error prone, because a file open block will automatically cleanup and close the file when your code has finished.

Blocks are nice, but properly scoped lexical variables in Perl have this property as well. As a bonus, Perl gets lexical scoping right and readable, unlike both Python and Ruby.

How about no visibly defined function parameters...

That's a fair point until you use a module such as signatures or Method::Signatures.

object oriented features are stuck on with duct tape

Perl 5's default object system is basically Python's object system. Everything Python programmers complain about (explicit self) and everything Python programmers haven't figured out yet (the conflation of namespace and class with no distinguishing between function and method makes for fragile classes) is a misfeature shared between the two languages. Python offers little additional value there, and it suffers greatly when compared to Moose.

you have to have a deep understanding of the language to understand what's really going on when someone assigns between variables that have different [sigils]

You only have to be able to understand subject/verb agreement in a spoken language (and you don't even have to know the term "subject/verb agreement"). That's one of the first things the book Modern Perl explains. (You can download it for free if you like.)

huge numbers of built-in magic 2-character variable names that you can't remember without a cheat sheet.

I've written a lot of Perl 5 over many years, and I can think of two or three I ever use. I could get that down to one.

Two substantial criticisms are "reference syntax is ugly", which is true and "most tutorials explain the language poorly", which is why I wrote what I believe to be a better book.

How about no visibly defined function parameters...

That's a fair point until you use a module such as signatures or Method::Signatures.

object oriented features are stuck on with duct tape

Perl 5's default object system is basically Python's object system. Everything Python programmers complain about (explicit self) and everything Python programmers haven't figured out yet (the conflation of namespace and class with no distinguishing between function and method makes for fragile classes) is a misfeature shared between the two languages. Python offers little additional value there, and it suffers greatly when compared to Moose.

you have to have a deep understanding of the language to understand what's really going on when someone assigns between variables that have different [sigils]

You only have to be able to understand subject/verb agreement in a spoken language (and you don't even have to know the term "subject/verb agreement"). That's one of the first things the book Modern Perl explains. (You can download it for free if you like.)

huge numbers of built-in magic 2-character variable names that you can't remember without a cheat sheet.

I've written a lot of Perl 5 over many years, and I can think of two or three I ever use. I could get that down to one.

Two substantial criticisms are "reference syntax is ugly", which is true and "most tutorials explain the language poorly", which is why I wrote what I believe to be a better book.

How about no visibly defined function parameters...

That's a fair point until you use a module such as signatures or Method::Signatures.

object oriented features are stuck on with duct tape

Perl 5's default object system is basically Python's object system. Everything Python programmers complain about (explicit self) and everything Python programmers haven't figured out yet (the conflation of namespace and class with no distinguishing between function and method makes for fragile classes) is a misfeature shared between the two languages. Python offers little additional value there, and it suffers greatly when compared to Moose.

you have to have a deep understanding of the language to understand what's really going on when someone assigns between variables that have different [sigils]

You only have to be able to understand subject/verb agreement in a spoken language (and you don't even have to know the term "subject/verb agreement"). That's one of the first things the book Modern Perl explains. (You can download it for free if you like.)

huge numbers of built-in magic 2-character variable names that you can't remember without a cheat sheet.

I've written a lot of Perl 5 over many years, and I can think of two or three I ever use. I could get that down to one.

Two substantial criticisms are "reference syntax is ugly", which is true and "most tutorials explain the language poorly", which is why I wrote what I believe to be a better book.

search.cpan.org states that there are 88,679 modules in 21,580 module distributions. It further says there have been 63,291 uploads by 8659 uploaders (authors).
Perl also has over 600 modules in the core distribution (as of 5.12.2 anyway).

On CPAN, a "module" is a module, and that's what it sounds like. A module is a program library that can be used by an application programmer. A module distribution is several related modules in a package. Some packages contain dozens of modules. Some may also contain example applications or helper applications along with the modules. PyPi also has packages which can be collections of modules. I don't mess with Python enough to tell you if that's common.

So, RubyGems has over 18,00 "gems", but what does that mean?

On RubyGems, it seems a "gem" can be anything. There are libraries there, sure. There are also applications. One, for example, is "vmail", which is a hack to let you read your GMail account in vim (using lynx for HTML mail viewing). Another is "rake", which is a software build program. You do have big frameworks pushed out as gems like "rack". There are smaller library modules that look useful, too. Then there's some stuff with no docs, no home page, and no apparent use. I found one "gem" that claims to redefined '==' to be more useful than in the standard library, but was all of 4 lines with no documentation.

RubyGems seems to have no real organization other than new, recently updated, popular, and alphabetical. There is a search.

CPAN and PyPi both have hierarchies of topics through which one can drill down. They have search, too. PyPi has probably the best combination of search and drill-down features of the three.

CPAN has some things it's pretty clear RubyGems doesn't. It has an automated build and test system for modules. It has a ticketing system for the modules right there in the public repository. It has a rating system for the packages. It has 228 mirrors worldwide for downloading the packages, too.

Okay..
http://search.cpan.org/~ascope/Net-Google-1.0/lib/Net/Google.pm

At least the JEB idiots got it out the door.

Permit me to introduce you to the CPAN.

Clicked enter for some reason:

Here is the module: http://search.cpan.org/~jmadler/Acme-LeetSpeak-0.01/lib/Acme/LeetSpeak.pm

I wonder if there's an opensource project to create and manage extended attributes on supporting filesystems?

http://www.freedesktop.org/wiki/CommonExtendedAttributes

But you're likely to get better results from having filenames be a field in a DB, and let all the metadata live in other DB fields..

ps: here's a CPAN entry that manipulates extended attributes: http://search.cpan.org/dist/File-ExtAttr/lib/File/ExtAttr.pm