Coding Horror

Stack Overflow – like most online communities I've studied – naturally trends toward increased strictness over time. It's primarily a defense mechanism, an immune system of the sort a child develops after first entering school or daycare and being exposed to the wide, wide world of everyday sneezes and coughs with the occasional meningitis outbreak. It isn't always a pleasant process, but it is, unfortunately, a necessary one if you want to survive.

Consider this question from two years ago:

New programming jargon you coined?

What programming terms have you coined that have taken off in your own circles (i.e. have heard others repeat it)? It might be within your own team, workplace or garnered greater popularity on the Internet.

Write your programming term, word or phrase in bold text followed by an explanation, citation and/or usage example so we can use it in appropriate context.

Don't repeat common jargon already ingrained in the programming culture like: kludge, automagically, cruft, etc. (unless you coined it).

This question serves in the spirit of communication among programmers through sharing of terminology with each other, to benefit us by its propagation within our own teams and environments.

Is this even a question, really? How many answers does it have?

Three hundred and eighty six!

A question that invites 386 different "answers" isn't a question at all. It's an opinion survey, a poll, a List of X. I suppose you could argue that reading through all those responses would teach you something about programming, but it was pretty clear that the bulk of the responses were far more about laughs and GTKY (Getting to Know You) than learning. That's why it was eventually deleted by experienced Stack Overflow community members. Although it is somewhat borderline in terms of learning, and I didn't personally vote to delete it, I tend to agree that it was correctly deleted. Though opinions vary.

I won't bore you with the entire history, our so-called "war on fun", and the trouble with popularity. Ultimately, Stack Overflow is a college, not a frat house. All the content on the site must exist to serve the mission of learning over entertainment – even if that means making difficult calls about removing some questions and answers that fail to meet those goals, plus or minus 10 percent.

In terms of programmer culture, though, there is precedent in the form of The Jargon File. Unfortunately, we don't have a good designated place for deleted "too fun" questions to live, but all Stack Exchange content is licensed under Creative Commons in perpetuity. Which means, with proper attribution, we can give it a permanent home on our own blogs. So I did. I've collected the top 30 Stack Overflow New Programming Jargon entries below, as judged by the Stack Overflow community. Enjoy.*

1. Yoda Conditions

Using if(constant == variable) instead of if(variable == constant), like if(4 == foo). Because it's like saying "if blue is the sky" or "if tall is the man".

2. Pokémon Exception Handling

For when you just Gotta Catch 'Em All.

try {
}
catch (Exception ex) {
// Gotcha!
}

3. Egyptian Brackets

You know the style of brackets where the opening brace goes on the end of the current line, e.g. this?

if (a == b) {
printf("hello");
}

We used to refer to this style of brackets as "Egyptian brackets". Why? Compare the position of the brackets with the hands in the picture. (This style of brackets is used in Kernighan and Ritchie's book The C Programming Language, so it's known by many as K&R style.)

4. Smug Report

A bug submitted by a user who thinks he knows a lot more about the system's design than he really does. Filled with irrelevant technical details and one or more suggestions (always wrong) about what he thinks is causing the problem and how we should fix it.

Also related to Drug Report (a report so utterly incomprehensible that whoever submitted it must have been smoking crack.), Chug Report (where the submitter is thought to have had one too many), and Shrug Report (a bug report with no error message or repro steps and only a vague description of the problem. Usually contains the phrase "doesn't work.")

5. A Duck

A feature added for no other reason than to draw management attention and be removed, thus avoiding unnecessary changes in other aspects of the product.

I don't know if I actually invented this term or not, but I am certainly not the originator of the story that spawned it.

This started as a piece of Interplay corporate lore. It was well known that producers (a game industry position, roughly equivalent to PMs) had to make a change to everything that was done. The assumption was that subconsciously they felt that if they didn't, they weren't adding value.

