Slashdot Mirror

As a programming language, PHP is simple. Simple to learn, simple to write, simple to read, and simple to debug.

PHP is not a simple language. A keymark of a simple language is consistency, and PHP is anything but - I won't even touch on the mess that is the standard function library, but just the language itself. For example, this gem, taken directly from the language spec, regarding array indices/keys:

A key may be either an integer or a string. If a key is the standard representation of an integer, it will be interpreted as such (i.e. "8" will be interpreted as 8, while "08" will be interpreted as "08"). Floats in key are truncated to integer. The indexed and associative array types are the same type in PHP, which can both contain integer and string indices.

This is awesome on many levels. The obvious fubar is the treatment of "8" vs "08" (and note that, while it is clearly obvious when a string literal is used in the source code, how about a string variable, or other expression computed at runtime?). But the bit about silent float->int truncation is also interesting, especially the "silent" part. Combined with rounding errors and the overall non-obviousness of binary floating-point arithmetic (especially to a typical PHP coder), this design decision is just hilarious.

I've long held the opinion that C/C++ rules on mixed signed/unsigned arithmetic and comparisons are a good example of awful language design, but PHP beats that by a margin so large it's not even funny.

Oh, I also don't know of any other language that has what effectively amounts to synactic sugar for try/catch with an empty catch block. Good programming practices FTW!

I find it curious, by the way, that PHP coders like to compare the language to C++ or Java - where it actually has some subjective advantages, such as dynamic typing - but very rarely to Perl, Python or Ruby, where all such advantages disappear, but design flaws immediately stand out.

Facebook uses Alternative PHP Cache and has contributed a lot to the project.

some quick points :-)

1. Garbage collectors are comparatively expensive at runtime.
2. "But let's run with it for a second. In PHP, I don't even have to count this part. In places where I do miscount, the interpreter will probably yell at me." ... and you pay a heavy price for that. Interpreters are SLOW. All that extra checking is also slow.
3. As for php memory leaks, you could have just searched. Here's one. http://bugs.php.net/bug.php?id=37929 Every server child process instance would leak 21 meg. The first time, so if you had 100 children, you could leak 2 gig.

php is a dog. I still use it, but I'm aware that it's a dog and that there ARE better ways - just that it's always a trade-off between development resources and run resources. For apps running like facebook, it's probably cost-effective to slowly switch pieces from php to c that are going to be more-or-less static.

Plus, php deliberately doesn't let you execute multiple statements with one call

I beg to differ...

Plus, php deliberately doesn't let you execute multiple statements with one call - anything after the first semicolon is stripped from your query as a "security measure". Same with php and postgresql.

Of course, if you're really into optimizing your code, you'd be using precompiled stored procedures and passing in parameters and not executing raw SQL, which suffers from the "must be interpreted" problems you ascribe to PHP.

Plus, php deliberately doesn't let you execute multiple statements with one call - anything after the first semicolon is stripped from your query as a "security measure". Same with php and postgresql.

Of course, if you're really into optimizing your code, you'd be using precompiled stored procedures and passing in parameters and not executing raw SQL, which suffers from the "must be interpreted" problems you ascribe to PHP.

PHP reuses a connection within a script but afaik every time a client requests dbrequest.php from the browser that script loads in its own little world and starts up its own personal connection to the server

Incorrect, PHP can indeed maintain persistent DB connections across multiple requests.

http://php.net/manual/en/function.mysql-pconnect.php

"the connection to the SQL server will not be closed when the execution of the script ends"

1. http://uk2.php.net/manual/en/intro.apc.php

Can't be bothered reading the rest of your post, real men use assembler.

You're still initializing your interpreter for EACH result set. Once you add an interpreter to the equation, you've already lost the race. With c, you only need a struct with pointers to the variables you actually use - a lot more compact - and since the actual values are not copied into the interpreter and then copied back out of it, then back into it again, then flushed, you save a lot of time AND memory.

