Hacker News Reader

Comment by mschuster91 | Hacker News Reader

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.

View on HN

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.

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 ;)

> 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.

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.

> 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.

Reply on news.ycombinator.com