The motivation for this blog post came from reading an article today touting the meme that cloud computing is coming. That’s the message from Sarah Perez over on Read/Write Web. The “classic geek” (which presumably includes many of the folks reading this on Planet PHP) will no longer be the ones “working with the CEOs to execute the vision and direction via information technology,” according to Sarah.

Presumably because the companies will have gone bust from a lack of good leadership. Something we’ve seen before, and will see again.

The successful IT departments in the sort of larger organisations that can provide food and shelter for your true “classic geek” have been part of the business for the last decade, if not longer. Before we had the sexy CTO and CIO titles, there were IT Managers and Operations Managers who did all this stuff with little fan-fare and trumpet blowing. They did it on a budget, so they had to have financial management skills. They managed staff, so they had to have people skills. They delivered results, so they had to have project management skills. They made sure the business could do its job, so they had to have quality assurance skills. They implemented approaches such as ITIL and more lately CoBIT to ensure that the IT department was aligned to the business and relevant regulation. And they did this whilst still groking computers. In fact, they did this because they groked computers.

I’ve seen this sort of nonsense before when Java came on the scene, and the rise of the Web 2.0 blogger means I’m seeing it again. “Everything is new, everything is different; the old skills and the old lessons no longer apply, so don’t bother learning them” – that is the seductive siren call. Any student of management history can trace this echo back hundreds if not thousands of years. The core skills of good governance – direction, organisation and supervision – have not changed. You can read the works of Confucius from over two thousand years ago, and the principles behind the lessons for the leaders of the time are no different than the principles behind the lessons for the leaders of today. Practices have changed, but not principles.

There are no secrets, no short-cuts for those-in-the-know; not in business, engineering, or the arts. You have to know the basics, and you have to do the basics. Hard work and dedication is always the key, and you won’t find a single leading member of the PHP development team who doesn’t reflect that reality.

So what does this have to do with our favourite punch-bag here on Planet PHP, Ruby on Rails? For me, the rallying call of Rails is different from the Java and Web 2.0 hype/bullshit machines. I cringe every time Terry takes a swipe at it. Whilst I’m as sick of the term ‘agile’ as can be, Rails doesn’t try to claim that the old skills don’t matter. Quite the opposite. What they have done is to take the old skills and put them into one approach that can, and does, really work exceptionally well for a lot of firms and a lot of problems. They’ve worked out what the basics are, and they’ve designed a whole paradigm that ensures the basics are done well. They’ve executed in a way that the PHP community should be in awe of, not taking the piss out of.

They are years ahead of us in so many important areas, and yet PHP is thriving more than ever. They must have done something wrong, because they sure didn’t grow the market for web applications. What did they do wrong?

The fundamental mistake the Rails designers have made, and one that they still haven’t groked en-mass that I can see, is architectural, not philosophical. Rails is a classic application server, with all the deterministic, concurrency and big-iron-needed-here problems that stopped J2EE from squeezing out PHP at the turn of the century. For many of the problems of the web, the PHP execute-again architecture has repeatedly been proven to be superior to the application server architecture.

  • PHP is easier for average-skilled folks to deploy. What’s the point of creating applications if you can’t figure out how to run them anywhere but your bedroom?
  • It is easier to track down and eliminate bugs in PHP applications. No persistent processes mean that PHP applications are deterministic. PHP code is also much simpler to work through and debug.
  • It is easier to scale applications written in PHP. Folks have done it, and other folks have repeated it. The Rails community as yet has not.
  • It may be quicker to create applications in Rails, but the operational costs once the application goes into production quickly erode that advantage. If you’re not in the US, servers cost real money, and application servers need more iron than the equivalent PHP code.

The Agile community likes to talk about “smells”, so how come they don’t see something like mod_rails and gag on the stench of trying to mask architectural failings with such cleverness?

Before I make it onto Terry’s Christmas card list, I should state that I firmly believe that Ruby itself is a programming language that is vastly superior to PHP, especially when you get away from Apache and are creating the behind-the-scenes plumbing required. The OO in Rails continues to leave PHP for dead, and OO brings many advantages to a thriving development community. There are real advantages to being able to share code between both the must-be-real-time web front-end and the non-real time backends, and to be able to easily reuse whatever external open-source libraries save you time and effort. And I believe that solutions such as the Ruby gems are vastly superior to PEAR and PECL. PEAR/PECL should have been our CPAN, or our RubyForge. They deliberately chose not to be, wrongly believing that CPAN was a negative feature of Perl. They believed that one high-quality solution would prove the superior model over time. They failed to execute, and the paradigm was plain wrong in the first place.

My prediction is that a Rails-like framework, but built using a PHP-style mod_ruby and execute-again architecture, would have a real chance at displacing PHP. RoR the application server hasn’t a snowball’s chance in hell of achieving that. Their market firmly remains the same market that .NET and Java already fight over, and it’s a market they’re very welcome to.