The artist working on the queen animations for Battle Chess was aware of this tendency, and came up with an innovative solution. He did the animations for the queen the way that he felt would be best, with one addition: he gave the queen a pet duck. He animated this duck through all of the queen's animations, had it flapping around the corners. He also took great care to make sure that it never overlapped the "actual" animation.

Eventually, it came time for the producer to review the animation set for the queen. The producer sat down and watched all of the animations. When they were done, he turned to the artist and said, "that looks great. Just one thing - get rid of the duck."

6. Refuctoring

The process of taking a well-designed piece of code and, through a series of small, reversible changes, making it completely unmaintainable by anyone except yourself.

7. Stringly Typed

A riff on strongly typed. Used to describe an implementation that needlessly relies on strings when programmer & refactor friendly options are available.

For example:

• Method parameters that take strings when other more appropriate types should be used.
• On the occasion that a string is required in a method call (e.g. network service), the string is then passed and used throughout the rest of the call graph without first converting it to a more suitable internal representation (e.g. parse it and create an enum, then you have strong typing throughout the rest of your codebase).
• Message passing without using typed messages etc.

Excessively stringly typed code is usually a pain to understand and detonates at runtime with errors that the compiler would normally find.

8. Heisenbug

A computer bug that disappears or alters its characteristics when an attempt is made to study it. (Wikipedia)

9. Doctype Decoration

When web designers add a doctype declaration but don't bother to write valid markup.

<!DOCTYPE html>
<BLINK>Now on sale!</BLINK>

10. Jimmy

A generalized name for the clueless/new developer.

Found as we were developing a framework component that required minimal knowledge of how it worked for the other developers. We would always phrase our questions as: "What if Jimmy forgets to update the attribute?"

This led to the term: "Jimmy-proof" when referring to well designed framework code.

11. Higgs-Bugson

A hypothetical bug predicted to exist based on a small number of possibly related event log entries and vague anecdotal reports from users, but it is difficult (if not impossible) to reproduce on a dev machine because you don't really know if it's there, and if it is there what is causing it. (see Higgs-Boson)

12. Nopping

I'm writing a scifi novel from the POV of an AI, and their internal language has a lot of programming jargon in it. One of the more generalizable terms is "nopping", which comes from assembler NOP for no-operation. It's similar to 'nap', but doesn't imply sleep, just zoning out. "Stanislav sat watching the screensaver and nopped for a while."

13. Unicorny

An adjective to describe a feature that's so early in the planning stages that it might as well be imaginary. We cribbed this one from Yehuda Katz, who used it in his closing keynote at last year's Windy City Rails to describe some of Rails' upcoming features.

14. Baklava Code

Code with too many layers.

Baklava is a delicious pastry made with many paper-thin layers of phyllo dough. While thin layers are fine for a pastry, thin software layers don’t add much value, especially when you have many such layers piled on each other. Each layer has to be pushed onto your mental stack as you dive into the code. Furthermore, the layers of phyllo dough are permeable, allowing the honey to soak through. But software abstractions are best when they don’t leak. When you pile layer on top of layer in software, the layers are bound to leak.

15. Hindenbug

A catastrophic data destroying bug. "Oh the humanity!"

Also related to Counterbug (a bug you present when presented with a bug caused by the person presenting the bug) and Bloombug (a bug that accidentally generates money).

16. Fear Driven Development

When project management adds more pressure (fires someone, moves deadlines forward, subtracts resources from the project, etc).

17. Hydra Code

Code that cannot be fixed. Like the Hydra of legend, every new fix introduces two new bugs. It should be rewritten.

18. Common Law Feature

A bug in the application that has existed so long that it is now part of the expected functionality, and user support is required to actually fix it.

19. Loch Ness Monster Bug

I've started Loch Ness Monster bug for anything not reproducible / only sighted by one person. I'm hearing a lot of people in the office say it now. (Possible alternates: Bugfoot, Nessiebug.)

20. Ninja Comments

Also known as invisible comments, secret comments, or no comments.

21. Smurf Naming Convention

