Language War: PHP vs. Ruby

It's time; queue the "Going the Distance" theme from Rocky. In the red ring: Envato developer extraordinaire, Ryan Allen, who built the original FlashDen with his cold bare hands. In the blue corner: Michael Wales, a well known member in the PHP and CodeIgniter communities. The battle? PHP vs. Ruby. Fight!


Before We Begin

It must be noted that these sorts of debates are purely for fun and educational purposes. There are times when you'll choose PHP for a project, and there are times when you'd opt for Ruby. The goal of this series, however, is to learn how and when to make these sorts of decisions. Rather than "your language sucks," these debates are meant to outline why you might, in certain situations, choose one over the other.


The Contenders

Ruby: Ryan Allen

Ryan Allen

Ryan Allen is a web software and systems engineer who's been working for Envato since forever. He built and supported the early versions of the Envato Marketplaces in Ruby on Rails, and now looks after the Tuts+ systems, amongst other things.

PHP: Michael Wales

Michael Wales

Michael Wales is a web developer for US Government agencies, and is an active contributor to the PHP and CodeIgniter communities.


And...Begin!

1 - How familiar are you with both PHP and Ruby?

Ryan: PHP was one of the first programming languages I worked with (asides from ActionScript and some very brief Visual Basic). I began building things with PHP in 2001. I worked fairly exclusively with it as a backend tool until late 2005, when Ruby (and Rails) took its place.


Michael: PHP was my introduction to the world of web development, in 1999 – so I’d like to say I have a pretty solid understanding of its position within our industry, its history and the direction in which it is headed. Ruby, like many others, caught my eye with the release of Rails and the success of 37signals. I have a fairly solid understanding of Ruby, as a scripting language in my System Administration duties (Capistrano) as well as some personal and fun projects (the Gosu game development library and Rails). I’m ashamed to admit I’m not as familiar with Rails’ latest versions and it is definitely on my list of things to reacquaint myself with.


2 - Do you feel that your language is more suited to beginners or advanced users? For example, if I’m relatively new to the industry, would I have more trouble learning PHP or Ruby?

Michael: Unfortunately, I can’t give a definitive answer to this – at least not as you’re expecting, since PHP and Ruby are two entirely different beasts. PHP is an amalgamation of language and web framework in one package, whereas Ruby is a programming language with numerous frameworks available.

If your focus is web development and that’s all you really wanted to focus on right now, I would definitely advise you to learn PHP first.

So, if your focus is web development and that’s all you really wanted to focus on right now, I would definitely advise you to learn PHP first for a number of reasons:

  1. You don’t really need a solid understanding of System Administration or deployment best practices to learn and get things done. For virtually every host, you upload and you’re done.
  2. You’re going to gain a lower-level knowledge of how the web works; for example, how a request is passed between the client and server (as it pertains to your application), what functionality sessions provide, the limitations of cookies, the difference between the various request methods.
  3. On the Ruby side (and I’m going to assume the Rails framework, based on its immense popularity): deployment can be very difficult at times (although this is alleviated by services like Heroku, but then you miss out on the educational opportunities of understanding the low-level). I think this lack of low-level education is the ultimate downfall of Rails, from both a deployment standpoint as well a development standpoint – you can quickly and easily use sessions, cookies, create insecure and destructive controllers (via the GET request method). Not that you can’t do these things in PHP as well, but Rails actively promotes this knowledge.

As a developer with 12 years’ experience, I appreciate the shortcuts Rails brings to our industry; but, that is only because I understand what is actually going on behind the scenes.

If you want to become a developer (Web Developer, System Administration scripting, Game Developer, API Developer) who understands low-level Computer Science concepts, object-oriented programming and, in general, advance your Critical Thinking skills – it goes without saying, start with Ruby, it’s an actual programming language (remember, PHP is a web framework disguised as a language).

From a Web Developer perspective, I think this is also one of Ruby’s (and Python’s, BTW) downfalls – is that there really isn’t any “mid-level” entry point. You either understand the HTTP protocol, with the ability to write your own stack, top-to-bottom, or you go with one of the “magical, hold your hand to make a CRUD-system frameworks”.

