(Before anyone follows-up with the usual "the right tool for the job", it's not the point here. There are good screwdrivers and bad screwdrivers).
(Before anyone follows-up with the usual "the right tool for the job", it's not the point here. There are good screwdrivers and bad screwdrivers).
I hear this a lot about Python. And I know a little bit about Python; I know less about ruby. But the thing of it is, from a SysAdmin perspective, Python is where Perl was in 2000. In 2000, you had differing versions of perl that were close enough to step on oneanother, but still so incompatible that you had to maintain one version of perl for your base OS tools, and usually another version of perl for every major application you used.
Perl has stabilized to the point where this is no longer a problem. I can run nearly everything on system perl without worrying about it. Python, on the other hand, I've had to wrangle with many RHEL systems that have two versions of python (one, because the RHEL base system requires a staggeringly ancient version of python, and then the other for the application the server was running.)
Python just isn't "done" in the way perl is. In five or ten years, sure. But for now, it's still a pain in the ass.
Hell, I'd bet money that at this point, perl5 has fewer memory leaks and other programming errors in the compiler than Ruby does, just because people have been pounding on it for so long.
Just because you had a bad experience with Python legacy code (yes, RHEL sucks), doesn't mean you get to discredit the language. What is it about the language you find unfinished? I'd be 99% certain any issue you're going to mention is actively being worked on.
(Hint: I don't think the grandfather comment was about Python 3.)
And different languages doesn't say much. :-)
Perl 6, compared to e.g. Python 2/3, is a really ambitious undertaking. But OK, with the backporting going on, Perl 5 might end up being similar to Perl 6... :-)
Me, I'm not complaining about the large, predictable breakage you get when changing major versions, but the breakage that you got with minor versions of perl5 10 years ago, that you get with minor versions of python 2 today.
> Also, Ruby is a better language than Perl.
"Perl is the syntax, CPAN is the language"http://www.onyxneon.com/books/modern_perl/index.html
you can download the PDF for free:
http://www.onyxneon.com/books/modern_perl/modern_perl_letter...
http://www.onyxneon.com/books/modern_perl/modern_perl_a4.pdf
this book follows and introduces modern practices/modules developed by the Perl community in recent years.
Ruby still lacks in scalability and speed compared to Perl
Ruby is faster than Perl, according to the language shootout:http://shootout.alioth.debian.org/u32/which-programming-lang...
http://shootout.alioth.debian.org/u32q/which-programming-lan...
These graphs tell me
1. Perl is slightly faster. 2. Perl uses much less memory on average 3. Perl uses less code.
http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...
However, on Ruby18 you do have a substantially bigger problem:
http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
Lies, Damned lies.
It must be the spectacles you're looking through.
These graphs tell me that
- about the same number of Perl programs are faster than the Ruby 1.9 programs by about the same amount, as there are Ruby programs faster than Perl programs
- some of the Perl programs use half the memory of the corresponding Ruby 1.9 programs
- the Perl programs and Ruby 1.9 programs use about the same amount of code.
Only if you focus on a single number - the median - and ignore the complete overlap of the measurements shown by the boxplot and interquartile range.