I think it is highly plausible that if there was some sort of contact with not-of-this earth beings and technology that the government would hide it, and try to take whatever they could for military advantage. Some of the reports I've read about secret budgets and groups seems highly plausible to me.
If the aliens are so smart and have such a military advantage... why the hell do they let the government push them around? I wouldn't even put up with airport security if I had advanced weaponry!
Not only did I RTFA, I have been following the threads from the start.
My apologies, shouldn't have been so quick with that.
There was zero obfuscation.
Some, but nobody has even touched a disassembler yet. That requires quite a bit more skill than looking at hex dumps and implementing AES from specs.
You could write an alternative implementation of AES that does not use keys in the normal form, but directly uses obfuscated values. You can make sure values are kept in registers and the entire key is never present. These can be defeated, but it takes a large amount of work with a debugger and disassembler to trace and re-create the algorithms from the machine code. This is a much harder task, and the pool of people who have the skills to do it, and the willingness, shrinks quickly.
As I read it, the WinDVD software definitely obfuscated the key... in time rather than in memory. There was only a brief execution time window in which it was in the clear. What you're proposing is some kind of obfuscation in terms of deviating from the official spec's straightforward AES algorithm. I agree that would make things more difficult, you'd have to disassemble to find out what the modified algorithm is doing differently.
Certainly would be more difficult, I'm not sure if the folks involved would be any less determined though.
I feel that as the DRM gets more and more complex, the prestige and economic value of cracking it goes up. So bigger and better people will get drawn to the challenge of cracking it. I mean... if AACS went uncracked for a year or two, I think we'd see some pirate-DVD companies in Asia actually *paying* hackers to work on it. (I don't want it to sound like I'm supporting large-scale piracy, but I think the economic incentive for those people would inevitably cause them to invest in cracking efforts.)
Read doom9, the rest of this/. thread, http://www.freedom-to-tinker.com/?p=1122, etc. It's quite puzzling that the manufacturers haven't yet used the full AACS spec.
It might, but it still wouldn't help the fact that as soon as they got the keys, they would be revoked, negating the usefulness of the attack.
Actually, if per-player keys became the norm, the AACS crackers would stop releasing device keys (the most powerful) and start releasing processing keys instead. Those can't be definitely traced to individual devices or models, since every device has a large subset of them. With a big enough pool of processing keys available, a software program could basically emulate an authorized device...
Or they could just use the cracked device to crack a big pile of discs, and release the keys for the individual discs.
Nope. Hardware players can be individually revoked.
Only in theory... the manufacturers don't yet implement the full AACS spec which would allow this.
Furthermore, if hardware players had completely individualized keys, then this would open up new vulnerabilities. The individualized keys would of necessity be stored in Flash or EEPROM, since the economies of scale required to manufacturer semiconductors inexpensively don't allow fabricating unique ASICs for each player.
This would, of course, help hackers narrow down the location of the hardware keys in the system.:-P
Will they really? I don't know the algorithm, so I may be talking out my ass, but is there any reason the entire key HAS to be in memory all at one time?
No, you could trivially devise an algorithm that didn't require the entire plaintext decryption key to be available at once. Just take an existing algorithm, double the key length, and use each half to decrypt half the data.
Is there any reason it can't encrypted, split and moved around, only to be streamed to where it needs to go?
Sure, but this does not increase security. It simply moves the weak point in the system from the decryption routines to the routines where the key gets divided up. Watch those algorithms, and you'll get the key.
All DRM is obfuscation. This is just more obfuscation...
Who the hell cares WHERE the key is kept? You want flipping bits and all that crap? It's been done in CSS with DVDs... look how well that turned out. *ALL DRM IS OBFUSCATION*
The key will have to be in memory, but there is no reason for it to be unobfuscated. Any kind of simple obfuscation will stop the kind of attack used here. Sure, somebody can start reverse engineering the code to work out the obfuscation, but that takes a lot more skill and time than what these people have spent. It cuts down the number of people who can and are willing to do the work considerably.
Did you RTFA? The folks who've accomplished this already got around a decent amount of obfuscation. They are determined and obviously have some coding skills. A couple more layers of obfuscation would be just another few weeks' or months' delay.
ALL DRM IS OBFUSCATION! The decryption keys must inevitably be revealed to the firmware/software, and it is at this point that they can be intercepted. How many times do I have to say this? *Sigh*
If you're going to require an internet connection, what's the point of the dongle? Just make the user verify the key in real time against the server for every play. This would already have been implemented if they thought users would stand for it. They won't.
Indeed. That was the premise of the original DIVX, which were basically throwaway DVDs that had an additional layer of encryption, and the player hardware would make a phone call to get the key to play the disc.
I remember when Circuit City was pushing those left and right... 1999?
But the biggest thing that turns me off from Ruby is the fact that the "print string" command is called "puts". It's also a Yiddish slang term for "penis", "idiot", or "fooling around".
Yes, you can simply put your swap partition on a flash device as opposed to the hard disk. An experienced Linux user can do this in a few seconds at the command line, and it wouldn't be hard to automate it with a HAL script if anyone thinks it's worthwhile.
Does Linux automatically optimize application startup based on the last five logon sessions? (I'm not trying to be a smart ass here, I'm really curious. And if it doesn't, why not?)
This is a feature I haven't seen in Linux, and it might be nice to have. Basically you'd want the Desktop Environment (GNOME/KDE) to keep track of the recently used apps, and preload them into memory on startup. I am actually kind of surprised that they implement this at the KERNEL level in Vista. It's something that can be done more elegantly in user-space. Linux tries not to clutter up the kernel with Desktop-type code.
By the way, Linux *does* do some vaguely similar things in the kernel. For pen sourceexample, it uses some heuristics to determine if a process is I/O bound or CPU-bound (see section 5.4.3 of http://josh.trancesoftware.com/linux/linux_cpu_sch eduler.pdf). It will schedule the I/O bound processes so that they get to run more frequently. This *really* helps with things like music player software. Under Windows, if I bog the CPU down Winamp will start skipping because it won't get CPU time often enough to keep the audio device buffer from emptying. But under Linux, even when I'm running a bunch of compiles and my web server is heavily loaded, the music keeps on playing smoothly in Rhythmbox because the scheduler has figured out what to do with it.
So, Windows certainly does a few interesting things. But none of them are that earth-shaking. And it's taken MS years to whip them out. On the other hand, a knowledgeable Linux hacker could code up one of Vista's enhancements in a day or two and the community would begin to comment on it and improve it. That's the power of free software.
I thought I would be interested in this article because I'm interested in the Linux kernel. But there's nothing particularly exciting about the Vista kernel, it seems. No interesting benchmarks, no off-color quotes by the developers, no wacky ideas about how to improve I/O performance. Reading about the Linux kernel on LWN or Kerneltrap is a lot more fun!
Well... this is yet another review of features I don't like in a product I don't want from a company I don't trust. *Yawn*
I'd like to get that album too, but the US version of the Puretracks site lists the whole BNL catalog as being available only in WMA infested with DRM:-(
I didn't say that! Perl definitely has more modules, CPAN is *huge*. Though Python includes more functionately, in a more polished and coherent form, in its standard library (everything from regular expressions to a complete standards-compliant subclass-able HTTP server with CGI support).
I use perl for the same reason I use debian. No matter what I want to do there's already a package to do it. It's the availablity of apps that makes an OS, and it's the availability of modules that makes a programming language. I have nothing against python, but until I can reasonably expect that there is a python module available for any given task I'll stick with perl.
I don't disagree... if I need to do something obscure, there are better chances of finding a Perl module than a Python module. But frankly, I haven't run into more than one or two such cases in nearly a year of using Python heavily now. I've found that when there *are* comparable modules, the Python one is typically easier to build and use (for example the Perl GPIB module vs PyVISA was a recent one, where Perl GPIB was a serious nightmare to get installed on Cygwin, while PyVISA Just Worked).
The only thing I can think of where I couldn't find a python module, was when I needed to read Intel HEX files (a fairly trivial file format). It only took me a few minutes to write such a thing in Python.
Yes, I'm aware of that:-P I was trying to give a very short example, and the objects returned by re.search are called "match objects". I wouldn't do that in a real program. *sheesh*
Strange, because I only know of one way to supply named parameters to a call, an anonymous hash. OK, to be fair, there may be more, but none of them are reasonable, and as such, that's really the only employed method you see with CPAN^H^H^H^H those 10,000+ modules.
I seem to recall that CGI.pm uses argument lists where positional and named parameters can be arbitrarily mixed, but the positional params always start with a dash. It's nice... but it's naturally Slightly Different From Every Other Way To Do It.
No that's brilliant - thanks for your opinion. A lot of people are pushing me for python, but I always figured it's reveared status for text processing/manipulation & wealth of existing scripts/implementations would mean perl would win hands down.
I had the same misconception! Turns out it's not much harder to do regexp stuff in python than in Perl:
PERL ---- $foo =~ s/bar/baz/;
if ($foo =~/bar(...)) { print $1 }
PYTHON ------ from re import *
replace(foo, 'bar', 'baz')
match = search(foo, 'bar(...)') if match: print match.group(1)
So... there's a little bit of extra boilerplate in Python, but that's it! For one-liners, Perl still wins, but for anything longer I think you'll appreciate the extra clarity of Python.
The best part is, the Python regexp syntax is an exact duplicate of the Perl syntax. The Python people made the decision to use the exact same syntax for the regular expressions as in Perl. A very smart decision I think. All my knowledge about \s and [A-Za-z] and (?:foo) transferred directly over with Python. Awesome!
Hmm, that seems a round-about way to do things. I presume you never happened to run into some of the nice features in Emacs python-mode, specifically python-shift-left and python-shift-right which will move the selected region left or right one python indent (that is, as many spaces as you have set for your block indentation in python-mode). Usually these are bound to "C-c " which lets you easily select a region (such as a pasted block) and move it to the correct indent level very quickly.
Wow! That does the trick nicely. Thank you very much, that makes things even easier. And who says you'll never learn anything on slashdot?
If only Python didn't require the use of whitespace for defining blocks. It is indeed tragic that an otherwise fine language is so goddamn retarded in that one aspect.
You know, it seems like *everyone* is put off by this aspect of Python at first. The first time I looked at it, it drove me nuts, and then I ignored Python for another two years.
But once I actually tried to write a program in Python, I found I didn't mind it one bit. Within a few hours my eyes didn't get confused by the lack of braces. I think it's actually easier on the eyes once you get used to it.
So I can't say, "don't knock it", because I've done that myself for sure. But do give Python another look, maybe play around with the tutorial for an hour or two.
That's a pretty common way of implementing objects in perl, but it is, of course, not the only way... The current thinking seems to be we should all switch to using "Inside-Out Objects" (briefly: object data is moved to class data, and the object only needs to be a unique id to pick out the correct values from the class data -- so you bless a scalar ref, and get a lightweight object which stringifies to a unique id). The point being that if you do things this way, you really *have* to use the accessors, you can't cheat and treat the object as a hash reference any more. Unfortunately, last I looked there was some argument about what precisely was the right way to do this (there's some issue with thread support), though the best publicized way of doing it certainly the one recommended by Damien Conway in his newish book "Perl Best Practices".
This is a pretty interesting idea. One thing is for sure, the Perl community has no shortage of interesting and thoughtful ideas about data structures and different ways of interacting with them. It makes for some good reading.
One problem I see with "inside out objects" is that they could wreak havoc on the ability to serialize Perl objects for persistent storage in a DB via freeze/thaw. All you'll end up storing is an index into a non-persistent table, unless yet-another-glue-module is written to provide for the serialization of such objects.
The Class::* modules do a pretty good job of standardizing appropriate interfaces to Perl objects, I think. But it seems that every *useful* high-level module uses a different subset of them:-(
But even things like renaming functions... different calling syntax can make it hard to grep for uses of a function, even. It's getting too ridiculous.
This was one of the things I noticed immediately when poking around in the Python standard library... it's quite easy to find where functions are called and defined. Just grep for "function\s*(" or "def function". It's always on one line. The parentheses are always there. It jumps out visually. Nice.
Our book of coding standards is getting so thick that we could be coding fucking Java instead, and feel liberated. It's madness.
ROTFLMAO
So, yes, you can do Perl for larger projects. It's possible. But you have to tie yourself down so badly, most of Perl's strengths as a language can't be used.
You've put your finger on it. Perl has many cool features, great strengths, and great depth. But it gives you almost no restrictions on how to combine them. Seductive, but not so good in the long run.
Now don't get me wrong, it's not so much the enforced importance of indentation. I always religiously indent my C code, and nothing is more obnoxious than finding half a dozen closing braces all at the same level of indentation. It's the absence of block-enclosing characters that I don't like. Block enclosing characters make it simple -- for humans and for machines -- to determine where a block begins and ends. With C, if I want to move a block of code I simply cut/paste it, hit my re-indent macro, and bam I'm done. With Python, I have to manually indent the block after I paste it, because for my macro to figure out what the new indention should be it also needs to know what the intended semantic meaning of the code is, because it would basically be deciding where the blocks begin and end. C explicitly encodes this information, so my macro doesn't have to figure anything out. Adding/removing a nested 'if' is a similarly annoying case.
Indeed, this is the only thing I mind about indentation in Python: it makes it hard to cut-and-paste code. Fortunately, Emacs has rectangle mode which I find very helpful in indenting a bunch of lines together all at once (C-x t SPACE SPACE SPACE SPACE ENTER to move them all 4 spaces forward, for example).
It's also hard to take Python code from web forums, since the indentation often gets lost in HTML, and you have to View Source to get them.
But I agree that it's a minor issue too, and in all other circumstances I have grown to enjoy the lack of curly braces.
The review says that the book uses the reader's knowledge of sed, awk, and grep. I figure: why not just use sed, awk, and grep...however, one advantage for Perl here is that (I presume) that line works with any Perl; '-i' is a GNU sed extension and may not work on non-GNU seds...
Indeed, you're completely right! After 6+ years of using Perl, I no longer use it for anything that sed/awk/grep can't do:-P
As I've said, Perl was great while it lasted. It's just that there are now better tools for everything it ever did well: sed/awk for super quick and dirty text munging, and Python for everything else.
(Of course there's also Ruby. I haven't tried Ruby, but my *totally uninformed* impression is that it's a lot less mature than Python, a little more Perl-ish, and the coolest thing on the block right now.)
Hehehe... ya got me! You know what's funny? I think that's the first time I've ever made that mistake. I'm a bit of a grammar Nazi normally. I'm off to do some self-flagellation now.
Indeed! I used to be a die-hard hard-core Perl hacker. When I discovered Perl in college around 2001, I thought it was the greatest thing since sliced bread. And Perl really was revolutionary: you could do almost everything you could do in C, but more concisely, since you could create complex data structures without manual memory management.
I used Perl for fun and profit (wrote many Perl scripts for a speech software company) for many years, hanging on past the point where others started using Python, PHP, and Ruby instead. I knew Perl and could practically think in it. But one of the main problems with Perl is it's so easy to right totally unmaintainable, totally unreadable code. I read a Perl program I wrote a few years ago and I can never figure it out. The object-oriented part of Perl is a ridiculous kludge with so many little details that I can't remember them all. There are about 100 subtly different ways to write a constructor for your object:
sub new() {
my ($class) = @_;
my $self = {}
return bless $self, $class }
sub new() { return bless {} }
sub new() {
my ($class) = @_
my $self = {}
bless $self, (ref $class || $class) }
All of these, of course, have subtly different behaviors. The second will break inheritance. The third will allow you to use the constructor as an instance method, not just a class method. There are no enforced function prototypes or standard way to get parameters... and if you do use the *optional* prototype mechanism, you will subtly change the precedence of calls to your function.
I thought that having 1000 ways to do something was great, but it turns out to be a nightmare for non-trivial programs. Every time I try to use a cute fancy shortcut in Perl, it bites me in the ass. As a result of the over-flexibility, people have tried to impose "standards" on Perl. There are "standard" techniques for named parameters, "standard" techniques for accessor functions, etc. And that's nice, but Perl has 10,000+ available modules to do everything from screen-scrape Google news to access Oracle databases (it's greatest strength!!!). And not all those modules use the standard techniques.
About a year ago I decided to give Python a try. And I haven't looked back. It can do everything Perl can do, and then some. Everything is clearer and having a "standard" way to do most things makes learning new modules immensely easier. Having slightly more verbose syntax and strict type-checking is slightly annoying at first, but keeps me sane in the long run.
Basically I don't use perl for anything other than one-liner regexp tricks anymore. Stuff like perl -i -pe 's/FOO/BAR/g' *, which will change the string FOO to BAR in all the files in the current directory.
Slashdot Mirror
If the aliens are so smart and have such a military advantage... why the hell do they let the government push them around? I wouldn't even put up with airport security if I had advanced weaponry!
Certainly would be more difficult, I'm not sure if the folks involved would be any less determined though.
I feel that as the DRM gets more and more complex, the prestige and economic value of cracking it goes up. So bigger and better people will get drawn to the challenge of cracking it. I mean... if AACS went uncracked for a year or two, I think we'd see some pirate-DVD companies in Asia actually *paying* hackers to work on it. (I don't want it to sound like I'm supporting large-scale piracy, but I think the economic incentive for those people would inevitably cause them to invest in cracking efforts.)
Read doom9, the rest of this
Actually, if per-player keys became the norm, the AACS crackers would stop releasing device keys (the most powerful) and start releasing processing keys instead. Those can't be definitely traced to individual devices or models, since every device has a large subset of them. With a big enough pool of processing keys available, a software program could basically emulate an authorized device...
Or they could just use the cracked device to crack a big pile of discs, and release the keys for the individual discs.
There's more than one way to skin a cat
Only in theory... the manufacturers don't yet implement the full AACS spec which would allow this.
Furthermore, if hardware players had completely individualized keys, then this would open up new vulnerabilities. The individualized keys would of necessity be stored in Flash or EEPROM, since the economies of scale required to manufacturer semiconductors inexpensively don't allow fabricating unique ASICs for each player.
This would, of course, help hackers narrow down the location of the hardware keys in the system.
No, you could trivially devise an algorithm that didn't require the entire plaintext decryption key to be available at once. Just take an existing algorithm, double the key length, and use each half to decrypt half the data.
Sure, but this does not increase security. It simply moves the weak point in the system from the decryption routines to the routines where the key gets divided up. Watch those algorithms, and you'll get the key.
All DRM is obfuscation. This is just more obfuscation...
Who the hell cares WHERE the key is kept? You want flipping bits and all that crap? It's been done in CSS with DVDs... look how well that turned out. *ALL DRM IS OBFUSCATION*
Did you RTFA? The folks who've accomplished this already got around a decent amount of obfuscation. They are determined and obviously have some coding skills. A couple more layers of obfuscation would be just another few weeks' or months' delay.
ALL DRM IS OBFUSCATION! The decryption keys must inevitably be revealed to the firmware/software, and it is at this point that they can be intercepted. How many times do I have to say this? *Sigh*
Indeed. That was the premise of the original DIVX, which were basically throwaway DVDs that had an additional layer of encryption, and the player hardware would make a phone call to get the key to play the disc.
I remember when Circuit City was pushing those left and right... 1999?
This is utterly juvenile...
:-P
But the biggest thing that turns me off from Ruby is the fact that the "print string" command is called "puts". It's also a Yiddish slang term for "penis", "idiot", or "fooling around".
Somehow I just can't take Ruby code seriously
Yes, you can simply put your swap partition on a flash device as opposed to the hard disk. An experienced Linux user can do this in a few seconds at the command line, and it wouldn't be hard to automate it with a HAL script if anyone thinks it's worthwhile.
This is a feature I haven't seen in Linux, and it might be nice to have. Basically you'd want the Desktop Environment (GNOME/KDE) to keep track of the recently used apps, and preload them into memory on startup. I am actually kind of surprised that they implement this at the KERNEL level in Vista. It's something that can be done more elegantly in user-space. Linux tries not to clutter up the kernel with Desktop-type code.
By the way, Linux *does* do some vaguely similar things in the kernel. For pen sourceexample, it uses some heuristics to determine if a process is I/O bound or CPU-bound (see section 5.4.3 of http://josh.trancesoftware.com/linux/linux_cpu_sc
So, Windows certainly does a few interesting things. But none of them are that earth-shaking. And it's taken MS years to whip them out. On the other hand, a knowledgeable Linux hacker could code up one of Vista's enhancements in a day or two and the community would begin to comment on it and improve it. That's the power of free software.
I thought I would be interested in this article because I'm interested in the Linux kernel. But there's nothing particularly exciting about the Vista kernel, it seems. No interesting benchmarks, no off-color quotes by the developers, no wacky ideas about how to improve I/O performance. Reading about the Linux kernel on LWN or Kerneltrap is a lot more fun!
Well... this is yet another review of features I don't like in a product I don't want from a company I don't trust. *Yawn*
I'd like to get that album too, but the US version of the Puretracks site lists the whole BNL catalog as being available only in WMA infested with DRM :-(
I didn't say that! Perl definitely has more modules, CPAN is *huge*. Though Python includes more functionately, in a more polished and coherent form, in its standard library (everything from regular expressions to a complete standards-compliant subclass-able HTTP server with CGI support).
I don't disagree... if I need to do something obscure, there are better chances of finding a Perl module than a Python module. But frankly, I haven't run into more than one or two such cases in nearly a year of using Python heavily now. I've found that when there *are* comparable modules, the Python one is typically easier to build and use (for example the Perl GPIB module vs PyVISA was a recent one, where Perl GPIB was a serious nightmare to get installed on Cygwin, while PyVISA Just Worked).
The only thing I can think of where I couldn't find a python module, was when I needed to read Intel HEX files (a fairly trivial file format). It only took me a few minutes to write such a thing in Python.
Yes, I'm aware of that :-P I was trying to give a very short example, and the objects returned by re.search are called "match objects". I wouldn't do that in a real program. *sheesh*
I seem to recall that CGI.pm uses argument lists where positional and named parameters can be arbitrarily mixed, but the positional params always start with a dash. It's nice... but it's naturally Slightly Different From Every Other Way To Do It.
I had the same misconception! Turns out it's not much harder to do regexp stuff in python than in Perl:
PERL
----
$foo =~ s/bar/baz/;
if ($foo =~
PYTHON
------
from re import *
replace(foo, 'bar', 'baz')
match = search(foo, 'bar(...)')
if match: print match.group(1)
So... there's a little bit of extra boilerplate in Python, but that's it! For one-liners, Perl still wins, but for anything longer I think you'll appreciate the extra clarity of Python.
The best part is, the Python regexp syntax is an exact duplicate of the Perl syntax. The Python people made the decision to use the exact same syntax for the regular expressions as in Perl. A very smart decision I think. All my knowledge about \s and [A-Za-z] and (?:foo) transferred directly over with Python. Awesome!
Wow! That does the trick nicely. Thank you very much, that makes things even easier. And who says you'll never learn anything on slashdot?
You know, it seems like *everyone* is put off by this aspect of Python at first. The first time I looked at it, it drove me nuts, and then I ignored Python for another two years.
But once I actually tried to write a program in Python, I found I didn't mind it one bit. Within a few hours my eyes didn't get confused by the lack of braces. I think it's actually easier on the eyes once you get used to it.
So I can't say, "don't knock it", because I've done that myself for sure. But do give Python another look, maybe play around with the tutorial for an hour or two.
Similarly, the C-x r k command will delete an entire rectangle of spaces. I use that frequently to de-indent whole regions of code. Hope that helps.
This is a pretty interesting idea. One thing is for sure, the Perl community has no shortage of interesting and thoughtful ideas about data structures and different ways of interacting with them. It makes for some good reading.
One problem I see with "inside out objects" is that they could wreak havoc on the ability to serialize Perl objects for persistent storage in a DB via freeze/thaw. All you'll end up storing is an index into a non-persistent table, unless yet-another-glue-module is written to provide for the serialization of such objects.
The Class::* modules do a pretty good job of standardizing appropriate interfaces to Perl objects, I think. But it seems that every *useful* high-level module uses a different subset of them
You've put your finger on it. Perl has many cool features, great strengths, and great depth. But it gives you almost no restrictions on how to combine them. Seductive, but not so good in the long run.
Indeed, this is the only thing I mind about indentation in Python: it makes it hard to cut-and-paste code. Fortunately, Emacs has rectangle mode which I find very helpful in indenting a bunch of lines together all at once (C-x t SPACE SPACE SPACE SPACE ENTER to move them all 4 spaces forward, for example).
It's also hard to take Python code from web forums, since the indentation often gets lost in HTML, and you have to View Source to get them.
But I agree that it's a minor issue too, and in all other circumstances I have grown to enjoy the lack of curly braces.
Indeed, you're completely right! After 6+ years of using Perl, I no longer use it for anything that sed/awk/grep can't do
As I've said, Perl was great while it lasted. It's just that there are now better tools for everything it ever did well: sed/awk for super quick and dirty text munging, and Python for everything else.
(Of course there's also Ruby. I haven't tried Ruby, but my *totally uninformed* impression is that it's a lot less mature than Python, a little more Perl-ish, and the coolest thing on the block right now.)
Hehehe... ya got me! You know what's funny? I think that's the first time I've ever made that mistake. I'm a bit of a grammar Nazi normally. I'm off to do some self-flagellation now.
I used Perl for fun and profit (wrote many Perl scripts for a speech software company) for many years, hanging on past the point where others started using Python, PHP, and Ruby instead. I knew Perl and could practically think in it. But one of the main problems with Perl is it's so easy to right totally unmaintainable, totally unreadable code. I read a Perl program I wrote a few years ago and I can never figure it out. The object-oriented part of Perl is a ridiculous kludge with so many little details that I can't remember them all. There are about 100 subtly different ways to write a constructor for your object:
sub new() {
my ($class) = @_;
my $self = {}
return bless $self, $class
}
sub new() { return bless {} }
sub new() {
my ($class) = @_
my $self = {}
bless $self, (ref $class || $class)
}
All of these, of course, have subtly different behaviors. The second will break inheritance. The third will allow you to use the constructor as an instance method, not just a class method. There are no enforced function prototypes or standard way to get parameters... and if you do use the *optional* prototype mechanism, you will subtly change the precedence of calls to your function.
I thought that having 1000 ways to do something was great, but it turns out to be a nightmare for non-trivial programs. Every time I try to use a cute fancy shortcut in Perl, it bites me in the ass. As a result of the over-flexibility, people have tried to impose "standards" on Perl. There are "standard" techniques for named parameters, "standard" techniques for accessor functions, etc. And that's nice, but Perl has 10,000+ available modules to do everything from screen-scrape Google news to access Oracle databases (it's greatest strength!!!). And not all those modules use the standard techniques.
About a year ago I decided to give Python a try. And I haven't looked back. It can do everything Perl can do, and then some. Everything is clearer and having a "standard" way to do most things makes learning new modules immensely easier. Having slightly more verbose syntax and strict type-checking is slightly annoying at first, but keeps me sane in the long run.
Basically I don't use perl for anything other than one-liner regexp tricks anymore. Stuff like perl -i -pe 's/FOO/BAR/g' *, which will change the string FOO to BAR in all the files in the current directory.