This is really the area in which PHP shines. If you are stepping beyond the boundaries of CRUD, you don’t need to have an extreme understanding of how an HTTP server works to make your dreams a reality.


Ryan: If I were to teach someone programming from scratch, I’d prefer to teach them Ruby (trouble setting up environments aside – though this is getting easier). A common way to start someone off (after perhaps variables and printing them) is to explain arrays with, say, a shopping list example, take this bit of PHP:

When I learnt PHP, I was taught to use for loops (as I was in ActionScript), when a more succinct and less error-prone foreach loop already existed (as it also did in ActionScript). I had to learn all about this $i = 0 thing, this test thing and this incrementor thing. It was all so confusing! The number of times I’ve screwed up for loops is uncountable (no pun intended). Here’s what the same thing would look like in Ruby:

There’s a lot less syntax there, and iterators are to my mind, a lot easier to understand and work with. But for completeness sake, here’s the the PHP example but with a foreach:

Well, that’s not to bad actually! I reckon that you should only use for loops to count to 10 and things like that, foreach is so much easier to read and teach and so much harder to screw up. And iterators are even better, so I’d go with Ruby.


3 - Many PHP developers move on to Ruby after a few years. Have you found this to be the case, and, if so, why do you think it’s so common? What’s the big “selling” point?

Ryan: The selling point for me (in 2005) was the Rails framework. I had tried my hand at web development with Python but being inexperienced I had somewhat of a tough time, not knowing what to do or where to look (but I managed to build some things, so take that!), but I really wanted to use Python day to day because I felt it had a better, more deliberate design and I liked the syntax. And because Snakes are cooler than Elephants.

ActiveRecord was just so amazing!

Having never worked with anything else beyond ADODB in PHP, and trying and failing at making an ORM many times (I had no idea what an ORM was but I knew I wanted something that somehow mapped classes to database tables), when I first saw ActiveRecord it was like all my Christmases had come at once.

I knew relational databases rather well but was sick of writing the same SQL over and over. ActiveRecord was just, just, so amazing! And Ruby was close enough to Python I was happy as Larry (whoever he is) to have a framework I could get busy and start building things. So for me it was the love of a library and a love of the syntax.

Nowadays we have heaps of amazing Ruby libraries written by talented individuals, libraries such as Sinatra (a lightweight web framework), Nokogiri (a HTML/XML parser), Sequel (a high level database library), RSpec (an automated testing library). All these libraries are installable as RubyGems which I found much easier and user friendly to work with than PHP’s PEAR system.

The community is still fairly vibrant, even a few years in, and companies are hiring Ruby developers like hotcakes. Ruby 1.9 is apparently almost as fast as PHP now as well, so there are many selling points!

Ruby 1.9 is apparently almost as fast as PHP now as well, so there are many selling points!


Michael: I think this is just a natural progression of developers (from Web Development to seeking overall knowledge of OOP languages and an overall Computer Science education) in general – I know it was the route I took.

I think the largest downfall, to this day, is the practice of picking a language and sticking to it to the death. That’s not the way the real world works.

I consider myself a “Developer” – therefore, language is an ambiguous a qualification as the brand of television to a Best Buy salesperson. There are instances in which I pick PHP (if there is an extremely short timeline – outside of CRUD, it’s the language I am most familiar in), there are others in which I pick Ruby (deployment via Capistrano or basic CRUD with Rails) and, even further, Python – which I prefer for Server Administration tasks and parsing of various files.


4 - Often times, we consider our current language of choice to be “better” than the previous. But is that always the case, or is it just “new”? Is it possible that your old code looks poor because you’re now a more skilled developer?

Michael: I think developers can very often get caught up in the “new hotness, old busted” craze. This is why my team always sits down before we begin a project, we lay out the requirements (in both user terms and developer terms – which are two vastly different things) and we talk it out, with very little language/framework preferences in mind. Last week we parsed a few GBs of messaging logs with Perl, this week we built an application whose primary view was an ExtJS GridPanel (because we have extended CodeIgniter core files that handle any situation ExtJS throws at us with 3-lines of code).