Plus, php deliberately doesn't let you execute multiple statements with one call - anything after the first semicolon is stripped from your query as a "security measure". Same with php and postgresql.

This is to help prevent sql injection attacks. For example, someone can't put their user name as "joe blow';drop table users';select 'hacked" (notice the embedded single quote before the semicolon) so that "select pw_hash from users where user_name='$username'" doesn't become "select pw_hash from users where user_name='joe blow';drop table users;'select 'hacked';"

Of course a c program has to do sanity checks on data as well, but it's a lot easier. For example, if you KNOW that you'll never get a response from the end user that's longer than 2k, as soon as you exceed that limit, stop reading from the socket, send a server redirect to goatse.fr, and close the socket. This way, you don't end up with someone doing a DoS on you with multiple loooooooooonnnnngggggggggggggg requests. You can also set it so that if the bytes don't show up within n time, close the socket anyway - so no tarpits.

Hope this helps :-)

You're still initializing your interpreter for EACH result set. Once you add an interpreter to the equation, you've already lost the race. With c, you only need a struct with pointers to the variables you actually use - a lot more compact - and since the actual values are not copied into the interpreter and then copied back out of it, then back into it again, then flushed, you save a lot of time AND memory.

Plus, php deliberately doesn't let you execute multiple statements with one call - anything after the first semicolon is stripped from your query as a "security measure". Same with php and postgresql.

This is to help prevent sql injection attacks. For example, someone can't put their user name as "joe blow';drop table users';select 'hacked" (notice the embedded single quote before the semicolon) so that "select pw_hash from users where user_name='$username'" doesn't become "select pw_hash from users where user_name='joe blow';drop table users;'select 'hacked';"

Of course a c program has to do sanity checks on data as well, but it's a lot easier. For example, if you KNOW that you'll never get a response from the end user that's longer than 2k, as soon as you exceed that limit, stop reading from the socket, send a server redirect to goatse.fr, and close the socket. This way, you don't end up with someone doing a DoS on you with multiple loooooooooonnnnngggggggggggggg requests. You can also set it so that if the bytes don't show up within n time, close the socket anyway - so no tarpits.

Hope this helps :-)

one of the things you don't generally see with PHP code is a buffer overflow, where you try to copy a bunch of strings and concatenate them together and you run out of room and don't notice it and you go clobbering memory. That's because the string manipulation code goes through a bunch of checks when you're appending strings.

And this is one of the great ironies of PHP... while there *have* been a number of vulnerabilities in PHP-based applications, that's more an artifact of the unqualified developers that the language's ease-of-use tends to attract.

PHP offers quite an impressive number of security-related features that make horrible, difficult-to-solve security problems almost a non-issue. PP example of string appending is but one of far too many to name, yet it's one that's the cause of the vast majority of security issues in software, everywhere!

What's that, you say? The #1 cause of security issues has been all-but-eliminated in a programming language that's often chided for security issues? Doesn't really make sense, does it?

And then, on to what is perhaps the #1 cause of security issues for database-driven product - the dreaded SQL injection error. Yep, that one has been solved too!

Yes, you can use PHP to write an insecure application. But you can use an SUV with seat belts and airbags to kill yourself, too. When discussing security, PHP doesn't get anywhere near the respect it otherwise deserves.

Only easy when using sane languages.

But it used to be very difficult to do the right thing with PHP.

The PHP developers were either incompetent or malicious. Evidence: they created insane stuff like addslashes, magic_quotes and even mysql_real_escape_string.

See: http://php.net/manual/en/function.mysql-real-escape-string.php

Fortunately they eventually introduced stuff like PDO (but there was some confusion in the days of PEAR::DB).

And we didn't get stuff like "mysql_definitely_the_real_escape_string_now_no_really" ;).

But why didn't they just copy other people and introduce stuff like PDO right at the start?

No namespacing.

