Hacker News Reader

Comment by mdasen | Hacker News Reader

PHP became such a huge success for a few reasons. It's easy to deploy. You just have .php files that execute code in <? ?> tags. It has a bunch of framework-type things built in such as all the database connector functions, session handling, and it returns HTTP responses easily.

What really bothers me about this article is that the author goes after Rails without knowing anything. He says that Rails is slow. That simply isn't true when compared to PHP frameworks. Rails is many times faster than CakePHP. And Rails has a ton more features. It's all well and good to just spout off that Rails is slow, but actual investigation proves that in the real world it isn't true.

See: http://video.merbcamp.com/public/katz3.mp4 http://avnetlabs.com/php/php-framework-comparison-benchmarks

Lerdorf doesn't even seem to know that scaffolding really isn't Rails. He just comes off as someone who doesn't actually know or get the technological landscape.

View on HN

> It's easy to deploy.

Yup. This is the reason PHP is trouncing Python. Python should be where PHP is, right? But it isn't. If you ask the Python folks for easy deployment, they'll go into a lecture about how it's ugly, or a hack, or not general enough. And then they'll start telling you about how you should be using WSGI.

You: "I like vanilla."

Python: "What? Vanilla? There are better flavors than that. C'mon. Let's get you some nice strawberry."

You: "But I don't like strawberry.

Python: "Well, you should! It's a great flavor! How many scoops would you like?"

You: "[Sigh]. 2. Sugar cone, please."

Python: "Here you go!"

You: "Hey, this is a wafer cone. And it's only one scoop. And it's sherbet!"

Also, learning to make a scripting language spit out some html is easy. Learning how to get various apache modules built, configured, and installed -- or convincing an inexpensive ISP to do so -- is a whole nother ball of wax.

AFAICT, PHP did deployment right, and is still making "better" languages look like they can't get their act together. I should be able to drop a .py file into my docroot and a persistent apache-managed python should execute it (when it's requested) and spit the results back to my browser. It's astonishing that we don't have that.

You: "I like vanilla."

PHP: "Here you go. Vanilla. Also take these napkins -- it's a little drippy."

Passionate software developers need to accept the fact that web programming has hit the mainstream. There are tons of amateurs doing it, and the number is growing explosively thanks to platforms like Facebook. It's pretty much a given that these type of people coming in with a passion for the end result are going to be different from the geeks for past generations who were just as obsessed with the process of programming.

PHP is ideal for seeing a quick result. HTML + PHP is the most rewarding platform ever invented in that regard. Naturally, many of these individuals will evolve and outgrow PHP, but it's also powerful enough to keep a lot of talent around just due to inertia. Ease of deployment is just one piece of this perfect storm.

Websites are a small corner of the Python world, but all of the PHP world.

Everywhere I look, when new programmers ask what language to learn first, they are most often told to learn Python.

C is too low-level, Perl's too old and crufty, Ruby's too trendy, Scheme is too esoteric, Haskell's too difficult, Lua doesn't have enough libraries, Java's too verbose and corporate, ... the list of reasons not to go with other languages is a mile long. Note: PHP is usually never even mentioned.

Then the new programmer asks what language they should use for web programming. At this point, everyone looks at the floor, scratches the back of their neck, clears their throat a bit, and says that, well, you should probably use PHP because that's what everyone else is using.

So, in most corners of the programming world, many experienced programmers are recommending Python.

You know how to get "everyone else" to use Python for web development? You make it easy to deploy -- just like PHP.

"Everywhere I look ... they are most often told to learn Python ... in most corners of the programming world ... recommending Python"

Combined with

"Ruby's too trendy"

There's that cognitive dissonance again.

"Then the new programmer asks what language they should use for web programming. At this point, everyone looks at the floor, scratches the back of their neck, clears their throat a bit, and says that, well, you should probably use PHP because that's what everyone else is using."

wow! This is some seriously fucked up advice. if someone were to ask me what language he should learn first, the answer is Python. When "Then the new programmer asks what language they should use for web programming" the answer is still Python - use Django with its awesome documentation and uber friendly community- (and PostGres as a database).

This steers them clear of two terrible (but popular) pieces of software, PHP and MySQL.