It’s all about how much time do we have and how can we produce the best product in that timeframe?


Ryan: Absolutely, some people (myself included) get used to designing things in a certain way that they don’t want to re-learn and change all their hard-earned habits. Once you’re productive with something, why would you bother changing it?

Another school of thought is the more languages and tools you have experience, you’ll be able combine the best techniques and ideas no matter what environment you’re working in (they say this about learning LISP, but I haven’t learnt it yet).

Young programmers will jump on the shiny new things but as you get older and more mature, you want to work with small tools that are simple and robust. If you don’t use every feature and every library available to in Ruby you can get simple and robust without too much trouble.


5 - Are there instances when you might choose to use Ruby for one project, and PHP for another (assuming you have 100% control over the choice)?

One word: maintenance.

Ryan: Yes, one word: maintenance. Software projects have a propensity to require modifications over time, and the original author of the program isn’t always going to be the person who’s making the modifications. Let’s say hypothetically teleports are invented and there is a world-wide Ruby conference and every single able Ruby developer in the world is going (teleports rock!). Now let’s also say that Earth hypothetically is Middle Earth, and Smaug the dragon is rather annoyed about this whole Ruby thing (dragons prefer Python, you see) and decides to pay a visit and gobble all of the developers up out of spite. Now there are no experienced Ruby developers left in the world, oh dear! Now you have this problem of not having a pool of Ruby developers available to work on your projects. What are we going to do Gandalf?

When I’m choosing tools, I’m often thinking about who’s going to have to maintain the project if I get hit by a bus (or crash my motorbike, which is more likely).

I certainly wouldn’t write anything in Haskell or LISP or even F# because we’d have a hard time hiring someone who could or would work on it. Availability of talent and existing talent in a company then very much influences my decision.

There’s another situation where I’d consider the language, and that would be if I was selling a product, say, a custom CMS selling on Code Canyon. I wouldn’t write it in Ruby because commodity web hosting doesn’t generally support it. Whereas PHP is pretty much readily available everywhere and web designers and less experienced programmers are somewhat familiar with it.

There’s another situation where I’d consider the language, and that would be if I was selling a product, say, a custom CMS selling on Code Canyon. I wouldn’t write it in Ruby because commodity web hosting doesn’t generally support it. Whereas PHP is pretty much readily available everywhere and web designers and less experienced programmers are somewhat familiar with it.


Michael: See my answers for #3/#4.


6 - If I’m more of a designer who only dabbles in development work from time to time, would you still recommend that I choose Ruby over PHP? Keep in mind that the terminal is a scary thing to some...

Michael: Personally, I would recommend the Django framework for Python. It was designed with this purpose in mind: the ability to get the developers working on data modeling and displaying data on-screen as quickly as possible, with easy to use tags for designers to present that data in a beautiful manner, while the developers continue to work on the business rules in a concurrent cycle.


Ryan: If you have experience throwing together HTML and CSS and uploading these with FTP, then I probably would recommend PHP, as it has low barriers to entry because you’re already familiar with its metaphor (Wrap your code in <?php tags! Upload it to your server with a .php extension! Away you go!). But if you started taking programming seriously, I’d suggest branching out and having a look into other things (such as Ruby) to broaden your horizons.

When things go wrong, your lack of knowledge will come back and bite you.

Oftentimes I see PHP programmers working with relational databases and having very little understanding of how they work. So really you can get things done without a deep understanding of the technologies you’re working with (you rarely use PHP all on it’s own), but when things go wrong, your lack of knowledge will come back and bite you. How much time do you have to invest in learning these things? Can you go to someone for help if you get stuck? Are you learning PHP so you can get work with it, or just for fun? Choice is a fairly open ended question depending on what your goals are.