What you mean is that PHP doesn't force namespaces. It has them, just no one uses them.

No Asynchronous execution.

That is not particularly relevant for a web programming language where a new process starts, runs code, and exits. You can't safely have background threads in that circumstances. It makes it really hard to write daemons in, but not for web programming.

Non-standard date formats

This just baffles me. Do you mean the DateTime object?

I've always stored dates as a Unix timestamp in PHP.

Dangerous stuff like "Global"

That is a valid point.

Without Zend-acceleration its incredibly slow.

All languages can be incredibly slow if you run them wrong.

If you're not using eAccelerator or Zend or Xcache or another bytecode cacher, you're running PHP wrong.

Now, you want to argue that a bytecode cache should be included within PHP, just like it's in Python and whatever, go right ahead.

No, not those, but benchmarks which measure actual web performance, not merely fibonacci.

Try these. Note that when we actually compare a full framework (Cake vs Rails), Rails is faster, and Merb is much faster. When we try to compare closer to the bare metal (raw PHP), we find that the Merb controller is almost as fast, and the Merb router is much faster.

Also, the page you linked to links to this, which is actually less about PHP and more about your app in general. Ruby may be the bottleneck more often than PHP, but still far less than database design, front-end (HTML/etc) design, and your own stupid mistakes.

Well, only if you care even remotely about having some level of security. Surely you've run into a website (typically a forum) that has a ?sessid=2387498798ad87c2eea92 querystring. It's hideous and stupid, but technically you CAN use cookie-less sessions (see: php: session.use-cookies).

...PHP doesn't even come close in this regard

ah so PEAR doesn't count? http://pear.php.net/

Ever look at a system and think to yourself, "every time the developers had a choice in designing this thing, they chose the wrong option"? I can think of a couple. Symbian is definitely in that class. It has:

• Drive letters. Enough said.
• Backslashes as directory separators
• Pervasive DRM, with code signing and a pay-us-to-access-more-OS-features capability model
• A bizarre and perplexing C++ API based on manual exception management, with too many kinds of string class to count
• "Active objects"
• Non-POSIX filesystem semantics
• A microkernel architecture for devices least able to afford the overhead
• Very strange application deployment consisting of several disparate directories with magical names

All in all, the sooner Symbian dies, the better off I am. I might have been slightly kinder if they hadn't tried to prevent my running my own code on my own machine. No, I'm never getting another Symbian device.

Flash might be great for action games, but I'd really like to see support for PHP in some mobile phone. There's already PHP-GTK [php.net] and several other frameworks that let you do it in Windows/Linux. Powerful, and still easily learned and used language would make wonders in mobile development (man does Symbian C++ suck) and because PHP has so many functions and api's build-in, it would be easy to program lots of things quickly for your phone.

There are many problems with PHP in the scenario you describe (and many others):

1. The existing implementation is very slow. Heck, it's slower than Ruby, much less Python or Perl! On the web, this can be kinda-fixed by caching, but for a desktop application there's no such dirty tricks available.

2. Its "many built-in functions and APIs" are an extremely inconsistent mess. Part of it is to blame for the lack of namespaces until recently. Another part is for the fact that most APIs are really, really old, and don't even use OOP constructs where it would make sense. Yet another is that they just don't have any coherent design.

3. It is an exceptionally poorly designed language, with a record of nasty hacks like autoglobals and "magic quotes" - gladly most of that stuff is cleaned out now, but it sure took a while. Even today, it has way too many implicit conversions than is reasonable, hence the need for things like operator ===, and some very weird rules for associated arrays - like $a["9"] being the same as $a[9], but not the same as $a["09"]. It's also the only language I know that has a convenient single-character operator, the sole purpose of which is to silently swallow errors, including critical ones. For you C++/C#/Java guys, this is akin to having syntactic sugar for try { ... } catch /* everything */ { /* do nothing */ }. I hope I don't have to explain why it is a horrible idea, nor why having it in the language doesn't say anything good about it.