I usually tell people "Use Python and Django" when they ask me what language they should use for web programming.

I agree though, Python apps should be much easier to deploy on the web. Just because it's currently the best solution doesn't mean it can't be better.

I usually tell people, you are not a mathematician, a crazy scientist or lonely sys admin, you are a web developer, go with PHP.

That corner is the largest, and is only going to get bigger. Python can ignore it at its own peril.

Bigger how? PHP can't be used for anything but simple web templating. Python is used across nearly the entire spectrum of computing.

PHP runs some of the largest websites out there - hardly "simple web templating."

You can write administration scripts in PHP, deploy scripts, hell, you can even write Windows apps in PHP (though it's horrifying).

Just because you don't use it for anything more than simple templating, doesn't really mean much. PHP is everywhere.

It runs the surface layer of them, sure. Put this text here, put that JPEG there. Do you think Facebook is traversing the social graph or routing chat or doing any interesting computation with PHP?

I'm not saying that whitewashing a fence or mowing a lawn isn't honest work, but it's a bit of a stretch to compare it to building an entire city.

When the boss says to make the website in php, they mean the whole website. You usually don't get to just do the presentation in php and use $your_language_choice for everything else.

Well, that's the goal of mod_wsgi, isn't it? To make it easier to deploy Python web applications, especially in shared hosting environments?

mod_wsgi should allow you to just drop in a .wsgi anywhere and run it, provided your host allows for that. Do you think there's anything preventing it from catching on?

I agree with you completely. Recently we created a small web app (http://hnwatch.scalien.com, Hacker News Watch) which already had a python back end for crawling and text processing, so we decided to try out python instead of choosing php which we were already familiar with.

We decided to use apache+mod_wsgi as it seemed the most performant option to use, and then we realized that you cannot use python as you would php, but you have to use a framework to do even the most simple things.

What's worse, with mod_wsgi python caches the interpreter between page requests, which means it also caches modules with errors, and randomly runs several versions of the same file!

So we hacked mod_wsgi to not to cache, and also created a minimalistic framework (150 lines) so that file deploying is like with php and you can easily use GET parameters, cookies and even mixed html and python code between <? and ?>. The only drawback is that python use indentation, so you have to be careful when writing one-line codes etc.

Now it is working correctly, but I was constantly wondering that nobody did that before us. Still I'm not sure we shouldn't use php again :)

I like to add automated tests for any application I write. These are mostly to prevent regression and to maintain sanity. Python makes this easy (as do the popular Python web frameworks such as Django). Do correct me if I am wrong, but I do not see the same importance given to automated unit testing in the PHP world. This leaves those who do want to automate tests with fewer choices of tools and accessories.

Well, I admit that I don't make automated testing as part of the web development process, so I don't really know the options (neither in python, nor in php).

But back when I worked on a quite big web application with the front-end developed in php, we did two things to detect errors early: - before building a package to be deployed, run a syntax check on all php files. - caught all runtime exceptions and sent an email to ourselves with a stack trace. Sure it generated a lot of traffic in the beginning, but it was quite rewarding after we filtered out the duplicates. Effectively our users tested the code paths for us :)

I think these can be done in any web development language, additionally to the automated testing. The other thing came to my mind, that in php you can detect if you are running as a webserver process or from command line. This creates a handy option to write automated tests too.

If you ask me why Python -- and Rails, for that matter -- aren't trouncing PHP, it's because Python ignores Windows, and doesn't focus on the web.

Hold the flame throwers for a second.

Everyone on this site knows you shouldn't be deploying websites on Windows. And I agree. WAMP is not a sensible production environment. But it's a great learning environment.

Because what the Python hackers of the world seem to forget is that 95% of all the computers in the world are running Windows. And for very large numbers of the owners of those computers "buy a second box and put Linux on it" is not an available option, and "run a virtual machine with Linux on it" is really complicated. They don't want to learn a new operating system, they want to learn a language to build websites in. In fact, all they want to do is _build websites_, and the language is the means to an end. They will take the path of least resistance, not the path that is most elegant.

