Software/Device Development and Design

Facebook is not written in PHP

Yea, I know you're thinking "This guy's nuts! Everyone knows Facebook is PHP!" Sit down, shaddup, and I'll explain...

But let me address this first: The claim that "Facebook is written in PHP" is frequently used to rationalize using the world's worst language. This is, of course, idiotic because appeal to authority is a logical fallacy. To put it in simpler terms: Just because Ozzy Osbourne abused the hell out of drugs and alcohol and wound up rich, famous and alive, obviously doesn't mean it's a good approach to imitate. Get the picture? So quit saying stupid shit like "PHP is fine because XXXX uses it". It makes it obvious you're an idiot.

Ok, back to Facebook's usage, or not, of PHP:

Like any remotely sane company, Facebook doesn't use PHP for its core systems. The actual "core stuff" language used varies by company, but at Facebook, they "use C++ heavily on [their] back-end systems"[1]. In fact, they "use C++ at Facebook all over the place".

While Facebook has things that are ostensibly PHP, it's not the real PHP. The real PHP is such a piece of shit, Facebook had to write their own alternate version of it (HipHop's HPHPc, which converted the "PHP" to C++). Then they had to make another, the HPHPi. And then yet another, the HipHop VM. Facebook does not use real PHP, and that's because true PHP is just simply crap unsuitable for them.

Not only that, but the psuedo-PHP that Facebook does use is being quickly overtaken by Facebook's increasing usage of C++: "...two years ago, maybe 90% of [Facebook] programmers wrote PHP and 10% C++. Now there are roughly as many C++ programmers as PHP programmers." Additionally, Facebook has had growing internal interest in D (note that link is over a year old already), and Facebook's HipHop team is one of the sponsors at this year's D conference.

So ultimately, no; contrary to conventional "wisdom", Facebook is not written in PHP.

[1]: See question #4 here.

Read more


The PHP CMS Screwed Up The Previous Article - And This One

Wow, leave it to a PHP-based content management system to help me prove a point about useless bug-riddled crapware.

No later than when I wrote and tried to post the following message, that's when this PHP-based article system inexplicably corrupted the post and turned it into a black hole. If I'm lucky, the same wont happen again right now...

Original *attempted* posting:

Anti-Perfectionism Doesn't Mean "Release Crapware"

"Don't let perfection become the enemy of the good"?

That's all fine and good to an extent, but many people take it too far and wind up with products that are only minimally useful. Or useless bug-riddled crap.

Don't let rapid development become the enemy of a worthwhile product.

UPDATE 2013-03-20: I've fixed the problem. For some idiotic reason, the id (primary key) column of the database's "article parts" table (actually "tcm_mod_article_parts") was set to signed TINYINT. Seriously. That meant only 127 articles parts (I have one or two articles here that are two-parters) and then KABOOM, error upon INSERTs, which is exactly what happened. I have no idea whether the TangoCMS installation script set it up that way or if MySQL's migration tool fucked it up when I changed servers, and I'm not going to investigate either. Either way: fuck!

Oh yea, and wasn't it nice of my PHP-based CMS to not bother to give me any indication whatsoever the DB had returned an error, or that there has been any error at all? Wasn't even in the damn logfile for shit's sake. But then that's the whole philosophy of these damn dynamic languages, isn't it: Never flag an error when you can silently do the wrong thing.

I am still working on my own custom D/Vibe.d-based replacement, and it's been coming along, but slowly since I haven't had much time lately to dedicate to my various pet projects. It's not too far from a releasable state, but still needs some work on a few things.

Read more


Anti-Perfectionism Doesn't Mean "Release Crapware"

"Don't let perfection become the enemy of the good"?

That's all fine and good to an extent, but many people take it too far and wind up with products that are only minimally useful. Or useless bug-riddled crap.

Don't let rapid development become the enemy of a worthwhile product.

Read more


Know Your Computer Terminology: Worse is Better

"Worse is Better":

The software development philosophy that flexible software is too useful to too many people and should therefore be replaced with a proliferation of inferior alternatives, all of which have significant problems or limitations which result in them all being of minimal overall usefulness.

Such non-useful software can be made cheaply and easily by lazy and poorly trained people who don't particularly feel like or know how to write reasonably good code. The result is that software becomes worse, however it is exactly this inferiority which is highly valued by savvy modern developers.

Summary:

"Worse is Better" is a hip, common and convenient way to rationalize the practice of habitually phoning-in half-assed work.

Read more


It's an absolute travesty of basic sense...

...that the buzzword "touch" is bandied about by the creators of buttonless touchscreen-only devices which inherently have no tactile sensation at all.

(Yes, I just used the phrase "bandied about". So I've been watching Frasier, ok? ;) )

Read more


The [Un]Robustness Principle

"Be strict in what you send, and relaxed in what you receive."

First it was considered a good way to build a robust system. Then HTML and early web browsers came along, took the principle to heart, and everything blew up. (Yes, I'm oversimplifying, but stay with me here.) Now the robustness principle is widely considered a recipe for poor reliability.

I think both stances on the robustness principle are missing a key point.

How can you be sure you actually are strict in what you send, if everything is relaxed about receiving it?

That's the problem with the robustness principle. It's a solid principle when people actually are following it. That is, if they actually are strict about what they send. But without strict receivers, you're not being strict about sending, you're just assuming you are. And your relaxed receiving is encouraging others to be relaxed about what they send, because you're forcing them to assume, too. The result is that the robustness principle is not actually being followed at all.

Strict begets strict, and relaxed begets relaxed. That makes the robustness principle difficult to implement.

There's another issue. "Relaxed" (or "liberal" if you prefer the original wording) is too vague. You want to be relaxed and accept bad input to the point of not dying or corrupting data. But not to the point of encouraging bad input.

What's needed is an amended robustness principle:

Be strict in what you send, and pragmatic in what you receive: Don't crash, but avoid assumptions and speak up about problems.

Read more