4. This one should be considered in light of 1-3 above. For all the nasty bits of PHP, its ultimate sin is that it doesn't offer absolutely anything over Perl, Python or Ruby. It's not simpler then them, neither as language, nor if we consider the standard library (comparing PHP standard library to that of Python quickly exposes the former for a disorganized mess that it really is). It's not more powerful. Its rules are generally more convoluted (okay, not in the case of Perl...). It's not safer - for the most part, the differences push programmer towards making more mistakes, not less. And don't forget about implementation quality, especially the perf part.

PHP is actually a lot like MySQL - a bad-to-mediocre product that has a lot of far better alternatives, and is only popular because at some point in the past it happened to be in the right place at the right time, and then its popularity became self-sustaining - people use PHP/MySQL because there are many other people using PHP/MySQL, because there are plenty of books on it (most of which are "learn in 5 minutes" crap promoting bad practices), and because there are plenty of cheap or free PHP/MySQL hosters. So popularity is the sole benefit there; everything else is inferior to competition.

Gladly, just like MySQL seems to be waning lately, with PostgreSQL picking quite a few of its users, so is PHP rapidly losing ground to Python and Ruby. Sanity restored!

Flash might be great for action games, but I'd really like to see support for PHP in some mobile phone. There's already PHP-GTK and several other frameworks that let you do it in Windows/Linux. Powerful, and still easily learned and used language would make wonders in mobile development (man does Symbian C++ suck) and because PHP has so many functions and api's build-in, it would be easy to program lots of things quickly for your phone.

Is the open source solution close enough to the needs of the Ontario government that, as the article alleges, all you need to do is buy some servers and set it up and there are negligible other costs? I seriously doubt it. I would be willing to bet heavily against it. Anyone who thinks otherwise probably hasn't spent much time developing software for government.

I haven't, no...but what are said needs?

I'm assuming that the main component of a record system is going to be a database. You'll also need a usable system and interface for entering and retrieving said records into the DB. You're also going to want to do SQL dumps and periodic offsite backups, so that if anything goes wrong, you can get the data back.

Of course, it will also be very important to ensure that the operating system the database is hosted on, is as robust as possible, to minimise the possibility of crashes; as well as a strong filesystem for times when you need to make a lot of queries at once. Even though that system is meant for servers, you can still make it user friendly for your administrative staff as well, if you need to.

If you're going to want the records accessible from outside the hospital, you'll probably also want to make sure that they are protected by a couple of very secure firewalls, as well, since it could potentially mean the loss of someone's life if they get cracked.

Finally, they will need to make sure that whoever puts the network together does so according to sound administration principles, as well.

I guess need to provide the chewed fish, not the fishing pole...

I guess I've also wondered why can't python, perl, php... have a modified language fork, so that they can be precompiled?

I can't speak for Python and Perl (don't use them often enough), but PHP has a number of extensions that support bytecode caching, such as eAccelerator and APC. It's not pre-compiled, but it does mean that a given script only has to be compiled the first time.

It appears that PHP, upon seeing an incoming parameter with a name that ends in [something] (where something may be empty), automatically turns that variable into an array.

How many of you PHP developers out there knew that?

I think any PHP developer would know that. But, you still need to access that variable from $_GET / $_POST / $_WHATEVER, it doesn't magically appear in your app (with sane defaults like register_globals = off). If you do but don't bother to filter your input, you can't blame PHP for that.

Can someone help debug my php? 20 $i = 1; 30 while ($i != 10) { 40 $i++; 50 }

I found the problem, you don't have any GOTO in your BASIC, err, PHP code!

My recommendation as a first language would be PHP. The nice thing about scripted languages is no compile time! So you can write your code and test it instantly. PHP also provides nice error handling to help you debug.

I used to like PHP, but today I would recommend Python or Perl over PHP any time.

