Jeremy Smith's blog

Entry Is Labelled

LAMP People Need to Grow Up

Okay, just can't help myself today (via Simon Willison's Blogmarks).

IBM: 'LAMP' users need to grow up

If you look at the history of LAMP development, they're really primative tools ... the so-called good enough model. The type of businesses being created around those particular business models are essentially going to have to grow up at some point.

I believe that in the same way that some of those simple solutions are good enough to start with, eventually, they are going to have to come up against scalability

This was a quote by Daniel Sabbah, [I-Am-Not-Making-This-Up] General Manager of IBM's Rational division.


  1. gravatar

    Haha, that is a very loaded quote.
    I am an employee of IBM at the current moment...but I have put on my Case hat for this comment.

    The LAMP model, in essence, is very simple. But in its simplicity is quite a bit of power to the common developer and user. I would not call it primitive.

    I can see where Daniel Sabbah is coming from, if you are looking from the perspective of a CIO or database manager of a Fortune 500 company. The "M" of LAMP stands for MySQL - which is a very easy to use, scalable, high performance and robust database.

    However, when looking at any product, you have to consider cost of ownership. "But MySQL is free!" But developing is not. The few lone rangers armed with their trusty Jedit/kdeveloper/Eclipse/notepad/vi(m) editor with an open source CVS such as subversion is perfect for most. In fact, it's quite perfect for most large companies.

    On the other hand, if you are employing an army of thousands...having a nice development environment (Rational Rose XDE Developer...for instance) can actually be cost saving in the end due to the number of skilled developers familiar with it. Rational Rose has been around and widely used for quite a few years . LAMP is still quite young...

    Do I agree with Daniel Sabbah? Not really. Will these businesses eventually have to grow up? I firmly believe that they will grow with MySQL, rather than out of it. Is IBM going to hurt because of MySQL? Not really...if they are smart. And they are smart. They're making a killing in the middleware industry. And that is where it is at.

    And if you take a look at MySQL's clients is quite clear that MySQL will get the job done in even the largest of companies. Is it worth paying the huge premium to invest in...IBM Rational database? Yes, when your business depends on the few advantages it offers OR you do not know better.

    For everything else, there's mastercard and LAMP.

  2. gravatar

    I can sort of see where he's coming from though. There are certain extra things you have to start doing to your lamp to get it to really scale, particularly heavy caching. You need things like a static home page and memcached can help a lot. And if your P is php, you really need to start thinking about Zend's tools.

    But the truth is that 99% of sites don't need to scale to an extraordinary level, but some of the ones that do, like Slashdot show us that lamp is a viable model.

  3. gravatar

    From the comments so far it seems like people are somewhat willing to accept Daniel Sabbah's position regarding the MP in LAMP, but not the Linux and Apache part. I think we can all agree that Linux and Apache are a fine combination. But when it comes to MySQL and PHP/Perl/Python, I'm mostly with Daniel on this one.

    I'll touch on each of these items, except for perhaps Python, which everyone knows I don't have any issues with (why would I use it otherwise?).

    First off, it saddens me that most of today's web programmers are also unnecessarily database programmers, in that they have to learn SQL. I'm good at SQL, but I hate writing it. Don't people know that there are plenty of decent object-relational mappers out there that will abstract the database away and give you objects in whatever language you're writing? Then it doesn't even matter which database you use, because most abstract that away also and do all the conversions for you. Seriously, why are you still writing it? Put the SQL down and step away from the code. And hey, Zope has already proven that the ZODB is a highly scalable object-oriented database.

    I don't have anything against Perl for web programming, just programming in general. Come on people, it's ugly. Nobody wants to read that crap.

    But surely PHP takes the cake for worst web programming fad. Why do you know PHP? Because it was easy to get started with, or because you had to. PHP's whole model encourages programmers to mix model code with view code with controller code! Most PHP files have SQL *and* HTML *and* PHP in them all at once! What a mess! I was explaining CherryPy to a PHP coder friend the other day, and when I told him that page templating was completely independent of the whole application, so you could use whatever you wanted, he got confused.

    And not only are those PHP files so mixed-up and cluttered, but 99% of PHP-enabled servers serve up PHP files. Huh? How can you like PHP and RESTful URLs at the same time if this is the case, besides relying on mod_rewrite, which shouldn't be necessary? And if you somehow use it through CGI instead, well, there goes your whole easy-to-get-started bit, so why not just use something else? I have more issues with it, but you're probably sick of my incendiary garbage by now...

  4. gravatar

    Sorry about that broken link, this is the right one.

  5. gravatar

    I would feel guilty if I didn't offer a rebuttle to Brian's comment regarding PHP. Your criticisms of PHP are well-deserved. When you trace PHP to its roots, you do in fact stumble upon what could only be described as a quick, dirty, and ugly language. For years, model, view, and controller code was mixed in together. This was the fault of the PHP language itself and the lack of good programming resources to show people how to properly do things. Considering PHP was used for quick and easy solutions, this really wasn't a problem.

    In the last year or two, PHP has seen some extraordinary growth. It is quickly turned to as the language of choice for web applications. It is fast, easy to read, and provides a Swiss Army knife of tools that other languages don't provide natively. Many libraries added to its arsenol. The Smarty template engine allows easy separation of program output from the controller code. The many database abstraction layers (PDO, ADODB, and PEAR::DB provide a simple gateway to connecting to multiple database architectures without rewriting SQL.

    With the release of PHP5, PHP became a real programming language. The changes were worth the wait and unless I am forced, I always write PHP 5 only code. The few complaints left about PHP are from people who don't understand the purpose of the language. Namespaces would be nice, I know, but PHP is a language in transition. As it evolves from a mainly web-only language to something which can be used to program GUIs, shells, and services, I'm sure it will adopt the components of more mature languages.

    I highly doubt that PHP is a "fad." The statistics can speak for themselves.

    I understand your frustration with PHP programmers. Many, I'll admit, have no clue what they are doing. Just the other day, I was looking through PHP 4 code for a popular open source project and found if ($foo == false). I think I screamed when I saw that travesty. Even in C that is poor programming. Judging from other code from the author, I could tell he had no clue how to program correctly. The PHP universe is unfortunately filled with such talent. Hopefully time will yield a change.

    And to address your last paragraph... WTF? Web servers serve up .pl, .py, .asp, and .jsp files all the time. PHP is no different. Are you saying this is a bad approach? I love the REST concept. I love PHP. They were very well together. Mod_rewrite, although not necessary, is very handy for REST applications. How do you manage to contruct a REST interface without using index.php?foo=bar&id=7 or mod_rewrite to simplify this to http://foo/7?

    And regarding PERL, I agree totally. Who wants to use a language which has an annual obfuscated contest? (I don't think one exists for PHP, but I could be wrong).

  6. gravatar


    Personally I think serving up code files is on its way out the door. Web application frameworks like Zope, Ruby on Rails, CherryPy and a ton of others serve class methods instead. How do you even do RESTful URLs by serving up files? I'm pretty sure you'd have to turn to CGI. Consider this very Blog@Case interface, where you can access posts by their date like so: 2005/05/27/lamp_people_need_to_grow_up. Are those dates *directories* that actually exist on the server? I sure hope not. PHP teaches you to either make them directories or do something like post.php?year=2005&month=05&day=27&post=..., etc., and that's just ugly. If you think making them directories is not so bad, well, how would you do it if that segment of the URL could be *any* string?

  7. gravatar

    Sorry, but I really don't buy mod_rewrite as a solution. Why should you have to rely on a completely separate module? And what if you don't want to use Apache anymore? You're screwed. If you migrate to another web server none of your URLs will work unless you can find another module that works the same way!

  8. gravatar

    I like his it's Jeremy's blog we always get into these discussions on. :) We should try more blog cross-posting.

    Last one for now: the statistics may be on your side, but we just got through discussing how most PHP sites are poorly structured and written due to bad programmers or design concepts from PHP

  9. gravatar

    Now I'm just spamming... it cut me off for not escaping <... should have been:

    I like how it's Jeremy's blog we always get into these discussions on. :) We should try more blog cross-posting.

    Last one for now: the statistics may be on your side, but we just got through discussing how most PHP sites are poorly structured and written due to bad programmers or design concepts from PHP <5. Are those really the kind of numbers you want counting for your side? ;)

  10. gravatar

    "Consider this very Blog@Case interface, where you can access posts by their date like so: 2005/05/27/lamp_people_need_to_grow_up. Are those dates *directories* that actually exist on the server?"

    Well, actually, they are. MT exports your blog to static HTML files when you change something. Don't believe me? Mount your blog as a WebDAV folder, then you will see.

    "And what if you don't want to use Apache anymore?"

    And use what instead, IIS? Apache is a viable solution on any platform. Any good web script which uses RESTful URL's in the form of cgi variables can easily be made to look nicer with Apache's mod_rewrite. It may not be required, but it looks nicer.

  11. gravatar

    Well, I didn't rule out the possibility of the WebDAV folders just being virtual... are you sure?

    And do you really think that the only options are Apache and IIS? Apache is not the only open-source, cross-platform HTTP server, just the most popular. And unless you're using a bunch of custom modules or configurations, web server software really doesn't have much lock-in, so why immediately reach for Apache?

    Personally I get sicker of Apache by the day. Sure, you can get it working in under a minute. But beyond that I hate configuring it. I can name several alternatives off the top of my head: Twisted, Medusa, lighttpd, and those are just the dynamic-language-oriented servers. Some research uncovers more: thttpd, Pi3Web, Xitami...

  12. gravatar

    But lighttpd supports URL rewriting which was supposedly your cause of Apache lock-in.

  13. gravatar

    Alex: I don't use mod_rewrite or any URL-rewriting mechanism.

    Also, I don't claim to have extensive experience with the named alternatives, just that they are viable alternatives...

  14. gravatar

    I see what you meant now. My beef with URL rewriting didn't have anything to do with Apache — remember, I was targetting PHP originally, the whole Apache alternative thing spun off of the idea that URL rewriting features in general cause lock-in. The point was, if the web framework you're using requires a URL rewriting mechanism, maybe there are bigger problems you should worry about...

  15. gravatar
    if the web framework you're using requires a URL rewriting mechanism, maybe there are bigger problems you should worry about...

    If the web framework you're using locks you into a specific URL scheme, well, you may be having problems.

    There's nothing intrinsically wrong with using mod_rewrite to clean up URLs which couldn't be constructed cleanly to begin with. Obviously, try to make the URLs clean naturally; use mod_rewrite as the exception. And, if you suddenly decide to wisk your application away from Apache+mod_rewrite to another web server that doesn't have any kind of URL remapping functionality, it's your own damn fault for picking a shoddy web server.

    And, can we please get off the "your programming language is a bad programming language because I've seen people write bad code in that language" arguments? They're just foolish. Writing code in .jsp, .asp, .py doesn't suddenly turn a dumb software developer into a smart one — you can give an idiot a better hammer, but you'll never stop that idiot from hitting himself with it.

  16. gravatar

    Well, I never claimed Python was superior, just that I don't have any issues with it. And there's a difference between noticing that lots of people writing bad code and the fundamental design of PHP being a templating language encouraging such code.

  17. gravatar

    Also, it's not about being locked into a URL scheme, it's about having the *choice* of constructing your URL scheme without having to rely on third-party modules.

  18. gravatar

    And hey, who says web servers that don't support URL remapping are shoddy? Many of the alternatives I named outperform Apache and aren't a nightmare to configure.

  19. gravatar

    funny how the same old boring arguments happen again and again .. and again..


    crap programmers write crap code - whatever language it's in.. the language just helps a bit..