You want to build a website in Python on Windows? Good luck. Sure, Python has a great Windows installer -- but then what? Django? Some other web framework? Have you tried installing Django on Windows? It is a gigantic pain in the ass. Oh, and the MySQL libraries aren't included. Oh, and they don't work with Python 2.6 unless you find a super-secret download mentioned only on a mailing list. And then you have to learn Python, and then Django, and then you have to work out how to deploy it to your host's web server.

Here's how you do the same thing in PHP. You go somewhere like here: http://www.wampserver.com/ You download one file, run one installer, and it gives you Apache, PHP, and a MySQL server, all at the same time. You put some .php files in there and web pages start turning up in your browser. It's not pretty, it's not elegant, it doesn't scale, but it's your first web page ever and it's ready in 10 minutes. Ready to deploy? Copy your three PHP files to your web host via FTP, and presto, they work just like they did on your home machine.

Later, you discover frameworks. You learn about encapsulation, and MVC, and loose coupling and scalability. You work out that Windows is not exactly like your web host, which is running Linux. You might get around to installing Linux at that point, but you don't really have to because the differences are pretty minor. But whatever happens, at that point, you already know PHP. You're not going to switch languages.

Until Ruby and Python hackers swallow their pride and accept that welcoming newbies to the language means not forcing them to switch operating systems, PHP will continue to monopolize the market for beginner web developers, and hence the market for the professional developers that they turn into.

Can't upvote you enough.

I mostly write desktop apps. I really want to write my own web apps, just as a fun exercise. So far, PHP looks like the only programming language that will let me write web apps without spending eight hours trying to set up a friggin' web server.

I compile an entire OS from source every week (the Haiku trunk), but getting Python with Apache set up on OSX Leopard is something I always shy away from.

(Also, why is it so hard to not have to use a framework to write your webapp in the Python world? All I want is a 'Hello World', not friggin' Facebook.)

IIRC (untested), a "Hello world" webapp in the Python world is as simple as dropping this into your cgi-bin:

    #!/usr/bin/env python
    print 'Hello world'

You can do CGI apps just as easily in Python as you can in other languages. It's just that CGI doesn't scale, and so you'll want a framework for anything more complicated than that.

Incidentally, have you tried to setup PHP on a machine that doesn't already have it installed? (Particularly without using a package manager - with port or apt-get, Python isn't all that difficult to install either.) It's a frigging nightmare of building shared libraries, making sure they're in the right place, finding the right Apache config files to edit, and adding the appropriate LoadModule/AddType/AddExtension/whatevers. The reason PHP's easy to deploy is because most webhosts already have it preinstalled - they've done the work for you. If you use a Django-aware webhost like Webfaction, the process of creating a new Django app is reduced to clicking a button on your web-based control panel.

> It's just that CGI doesn't scale, and so you'll want a framework for anything more complicated than that.

No, that's not the issue. The issue is, when you have a relatively small webapp that you want to be fast. It's large and fancy enough -- you just want it to be fast.

So, for that you want a persistent language runtime, such that when your page gets accessed the already running Python interpreter just grabs your .pyc file and runs it immediatly.

The final ingredient is that with php you can put your php files into your docroot so that you don't even have to mess with apache rewrite.

If Python had those things, there wouldn't be any reason for a new user to choose php over python.

The link you yourself cite shows a fourfold speed advantage for procedural PHP over ROR. Not mentioned is the large memory footprint of a Rails process compared to a procedural PHP page. It's the usual phenomenon of trading off development time and complexity for performance. I'm sure if you wrote a web app in C, it would run even faster.

Rasmus's point in the article is that as soon as you move away from simple apps under light load into real applications, it is no longer enough just to rely on Rails magic. You find yourself needing to understand the innards of what is a very complex environment, and dealing with an idiosyncratic development community that considers monkey-patching a neat programming techinique, and likes to publish its documentation in video format.

He doesn't seem to me to be saying 'don't use Rails'. He's just pointing out you should be fully aware of what you're getting into. Caveat scriptor.

Rasmus's point in the article is that as soon as you move away from simple apps under light load into real applications, it is no longer enough just to rely on Rails magic.

