While I agree with the overall point, I don't think the "I don't know C" hand-waving is very useful (both from the author and various commenters). If you want something done, then one should not be afraid to dive in and learn some C to figure it out. I don't know a lot of C though I learned on it, but I knew enough to open up the PHP source code and figure out what was going on with a multibyte encoding issue to file an accepted bug report and a follow-up feature request. Why don't I do that for parameter ordering in functions? Because, like the author stipulated, I'm not one of the people who cares enough to want to. But, those who do care enough to want it should stop making excuses for themselves about not knowing C and go learn it. Move on from there to writing documentation for the Zend stuff if it sucks in the places you want it to shine.

It's a recurring theme - "we need to rewrite PHP and I know exactly how to do it and PHP maintainers are idiots for not doing it years ago. Oh, btw, I don't know C and have no idea how PHP internals look like, but how hard could it be?" Happens all the time.

Yeah the old armchair programmer syndrome. It is very easy to just sit back in your armchair and give out advice on how to do stuff without having any knowledge or experience in doing it.

"Ah yeah just rewrite the entire code, you are meatheads for not doing that in the first place, you should have done it years ago. Oh yeah I have no programming experience per se, for example I don't know how to program in C and have no idea what the PHP internals look like, but how hard can it be? I mean you just load your C Code into your IDE and then search and replace all the bad code and write in the good code and then press the compile button and there you go. It works that way when I design HTML web sites in Dreamweaver, so it should also work for C, right?" -Archie Bunker 'Armchair Programmer' and 'Technology Bigot'

I wouldn't say I have no idea, I've looked into it. I know exactly how difficult it is and respect anybody who manages (or even tries to) make PHP better. I certainly at no point in the article called anyone an idiot.

You would not claim this bullshit if you had any idea who is actually maintaining and using PHP. Unfortunately, somehow it seems fashionable to make broad statements about PHP without bothering to find out a single bit of information.

You don't remember the code examples on Zend Technologies' own website? Teaching PHP with really embarrassing security holes.

Or Rasmus Lerdorf who releases software that doesn't run all unit tests?

Read the source code to MediaWiki some time. You can say a lot about MediaWiki, Wikipedia and PHP, but at least MediaWiki is PHP done right (if such a thing is possible).

Actually the comment is spot on.

It's a stinking shit crock from end to end. Just because it has a few celebrity developers like Rasmus, doesn't mean it doesn't fuck you in the eyeballs the moment you see it.

Just sit down for a couple of hours with tmux fired up, and vim with bits of ZE source code on the left and on thr right, Python.

You will see. It will make you sick looking at the ZE source code.

I work as a PHP developer, but for personal projects I create apps with Java on Android, and have also created iPhone apps with Objective C, I disagree with you. PHP has some issues (like the ones presented here), but its also a great language for specific projects. I do prefer Java syntax honestly, but I'll never use JSP for a website, PHP is more adapted for that. PHP is not for newbies, it is easier for newbies yes, but you can be a hardcore programmer and still use PHP.

i bet you think whatever language you use makes your balls bigger , but not your brain obviously, because you dont know what PHP is and how it is used everyday by million of businesses. In fact you must be a noob, only noobs talk like that.

That's the definition of a newb's statement. What are you, 16 years old?

Like the "newbies" at Facebook, Yahoo and tons of major sites using Wordpress, huh?

Let's say - for the sake of argument - that I walk outside, buy a "C for Dummies" book and read that thing cover to cover. In a month I might be a reasonable C developer and after a few more months I might have a good enough understanding of how PHP works internally, fire my code into a feature branch post that RFC up on the board, then... what? If people are dismissing things like Property Accessor syntax after it's coded up by an experienced C and PHP dev, then why are they all going to vote yes on an RFC bashed together by somebody who is brand new to this?

That's not an excuse, thats logic. It's very possible that so few people get involved in core development because there is very little motivation to do so. "I can work really hard on something that I feel really passionate about, then have it totally ignored by a bunch of people who think PHP should just remain a cluster-fuck of inconsistent PHP functions." Yaaaay!

See the issue? It's very easy to say "Well why don't you do more?" but when people see those that try being met with negativity in such a big way it REALLY doesn't make me want to even try to help.

Are you saying it is a "Leaky Egos" type of problem here? That the maintainers' egos are preventing new people from joining and helping out?