No Comments

  1. OOP does not equal portable or shareable « Ramblings of a web guy says:
    June 6th, 2008 at 7:30 pm

    […] Posted in PHP, Programming by Brian Moon on the June 6, 2008 So, just now, I was reading a good Rails post by Stuart Herbert and nodding my head along.  I have not gotten into the Rails bashing fun on my blog, but I do poke […]

  2. PHP Coding School » Blog Archive » php code [2008-06-06 20:12:54] says:
    June 6th, 2008 at 8:30 pm

    […] On Management, False Sirens, And The Threat of Rails By Stuart Herbert It is easier to track down and eliminate bugs in PHP applications. No persistent processes mean that PHP applications are deterministic. PHP code is also much simpler to work through and debug. It is easier to scale applications written … Stuart Herbert On PHP – http://blog.stuartherbert.com/php […]

  3. Luke says:
    June 7th, 2008 at 8:34 am

    I’m a 4 year veteran of PHP and I’ve just started using Ruby and Rails, and I can tell you there’s no way known PHP is easier to debug. Ruby has debugging hooks built into the language, letting you log the exact execution path with just a few lines of code. A one-command install is available for ruby-debug, which drops ANY Ruby application (Rails web-apps too, when using the script/server command) to an interactive console at the point the debugger command was issued.

    If you’re interested in finding out more about Ruby/Rails’s debugging capabilities, there’s a few screencasts up at http://railscasts.com/tags/10.

  4. OOP does not equal portable or shareable says:
    June 7th, 2008 at 8:41 am

    […] portable or shareable by brianlmoon Sat, Jun 7, 2008 01:45 AM So, just now, I was reading a good Rails post by Stuart Herbert and nodding my head along.  I have not gotten into the Rails bashing fun on my blog, but I do […]

  5. David Salgado says:
    June 7th, 2008 at 10:42 am

    Hi there

    These days I’m a more or less full-time Rails coder, with a background in building highly-scalable mod_perl apps. I also do a bit of PHP, and maintain a mod_php app. taking about 4M hits/day.

    I’m curious what you think are the bad smells around mod_rails. Not that I’m disagreeing, but the Rails community clearly sees mod_rails as the holy grail of making Rails app. deployment easy enough to be comparable to PHP.

    Where do you feel mod_rails falls down?

    Also, I definitely have to agree with Luke that Rails code is way easier to debug than PHP. I’ve yet to find a step-through debugger for PHP that isn’t a total pain to set up, whereas ruby/Rails comes with that built in.

    Cheers

    David

  6. markus says:
    June 7th, 2008 at 12:01 pm

    There is a little discrepancy.

    On the one hand you say Rails is not the web-app that will dethrone PHP.
    I can agree on that, or live with it.

    However on the other hand you say that ruby is a better language than php (I agree on that as well).

    The same I believe is valid for python (although I really think python’s OOP is inferior to ruby’s model. Carring around implicit self makes python uglier than it should be, the indent can actually be an advantage, but python gave it away with the choice to use implicit self)

    So who will dethrone php then?

    Rails is simply the biggest contender out there. Any other framework will always have to challenge rails AND php (on the other side).
    phpBB for example may be ugly as hell, but it is very useful, and no rails framework, nor any ruby framework up to date, can dethrone. Python neither has a challenger here… trac is cool but simply not a forum.

    “My prediction is that a Rails-like framework, but built using a PHP-style mod_ruby and execute-again architecture, would have a real chance at displacing PHP. ”

    I dont so much think the problem is rails, or whatever. Dethroning php will take a long long time… unfortunately. Because php, as ugly as it may be, has clearly shown that there is a NEED for these things (it claims to solve…)

  7. Interactive PHP Shell (a la Python) | Lusion Technologies - Web Hosting Blog says:
    June 7th, 2008 at 3:28 pm

    […] web development language but lately I’ve been tempted to try out Ruby on Rails (although an article from ‘Stuart Herbert on PHP’ changed my mind) and Python (I use it for all my small scripts – but havn’t given mod_python […]

  8. Mauriel says:
    June 7th, 2008 at 5:04 pm

    Ruby syntax is horribly, and it’s not compatible with popular languages, such as C++, Java, C#, Javascript. That means that if you invest your time learning Ruby then you are stuck to Ruby’s syntax, something similar happened to me with Delphi. I wasted 3 years of my life for nothing.

    Chances of getting a job as a Ruby programmer is one in a million. So, I don’t care about the future of Ruby, it’s been around for more than 13 years. For that reason, I’m out.

  9. Bill says:
    June 9th, 2008 at 1:37 pm

    Mauriel is right, and don’t even get me started on Lisp. That sh_t is whackt!

  10. Si says:
    June 16th, 2008 at 10:17 pm

    @Mauriel: Been watching too much Dragons Den? 😉

    Ruby is one of the youngest languages out there btw, so I’m not too sure what you mean about 13 years. Talking frameworks specifically, it gets even better: Rails was released around 2004. To become one of the defacto web frameworks in 4 years is a pretty big achievement do you not think?

  11. Si says:
    June 16th, 2008 at 10:17 pm

    @Mauriel: Been watching too much Dragons Den? 😉

    Ruby is one of the youngest languages out there btw, so I’m not too sure what you mean about 13 years. Talking frameworks specifically, it gets even better: Rails was released around 2004. To become one of the defacto web frameworks in 4 years is a pretty big achievement do you not think?

This Month

June 2008
M T W T F S S
« May   Aug »
 1
2345678
9101112131415
16171819202122
23242526272829
30