I'm okay with people promoting Ruby to Java programmers, in the theory that Java isn't the be-all end-all of applications. However, I'm fairly not okay with amazingly stupid claims such as:
PHP and Perl haven't consistently produced readable code for larger applications.
What exactly does that even mean? Are PHP and Perl somehow preventing people from writing maintainable code? Does Ruby somehow enforce good design, good naming conventions, encapsulation, and consistent interfaces where PHP and Perl don't?
Okay, I've often pointed out that PHP has a lot of flaws that make it difficult to write and maintain applications beyond a few pages -- lack of namespaces, inconsistencies in the standard library, backwards incompatibilities, and weird syntax issues. However, the most important work is that of the programmer. Programming languages and libraries are just tools. If you're a deranged ape with no sense of design or style, of course you're not going to write maintainable code, whether PHP, Perl, Ruby, Java, Lisp, or even XSLT.
It's probably never going to happen, but a debate worth having is whether one language can be an order of magnitude more maintainable than another. Aside from the obvious non-contenders (Malbolge, BF, and Befunge, for example), are there any mainstream programming languages that really enforce any sort of meaningfully good style that actively prevents people from writing bad code? Frankly, Python's enforced indentation is a heck of a lot less useful than enforced meaningful identifiers.
Why are there so many unmaintainable applications written in PHP and Perl? Because PHP and Perl let undisciplined, inexperienced programmers write useful code. So does Ruby -- but give it the popularity and longevity of PHP and Perl (at least in English-speaking circles) and I bet you'll see plenty of bad code written in Ruby too.
This seems like a variant of the Hackers and Painters fallacy. (Paul Graham is rich. Paul Graham writes Lisp. Therefore everyone who writes Lisp will get rich.) "All of the good, smart programmers I know are using Ruby. They write good code. Therefore you can't write bad code in Ruby!"
It feels like there's another fallacy in there somewhere. I want to call it the Pre-Post-Java Blindspot, where Java was the beginning of Serious Programming Languages and only its successor will unseat it. (Like any good fallacy, you have to ignore history, such as the fact that Ruby's between 10 and 12 years old.)
(I mean, if you really just can't read regular expressions, why not admit it? You could start a twelve-step program or something.)
The whole readability issue would make more sense if they were talking about Python. Python at least makes an attempt to eliminate TMTOWTDI, which is an active attempt to make it more maintainable (although it may be misguided, depending on who you ask).
I just have to assume that most of these people have never seen a good program written in Perl. They probably only know it from hacky admin scripts and the like.
Re:It's a strange tactic to take when promoting Ru
jjq on 2005-11-19T16:04:18
You might care to take a look at:it builds on Chromatic's view that the quality of a program rests with the skill of the programmer and not the choice of programming language. Again, it has a pop at Ruby in this regard.The drink-me document also shows how it is possible to combine perl-python-ruby re-entrantly, using program folds, and so there is no point squabbling over which language is best. When push comes to shove: a program is just a bunch of characters in a file. And if we're mindful of the Hackers and Painters syllogism, we realise that few programmers have what it takes to produce Shakespearian code; I certainly don't.
Now when I wrote the drink-me document, back in 2002, I was careful to include a section "people in glass houses
..." for I am well aware that the literate-programming route I am proposing to improve code-readability is not without its own weaknesses. Moreover, if you do go to the trouble of downloading an AMRITA kit you will see that its Perl implementation is not pretty. Large parts of it date back to 1996 and were written in Perl 4, and over the intervening years, bits of Perl 5 have been tacked on, and on. It clearly needs to be rewritten from the ground up, but I don't have the time, or energy to do so. Nevertheless, if you take a look at:
you will see that the system is capable of producing some nifty interactive listings, where a code-author can lead a code-reader through the construction of a program. Again, the approach is not without its weakeness. But as a technology demonstrator, it shows that there are avenues to explore, for improving code-readability, that transcend today's Orwellian mentality: "perl bad, python good, ruby best."
I seem to remember that Ruby used to be compared to Perl by using the statement "Ruby is an object-oriented Perl" or something close to that.
I have been programming Perl for 1 year now. I and those I work with can look at my programs and see what is going on. Just because Perl can be used to write ecclectic line noise, doesn't mean you have to. I made a decision when I started my Perl would not be unreadable.
Re:What Ruby has...
chromatic on 2005-11-19T07:35:49
Ruby does five things much better than Perl.
Ruby blocks are very convenient. There's a lot of goodness in making closure-passing simple, easy, and syntactically lightweight. There's also a tremendous amount of goodness from making the language core aware of such constructs.
The strong built-in object orientation gives Ruby a lot of power too. I credit Smalltalk. Though I'm still unsure how I feel about the looks the append operator in general, being able to declare objects that respond to it, or the subscripting operator, or whatever and using them in place of built-in objects as appropriate is very useful. Sure, Perl has
tie, but Ruby's approach is much better.Of course, having open classes by default -- even the built-ins -- is also amazingly useful.
Ruby's threads are easier to use than even Perl 5.8's threads. (I don't mean that sarcastically.)
Ruby's extension system is easier to use than Perl 5's extension mechanism.
Re:
Aristotle on 2005-11-19T23:56:36
“Ecclectic line noise” is my new favourite phrase.
my $self = shift;
my(@arg1, @arg2, @arg3) = @_;results = [anobject.some_call].flatten because ruby doesn't have context and the author of the framework I'm using didn't make the return signature of 'some_call' consistent across all subclasses... well... it's annoying.