Hacker News Reader

> default to HTML escaping on output

??? Is that a joke? Don't do that! That's just as bad as magic quotes.

> no register globals

It hasn't existed for a quite a while now in PHP.

Other than that I quite agree with what you wrote.

Most of the criticism of PHP is simply a desire to be special. If lots of people are using something, you want to make sure not to, so that you feel special. Now that you've decided not to use it, you need to justify it to yourself. And people find all sorts of real criticisms in the process - yet none of them matter!

> > default to HTML escaping on output

> ??? Is that a joke? Don't do that! That's just as bad as magic quotes.

No, it's not. Magic quotes are a pain to reverse. HTML escaping can be built into the echo/print/<?= .. ?> commands, so that it is:

    - A setting that can be totally turned off at run-time, if you want;
    - Easily overridden on a case-by-case basis with a 'rawecho' function that 
      does *not* escape anything.

I've seen too many multiply encoded things to be so sure this is a good idea.

Plus too many cases of extra backslashes from back in the magic quotes days.

Problem with HTML escaping by default - it's not all HTML escaping. Javascript strings need to be JS escaped, sometimes escaped by HTML as a second (or even first) step to complete the correct encoding needed to avoid XSS for the specific context(s) that output actually ends up in for a browser. Same for CSS, URIs, vbscript, parameters, etc.

HTML escaping is not the one and only escaping strategy that magically makes everything safe. So any automated system would need to incorporate overrides on a per variable basis.

http://blog.astrumfutura.com/2012/06/automatic-output-escapi...

    > > default to HTML escaping on output
    > ??? Is that a joke? Don't do that! That's just as bad as magic quotes.

Microsoft's Razor and Python's Django templates have both shown that HTML-escaping-by-default can be cleanly done in a way that is not magical and that is highly reliable. I'm not honestly sure what you're protesting here.

In a way, "default escaping" isn't even the way to think of it. There is everywhere functions to emit raw characters and to emit them HTML-encoded. "Default" escaping just means that the function that emits HTML-encoded characters is easy to get at and smoother to use than the raw one.

I understand the debates Django had about changing what the unspecified output function did, but nowadays if you're building a new template language of any kind it's an absolute no-brainer: Make it easier to encode than to bypass encoding. The alternative is just awful.

If I make a string: '' . $var . '' - does it know to encode the variable, and not the entire string?

What if I assign that string in a variable, and then output it later?

I'm not convinced this can be done well. Maybe if all you do is make some templates and fill them in you could do it. But I do a lot more than that, I output dynamically built html all the time.

Just give people a very easy and shortly named function for escaping.

Just needs a bit of type system magic. Don't use the same type for escaped and unespaced strings. (And don't use the same type for user generated input before and after it's scrubbed / escaped of any nastiness.)

Ask any Haskell weeny for details.

Also in your example, you'd probably be better of, if your language knew about the HTML structure, e.g. something like P($var), instead of putting the tags in as strings.

> Don't use the same type for escaped and unespaced strings.

And if you can't extend your type system to make this work, do it in your head, mutating the names of variables to help you keep it straight. For example, esStr and unStr are not of the same type, and moving data from one to the other without conversion is always an error.

Which was one of the original and useful points of (apps) hungarian notation.

This reminds me of Charles Simonyi's classic article on Hungarian Notation. I know that style gets criticized a lot, but that's usually when it has been used inappropriately. If you have a language with a weak type system then a sensible variable prefix convention can help a lot.

http://msdn.microsoft.com/en-us/library/aa260976(v=vs.60).as...

