5 ms·

I'm spending most of my time maintaining a web application consisting of around 150k lines of PHP code. We (well - initially, it was just me) began development

by pilif 16y ago

I'm spending most of my time maintaining a web application consisting of around 150k lines of PHP code. We (well - initially, it was just me) began development back in 2004 but since then the application has grown constantly. Back in 04, I already felt some reservations against PHP, but that's what I knew best and that's what was most used for the web (Rails might have been around, but not really known - other ruby options were not quite there yet. Python I disliked and Java I. don't. touch.). The application was written in PHP5, initially developed on some RC of 5.0.0 and I was careful to keep a clean style and not using deprecated code. This lead to a quite clean application that I could really be proud of. And still: While it has suffered from sometimes not quite reasonable customer demands, it's still very good at what it's doing and while there might be some dead bodies rotting in the code, it's nowhere near daily WTF material (aside of some bugs we have a good laugh at and fix shamefully). Still. I have some bad gripes with PHP that made me stop doing anything new in that language. I can easily live with the usually quoted problems though: - parameter order in library function? I don't care - my IDE lists them. - Huge base library? I don't care as the stuff I don't need doesn't cost me anything but disk space and the stuff I do need, I'm glad is there. - No namespaces? Yeah. Bit me a couple of times, but I can work around that - besides, with 5.3 we got namespaces, so this doesn't count any more - Performance issues? It's fast enough for said application. - Security? It's just as secure as any other language you can write insecure code in (i.e. all of them). - Allows intermixing of layout and code? Sure, but you don't have to. If you have any sense what so ever, all requests go through a central /index.php and all other code is in some not-publicly accessible location and emits no html what so ever. All output is generated using any of the thousands of templating libraries. What really disturbs me about PHP is its type conversion rules. 1 == '1' or even worse 'foobar' == 0, or '123n' == 123. This is cause for so many subtle bugs. Just use === you tell me? Sure, but then you clutter your code with an insane amount of isset()'s and isint()'s and whatnot - the fact that the database library I'm using (pgsql) returns everything as strings doesn't help that cause either. The other thing is the really clumsy syntax. Array literals, anonymous functions, closures (with explicit declaration of all variables of the outer scope you want access to), operators, even just the lack of named function parameters. The syntax is clumsy and all the elegant code you see even from JavaScript just gets bloated and unreadable once you port it to PHP. These two issues made me do stuff in Ruby, Python(3) and lately a lot of Node.js, but the maintenance of that huge application remains to be the main part of my day-job and even though the two issues really bug me, it's still not painful enough to really be complaining (or, heaven forbid, port the thing to whatever-other-language-thats-currently-hip). So in retrospect, while I'm as die-hard a PHP user as you can get with many, many lines of PHP under my belt and while I do find some of the stuff highly enjoyable (php's arrays that are also ordered hashes for example. Or the really easy and accessible web-server/HTTP integration), I also dislike it quite a bit to the point of being unwilling to start something new in PHP.

mfukar 16y ago
It's just as secure as any other language you can write insecure code in (i.e. all of them). That may be true; I've only developed two half-serious projects in PHP a while back. But given the amount of XSS and injection vulnerabilities we're seeing daily, I think that something is wrong with those web development guys. PHP is admittedly a widely used tool and I can't help but wonder: "Could it be just the language? Is there a possibility things would be better if PHP was abandoned?". Of course things would improve if we educated all PHP developers on the security implications of whatever it is they're programming. But so many years of coding have shown it's infeasible (for any language).
- generalk 16y ago
  Is there a possibility things would be better if PHP was abandoned? Nope. Beginning coders write vulnerabilities until they're otherwise educated. In PHP these are SQL injection and XSS holes. In C they're buffer overflows. Of course things would improve if we educated all PHP developers on the security implications of whatever it is they're programming. But so many years of coding have shown it's infeasible (for any language). Education is feasible for any language. Some segment of the programming population will always remain uneducated -- laziness or apathy on their part -- but this doesn't mean education doesn't work.
  - mfukar 16y ago
    You mean to tell me that in a world where anyone could take up on any programming language and start writing code on one's own, properly educating that someone is feasible? Please. This isn't 1960 anymore. Code is not written by "scientists" exclusively anymore.
- pilif 16y ago
  up until very recently, no templating language provided XSS protection by default. Rails sample code you see in the various tutorial for example still is full of <h1><%= title %></h1> which for all versions of rails < 3 is an open door for an XSS attack. PHP had a filter extension that helps with this for ages, but it's not on by default and not widely used by the various projects which hope/need to still run on up to 10 years old versions of PHP. We'll see how the common Rails user will react to all text injected into ERB being escaped by default. I'm sure this will cause rants like http://news.ycombinator.com/item?id=1162122 http://news.ycombinator.com/item?id=1162122 which was complaining that ruby 1.9's string handling became "so complicated". "but... I just want to allow the user to type HTML and to display it - why do I have to go all these lengths to accomplish that?"

by pilif 16y ago

mfukar 16y ago

It's just as secure as any other language you can write insecure code in (i.e. all of them). That may be true; I've only developed two half-serious projects in PHP a while back. But given the amount of XSS and injection vulnerabilities we're seeing daily, I think that something is wrong with those web development guys. PHP is admittedly a widely used tool and I can't help but wonder: "Could it be just the language? Is there a possibility things would be better if PHP was abandoned?". Of course things would improve if we educated all PHP developers on the security implications of whatever it is they're programming. But so many years of coding have shown it's infeasible (for any language).

generalk 16y ago
Is there a possibility things would be better if PHP was abandoned? Nope. Beginning coders write vulnerabilities until they're otherwise educated. In PHP these are SQL injection and XSS holes. In C they're buffer overflows. Of course things would improve if we educated all PHP developers on the security implications of whatever it is they're programming. But so many years of coding have shown it's infeasible (for any language). Education is feasible for any language. Some segment of the programming population will always remain uneducated -- laziness or apathy on their part -- but this doesn't mean education doesn't work.
- mfukar 16y ago
  You mean to tell me that in a world where anyone could take up on any programming language and start writing code on one's own, properly educating that someone is feasible? Please. This isn't 1960 anymore. Code is not written by "scientists" exclusively anymore.
pilif 16y ago
up until very recently, no templating language provided XSS protection by default. Rails sample code you see in the various tutorial for example still is full of <h1><%= title %></h1> which for all versions of rails < 3 is an open door for an XSS attack. PHP had a filter extension that helps with this for ages, but it's not on by default and not widely used by the various projects which hope/need to still run on up to 10 years old versions of PHP. We'll see how the common Rails user will react to all text injected into ERB being escaped by default. I'm sure this will cause rants like http://news.ycombinator.com/item?id=1162122 http://news.ycombinator.com/item?id=1162122 which was complaining that ruby 1.9's string handling became "so complicated". "but... I just want to allow the user to type HTML and to display it - why do I have to go all these lengths to accomplish that?"