Let's just for the sake of argument say you read a "C for Dummies" book and actually write a few programs. OK now you are a beginner C developer with a small bit of experience under your belt. Now you need to read an Intermediate C book and learn data structures and algorithms that "C for Dummies" didn't teach you. Then you need to read a few Advanced C books to learn how to do system level programming, write your own libraries, hook into interrupts, link to binary libraries written in a different language, and learn how to program C to access operating system internals. After all that, you have to join some smaller level open source C projects, and then move up to medium level, and then finally to large level such as PHP.

Of course at that level, you got people just like you used to be giving you advice on how to do your job, and how to rewrite the program, but you are very busy trying to submit code to the project that is accepted by the maintainers and included in the main branch of code, and you have a few other maintainers telling you how bad your code is, and a few others telling you that your code conflicts with what they wrote. Of course the noobz don't know any of this, but you are frustrated, stressed out, and nobody is paying you any money to do this and you owe a lot of debt on your bills. So you get told "Well why don't you do more?" by a noob, in response to some feature they want you to add to the project, but you know that adding it will cause a lot of problems with the other programmers and maintainers, and also cause them to give you a lot of negative feedback for it.

You consider your options, you could just fork the PHP code into a different open source project, but then who would join you in on it? You could write an open letter to the PHP community about adding this feature and supporting the programmers and maintainers by donating money so they are able to spend extra weeks working on it and quit their jobs and start doing the project full-time. You could just hope that everyone sees it your way and works on adding this feature eventually. You could just give up in frustration and quit, citing family issues. You could talk negatively to the noob and hope he/she quits suggesting these features be added and tell him/her just how hard and complex that would be. You could do something else as well.

I don't get why a string object would be so concerned about UTF encoding. What's the difference between a "UTF-8 string" and a "UTF-16 string"? The encoding only matters as you serialize the string to a set of bytes. Very confusing article.

Most PHP developers I've worked with had no idea of different encodings, serializations, etc. They just wanted to echo $_GET['input'] and be done with it.

Hello, XSS :)

Welcome to PHP. This is the norm.

I worked at an outfit that hired some utter fuckwits who had been recommended by some more fuckwits for something and they did it in PHP and put it on budget shared hosting.

A week later: SQL injection, CSS, CSRF attacks and someone who had cracked the server was injecting malicious js in the page header.

That day was the day that management finally listened to my doomsaying about security...

Yeah I found this out the hard way back in 1997 writing ASP pages using SQL Server. I learned to sanitize my data inputs.

It all started with employees who had Irish names like O`Brian, they would cause database errors when trying to insert their name. I found out the data entry clerks didn't know the difference between the "`" apostrophe and "'" single quote character. So I wrote a SQL filter function to double up the single quotes if one is entered. As it turned out some employees where using the single quote for SQL Injection and it foiled their attempts and they filed support tickets for it. I could not replicate the error and then I asked how they were entering the data, and none of them wanted to tell me. So I made a logging code when their user ID is used to access the database and noticed they were trying to use the single quote to gain access to other tables and in some cases entering "1 or 1" and other stuff that just returned all the results in a table. I had to filter out SQL commands, system characters, and other things, even HTML statements because they would stick them in there to deface ASP pages and insert messages.

This was a law firm I worked for, and they had no clue their users were doing this, it was an Intranet site that was not accessible from the Internet. For stopping their 'cracking' of ASP pages, I gained a lot of enemies for that. Some would send denial of service attacks to my Windows PC, some would file fake complaints about me to get rid of me and replace me with someone who didn't sanitize inputs. Eventually I got too sick to work, and was fired for being mentally ill after all the stress I had caused me to develop schizoaffective disorder.

And we all know such vulnerabilities never happen to respectable frameworks written by real programmers using real languages (read: not PHP), only to people that lack basic clues and are utter fuckwits... oh wait, https://www.pcworld.com/article/251259/user_hacks_github_to_... https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...

I wouldn't really let Rails slide here or call them an exemplar in the subject at hand. They were lazy and paid dearly for it.

A better example would be Django, most server-side Java frameworks, Ruby frameworks like Sinatra and Padrino, most Erlang code I've seen is solid, Haskell users generally know better, etc.

You mean neither of those ever had or will have security issues, because only stupid incompetent developers ever have those? That was pretty much the point of the parent comment.

Meanwhile on planet Earth every popular software package has had some issues. That's natural, security is hard and requires constant vigilance, and people are bound to err or oversee something from time to time.

I'm not suggesting that the other people aren't fuckwits either. TBH Rails is just as bad - it's the same culture of incompetence.

You're lucky they didn't think it was you.