I wouldn't say PHP provides nice error handling; in my experience a proper try/catch implementation/whatever is way more beneficial when you're striving for an even somewhat modularised design than the try/catch hack PHP implements - at the moment, there is a base Exception class which is extensible by the programmer, however, this (at least as of PHP5) isn't used or extended by any of the built-in functions/modules - instead, they take the (PHP native) functional error handling paradigm by "triggering" errors (and returning an error-indicating value) which can be caught at top application level. PHP6 might make up for this with the PHP STL, though I'm sorry to say I wouldn't set my hopes too high for that.

As for myself, I started out with some basic HTML/CSS/JS, then Visual Basic 6 and Borland Delphi, went on to learn classic ASP, quickly switched to PHP, where I stayed for a couple years, then I learned more advanced JavaScript and picked up C++ and Perl and am now learning Java and Python.

My recommendation as a first language would be PHP. The nice thing about scripted languages is no compile time! So you can write your code and test it instantly. PHP also provides nice error handling to help you debug.

I used to like PHP, but today I would recommend Python or Perl over PHP any time.

I wouldn't say PHP provides nice error handling; in my experience a proper try/catch implementation/whatever is way more beneficial when you're striving for an even somewhat modularised design than the try/catch hack PHP implements - at the moment, there is a base Exception class which is extensible by the programmer, however, this (at least as of PHP5) isn't used or extended by any of the built-in functions/modules - instead, they take the (PHP native) functional error handling paradigm by "triggering" errors (and returning an error-indicating value) which can be caught at top application level. PHP6 might make up for this with the PHP STL, though I'm sorry to say I wouldn't set my hopes too high for that.

As for myself, I started out with some basic HTML/CSS/JS, then Visual Basic 6 and Borland Delphi, went on to learn classic ASP, quickly switched to PHP, where I stayed for a couple years, then I learned more advanced JavaScript and picked up C++ and Perl and am now learning Java and Python.

My recommendation as a first language would be PHP. The nice thing about scripted languages is no compile time! So you can write your code and test it instantly. PHP also provides nice error handling to help you debug.

I used to like PHP, but today I would recommend Python or Perl over PHP any time.

I wouldn't say PHP provides nice error handling; in my experience a proper try/catch implementation/whatever is way more beneficial when you're striving for an even somewhat modularised design than the try/catch hack PHP implements - at the moment, there is a base Exception class which is extensible by the programmer, however, this (at least as of PHP5) isn't used or extended by any of the built-in functions/modules - instead, they take the (PHP native) functional error handling paradigm by "triggering" errors (and returning an error-indicating value) which can be caught at top application level. PHP6 might make up for this with the PHP STL, though I'm sorry to say I wouldn't set my hopes too high for that.

As for myself, I started out with some basic HTML/CSS/JS, then Visual Basic 6 and Borland Delphi, went on to learn classic ASP, quickly switched to PHP, where I stayed for a couple years, then I learned more advanced JavaScript and picked up C++ and Perl and am now learning Java and Python.

The site is running Apache on Red Hat Enterprise Linux 5, and it looks like Drupal running on PHP. What more do you want?

Getting a web page clean is a hard problem ... when you accept user input in something approaching HTML format, like /. does

No it is not. Have php run the user input through tidy. Even if it doesn't display as the user wanted in their browser, at least it displays consistently between browsers which is more important imho. Just go. Install it now in php. Seriously, if you are not checking html code coming in from users, something is not right. They could destroy your page with some of those unclosed tags.

PHP supports PostgreSQL its as simple as doing a global find-replace of mysql_ with pg_ there done. Okay a bit too simple but the mysql functions and the pg functions have the same names other than the prefixes and they behave in the same exact manner.

... or you could just use PDO, the way God intended.

Well actually that's what the SPL extension aims to achieve.

http://ca.php.net/manual/en/intro.spl-types.php

If you want a stronger typed language, this is your solution.

Theres a list of functions deprecated in PHP 5.3. I can't find an official list for PHP 6 though.

