Author's credentials: not enough knowledge about PHP's development?
Posted Dec 25, 2006 4:56 UTC (Mon) by erich
In reply to: Author's credentials: not enough knowledge about PHP's development?
Parent article: The state of PHP security
Sorry, but your post is typical - in lack of hard facts, you attack him because of his CV. Very lame, dude! Then next you go after perl - "see, the dinosaurs are extinct, too, so we can just die as well!".
And the author did pretty much state your opinion in his article, too: "PHP proponents tend to take a 'blame the user' approach that is reasonable in some ways, but fails to recognize some of the inherent issues with PHP itself" - there you go, fits you dead on.
"with reasonable default security"
ROFL. Don't tell me anybody during the design of PHP really thought about security. It's been about legacy compatibility mostly.
There is more stuff that's wrong with PHP. For example the way it's embedded in HTML, and actually encourages that. People should be offered an easy to use template language (preferrably one where they can edit the HTML with their favourite GUI editor, talking about easy-to-use...) and some variable mapping. Have a look at Kid, Genshi, TAL/METAL, XML::Template (also available for PHP).
Your comparison with perl is very unfair. Perl has been around for even longer than PHP, and it was NOT DESIGNED to be a web development language, but for writing regular applications. It was not designed for security on the web either (though tainted mode is a great feature; just that many people don't know how to use it, just like they don't stop using register_globals). It was designed for chewing texts quickly, with a really compact syntax.
Still, the typical Perl CGI has fewer security issues compared to a typical PHP script out there, so who is the "glass programming language".
/me uses Python for his stuff. Much easier to read than PHP hidden in HTML.
Ruby has some nice sandboxing concept, that sounds useful for secure web programming...
A comment to the meeting notes:
"this is a moot point as we need to have different contexts (SQL, output...) and this can not be checked without knowing the application."
Oh, and Perl doesn't have SQL?
to post comments)