I warned the local lottery about the security issues they had with their website (I was doing them some side work) but they didn't listen until someone defaced their website and the first thing they did was ask me if I did it.

Yes that usually is the case. You warn the administrators and managers about security issues and then when some script-kiddie runs a script and cracks the security and downloads the database, they blame you for it.

Sort of like this:

Programmer "Uh you really should use a numerical keypad to the server room, it is more secure than the doorknob lock which is so common anyone can find a key that fits it and rob the server room."

Management "Feh! Forget it, we don't have the budget for it. Besides that doorknob lock was on sale at Lowe's and fit out budget. The clerk there said it was lockpick proof, and that's good enough for us."

Later on someone picks the lock and then steals all the server hardware.

Manager "Someone broke into the server room. Hey programmer was it you, you seem to know a lot about locks and stuff?"

Programmer "No it wasn't me, if you followed my advice with the numerical key pad you wouldn't have had this problem. The lock you used made the server room insecure and allowed a robber to easily pick the lock and rob us all."

Manager "Yeah whatever, I'm pressing charges against you anyway."

I've worked for an asshole company that did that. We reached a stalemate after I managed to use my code ownership clause against them - basically "fuck off or I'll open source all your code".

I'll have to remember that should I find myself in another position to be hired or contracted by another asshole company to include a 'code ownership' clause and a 'right to open source the code" clause in case of any problems or difficulties.

That's a developer incompetence problem, not a PHP problem. If python or ruby was as trivially easy to get running (read: preinstalled everywhere), then they would be the lowest barrier to entry and have the exact same problems.

Actually no. PHP has many fundamental flaws which do not exist in Python or Ruby.

I would hardly call this 'the norm', may as well say the all C software inevitably segfaults and is thus unreliable since that happens at least once to everyone who's ever learnt the language. PHP newbies just have the unfortunate side effect of being a bit more exposed to the 'outside elements' while learning.

And if your prior employment recruited based on connections rather than competence that speaks to a management issue that couldn't possibly be solved by switching languages.

(this isn't really to single out your comment meaty, could be attached to anyone else in this thread)

I wonder when the Wordpress installations will blow up that were set up against my recommendation.

Those large sites sure have a whole team attending them. And can update it 24/7.

And those sites became large because people could get them up and running quickly which is what made PHP a popular language. Hobbyist programmers made it what it is, and many of those hobbyist programmers went on to build big companies... Mark Zuckerberg, Matt Mullenweg, just to name a few.

Big value companies - yes. Big companies - no.

They are just fad artists.

Website is down but I really like the error page.

http://i.imgur.com/f20igSW.png

Heh, that's what you get for not serving cached content.

I think this was initially caused by RDS playing up, but varnish is in place now.

Persistent connection pools are not popular in the PHP world :)