Regarding terminals, they are, in short, AWESOME. I use them all the time. Yes, they have a learning curve (but what doesn't?). Once you get a handle on them and start writing your own little programs you can’t go on without them. To be fair, I didn’t find the Command Prompt in Windows very useful, but once I switched to a Mac and had access to all the *nix fun under the hood, it’s become rather productive.


7 - What specifically does your language have that the other does not -- if anything?

Ruby has hype, vibrancy, and sex appeal.

Ryan: I’d say something Ruby currently has that PHP does not is hype, vibrancy and sex appeal. Ruby is unequivocally sexy. Women love it. Men want to be like it. Godzilla fears it. I’d suggest hopping along to a Ruby User Group and you’d find a diverse group of people who just love to code, love making things and technology in general. When I began meeting people in the local Ruby community, it was the first time in my life I felt like I was with “my people.” I honestly thought I was the only programmer on the planet who cared about their work up until then. It was very refreshing and I’ve learnt a lot since then, mostly from the people I’ve met through these groups.

Here's a secret: if PHP released an official update with an alternate syntax (more Ruby/Python like), and wrapped the existing standard library in the style of the popular Ruby libraries (and made it consistent), and had backwards compatibility and ability to integrate with legacy code, it'd be a killer product. Don't tell anyone I said that.


Michael: Ease of deployment, a graceful introduction to the lower-level concepts of web development and over a century of documentation and tried-and-true best practices.


8 - It’s common knowledge that PHP is far and away the most popular server-side language on the web. Yet, it’s also the most ridiculed. Why is that? Certainly there’s a reason why it’s so widely used, right?

Michael: Again - ease of deployment, a graceful introduction to the lower-level concepts of web development and over a century of documentation and tried-and-true best practices.

But seriously – because of the low-barrier to entry with PHP it can be hard to discern the difference between someone who actually knows what they are talking about and someone at the same skill level as you that had a spare domain for a blog. Plus, due to PHP’s vast seniority, there’s a lot of content out there – and not all of it is good.

This isn’t a unique problem of PHP’s – one quick look at W3Schools.com will ruin the dreams of any proponent of xHTML, JavaScript, CSS or PHP.

PHP devs suffer from “not invented here syndrome.”

It can be very easy, when you are a learning a language, to find what you believe to be an authoritative resource (which could be out-dated or just plain wrong) and follow along with what they are “teaching” you. This is something the PHP community needs to get much better at – spreading the “right” way to accomplish certain tasks. I’ll admit – the Ruby community has the advantage here, Rick Olson solved authentication for everyone when he released the Restful-Authentication plugin. J

PHP developers, for their first few years, suffer from “not invented here syndrome” – which I don’t believe is a bad thing (until they start selling that or passing it off to others). I think the mindset behind a new developer, experiencing PHP for the first time, is that they really want to understand exactly what is going on – and PHP does a perfect job of “giving them enough rope to hang themselves” – revealing enough to learn, but you’re probably going to hurt yourself. Whereas, and not to discount Rick’s plugin (which is an awesome authentication system), Rails developers are willing to assume this guy got it right and continue on their way.


PHP became immensely popular because it was in the right place at the right time.

Ryan: I’d say PHP became immensely popular because it was in the right place at the right time. The alternatives for server side development back in the day required a fair amount of programming knowledge, yet many people who never thought of themselves as programmers were already throwing things together with HTML and CSS. Following the same deployment metaphor and a basic understanding of how to put websites together you could make moderately useful programs and throw them up on an inexpensive shared web host. Or you could download one that someone else made and tweak it up a bit because the HTML and code was all mixed in together.

Another thing that helped PHP along was the boom of the likes such as the cPanel product and hosting providers white-labelling web hosting. Every man and his dog could become a web host at low cost and without any technical knowledge. Every man and his dog wanted a web site and cheap hosting. PHP and MySQL were stock standard on these shared set ups, and they were everywhere (and still are).

The best doesn’t always ‘win’, a lot of people are still annoyed that SmallTalk lost to Java, though the people I’ve met (serious software veterans) who were around when this happened, say they feel quite at home in Ruby!


9 - PHP is often criticized for its sloppy nature. But, is this a reflection of the language itself, or the users who aren’t familiar with quality code? There are plenty of ways to write clean MVC-based PHP.

Ryan: This isn’t very nice, but I’d say the common criticisms of PHP are quite valid and are due to the way the “language” was designed (or rather, not designed). PHP was born out of a number of CGI scripts that the original author wrote in C (or was it Perl?), and the common case of why PHP went the way it did was so “I could have a C programmer writing scripts for the web in only a couple of days”.

I don’t ever recalling asking a C programmer to make me a web application!

Ruby on the other hand was designed to take the best from a number of languages to create something that was a joy to work with, it has taken cues from Smalltalk, Perl, LISP and others, and it shows.

A very big difference between PHP and Ruby for me was that Ruby encourages you to work with their basic data types like Hashes and Arrays where I never found them natural in PHP. The number of times I had to look up the order of arguments for String and Arrays in PHP is mind boggling.

The number of times I couldn’t remember if this or that function had underscores or not was equally as annoying. I used Zend IDE so I didn’t have to remember but I didn’t like the IDE. It felt like you were damned if you did and damned if you didn’t. There is no consistency in PHP’s standard library and it’s frustrating as an enraged bear in a telephone box. In Ruby, I rarely spend any time in documentation for common data types because the common interactions are so easy to remember.

Once you start using features in Ruby’s Enumerable module, you’ll wonder how you ever lived without it, pinky swear!


Michael: I think this is a reflection of the low-barrier to entry and the inherit curiosity of PHP developers to really understand what is going on. I had read/studied hundreds of white papers, blogs, articles on authentication systems – but it wasn’t until I built my own that I truly felt as if I knew what was going on. I believe new PHP developers are eager to share what they’ve done with the rest of the world and are frequently slammed for doing so, because they didn’t follow best practice or proven security patterns.


10 - Community and documentation are many times more important than the framework/language itself. How does Ruby or PHP’s community compare to the other?

Michael: I think both PHP and Ruby have serious issues in their documentation – and for completely opposite reasons.

PHP has tons of documentation, thanks to its seniority – you can find the answer to any question with a quick Google search and it’s going to work. Is it the best solution? Maybe, maybe not …

Rails has been growing so quickly, that even I have a hard time keeping up.

Ruby has great documentation, but in reality this appears to be a framework vs. framework question, so we’ll assume Rails. Rails has been growing so quickly, that even I have a hard time keeping up. Rails API documentation is great; but when it comes to third-party documentation (books, blog articles, StackOverflow responses) – they’re all out-dated and while following along with this information it is very difficult to debug the problem and fix it.

In this respect, I believe PHP has the advantage as the individual frameworks (CodeIgniter, FuelPHP, Kohana, CakePHP, etc) can mitigate this effect to some degree – if you are using one of these frameworks it is simple to go find the definitive answer for what you are looking for.


Ryan: When I was using PHP, a lot of emphasis was put on how awesome the comments in the PHP.net documentation was. The philosophy seemed to be to ‘write the documentation once, and let people add their two cents’. The problem with this is that comments are laid out in order of posting which means the good ones do not filter to the top, and any insights shared in them were not worked into the documentation in a timely manner (or at all).

So much of the common API is included in the PHP core, which doesn’t change that often, so I think a wiki solution would be more appropriate. That way the community could modify the official documentation, suggest changes, suggest examples, integrate the good from the comments into what people see first. That would be useful (especially to a beginner).

Java courses teach people about polymorphism first and look at what they do – design with class hierarchies as a first cut! It makes me crazy!

In Ruby, a lot of the commonly used libraries are on GitHub, where people can submit small changes and improvements which get rolled into what is generally a regular release cycle. Documentation is paired up in code using RDoc (which is similar to PHPDoc), and when you install a gem it generates documentation on your local system. For much of my work, I’ll either be reading core documentation on rubydoc.info, or locally on my machine, or if any of those fail the libraries’ source code itself.


Conclusion

We've heard Ryan and Michael's thoughts, and you most certainly have your own views. Continue the debate in the comments!

Tags:

Comments

Related Articles