And you might even write a `lint' like source auditer to warn you about those conversions, even if your compiler doesn't.

I agree, the language runtime should support this somehow.

http://roboprogs.com/devel/2009.07.html#2009_07_30 (point number 4 in the numbered list)

Of course, I was thinking of a runtime attribute, rather than static typing, but the idea is similar.

Even with static typing, you might end up implementing using run-time support. (Of course the holy grail is to compile away all type information. But that's not only attainable. Even Haskell's ghc compiler keeps some information around for runtime. Something to do with typeclasses, if you want to look up the details.)

> Just needs a bit of type system magic.

I like this, although when you concatenate strings, does it actually concatenate them (and loose the type info)? Does it escape them, and then concatenate? Or does concatenation actually make a closure, which is only executed upon output? (And does doing that make things memory heavy.)

Haskell is on my next language to learn list.

> something like P($var)

Ugh. I hate that. I've spent years learning HTML, I want to write HTML, not some other language that looks like it.

How about just:

$foo = $textvar; $foo->append(Hello!); // etc.

Mozilla proposed to add XML literals to JavaScript at one point, which didn't take off for security reasons, but server-side it's a different ballgame... maybe it could be worked out? Hmm.

Wow, that's even uglier. But you did not only propose an alternative syntax for HTML, but also for its manipulation. So that's a good enough excuse.

Have you looked at how Racket (Scheme, Lisp) deals with encoding HTML in S-expressions? I find that rather nice, and even prefer it to plain HTML or XML. Racket is a fine language for manipulating S-expressions, too.

Yes, judging by your questions Haskell is a good language to learn for you. To give you a sneak preview: You can use the type system in such a way, that your source program will safely discriminate between the two types of strings (e.g. tainted and untainted), but there won't be anything left in the compiled assembly (tags or wrapping or whatever).

Also about the HTML: You can of course use different syntax for what I proposed, one that's closer to actual HTML. But I think as long as the syntax tree is preserved, it's still close enough to HTML for me, and all your accumulated knowledge about HTML is still applicable. (Not to be derisive, but if your years of learning are no longer of any use upon such a cosmetic change, you should probably examine your level of comprehension.)

The hopefully obvious answer to your question is to not generate markup in PHP (or any server-side language). These are the kinds of questions that Backbone, Spine, Ember, etc attempts to solve. You should look toward separating view concerns from your business logic and stop procedurally generating html in PHP.

I separate my concerns just fine using PHP. Different files, not different languages.

PHP IS a templating language. Writing another one on top of it is just adding complexity for no gain.

> If I make a string: '' . $var . ''

I'd say don't do that, refactor into templates instead. With your preferred approach to generating markup, you're largely on your own in protecting against XSS. Hopefully all the developers using your code are awesome at spotting and pro-actively dealing with XSS issues.

Still, with a HTML escape everything default, either turn it off, or use a raw "I know what I'm doing" method instead.

In Razor at least you'd create HtmlHelpers to output html, which returns a string that the system knows is html and you've already dealt with. It knows not to escape the string as you've explicitly said the string you're creating is markup.

You'd do something like @html.SalesWidget("90% off today") with the SalesWidget being responsible for escaping the string.

Also I don't really get your argument, why not give people a really short and easy way of not escaping a string instead? The opposite of what you're suggesting is just as easy and far safer. You're less liable to accidentally muck up.

Perhaps what we need is a language/platform that has built in strings that track not just the code page type encoding, but some kind of "intent assertion" as well -- is the string intended to be encoded for a particular output? Combining an "unknown" string with an HTML (or SQL, or PostScript, or JSON/JavaScript, ...) string would produce an exception.

Such a mechanism would have to include encoding functions (and assertion override functions), of course.

It seems this would help alleviate many types of fill-in-the-blank injection problems as well.

The Haskell frameworks do this, more or less: www.snapframework.com, for instance.

This problem has already been solved in the Haskell ecosystem [1]. For example, you get typesafe URLs so that if you have a standard query like myapp.com/person/345 you can't mistakenly misuse 345 as an article id. Every input string is tracked by the type system so the possibility for escape issues, injection attacks or cross site scripting exploits to sneak in is minimal. Static types also make sure that internal links can not be broken - if for example you decide to change the above URL to myapp.com/getperson instead, your application won't compile until you've fixed every other part that still references the old link .../person, and so on.

Not to mention the (also type safe) dead easy to use persistence framework.

I'm still in the process of evaluating different solutions for my next web project but so far I'm pretty sure this is gonna be my go-to framework in the future.

[1] http://www.yesodweb.com

GWT too. Not having escaping by default by now, in 2012, is just plain backward.

"And people find all sorts of real criticisms in the process - yet none of them matter!"

I'd like to mention something similar that I found in human behavior with respect to manufacturing jobs that we used to do for customers at a company that I was at. What we found was that people had 1 or 3 major complaints about something that were pretty valid. But what they did then was feel that they needed to build a strong case so they ended up coming up with as many nits as they could to build their case as if that somehow made the true concerns stronger. Just my experience but I have found that if you have a true concern about something to simply focus on trying to get that fixed. If you throw everything in the other party sometimes feels that they will never be able to please you and then they don't even try to fix anything. YEMV.

> 3. Imperative programming is IMHO a natural fit for Web programming.

I disagree with this, especially in a RESTful world. It is very convenient, and obvious, way to look at a web request as a referentially transparent function for the most part. And the non referentially transparent requests really do change the world. We are moving our backend to a bunch fairly clear workflow of, that has layers that look like:

Get DB stuff -> referentially transparent -> Write DB stuff

And these can be arbitrarily nested. It works pretty well, it's easy to reason about, and it's pretty easy to write.

I think you forgot an important feature of PHP: it just works.

I can pretty much create and "deploy" a PHP web app within minutes of getting a run-of-the-mill hosting service.

It's not a feature of PHP, it's a feature of the world. Had hosting providers put the same effort to make deployment of Python, Ruby or Haskell web apps, this argument would be void.

Similarly, LPG is a great car fuel here where I live, because of a good price and abundance of gas station, but it's not the case in the US.

I simply disagree with the premise. PHP has a lot going for it

Did we read the same article? Jeff admits that PHP has a lot going for it and we should stop complaining about it.

The biggest thing PHP has going for it is that it is supported everywhere.

> One thing that's wrong with PHP is all the bloated OO mega-frameworks people create on top of it to try and make it Java, Rails, whatever...

The thing that really fries my brain is templating systems built over frameworks -- PHP is already a templating system, and building another one in PHP is just silliness of the highest order. I mean, sure, separate out the gnarlies and include or require them as necessary (but, please, don't nest includes so deeply that you can't find anything anymore), but don't throw away what the environment provides just so that you can reinvent that particular wheel.

PHP is a terrible template engine; replacing it with something better is just obvious. I like to think of PHP's output mode as REPL for the web but not as a way of constructing templates in real-world applications.

I can add to this list:

5. The set of functions for a gazillion useful everyday things that don't come standard in other languages. Where else would you find functions like htmlentities(), strip_tags(), mysql_real_escape_string()? I like list comprehensions - Python can be very concise - but PHP isn't exactly verbose:

Compare, reading a web page:

http://rosettacode.org/wiki/HTTP#PHP

http://rosettacode.org/wiki/HTTP#Python

http://rosettacode.org/wiki/HTTP#Java

Sending an email:

http://rosettacode.org/wiki/Send_email#PHP

http://rosettacode.org/wiki/Send_email#Python

http://rosettacode.org/wiki/Send_email#Java

6. Navigating or searching the online documentation is lightning quick. You don't have to know the names of functions or variables, you'll find them. The examples are like mini tutorials.

7. The write-test turnaround is lightning fast. There's probably not a small group of languages in this group, but you will really notice this if you come from say, JEE.

You need (need!) a language that's fun to use (that's fun for you to use), day in day out, not verbose, nor loaded with layers of frameworks. PHP is simple, direct, and I haven't been bitten by problems that in other languages have taken days to work out... or have never been worked out.

Honestly, I have never been bothered by the humungous list of "issues" in the link at the top of Jeff Atwood's post.

BTW, === exists explicitly to test type equality first, that's the point.

When I wrote in PHP (and it lasted 10 years just to let you know), I would say exactly the same. PHP tasted better than, say, C++ Builder.

As we use to say in my country, "never tried things sweeter than carrot". I mean that was about me: I didn't know better things existed.

All that is done better in Python:

5. You don't need many of functions you use in PHP, for instance, _real_escape_string is not needed when you can do cursor.run("SQL Query param1=? AND param2=?", [param1, param2])

6. You can get help on functions in coding shell:

>>> help(open) # help on file opening function or even >>> open? # in IPython

With that I look into online or PDF docs quite rarely.

7. That's even faster in Python: you try things out in the shell, then save the shell session (IPython) and copy the code you need into the working file.

Moreover, while in PHP I was adding var_dump's everywhere, reloading a page 10 times before reaching the source of a bug, in Python I just do $ python -m ipdb same_script.py and have the debugging shell in the place I need, and it takes a minute of two to find the source of a bug.

The funny thing about #4 is that php has been making a lot of progress on that exact front. Register globals has not only been deprecated but removed. Mysqli is now the default means of talking to dbs. Meanwhile, you see very fundamentally similar issues in, say, rails not getting the attention they deserve because everyone assumes rails is well engineered.

I don't mean to defend php overly much. However, it can't be ignored that progress is being made at making php better.

There's a simple adage that a good tool makes simple things easy and difficult things possible. By that measure, PHP is a pretty good tool. Yes, other tools are better in various ways, but ease of deployment is a non-trivial quality.

(I did like the quote suggesting AppleScript is "even worse" than PHP. I'd say it's far worse, since AppleScript makes easy things difficult.)

Please don't use Facebook as an example, the fact they gave in and built HipHop to get it into C++ spoils it. Are they coding in PHP? Sure! Are they actually using it like it's meant to be used? Not quite!

Almost every web stack at the scale of a Facebook at some points starts writing some part of it in C. Its a pretty consistent pattern.

Hey. I work on Facebook's PHP toolchain, HipHop, which these days includes a debugger, interpreter, JIT compiler, and the ahead-of-time compiler. The fact that the AoT compiler uses C++ as a target doesn't change the input language, which really is PHP. E.g., $i = 0; $a[$i] = $i++; makes a different array than $i = 0; $a[$i + 0] = $i++;. We have to get all the nooks and crannies right because we use significant open source packages in PHP.

The developer's usual routine is the same as someone using Zend; they write honest-to-goodness PHP and reload the page. There is no compilation involved; you instead are using the JIT (or until recently, an interpreter) that monitors the filesystem for changes and silently integrates them.

Facebook devs use PHP exactly as everybody else does; they just do so with a different toolchain.

I have to ask, because it's really been getting at me for a while honestly. How do your developers react to that? I mean, you guys are known for going after the best and the brightest. People who have worked hard to perfect their craft. These people tend to have strong opinions when it comes to language design. How do you get them from that point to "ok, now write some php code" ?

That's easy: the best recognize languages are just a means to an end. Language snobbery, in my experience, tends to be highly correlated with being a "wannabe" rather than "great" and a useful filter.

You will find any number of C/C++ programmers who think you can't write anything in Java. Many Java programmers think you can't write anything (beyond 100 lines) in Python. Many Python programmers think you can't (or simply shouldn't) write anything in PHP. And so on.

Some people are insecure.

Some people can't separate their language from themselves (and see a criticism of their language as a criticism of them as people).

Some people exemplify the Dunning-Kruger effect [1].

Some, like teenagers, are just asserting their identities.

Some simply have biases that are mental blocks.

[1]: http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

Not all languages are equal. (if they are, why not just write everything in assembly?)

That's a well-reasoned but rather lazy response imo.

Ppl who have strong opinions when it comes to language design have strong opinions when it comes to language design. Ppl who think languages are just a means to an end think languages are just a means to an end. These are two differenty species and indicative of their particular worldview, attitude and preferences. To use that as any kind of filter is silly.

Lets not look at CS for a second...If you want to know what a Stieltjes integral is, a probabilist will tell you one thing, a functional analyst another, and a measure theorist will give you yet another more pedantic definition. There's no right or wrong definition here...every one is coming at it with the tools they are more well versed in. The probabilist is the end-user, so to speak. He can't do his day to day work without internalizing it, because his bread and butter, the PDFs and CDFs of all the distributions he deals with, comes from Stieltjes. The functional analyst is going to use Stieltjes when he deals with Banach spaces, but otherwise he has other preoccupations. The measure theorist studies Stieltjes in depth because it goes to the very foundantion of measure theory...but he isn't really an end-user.

Now back to CS...a C++ programmer will think of Java as an interesting toy because you don't get union types and pointers & so forth. The Java guy will think of Python as an interesting toy, and the Python guy thinks PHP is an interesting toy. None of this means any of these people are insecure or being a teenager. If the only goal in life is "languages as means to an end" where end = $$$ in the short term, then yeah, lets just cut to the chase and do PHP. But there are other goals, yeah ?

You have obviously never worked on a million-line codebase.

When you have crap like this in your language:

> E.g., $i = 0; $a[$i] = $i++; makes a different array than $i = 0; $a[$i + 0] = $i++;

you have no hope of making a truly large program work. There are just too many sources of itsy bitsy bugs; you'll never find them all.

(I'm not a PHP user; I have no idea why those are different arrays. Don't bother explaining; I don't want to know.)

I don't use PHP much, but I was curious, so here's the answer you don't want:

You get $a[1] = 0 the first way, and $a[0] = 0 the second way. PHP seems to evaluate the array index before the right hand side if there is something more than a $variable to evaluate; otherwise PHP evaluates the array index after the right hand side, after $i has been incremented.

I haven't used hiphop, but I'm curious if it preserves that disparity between arrays when translating to C++, or if it breaks PHP compatibility by making those two arrays equivalent.

The entire point of my post was that we preserve the semantics of this (and many other) PHP-isms. We have to, because you never can tell which glitches useful code has come to depend on.

I like how people who exemplify the Dunning-Kruger effect are entirely willing to cite it in order to look smart.

I'm not the best and the brightest, but I'm sure the people they are going after are more excited and concerned with the quality and quantity of problems that facebook is in the unique position to solve. They could probably care less what they use to solve said problems.

The best and the brightest appreciate the technical, product, and engineering challenges of Facebook and certainly don't waste their time whining about a language or feeling entitled.

Some of us like to write good code in a good language too.

Maybe you should be the one to stop being so arrogant as to tell other people what they should feel.

The aspects of PHP that are bad (and there are more than a few) are easily tooled around. We have a review-time tool that parses your PHP, symbolically executes it, and looks for dubious idioms, flagging them for you and your reviewer.

Meanwhile, PHP gets a number of things very right. For instance:

* State: there is none across requests. Oh sure, there's APC, and the filesystem, and databases, etc., but those are all accessed via libraries. There is no PHP-level state that survives a request, which provides natural fault isolation: a request which goes wrong doesn't take the server down with it, or live on to corrupt other requests.

* Concurrency: PHP's concurrency model is the web request. If you want to run some code in parallel, curl to localhost. If you wrap an appropriate library around this, it looks just like Erlang's actors. This is shared-nothing concurrency, which turns out to be a compelling local maximum.

* Interactivity: The development workflow PHP provides is very productive. You save and load the page. You don't save, optionally recompile, restart the server, wait for it to initialize, forget what's different from the last three times you tried this because this has all taken three minutes and you forgot to write it down, etc.

These three things turn out to be among the most important parts of a server-side language, and PHP gets them very, very right. The rightness was accidental, not by design, but this doesn't make it any less right.

Also, the language itself can be improved. In the HipHop toolchain, -v Eval.EnableHipHopSyntax=true turns on a bunch of (backwards-compatible) features we've added to our PHP dialect, the most notable of which are XHP (syntax for using XML literals as PHP expressions) and generators (inspired by Python's, using similar 'yield' syntax). I put up some sample code for a talk just the other day, if you're curious: https://github.com/kmafb/hiphop-samples

Is that tooling you mentioned related to/uses 'pfff' ? (https://github.com/facebook/pfff)

Yes, exactly. Thanks for mentioning it.

>These three things turn out to be among the most important parts of a server-side language

So the language does two of these three things by not doing them at all ? State: oh there's no state across requests. Concurrency: No shared resources, no threads, but we'll call it shared-nothing concurrency and then say it looks like Erlang!! Amazing. An Erlang actor holds mutable state and sends immutable messages. A web request in PHP does neither.

> If you want to run some code in parallel, Why do you even bring up parallelism in a post about concurrency ? ( http://news.ycombinator.com/item?id=3837147 )

> PHP gets them very, very right. The rightness was accidental.

Completely agree. Here you have a language that decides to tackle hard problems in CS by not tackling them. Then it becomes uber-pervasive because you can do "hello world" over the web by just doing <?print("hello world");?> Once the traction is a given, we argue about why not tackling hard problems is actually "very, very right".

Nobody's asking you to like PHP. I'm explaining why it's effective; if you'd like to build something better, there are affirmative lessons to learn from PHP's undeniable successes. While your point about Erlang is correct for pure PHP, one of the nice things about the "curl as concurrency model" world is that the thing on the other end of the curl doesn't have to be PHP, or stateless.

Getting "hard problems" right by realizing they're intractable and refusing to solve them is a perfectly valid system design choice, even though it drives people up a wall when they first encounter it. For an example that has stood the test of time, check out UNIX's handling of the "PC-losering" problem: http://dreamsongs.com/WIB.html. When modern systems people read about this controversy, it seems kind of insane; of course system calls can be interrupted, and of course you don't want the OS to be magically trying to make them look transactional by backing up and restarting your system call when the world is really in an unknown and unknowable state. Ctl-C on a read() shouldn't restart the read(), unless the application thinks it should, and only the app really knows. EINTR was the non-solution that acknowledged the intractability of solution.

Historically, UNIX is a "worse-is-better" system not unlike PHP. I claim anyone designing a new system from scratch to replace it should learn from it, though, both mistakes and successes. PHP is not free of successes.

Well, except that PHP has access to the database, sessions, cookies and the filesystem. There's a whole bunch of state right there.

It also has a variables and instruction pointer. The point is that this state is not preserved between different requests.

The point is that it's still shared state, so it's possible in practice to take down your server if you manage to corrupt your database or a file on your filesystem.

About the only thing you're protected against is memory leaks, and that seems to be because you have to, otherwise PHP would fall over in a big heap: https://www.google.com/search?q=php+memory+leak

I haven't had any problems with memory leaks running things like Django or Bottle.

I should have expected someone with more knowledge of the system on HackerNews :)

What I mean is that whilst you guys at Facebook are using PHP you're not using it in the sense of 'we write code anywhere and deploy it anywhere'. There's an additional build step in between the developers and the final product, rather than just straight up serving PHP as is which is one of the biggest PHP recommendations. Although HipHop is open source so I guess you could still say it's within reach of all developers.

> ... 'we write code anywhere and deploy it anywhere'. There's an additional build step in between the developers and the final product, rather than just straight up serving PHP as is which is one of the biggest PHP recommendations.

According to him there's no explicit build step the devs have to perform and they're just writing PHP and using open source packages--meaning they are in fact making use of the "write once run anywhere" ideal at least in some places since the open source packages were made to run on Zend and now they don't. The "write once run anywhere" ideal is kind of a myth anyway since there's always configurations to do, and language-wise was even more of a myth when PHP 5.3 was new. (Some hosts still don't support it, and I'm sure a lot of us remember hosting services who dragged their feet just getting off PHP 4.)

It seems like you think the Zend backend is the One True PHP runtime and anything else isn't PHP. This is like saying PyPy isn't Python. It's just a bad argument.

Hm, I possibly need to clarify it up a bit.

Now, as far as I understand it the Zend backend takes the PHP code, creates opcodes and executes it in a VM, whereas HipHop takes the code, compiles it down to C++, compiles it again with G++ then runs the resulting C++ binary instead. To me at that stage HipHop is no longer a backend, but an entire build system transforming the language away from PHP.

Like I said, I'm not as intimately familiar with the system, but I thought it was along the lines of they have a dynamic system for local development, and when they serve it up it's run through the HipHop compile process.

I'm still curious why the target is C++ and not LLVM or a direct ISA. AoT seems very useful, using PHP as a language and not a runtime at least in deployment.

His post irritated the hell out of me. For 90% of it, he rips on PHP, then at the end he says, "how about bloggers stop ripping on PHP?"

Hey guys, Jeff said his piece about PHP, everyone else shut up about it now.

You do have a point, this seems to be a fairly common way to vent yet still appear 'objective'. I do it myself sometimes, and occasionally pick myself up on it... mainly when I get away with it. :)

I sense this is probably done quite a lot in journalism, so you can write 'interesting' articles without coming off like a completely biased douche.

I am damn tired of his takes on PHP. It's damn pissing off to see the kind of points he puts in his posts.

I don't even get the part where he says that we need to come up with better solutions. So, if we want better solutions when are they going to arrive. It's not like that the solutions are getting baked in some oven or something.

We have new solutions that we can use. We may even call them better, but I don't think that I will quit a language just for the fun of using something new.

PHP might be st, it might even break at times, but there are some wonderful frameworks which have come up lately. Laravel is one of them and a number of developers are contributing to the code. One cannot just ignore the fact that so many people have gone mad and not even a single one of them actually felt the need to quit PHP forever and build a new language that is better than it.