The error is that there are too many connections, not that it took too long to establish them. MySQL is generally pretty quick about establishing connections (although you can have issues w/ reverse DNS taking forever; it's best to turn that off and do access control by ips).

Ideally, a blog can be cached to static html (regen pages when owner adds an entry and if comments are self hosted, regen when a comment is added/approved). Even so, it looks like there are too many php processes running compared to mysql connections allowed; lowering the php processes will probably lead to better throughput than ramping up mysql connections.

Also, last I checked, at least Debian ships with an Apache max-workers setting greater than the MySQL max-connections setting out of the box, pretty much guaranteeing errors like these even on a single virtualhost under load.

Or generally possible directly with web requests. Pretty much everything is torn down at the end of each request. (Yeah PHP-FPM slightly muddies the waters)

With MySQL it's not necessarily always a good thing to persist connections. If your script dies, you lost that connection as a resource until it's killed for being idle.

Most DBs all have their own connection pooling mechanisms that don't work the same way, so we need to look into each to see if it's worth it. Caching though (query as well as HTML), is usually always a good idea.

This is a standard CodeIgniter error message.

This is a poorly configured webserver/CodeIgniter framework. It's an info leak that should be avoided.

I can't tell you much I'd love to see smarter scalars in PHP, but then for a business what's the difference between upgrading to PHP 6 or upgrading to, say, Python?

The difference would be converting all the places in your code from strlen($string) to $string->length() instead of rewriting it. One may take a few days/weeks to do in an existing app. The other would take months if not years to get out the door, test, and deploy.

The PHP world is mired in legacy codebases. I have seen many code bases that are on very old, unsupported PHP versions. Although PHP strives to maintain backwards compatibility, it doesn't always work. And many of the backwards incompatible changes are only apparent at runtime and are incredibly difficult discover due to the dynamism of the language and the abuses that are present in most legacy PHP code.

"PHP strives to maintain backwards compatibility", I'll have to say I've seen enough evidence to the contrary. Even basic object-oriented metaprogramming have been radically changed in minor point/patch releases. Stuff like "get_class_vars()" changing from returning private vars, to not returning private vars, etc. (edit: between PHP v5.2.6 and v5.2.7 if I remember correctly)

Although true, I would say that's kind of an "abuse". I find many PHP functions have changed over versions to give more predictable output and validate expected input more stringently. If backwards compatibility wasn't a concern, they would attempt to standardize the lib in obvious incompatible ways.

Well, backwards compability is kind of a binary thing, isn't it. Either you're aiming for backwards compability and you can be sure your legacy code will keep running, or you don't. In fact it would be more helpful to throw fatal errors because a method signature changed, than start returning different and unexpected values which can break data integrity in subtle ways.

Today's PHP doesn't really want to support legacy code. A customer's hosting provider forces an upgrade to PHP 5.4 in April. They tested a CMS and it is broken. Just because the CMS used split() instead of explode(). Deprecated function.

especially nasty is magic_quotes , switch your old website to a new webhost (or have your existing one upgrade their PHP installation) and you get instant SQLi vulnerabilities.

If you relied on magic_quotes for security, you deserve it.

In my defence, it wasn't my code but I was hosting it. Getting 3 angry "why does my website have porn all over it" calls in one day isn't fun.

Oh, yeah, the magic_quotes. They implemented something like this without knowing anything about SQL.

PHP supported different SQL databases, but they implemented some kind of protection in a non standard way, just because it was supported by MySQL.

magic_quotes has been deprecated for three and a half years, and widely understood to be a bad idea for around a decade.

If you don't check your configs when moving to a new host, you get what's coming to you.

you'd be surprised how many small businesses still have ~10+ year old websites.

Mirror of the article as phil has been having some trouble on his aws rds box dealing with the traffic. https://gist.github.com/raw/4645323/2e581d48609effb553dd9ce0...

I didn't realize that the Property Accessors Syntax RFC was voted down, 34 (yea) to 20 (nay). I'm curious to know why people objected to it. Magic methods are a horrible way to do get/set and writing separate getProperty/setProperty methods is pretty annoying also.

Seriously - just find another language. The people upstairs are crack smokers.

The HN effect is enough to take down even the mightiest of servers lol, avoid shared hosting if you plan to make the front page, I'm curious what the article reads like but I can't get to it...the suspense is killing me

Although it looks like the DNS is pointing to AWS...how did it go down?

> @philsturgeon: When you click Terminate instead of Reboot bad things happen.

So if you terminate an instance on AWS you automatically lose your data? How does that work? I've never used AWS, I usually self host or use 1and1 VPS

depends, TL;DR, local disk drives (Ephemeral) do not persist anything that wasn't part of the base image if you power down the machine (doesn't include restarts - data is persisted in this situation). network based drives (EBS) persist all their data across machine shutdown.

Slightly longer version - When you stop a AWS instance, the instance is torn down completely and all local state/data (Ephemeral) on the hypervisor is lost. when you then start the instance again a new hypervisor with spare capacity is found and then booted with your chosen base disk image. Restarts do not cause your instance to torn down so you don't lose local state / data. If your instance uses network drives (EBS) then these drives keep state when your server is torn down, and are re-attached when the server is started back up again,

If you click Terminate, I believe Amazon deletes the default EBS drive generated when you started the instance as well as any instance storage.

Yeah, if you terminate rather than stop the instance then everything that was created as part of the instance will be destroyed by default although you can choose to not kill attached EBS drives. Any EBS drives that were attached after instance creation will be left untouched by default after instance termination.

Aha, just checked his twitter feed

I can't view that article because it's down, but I assume this is some sort of "PHP internals suck" rant.

I'm surprised there isn't something like JPHP yet to run PHP on the JVM.

Don't think it solves this problem but Caucho Resin (Java EE server) should be able to run php as well.

there are a few options:

quercus and ibm's ... ack - what was it called? they had a 'freeware' CMS that included their own implementation of PHP in Java.

I think there's another too, but there's quite a lot of oddities and assumptions that make PHP-based code not play well in the JVM.

ibm thingi was called "project zero" btw i hear facebook is also looking to move to the jvm to ease some troubles with their hiphop approach

Facebook is doing this as successor of their php-c++ translator

Doesn't seem to be cached by Google, yet. Does someone have a copy?

Now it's 404.