Absolutely and evidence of this is always only a Google search away. Search on how to do something with a database and the results you get are riddled with things like SQL injection vulnerabilities, even when the source of the official documentation.

To follow on from this: Language Community Litmus Test: Database Placeholders. An informal survey shows PHP joint bottom, with all but one of the top 5 hits for "PHP database tutorial" promoting insecure methods.

And, as you mention, the official PHP tutorial had beginner-level security holes in it for YEARS. The whole community is riddled with this crap.

Blaming the language for bad code is asinine.

This is bullshit. A shitty language promote shitty code. Aside from the whole taking pride in your work and other "soft" effects, in PHP's case, there are several big, concrete instances of this happening.

For example, older versions of PHP were obviously designed without any clear understanding of how a web request operates. So, for example, you'd have SQL escaping happening in the input layer rather than at the database layer. Nobody who understands what they are doing would design something to work that way. But the core PHP devs totally fucked up in the beginning. They have since started to pull this crap out of PHP, but take a look around. Big, widely-used PHP packages like CodeIgniter have replicated this topsy-turvy design fuckup even in recent versions. That's no coincidence - that's inherited from PHP's design flaws. The blind led the blind into hell, and this crap permeates the PHP developer community as a result.

Likewise with the cavalier attitudes towards correctness. Error handling, character encoding, testing, release management, things like that. Where PHP fucks up, the community is sure to follow. The low quality of PHP has a direct negative effect on the code its fans write.

I'm fed up with the equivocation PHP fans trot out whenever any criticism heads their way. Yes, the quality of a language really does have an effect on the quality of the code you write with it. This is plain for anybody to see, and if you don't see the difference in quality, then you should seriously question your competence.

...if you have the financial resources to afford to crash and burn

That's implied in the name "moonshot". If budget is a constraining factor, then what you're attempting isn't a moonshot, but standard R&D. It's the difference between a Boeing exec. deciding to fund the development of a better plane and JFK saying "get us to the moon no matter what".

some people are simply too dangerous to others to leave to their own

Even assuming that's the case, a state that is allowed to execute its citizens is even more dangerous.

why is it our responsibility to support them for the remainder of their natural lives?

Executing a person is more than simply deciding not to support them. It's genuinely disturbing that you seem to think that a person's execution is a decision about whether to support them or not.

Death penalty is not a secret, people know if you do this, chances are you are going to die for it.

No, in many cases they don't. Such as the getaway driver for a robbery where something goes wrong and the other person kills somebody. Or the mentally retarded. Or the clinically insane. Or minors. All of these kinds of people have been executed by the USA and a lot of them can genuinely claim to have not understood the ramifications of what they were doing.

I've heard some horror stories from people who've had their Google accounts auto-banned due to overzealous spam filters for the Play Store, Adwords and things like that, and been unable to get to speak to a human at Google about it. What happens if you protect your phone so that you need to sign into your Google account, then you lose your Google account?

It's not computer-related, but this book reminds me of the Phantom Tollbooth.

Simply put, VR headsets (displays mounted in such a way as to be placed in front of a person's eyes) have been visualized and built for decades.

Sure, but that's not what's being patented here. What's being patented here is a frame that you can slot an existing mobile device into to be used as a headset, where the headset detects the insertion and notifies the phone to switch to VR mode. That's not something that has been built for decades.

Lawnmower Man anyone?

Lawnmower Man didn't include a device like this. This is not a patent on any and all VR displays, it's a patent on a specific type of frame for mobile devices.

Yep. At that time Microsoft were still running Hotmail on FreeBSD because they were struggling to migrate it to Windows.

I'm surprised nobody has mentioned this yet, on Slashdot of all places. How many times have you seen a shitty submission here and comments correcting it? It's practically Slashdot's unofficial slogan: "yeah, the stories are awful, but I come for the comments".

I thought reverse engineering the server protocol was perfectly legal.

In theory, yes. In practice, the DMCA can be used to squash interoperable implementations. Look at bnetd, for example. Despite it being a completely separate implementation of the protocol, Blizzard used the DMCA to successfully sue the project maintainers.

Although Apple has never officially acknowledged issues surrounding Yosemite and Wi-Fi connectivity, the company is clearly aware of the problem: Leading off the improvements offered in the update 10.10.2 update released Tuesday was 'resolves an issue that might cause Wi-Fi to disconnect,' according to the release notes.

So basically, you said that Apple haven't acknowledged the problem, then quoted them acknowledging the problem?

It is broke though. Look at the SendFile bug, for example. It's been there for years, it bites a tonne of people who try to virtualise web servers, and there has been seemingly no attempt whatsoever to fix it. Its kernel drivers on OS X and Linux aren't particularly stable either.

the functionality of the devices is about the same

It's very different. On Android, you have to decide whether to grant permission before you've ever run the application, and it's all or nothing. On iOS, you run the application before deciding whether or not to grant it permission. You have the ability to deny permission while still running the application. You can also allow permission for some things but not others.

This functionality is partially available to Android users who root their phones and install the right tools, but that's far from the common case.

It's true that the majority of the profits in App Store sales is focused at the extreme top, but it's not true that 99.999% of the rest make "near 0". This analysis estimates that the top 3,175 applications earn at least the average annual income for a US household per year, and applications that rank about number 6000 still earn $25K/yr.

And that's only counting App Store revenue. I've earned a lot more than average since I started developing for iOS, and most of the applications I've worked on are free. You don't see things like banking applications earn revenue directly, but the developers responsible certainly profit from it. The Facebook application is free, but you don't think its developers are working on it for free do you? I've been paid to built plenty of enterprise applications that will never appear in the App Store.

There is a huge amount of profit in the "app economy" that will never be accounted for merely by looking at App Store profits. The "app economy" is much bigger than the App Store.

It wasn't impossible to write cross platform browser stuff in the late 1990s, when most corporations started this whole "We'll standardize on browser X" policy making, but it required a discipline that had most developers throwing their hands up in the air in disgust.

I had these arguments many times back then. It was laziness more than anything else. We were writing cross-platform web applications without problems at that time. We were trying to convince other developers to follow the same route, but their attitude was mainly "IE has 90%+ market share, why bother?" They didn't believe a time would come when proprietary IE code wouldn't work - even if other browsers caught on, they were expecting them to copy the IEisms. They certainly didn't believe that even later versions of Internet Explorer wouldn't support their crappy code.

- IE4+ was the most standard. Yes, really. Those versions had a relatively complete implementation of CSS.

Let's not overstate things. Netscape bet on JSSS and when the W3C selected CSS as the standard instead, they scrambled to fix Netscape 4 to convert from CSS to JSSS on the fly. So Netscape 4 was exceptionally bad at CSS. Internet Explorer 4 was merely very bad at CSS. Opera was ahead at that time. I don't think you can call IE4 "relatively complete" unless you only compare it to Netscape 4, which was unusually bad.