This seems backwards to me. I consider PHP to be ideal for simple apps. Rails comes with a certain amount of overhead (memory being the most important as far as cost is concerned), therefore I think it's only really useful for applications of a certain complexity. What makes Rails useful are some basic architectural assumptions (MVC + a bunch of low level assumptions / web helpers) that are surprisingly applicable to a large chunk of web apps. The magic is just some Ruby tricks to streamline things, but you don't "rely on it". Where Rails tends to fall down are limitations of the Ruby runtimes, or applications where the web front-end is not a significant enough part of the problem to warrant the Rails approach.

PHP is similar in some ways--it includes many web-based assmptions, but it doesn't make any architectural assumptions, which means there is no way to benefit from common conventions (eg. knowing where to look for a certain file or class definition, what a variable or database table should be named, where is the default place to put certain types of logic, etc). As such, PHP is better than any other raw language for web work, but it doesn't really allow you to easily utilize best practices that we've collectively learned over the last 15 years of web development.

That's not to say Rails is just plain better... to the contrary, I think PHP is a better templating language. The difference is that with PHP you are better off moving to a real language for your back-end on any moderately complex application fairly quickly. Rails, on the other hand, will let a significant portion of web apps (if not a majority) go quite far without any separate back-end.

But as soon as you move away from simple apps under light load into real applications, it is no longer enough just to rely on PHP magic. You find yourself needing to understand the innards of what is a very complex environment, and dealing with an idiosyncratic development community that considers ad-hoc exposure of C libraries a neat programming techinique, and likes to publish its documentation as comments on a web page. ;-)

PHP occupies an unfortunate middle-ground: it's less productive than Rails or Django, but less performant than C++. If your site really gets to Google- or EBay- or Facebook- or Twitter-scale, it's probably worth rewriting it in C++.

PHP, Python, and Ruby all have fairly easy-to-use C interfaces, so it's not that hard to link in the performance critical parts later as you rewrite them. Given that PHP isn't an effective final solution anyway, why not start with something a bit more sane?

PHP isn't an effective final solution? Yahoo uses it as the front-end language for tons of stuff.

Ruby on Rails isn't an effective solution? Twitter uses it as the front-end language for tons of stuff.

It's not. Twitter ended up having to move the guts of the service off Rails to handle growth, back when it was a small fraction of the size of a typical Yahoo property.

Also, the comparison doesn't really make much sense. ORM is at the heart of Rails, and the framework has a very intimate relationship with a backing data store. At a company like Yahoo, PHP is used as a kind of presentation layer that communicates with various backend services that do the heavy lifting. It's a different architectural model, designed to avoid precisely the kind of problems you get scaling Rails (or Django, or your favorite framework).

AFAIK, Twitter is doing exactly the same thing with Rails that Yahoo is doing with PHP. They ditch the ORM and use it as a thin presentation layer over RPC calls.

I don't know too many intimate details of Rails, but ORM is most certainly not at the heart of Django. It's quite common to drop the model layer entirely and run it on top of either RPCs or a different backing data store (see AppEngine, for example, and every Django app I've written at Google).

ORMs have well-known performance problems - a couple startups ago, I was doing webapps in Java, and we found that relying on Hibernate gave us an instant 5x slowdown over raw JDBC calls, and far more than that relative to our proprietary database.

The link you yourself cite shows a fourfold speed advantage for procedural PHP over ROR. Not mentioned is the large memory footprint of a Rails process compared to a procedural PHP page.

Apples and oranges. Why not compare plain PHP to plain Ruby to be fair?

and likes to publish its documentation in video format.

Hardly a negative point. The screencasts are one of the reasons Rails became so popular in the first place.

I'd love to see a memory/speed comparison of vanilla PHP and Ruby. I don't think it would be very flattering to Ruby, but I'd be happy to be wrong.

Maybe not, but PHP code tends to be of lower quality. It'd be like comparing a Lego house to a real one. You can build a Lego house quicker, but so what?

Just wanted to note, before I piss anyone off, my tongue was firmly in cheek on that post ;-)

I don't think that Lerdorf (btw, not Lerforf) doesn't know what he's talking about.

He's just saying that frameworks like Rails are inherently slower, and all the magic (like scaffolding etc.) isn't really worth it.

He also says: > Ruby as a language is great, I think it's a really clean and nice language. There just aren't that many people who know it well.

