This post, “14 descriptive reasons why Ruby may be better than PHP,” popped up on PHPDeveloper.org yesterday. These types of lists appear regularly in the blogosphere. I usually don’t feel compelled to respond, but for some reason this time I do. Perhaps it is the cool graphics. Perhaps it is because I just wanted to blog.
Speaking as someone who has done a lot of PHP, and very little Ruby or Rails, overall, I agree with the article. It talks about many of the reasons I wish I could start using Ruby more. However, I would like to refute a few particular items in the list. I’ll just cover each one with my input.
1. Human-readable code.
Yukihiro Matsumodo wanted to create a language that was designed for programmer functionality. By keeping naming consistent and keywords sensible, he was able to do so.
Agree. I think this is more of a result of the object-oriented features of Ruby than anything else, but the names and keywords are indeed nice.
2. Principle of least surprise
it is designed in such a way that the language minimizes confusion for experienced users. Methods for different objects, if they do the same task, are generally named and capitalized the same way. This makes it less necessary to constantly refer to the documentation, which leads to faster coding.
Agree. The inconsistencies in PHP names are well-documented.
3. Community maturity
The community is better able to give concise, coherent answers since the community is a little more learned. As it is generally not a first language the people in the community already have experience coding and helping others.
Disagree. I can’t tell if he is in fact boasting that the Ruby community is in general smarter, but the PHP community includes some of the brightest and veteran software developers in the world. It is also one of the most diverse, in terms of skillset, and thus is also one of the most welcoming and open technology communities around. Maybe he means that diversity is a disadvantage, which I also would disagree with. Anecdotally, the Ruby community is often perceived of as elitist and prone to groupthink. I believe that these are qualities of a very immature community, one that has not healthily fragmented or penetrated the corporate world. The PHP community is older and has experienced this fragmentation, which seems to be exactly what the author is criticizing. Just wait, Ruby. Just wait.
Creating a web application complete with database is as easy as typing in a few simple commands. The web app framework community for PHP, on the other hand, is fragmented and far less organized.
Basically agree. It is true that Ruby as a whole has embraced a single framework thus enjoying the advantages that have resulted. Would PHP have enjoyed the same benefits had it settled on a single framework early on? Impossible to know. I predict that over time, the Ruby web frameworks will become fragmented and less organized as well.
5. Objected Oriented Programming
Ruby was initially designed to be object-oriented. Robust, organized programs are easier to create with an object oriented language.
Basically agree. It is of course possible to write very good object-oriented code in PHP, but Ruby provides less rope to hang yourself with.
6. ActiveRecord design
using Rails, it is possible to map database records/tables to objects, which makes creating and handling persistent data extremely easy.
Basically agree. Like point #4 above, there are plenty of good ActiveRecord libraries for PHP, but having a single, agreed-upon ORM to go with your single, agreed-upon MVC framework lends many advantages.
7. Easier to install
Gem makes it extremely easy to download and install different frameworks and applications to use in your code. PHP, however, makes you find, download, install, and configure all extensions yourself.
Disagree. This should not even be on this list. I see no real advantages of
pear. Furthermore, I have seen some really hairy gem problems involving paths and multiple installations.
The model view controller architecture is a common system that all software engineers use. Rails is designed around this concept, so it gives future maintainers of your project an advantage when trying to understand your code.
Basically agree. See points #4 and #6 above. As I type this, points #4, #6, and #8 could be combined into a single item.
9. JVM support
Whenever there is a JVM installed, you can use JRuby to run your programs. You can also integrate your project into a Java application if you would like. This is especially useful if you are already writing a large application in Java, and are just looking for a scripting language to augment some functionality.
10. Formal namespaces
Organizing code is much easier when you can group classes into namespaces.
Disagree. PHP 5.3 fully supports namespaces. Personally, I have always questioned the value of namespacing. It always seemed more confusing to have identically named entities in different namespaces than to just prefix them and call them different things – which is what you have to do in PHP 5.2.
11. Pre-installed on certain operating systems
It ships with OSX 10.5 (Leopard), so you can get started coding immediately.
Disagree. It sounds like he is referring to local installations, and not deployed installations, but in either case I would disagree. OSX comes with PHP as well. And PHP comes installed on every Linux distro currently made, so I really don’t understand this one at all. If he is referring to deployed installations, PHP is still installed on more hosting environments than any other language, and it is easier to get running than any other language. Passenger is slowly mitigating this situation, but PHP still is in front.
12. Interactive shell
It comes default with a robust interactive shell that makes it easy to experiment with code. Instead of typing out some code, saving it to your sever, opening up your internet browser, and navigating to your page, you can just open up the console and type.
Agree. PHP has
`php -a`, but it is no where near as usable as IRB.
Less code (assuming the complexity is the same) means there is less to get confused about. Forcing MVC on you (through Rails) also helps developers maintain your code. Unit testing has also been tightly integrated from the beginning of the language, so it is more convenient to create/use unit tests for regression tests.
Basically agree. I am now combining points #4, #6, #8, and #13.
14. Everything is an object
Not having primitives makes code easier to handle. Instead of making sure something is an object and then executing it’s methods, one can just execute the method.
Agree. If you start treating everything as an object, your business model starts becoming cleaner. I’d much rather write
“hello world”.lower than
Right about now is when I might conclude with: “every situation is different and the proper solution depends on your particular requirements, blah, blah, blah.” I basically agree with that statement, but in my experience, it is missing the point.
In my experience, one can pretty much do anything with one platform that one can do with another. One (web) technology may be faster or easier, but in the end, it’s all just web. In my experience, most people are not equally strong in more than one platform. Most people are stronger in one language, even if it is because it is the language most recently used.
So back to the “every situation is different…” statement. The particular requirements are usually, how can I make the business money? Then, the proper solution becomes: by using the platform I know the best, and that is already running, formal namespaces be damned.