When almost every class has the same prefix. IE, when a user clicks on the button, a SmurfAccountView passes a SmurfAccountDTO to the SmurfAccountController. The SmurfID is used to fetch a SmurfOrderHistory which is passed to the SmurfHistoryMatch before forwarding to either SmurfHistoryReviewView or SmurfHistoryReportingView. If a SmurfErrorEvent occurs it is logged by SmurfErrorLogger to ${app}/smurf/log/smurf/smurflog.log

22. Protoduction

A prototype that ends up in production. Heard this from a tech at the Fermi lab. He said he didn't coin the term but had heard it used a number of times at Fermi.

23. Rubber Ducking

Sometimes, you just have to talk a problem out. I used to go to my boss and talk about something and he'd listen and then I'd just answer my own question and walk out without him saying a thing. I read about someone that put a rubber duck on their monitor so they could talk to it, so rubberducking is talking your way through a problem.

24. Banana Banana Banana

Placeholder text indicating that documentation is in progress or yet to be completed. Mostly used because FxCop complains when a public function lacks documentation.

/// <summary>
/// banana banana banana
/// </summary>
public CustomerValidationResponse Validate()

Other food-related jargon: Programmer Fuel (Mountain Dew, coffee, Mate, anything which gets you well-caffeinated), Hot Potato (Http and Https respectively. Same number of syllables, but more fun to say), Cake (Marty's noob cake broke the build), Chunky Salsa (based on the chunky salsa rule, a single critical error or bug that renders an entire system unusable, especially in a production environment).

25. Bicrement

Adding 2 to a variable.

26. Reality 101 Failure

The program (or more likely feature of a program) does exactly what was asked for but when it's deployed it turns out that the problem was misunderstood and it's basically useless.

27. Mad Girlfriend Bug

When you see something strange happening, but the software is telling you everything is fine.

28. Megamoth

Stands for MEGA MOnolithic meTHod. Often contained inside a God Object, and usually stretches over two screens in height. Megamoths of greater size than 2k LOC have been sighted. Beware of the MEGAMOTH!

29. Hooker Code

Code that is problematic and causes application instability (application "goes down" often). "Did the site go down again? Yeah, Jim must still have some hooker code in there."

30. Jenga Code

When the whole thing collapses after you alter a block of code.

This is just the top 30, what I consider to be the most likely candidates for actual new programming jargon based on community upvotes, not just "funny thing that another programmer typed on a webpage and I felt compelled to upvote for hilarity". Because that would be Reddit. If you're itching to see even more, there are plenty more answers to read – three hundred and fifty six more to be precise. Longtime Stack Overflow user Greg Hewgill maintained an archive of old deleted Stack Overflow questions, but this one hasn't quite made it in there yet. In the meantime, try Stack Printer, or if you have the requisite 10k rep on Stack Overflow, you can view the full soft-deleted question on the site.

* But don't enjoy it too much. We will be watching you.

If I had to make a list of the top 10 things I've done in my life that I regret, "writing a book" would definitely be on it. I took on the book project mostly because it was an opportunity to work with a few friends whose company I enjoy. I had no illusions going in about the rapidly diminishing value of technical books in an era of pervasive high speed Internet access, and the book writing process only reinforced those feelings.

In short, do not write a book. You'll put in mountains of effort for precious little reward, tangible or intangible. In the end, all you will have to show for it is an out-of-print dead tree tombstone. The only people who will be impressed by that are the clueless and the irrelevant.

As I see it, for the kind of technical content we're talking about, the online world of bits completely trumps the offline world of atoms:

• It's forever searchable.
• You, not your publisher, will own it.
• It's instantly available to anyone, anywhere in the world.
• It can be cut and pasted; it can be downloaded; it can even be interactive.
• It can potentially generate ad revenue for you in perpetuity.

And here's the best part: you can always opt to create a print version of your online content, and instantly get the best of both worlds. But it only makes sense in that order. Writing a book may seem like a worthy goal, but your time will be better spent channeling the massive effort of a book into creating content online. Every weakness I listed above completely melts away if you redirect your effort away from dead trees and spend it on growing a living, breathing website presence online.

A few weeks ago, Hyperink approached me with a concept of packaging the more popular entries on Coding Horror, its "greatest hits" if you will, into an eBook. They seemed to have a good track record doing this with other established bloggers, and I figured it was time to finally practice what I've been preaching all these years. So you can now download Effective Programming: More Than Writing Code for an introductory price of $2.99. It's available in Kindle, iPad, Nook, and PDF formats.

(As of March 2013, the first book was apparently popular enough to warrant a second volume, How to Stop Sucking and Be Awesome Instead)

I've written about the ongoing tension between bits and atoms recently, and I want to be clear: I am a fan of books. I'm just not necessarily a fan of writing them. I remain deeply cynical about current book publishing models, which feel fundamentally broken to me. No matter the price of the book, outside of J.K. Rowling, you're basically buying the author a drink.

As the author, you can expect to make about a dollar on every copy that sells. The publisher makes several times that, so they make a nice profit with as few as, say, five thousand copies sold. Books that sell ten or fifteen thousand are rare, and considered strong sellers. So let's say you strike gold. After working on your book for a year or more, are you going to be happy with a payday of ten to fifteen grand?

Incidentally, don't expect your royalty check right away. The publisher gets paid first, by the bookstores, and the publisher may then hold on to your money for several months before they part with any of it. Yes, this is legal: it's in the publisher's contract. Not getting paid may be a bummer for you, but it's a great deal for the publisher, since they make interest on the float (all the money they owe to their authors) - which is another profit stream. They'll claim one reason for the delay is the sheer administrative challenge of cutting a check within three months (so many authors to keep track of! so many payments!)... a less ridiculous reason is that they have to wait to see whether bookstores are going to return unsold copies of your book for a full refund.

Here's one real world example. John Resig sold 4,128 copies of Pro Javascript, for which he earned a grand total of $1.87 per book once you factor in his advance. This is a book which still sells for $29.54 on Amazon new.

Tellingly, John's second book seems permanently unfinished. It's been listed as "in progress" since 2008. Can't say I blame him. (Update: John explains.)

When I buy books, I want most of that money to go to the author, not the publishing middlemen. I'd like to see a world where books are distributed electronically for very little cost, and almost all the profits go directly to the author. I'm not optimistic this will happen any time soon.

I admire people willing to write books, but I honestly think you have to be a little bit crazy to sit down and pound out an entire book these days. I believe smaller units of work are more realistic for most folks. I had an epic email discussion with Scott Meyers about the merits of technical book publishing versus blogging in 2008, and I don't think either of us budged from our initial positions. But he did launch a blog to document some of his thoughts on the matter, which ended with this post:

My longer-term goal was to engage in a dialogue with people interested in the production of fast software systems such that I could do a better job with the content of [my upcoming book]. Doing that, however, requires that I write up reasonable initial blog posts to spur discussion, and I've found that this is not something I enjoy. To be honest, I view it as overhead. Given a choice between doing background research to learn more about a topic (typically reading something, but possibly also viewing a technical presentation, listening to a technical podcast, or exchanging email with a technical expert) or writing up a blog entry to open discussion, I find myself almost invariably doing the research. One reason for this is that I feel obliged to have done some research before I post, anyway, and I typically find that once I'm done with the research, writing something up as a standalone blog entry is an enterprise that consumes more time than I'm willing to give it. It's typically easier to write the result up in the form of a technical presentation, then give the presentation and get feedback that way.

Overhead? I find this attitude perplexing; the research step is indeed critical, but no less important than writing up your results as a coherent blog entry. If you can't explain the results of your research to others, in writing, in a way they can understand, you don't understand it. And if you aren't willing to publish your research in the form of a simple web page that anyone in the world can visit and potentially learn from, why did you bother doing that research in the first place? Are you really maximizing the value of your keystrokes?

More selfishly, you should always finish by writing up your results purely for your own self-improvement, if nothing else. As Steve Yegge once said: "I have many of my best ideas and insights while blogging." Then you can take all that published writing, fold in feedback and comments from the community, add some editorial embellishment on top, and voilà – you have a great book.

Of course, there's no getting around the fact that writing is just plain hard. Seth Godin's advice for authors still stands:

Lower your expectations. The happiest authors are the ones that don't expect much.

Which, I think, is also good life advice in general. Maybe the easiest way to lower your expectations as an author is by attempting to write one or two blog entries a week, keep going as long as you can, and see where that takes you.

I'd argue that the last truly revolutionary version of Windows was Windows 95. In the subsequent 17 years, we've seen a stream of mostly minor and often inconsequential design changes in Windows – at its core, you've got the same old stuff: a start menu, a desktop with icons, taskbar at the bottom, overlapping windows, toolbars, and pull-down menus.

Windows 7 may be bigger, prettier, and more refined – finally, a proper sequel to Windows XP – but it's also safe. Rote. Familiar. Maybe a little too safe.

Windows 95 was a big deal because it innovated, because it was a break from the status quo. It sold 40 million copies in a year. It marked the coming of age of the Wintel beige box PC hegemony, and in the process dealt a near death blow to Apple and its rapidly aging System 7 OS.

But we all know how that story ends – with the iPhone in 2007, and most of all the iPad in 2010, Apple popularized the idea of simple touch computing surfaces that are now defining the Post-PC Era. The best way to predict the future is to invent it. And to their credit, Apple did; that is why their star is ascendant. Kind of absurdly scarily ascendant, actually.

It's not like Microsoft isn't investing in R&D. The Surface table looked amazing. Unfortunately, it was also trapped in a ridiculous, giant coffee table form factor that no regular person could afford or even want. That's too bad, because the Surface table was actually … kind of amazing. I've only ever seen one, in the lobby of a Seattle hotel in 2008. I went in skeptical, but when I actually got to try the Surface table, I came away impressed. It was a fascinating and intuitive multi-touch experience … that virtually nobody will ever get to experience or use. The iPad also offers a fascinating and intuitive multi-touch experience; let's compare:

a multi-touch Surface Table priced at $10,000 that, statistically speaking, nobody will ever be able to see or afford

… versus …

a multi-touch iPad in the hands of every consumer with $500 in their pocket

Now guess which of these companies is currently worth umpteen bazillion dollars. Go on, guess! No, it's not Webvan, you jokers.

After using the retina iPad for a while, I was shocked just how much of my everyday computing I can pull off on a tablet. Once you strip away all the needless complexities, isn't a tablet the simplest form of a computer there can be? How could it get any simpler than a tablet? Is this the ultimate and final form of computing? I wonder. It's a display in your hands, with easy full-screen applications that have simple oversize click targets to poke your finger at, and no confusing file systems to puzzle over or power-draining x86 backwards compatibility to worry about. Heck, maybe a tablet is better than traditional PCs, because it sidesteps all the accumulated cruft and hacks the PC ecosystem has accreted over the last 30 years.

If you're Microsoft, this is the point at which you should be crapping your pants in abject fear.

It is nothing less than the first stages of the heat death of the PC ecosystem, the formation of a tidal wave that will flow inexorably forward from this point. But you can't say they didn't see it coming. Bill Gates, of all people, saw this coming all the way back in 1995, the same year Windows 95 was released.

One scary possibility being discussed by Internet fans is whether they should get together and create something far less expensive than a PC which is powerful enough for Web browsing. This new platform would optimize for the datatypes on the Web. Gordon Bell and others approached Intel on this and decided Intel didn't care about a low cost device so they started suggesting that General Magic or another operating system with a non-Intel chip is the best solution.

To be honest, I had almost written Microsoft off at this point, to the "whatever the abomination that IBM is now" enterprisey deadpool. It's not like they would disappear, necessarily, but they no longer had a viable horse in the race for the future of consumer computing devices. In these darkest of hours, I was actually considering … switching to OS X.

That is, until I tried Windows 8, and until I watched Microsoft unveil Surface. No, not the huge table one, the new one that's roughly the size (and one hopes, the price) of the iPad. I was expecting Yet Another Incremental Improvement to Windows, but I got something else altogether.

It took a little longer than originally anticipated, but what's 17 years between friends?

Windows 8 is, in my humble opinion, the most innovative version of Windows Microsoft has released since Windows 95. Maybe ever. And it's good. Really good! I can't remember the last time I was this excited about a Windows release, except when I was kind of obsessively running betas of Windows 95 and waiting for Windows 95 to be released. Don't judge me man!

What's good about Windows 8? A ton of stuff.

• Excellent, beautiful, "live tile" Metro multi-touch tablet optimized interface, as honed from two prior Windows Phone releases.
• Integrated app store with updates for Metro apps. Yes, it actually works.
• Fantastic new overlay notification system.
• Noticeably faster to boot, faster to shut down, faster to sleep. It's just faster.
• Awesome new Task Manager. I am seriously in love with this thing.
• Updated Office 2010 style "ribbon" Explorer UI.
• New copy dialog with graph of transfer rates over time, along with a visible moving average.
• Lower system requirements and smaller footprint than Windows 7.

That's just a list off the top of my head. But don't take my word for it. Download the free Release Preview and try Windows 8 yourself.

Now, I will warn you that Windows 8 definitely has a wee bit of Jekyll and Hyde going on, because it smushes together two radically different paradigms: the old school mouse and keyboard centric desktop UI, and the new school tablet and touch centric Metro UI. It can be disconcerting to get kicked abruptly from one to the other. It's different, so there's a learning curve. (Protip: using your mouse scroll wheel in a Metro panel scrolls sideways. Don't forget the hover corners, or the right click, either.) But I have to say, this choice seems, at least so far, to be a bit saner approach than the super hard totally incompatible iOS/OSX divide in Apple land.

I expect that most people will decide early on whether they prefer treating their computer like a traditional laptop, or a tablet, and stick to their guns. Fortunately, the tablet stuff in Windows 8 doesn't get in the way. Even if only used as a glorified Start Menu, the Metro interface works surprisingly well – just start typing and match what you want to launch.

What's even more amazing is that Microsoft is actually pricing the upgrade sanely. Can you believe it's only $40 to upgrade from Windows 8 from XP, Vista, or Windows 7? It's like someone at Microsoft woke up and finally listened to what I've desperately been trying to tell them for years.

In the post PC era, Microsoft is betting the company on Windows 8, desperately trying to serve two masters with one operating system. The traditional mouse and keyboard desktop is no longer the default; it is still there, but slightly hidden from view, as the realm of computer nuts, power users, and geeks. For everyone else, the Metro UI puts an all new, highly visual touch and tablet friendly face on the old beige Wintel box. Will Microsoft succeed? I'm not sure yet. But based on what I've seen so far of Windows 8, its pricing, and the new Surface hardware – I'm cautiously optimistic.

Look at this incredible thing Ian Baker created. Look at it!

What you're seeing is not Photoshopped. This is an actual photo of a real world, honest to God double-clawed hammer. Such a thing exists. Isn't that amazing? And also, perhaps, a little disturbing?

That wondrous hammer is a delightful real-world acknowledgement of the epic blog entry PHP: A Fractal of Bad Design.

I can’t even say what’s wrong with PHP, because – okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there.

You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes.

You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways.

You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever.

And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there’s no clear problem with the set as a whole; it still has all the tools.

Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door.

That’s what’s wrong with PHP.

Remember the immediate visceral reaction you had to the double-clawed hammer? That's exactly the reaction most sane programmers have to their first encounter with the web programming language PHP.

This has been going on for years. I published my contribution to the genre in 2008 with PHP Sucks, But It Doesn't Matter.

I'm no language elitist, but language design is hard. There's a reason that some of the most famous computer scientists in the world are also language designers. And it's a crying shame none of them ever had the opportunity to work on PHP. From what I've seen of it, PHP isn't so much a language as a random collection of arbitrary stuff, a virtual explosion at the keyword and function factory. Bear in mind this is coming from a guy who was weaned on BASIC, a language that gets about as much respect as Rodney Dangerfield. So I am not unfamiliar with the genre.

Except now it's 2012, and fellow programmers are still writing long screeds bemoaning the awfulness of PHP!

What's depressing is not that PHP is horribly designed. Does anyone even dispute that PHP is the worst designed mainstream "language" to blight our craft in decades? What's truly depressing is that so little has changed. Just one year ago, legendary hacker Jamie Zawinski had this to say about PHP:

I used to think that PHP was the biggest, stinkiest dump that the computer industry had taken on my life in a decade. Then I started needing to do things that could only be accomplished in AppleScript.

Is PHP so broken as to be unworkable? No. Clearly not. The great crime of PHP is its utter banality. Its continued propularity is living proof that quality is irrelevant; cheap and popular and everywhere always wins. PHP is the Nickelback of programming languages. And, yes, out of frustration with the status quo I may have recently referred to Rasmus Lerdorf, the father of PHP, as history's greatest monster. I've told myself a million times to stop exaggerating.

The hammer metaphor is apt, because at its core, this is about proper tooling. As presciently noted by Alex Papadimoulis:

A client has asked me to build and install a custom shelving system. I'm at the point where I need to nail it, but I'm not sure what to use to pound the nails in. Should I use an old shoe or a glass bottle?

How would you answer the question?

1. It depends. If you are looking to pound a small (20lb) nail in something like drywall, you'll find it much easier to use the bottle, especially if the shoe is dirty. However, if you are trying to drive a heavy nail into some wood, go with the shoe: the bottle will shatter in your hand.
   
   
2. There is something fundamentally wrong with the way you are building; you need to use real tools. Yes, it may involve a trip to the toolbox (or even to the hardware store), but doing it the right way is going to save a lot of time, money, and aggravation through the lifecycle of your product. You need to stop building things for money until you understand the basics of construction.

This is not an abstract, academic concern to me. I'm starting a new open source web project with the goal of making the code as freely and easily runnable to the world as possible. Despite the serious problems with PHP, I was forced to consider it. If you want to produce free-as-in-whatever code that runs on virtually every server in the world with zero friction or configuration hassles, PHP is damn near your only option. If that doesn't scare you, then check your pulse, because you might be dead.

Therefore, I'd like to submit a humble suggestion to my fellow programmers. The next time you feel the urge to write Yet Another Epic Critique of PHP, consider that:

1. We get it already. PHP is horrible, but it's used everywhere. Guess what? It was just as horrible in 2008. And 2005. And 2002. There's a pattern here, but it's subtle. You have to look very closely to see it. On second thought, never mind. You're probably not smart enough to figure it out.
   
   
2. The best way to combat something as pervasively and institutionally awful as PHP is not to point out all its (many, many, many) faults, but to build compelling alternatives and make sure these alternatives are equally pervasive, as easy to set up and use as possible.

We've got a long way to go. One of the explicit goals of my next project is to do whatever we can to buff up a … particular … open source language ecosystem such that it can truly compete with PHP in ease of installation and deployment.

From my perspective, the point of all these "PHP is broken" rants is not just to complain, but to help educate and potentially warn off new coders starting new codebases. Some fine, even historic work has been done in PHP despite the madness, unquestionably. But now we need to work together to fix what is broken. The best way to fix the PHP problem at this point is to make the alternatives so outstanding that the choice of the better hammer becomes obvious.

That's the PHP Singularity I'm hoping for. I'm trying like hell to do my part to make it happen. How about you?

And now for the dramatic conclusion to The Great MP3 Bitrate Experiment you've all been waiting for! The actual bitrates of each audio sample are revealed below, along with how many times each was clicked per the goo.gl URL shortener stats between Thursday, June 21st and Tuesday, June 26th.

During that six day period, my overall Amazon CloudFront and S3 bill for these downloaded audio samples was $103.72 for 800 GB of data, across 200k requests.

Based on the raw click stats, it looks like a bunch of folks clicked on the first and second files, then lost interest. Probably because of, y'know, Starship. Still, it's encouraging to note that the last two files were both clicked about 5.5k times for those that toughed their way out to the very end. Of those listeners, 3,512 went on to contribute results. Not bad at all! I mean, considering I made everyone listen to what some people consider to be one of the bestworst "rock" songs of all time. You guys are troopers, taking one in the ear for the team in the name of science. That's what I admire about you.

I belatedly realized after creating this experiment that there was an easy way to cheat. Simply compress all the samples with FLAC, then sort by filesize.

10,836,505   We+Built+This+City+-+Excerpt+(Feta).flac
11,054,288   We+Built+This+City+-+Excerpt+(Limburger).flac
11,294,757   We+Built+This+City+-+Excerpt+(Brie).flac
11,731,999   We+Built+This+City+-+Excerpt+(Cheddar).flac
11,816,415   We+Built+This+City+-+Excerpt+(Gouda).flac

The higher the bitrate, apparently, the less compressible the audio files are with lossless FLAC compression. It's a small difference in absolute file size, but it's enough to sort exactly with quality. At least you can independently verify that I wasn't tricking anyone in this experiment; each sample was indeed different, and the bitrates are what I said they were.

But you guys and gals wouldn't do that, because you aren't dirty, filthy cheaters, right? Of course not. Let's go over the actual results. Remember each sample was ranked in a simple web form from 1 to 5, where 1 is worst quality, and 5 is highest quality.

The summary statistics for the 3,512 data points:

(If you'd like to perform more detailed statistical analysis, download the Excel 2010 spreadsheet with all the data and have at it.)

Even without busting out hard-core statistics, I think it's clear from the basic summary statistics graph that only one audio sample here was discernably different than the rest – the 128kbps CBR. And by different I mean "audibly worse". I've maintained for a long, long time that typical 128kbps MP3s are not acceptable quality. Even for the worst song ever. So I guess we can consider this yet another blind listening test proving that point. Give us VBR at an average bitrate higher than 128kbps, or give us death!

But what about the claim that people with dog ears can hear the difference between the higher bitrate MP3 samples? Well, first off, it's incredibly strange that the first sample – encoded at a mere 160kbps – does better on average than everything else. I think it's got to be bias from appearing first in the list of audio samples. It's kind of an outlier here for no good reason, so we have to almost throw it out. More fuel for the argument that people can't hear a difference at bitrates above 128kbps, and even if they do, they're probably imagining it. If we didn't throw out this result, we'd have to conclude that the 160kbps sample was somehow superior to the raw CD audio, which is … clearly insane.

Running T-Test and Analysis of Variance (it's in the spreadsheet) on the non-insane results, I can confirm that the 128kbps CBR sample is lower quality with an extremely high degree of statistical confidence. Beyond that, as you'd expect, nobody can hear the difference between a 320kbps CBR audio file and the CD. And the 192kbps VBR results have a barely statistically significant difference versus the raw CD audio at the 95% confidence level. I'm talking absolutely wafer thin here.

Anyway, between the anomalous 160kbps result and the blink-and-you'll-miss-it statistical difference between the 192kbps result and the raw CD audio, I'm comfortable calling this one as I originally saw it. The data from this experiment confirms what I thought all along: for pure listening, the LAME defaults of 192kbps variable bit rate encoding do indeed provide a safe, optimal aural bang for the byte – even dogs won't be able to hear the difference between 192kbps VBR MP3 tracks and the original CD.