Here's what he said:

"But there are performance issues with the scaffolding and stuff, and they recognise that, which is why the new build will be better."

Any rails dev could tell you that scaffolding is irrelevant to the performance of a typical rails app. Yet he mentions "scaffolding and stuff".

Also, DHH has said numerous times that scaffolding is mostly just a development tool. I think people who still trot it out as one of the problems with Rails are deliberately ignoring what he said.

I think it's a fair knock because it is so prevalent in the screencast (which he mentioned). If it's in the sales pitch, it's fair to knock.

It's a bit like saying Ford cars are crap because they don't fly well. It's knocking the wrong thing.

I don't follow... Ford doesn't sell their cars by showing how easy it is to make them fly.

Scaffolding does not make Rails fast or slow. It's code generation that happens prior to run time.

"The" screencast? Maybe in 2004 there was The One Rails Screencast, but their numbers are now legion.

Referring to a screencast that's four or more years old so as to knock something today is dopey. It would be like complaining today about PHP3 speed and syntax.

Seems pretty clear Mr. Lerdorf has very little knowledge of Rails, and likely very little interest in changing that.

"But when they needed to do something real, they thought, 'Oh crap, I don't know Ruby very well!'"

Pretty sure that's true for people who hear good things about any [Perl|PHP|Python] framework and decide to pick it up. Usually people then just learn the language.

PHP might have a brighter future if its BDFL wasn't so myopic about other languages.

> "The" screencast? Maybe in 2004 there was The One Rails Screencast, but their numbers are now legion. Referring to a screencast that's four or more years old so as to knock something today is dopey. It would be like complaining today about PHP3 speed and syntax.

Visit Ruby On Rails' homepage (http://rubyonrails.org/) and click "Screencasts" on the top menu bar. Click the first one, "Creating a weblog in 15 minutes with Rails 2". Watch. That's what I'm referring to, but it's not much different than the original screencast you're referring to.

" That's what I'm referring to, but it's not much different than the original screencast you're referring to."

If that is as far as someone gets in trying to get an understanding of Rails, then they aren't even trying.

What's disappointing is not that Mr. Lerdorf doesn't like Rails (though his reasoning could be better), but that he doesn't even seem interested in it or why people get so excited about it.

I hope he sees the hypocrisy in being the creator of a slow (relative to Java/C) language which had a selling point of being productive and easy to use criticizing the next generation of web programming (frameworks) for having these exact same attributes compared to what he made.

Also, the PHP framework world blows, I tried Zend's Framework, Cake, and Symfony when I had a boss that refused to use anything non-PHP, and they just don't have feature parity with Rails (though this was a year ago). They also don't have as many mature plugins available as Rails (and a web programming language lives and dies by its libraries).

Comparing an interpreted langauge like PHP with C speedwise doesn't make any sense. Even Java is semi-compiled to an intermediate form unlike the strictly interpreted PHP.

Also, in my experience there are plenty of libraries available for PHP. It comes with a lot more built in functionality than other languages.

What I like about PHP over Ruby is that it has a more comfortable C-like syntax. In comparison Ruby is more like Basic than C. When I use Ruby I miss the simple curly braces of C or PHP. In my humble opinion that is a much better way of defining blocks of code.

It makes sense in the context of PHP's creation. When PHP was created, web apps were still commonly written in C/C++. PHP is much older than Rails, even if you don't count PHP 1 or 2.

> In my humble opinion that is a much better way of defining blocks of code.

I also don't like Ruby's syntax in this regard. However I long for the simple ways of Haskell, Clean and Python here, using indentation.

Comparing a language like PHP to a framework like rails makes no sense either. That was my point.

I think you've missed his point a bit. He doesn't like code generation in general, which would mean he wouldn't like CakePHP's scaffolding either.

If you read other interviews with him I think you'll find he's surprisingly modest about the whole thing. I've never heard him hold PHP up as particularly better than any other language, and he's the first to admit that it can be messy.

FWIW, I'm a huge fan of CakePHP and I use it daily (although I don't have much use for scaffolding). Its plenty fast if used correctly, which is a common feature of any good framework.

Reply on news.ycombinator.com