You can also read the official release announcement instead of some random guy's blog.

http://php.net/releases/5_3_0.php

GOTO has its uses. I never used it (as I prefer a more structured way to code), but critical mission error handling may take advantage of a more direct way to "jump". Anyway, one excepcional addition to the language is closures. Real anonymous functions were missing for a long time on the language, and it is great to have it now. Now it is only a matter of our customers' hosting providers to update their versions of PHP. Oh, well, considering most just migrated from PHP 4 to 5 (thanks to the EOL last year), it may take some time.

Pffft. If you're going to say that, you had better include the link to the documentation: http://us.php.net/goto

... scroll down.......

If you're going to spam with non-ASCII characters, at least do it right.

Doofus.

Unfortunately you are incorrect at how easy it is to prevent these issues. In some examples, you want the input to come through as HTML that is allowed to be displayed back to the end users. An example of this is MySpace.com (or even the commenting system here). Do you remember the Samy worm that crawled through their system? The techniques you have given would not have worked. An advanced parser that validates the input is necessary to prevent that (by stripping out the bad portions of the data). I was tasked with creating such a parser for a website I worked on (emerciv.com) to prevent the XSS attacks like that from occurring (and also the problem with invalid HTML that can break page flow). Furthermore, mysql_escape_char is not the industry preferred method of preventing MySQL injection attacks as it still allows some to occur; the preferred method is to use PDO. You might want to study up on those...

Oh, and by the way, I am a software engineer (finishing up my Master of Science in Software Engineering with a focus on Knowledge and Information Engineering from the University of Michigan's Dearborn campus at the end of the summer and have been asked by the Electrical and Computer Engineering department chair to create new curriculum for the undergraduates in interactive web development, and will be teaching it as well) and I consider myself a PHP developer (amongst other languages) and take offense to that ;)

for a 'taint mode' in PHP, try this: http://wiki.php.net/rfc/taint

We repeat the same lessons every generation, don't we?

We have our own terrible business languages, our own non-relational databases*, our own stupid development fads, our own overwrought RPC protocol, our own profoundly ignorant ways to "disable" things for the user, our own wasteful incompatibilities, our own locked-down propretiary platforms, and the same casual disregard for proper security.

This industry has no sense of its own history. Instead of benefiting from the innumerable hours past programmers spent solving universal problems, we ignore and reject their work, and with only a few exceptions, we spend countless hours solving solved problems.

By the time we work through the mess, another generation of programmers will have rejected our work, and will be well on the way to repeating the cycle. It's depressing as hell.

(Come to think of it, I don't think I've ever written a post that offended so many software developers simultaneously.)

* RDBMs systems didn't come first; people started using them over navigational databases for good reasons that still apply today.

For all those people complaining about PHP 4/5 issues.. really?, REALLY!? Not to sound like a troll here, and KARMA aside,but cmon. There are not that many changes at all that can't be fixed even on huge applications.

Haven't any of you people heard of php_compat? Simply install PHP_Compat library from pear:
#pear install php_compat
downloading PHP_Compat-1.5.0.tgz ...
Starting to download PHP_Compat-1.5.0.tgz (44,133 bytes)
............done: 44,133 bytes
install ok: channel://pear.php.net/PHP_Compat-1.5.0

Then in PHP
require_once 'PHP/Compat.php';
PHP_Compat::loadFunction('file_get_contents');


This should solve your integration issues with PHP5. http://pear.php.net/package/PHP_Compat

Bad timing :)

RC2 just came out link

Improve array speed (for simple arrays, use internally one simple C array/list - current days, any array is a map);

Try the SplFixedArray class. The SPL data structures are much, much faster. I actually rather like the "easy by default, fast when you need it" dichotomy.

http://gtk.php.net/
http://en.wikipedia.org/wiki/PHP-GTK

PHP-GTK does exist.

