DHH on the immediacy of PHP (2008) | Hacker News Reader

DHH on the immediacy of PHP (2008)

david.heinemeierhansson.com

37 pointstilt29 comments

The biggest advantage PHP has is that it's easy to set up: either the hoster already has php, or it's a simple matter of apt-get install if you're developing on your own. No messing around with config files, server ports, ..., it just Works (tm).

PHP enables really rapid development: just save the file and reload in your browser to see a change, compared to Java/CGI-C which need recompiles.

And finally, PHP is written expressly for the web, not like Java, Python, Ruby or whatever the latest fad is these days - where web stuff was bolted on instead of baked in the design and operations of the language.

I don't understand why you're getting downvoted. Even though I would personally never use PHP for anything, your statements are accurate.

I didn't see any downvotes, but well, it's HN... a stronghold of PHP haters ;)

There is one other strength that PHP has which is not replicated by any other runtime on the web, with the partial exception of Perl: its execution model. PHP code is executed per-request only, as opposed to within the context of an already-running app server. This means your PHP app has no state beyond what you explicitly build into it during each request, and this makes reasoning about state and control flow very easy. I love how this makes debugging, optimizing, and scaling, much more natural.

This is the reason why PHP is still my go-to first choice when it comes to request-based server apps (and together with Node.js it's also a good option for continuously-running applications). For me, the sore points of PHP are its syntax, scoping behavior, and the awkwardly structured standard library - to the point where I occasionally look elsewhere, or consider building an alternative myself.

A few configuration lines, and you can run Python scripts just like PHP scripts, using mod_wsgi: https://ubuntuincident.wordpress.com/2012/05/06/use-python-l...

Oh, you can go that with most languages, not just Python. However, they're not designed for it. PHP comes with the FPM server and an opcode cache which makes this execution model performant in a way that was not possible before with CGI. With PHP, a lot of development effort went into making this work really well.

Opcode caching actually came late in PHP (Python had it built-in since at least version 1.4, from '96). I agree that Python has no FPM equivalent, though. There are FastCGI servers, but none that simply throws away all state between each request, AFAIK.

This also leads to the rise of single tons and creating objects wherever you need them. It's hard to grok Dependency Injection when your objects live and die all the time.

It makes reasoning about state easy because you don't have to consider it. In my experience (which involves several large and mature PHP codebases), that's not a good thing.

You're right about the benefits, but the downsides are glaring too.

I agree, and I see every day that PHP apps are not written with both these pitfalls and advantages in mind. Instead, most "foreign" PHP code I look at today is either made to look like it was designed for a Java app server or is so ineptly cobbled together that no apparent thoughts were invested into the structure at all.

I blame both of these on the messaging and marketing coming out of Zend and the surrounding ecosystem, namely that PHP is supposed to be a language where big applications are constructed with convoluted EE-like class trees, and that PHP is supposed to be a beginner's language. Both of these constitute an outright failure to recognize where its strengths and weaknesses lie, in my opinion, by the same people who are maintaining the language.

Agreed, but as we're reasoning about a post of DHH, an idiomatic Rails application doesn't carry any state worth thinking about from a request to another one. Exceptions are tiny bits of information stored in cookies (usually nothing more than the id of current user) and the database. PHP does the same.

The difference between PHP and application servers is that all its runtime environment is reloaded from scratch at every request. This is both a good and a bad thing.

> And finally, PHP is written expressly for the web, not like Java, Python, Ruby or whatever the latest fad is these days - where web stuff was bolted on instead of baked in the design and operations of the language.

I don't think this matters at all.

Python and Rubi in particular have much better constructs for web development than PHP could ever get (because of its lack of state mainly).

"Bolting" things on top of a general purpose language is exactly what those languages are designed to enable.

In my view, PHP's main feature is that it enables an smooth transition from static pages to fully dynamic ones. That's responsible for a lot of its popularity, but is not a good feature to consider when starting a new project.

> PHP is written expressly for the web, not like Java, Python, Ruby or whatever the latest fad is these days - where web stuff was bolted on instead of baked in the design and operations of the language.

Is it though? How come something written expressly for the web does not include a simple and safe way to output untrusted input without being vulnerable to XSS attacks?

  <?php echo htmlspecialchars($var) ?>

is a joke.

It is. PHP was clearly never designed with safety in mind, though, which is very unfortunate. The web would be a much better place if PHP tainted and escaped variables by default.

Although, to be fair, the solution to this is still the same as with any other web-facing language - use a framework (which will, eventually, just wrap htmlspecialchars around everything for you.) It just happens that other languages make those decisions for you and PHP doesn't. Developers pretend those languages are more "secure" when really the ugly low level stuff is just already hidden behind abstractions before they even approach a project.

Better to know that by default ANYTHING is unsanitized than this: $a=$_GET["username"]; echo "Hello & Welcome $a";

By tainting, the & in the & would be double escaped as $a would carry its taint over to the output string. No thanks, I like to know what is escaped and where.

Right, because in any sane templating library you would just have something like

    Hello &amp; Welcome {{a}}

but despite being "built for the web", php is not a sane templating language for dealing with html.

Facebook's XHP solves this problem:

https://github.com/facebook/xhp-lib#escaping

"An interesting feature of XHP is the idea of automatic escaping" ... "As you can see, using XHP makes safety the default rather than the exception."

Unfortunately your standard php hosting site is not running hhvm.

These advantages are not unique to PHP. Perl, Python, and Ruby allow you to "just save the file and reload in your browser to see a change." They can be installed via apt-get (although Python always had cross-version compatibility problems.) And these languages are a lot more usable than PHP once your application grows beyond a hundred or so lines. That's why people refer to PHP as "training wheels without the bike."

What does "being written expressly for the web" mean in the context of PHP? Does it mean they implemented a taint mode like Perl, where you could sandbox untrusted user input. Well... no. Did they implement defenses against common web vulnerabilities like SQL injection? Not really. In fact, a lot of the built-in string escaping functions in PHP are seriously broken and will lead to security vulnerabilities if you use them. Is it part of a bigger web framework like Ruby on Rails? Nope. As far as I can tell "being written for the web" is just marketing.

"Did they implement defenses against common web vulnerabilities like SQL injection?"

Prepared statements has been available with PDO since 2005. It might very well have had bugs, but that isn't uncommon.

Yes, it's possible to write secure code in PHP. Just more difficult than in other languages because you are fighting against the design of the language.

Having moved to PHP nine years ago after being unable to find .NET work I have to say it was the right thing to do. The jobs are STILL bountiful, and I can knock out a prototype in PHP in no time flat. There have been a couple instances in the last few months where I built a prototype in a couple hundred lines of PHP then take what I learned and rewrite it as a several thousand line Go application.

I'd argue PHP truly shines on the command line, when I need a script that does what I need and quick. OS X comes with PHP built in and this is wonderful. The invention of phar's akin to Java Jars has made these even more portable, such that you can include all dependencies in a single file.

Why does PHP shine on the command line? OS X ships with Python, Ruby and Perl, Linux ships with Python and Perl (not sure about Ruby).

Because it's fast and easy.

Python is a nightmare especially when you copy and paste stuff together from the internet because spaces and tabs are a different thing, Perl is next to unreadable (but immensely powerful) and Ruby is exotic at best. Then there are bash scripts, a drama in itself and only to be used when you want cross-platform/cross-distribution compatibility.

PHP - the early version of the 12 factor app.

Problem is people start using it for this reason and end up with a mess.

You can make a mess with any language.

Mm hmm.

Is that worse than if they never got around to starting at all?

It's really not a problem. And if it scales poorly, just write your own vm with the billions of dollars you made saving time using php.

tbh Facebook only started with hhvm in the three-digit-million user range, the only complex apps hitting such massive concurrent users are Wikipedia, Twitter and FB.

Yahoo would beg to differ there

Reply on news.ycombinator.com