Hey, I can't imagine that would be asked a lot or anything. There's no way that would be in the PHP FAQ!

Oh wait...

There is an ArrayObject class in PHP http://us2.php.net/manual/en/class.arrayobject.php

But like a lot of the stuff in the SPL, no one ever uses it (including me). I'm not sure why.

Sure the *NAME* is "Secure Sockets Layer", and perhaps that was what it was originally developed for, but it's just wrong to say that it can't be used otherwise, and/or that it only encrypts data "in transit", not on a server. Take a look at this:

http://us2.php.net/manual/en/function.openssl-public-encrypt.php

Here's the use of SSL functionality without (ahem) a socket. Right from the docs:

This function can be used e.g. to encrypt message which can be then read only by owner of the private key. It can be also used to store secure data in database.

I routinely use SSL to sign files in order to prove whodunnit. This information is stored alongside the signed document. Whether it's transported subsequently is inconsequential.

All the main programming languages were invented in the English speaking world, by English speakers for English speakers.

Yeah, right.

Your first point is valid enough, and your second one does hold some water, but it seems that it has already been addressed by other books on programming in PHP. Further, if I fully understand what your second point is talking about, it would seem that solving it would require getting rid of some of the flexibility (and hence, utility) of the language.

Notably, points 3.2 and 3.3 in your post have already been addressed (not sure about 3.1 or 3.4... never ran into anyone who did 3.1 since it seems incredibly foolish, and haven't heard of any changes yet for 3.4).

3.2: 1 == '1more' is true for two reasons: you're using the weak equivalence operator (hence why a string and an int can be equivalent) and your string starts with valid numeric data which can be converted properly while the rest is ignored. See here for more examples of what would and wouldn't be converted.

3.3: Using the strict equivalency operators ('===' and '!==') in your conditional statements solves this. According to the link, this has been available since PHP 4 so I'm not sure why you're still going on about it...

Your fourth point doesn't necessarily make PHP any less secure than any other programming language that can use external libraries, unless the ones PHP uses are particularly poorly written. While it is true that most of the issues with buffer overflows and memory corruptions in C can be more easily avoided with other languages (e.g., Java), it doesn't mean they can't also be avoided in C with careful coding.

Your first point is valid enough, and your second one does hold some water, but it seems that it has already been addressed by other books on programming in PHP. Further, if I fully understand what your second point is talking about, it would seem that solving it would require getting rid of some of the flexibility (and hence, utility) of the language.

Notably, points 3.2 and 3.3 in your post have already been addressed (not sure about 3.1 or 3.4... never ran into anyone who did 3.1 since it seems incredibly foolish, and haven't heard of any changes yet for 3.4).

3.2: 1 == '1more' is true for two reasons: you're using the weak equivalence operator (hence why a string and an int can be equivalent) and your string starts with valid numeric data which can be converted properly while the rest is ignored. See here for more examples of what would and wouldn't be converted.

3.3: Using the strict equivalency operators ('===' and '!==') in your conditional statements solves this. According to the link, this has been available since PHP 4 so I'm not sure why you're still going on about it...

Your fourth point doesn't necessarily make PHP any less secure than any other programming language that can use external libraries, unless the ones PHP uses are particularly poorly written. While it is true that most of the issues with buffer overflows and memory corruptions in C can be more easily avoided with other languages (e.g., Java), it doesn't mean they can't also be avoided in C with careful coding.

NO! How many times to people have to get hammered because their own or someone else's sanatizer didn't really sanitize (ex: php's mysql_escape_string vs mysql_REAL_escape_string, and other idiotic things) before folks will listen to DBAs and start using well parametrized stored procedures/prepared statements.

More important than sanitization is actual validation. Is it supposed to be an integer? Check that first. If the input is no good, reject the whole thing before it gets in to your query in any way, shape or form. http://php.net/filter is a very underrated way to do this.

OTOH, I do agree, much grief could be saved if more people just used PDO.