Praising companies for providing APIs to get your own data out is like praising auto companies for not filling your airbags with gravel. I’m not saying data export isn’t important, it’s just aiming kinda low. You mean when I give you data, you’ll give it back to me? People who think this is the pinnacle of freedom aren’t really worth listening to. –DiveIntoMark

People are going on and on about the lack of ability to do background processing in an iPhone app. Gruber counters the flow (and may be right), but I can’t help but wonder if maybe Apple has something else up their sleeve?

I may be out to lunch, but it’s possible that the iPhone’s TCP/IP stack (or its select equivalent) is able to hold connections open in an event-ish way. Really this is all that’s needed in most cases, some sort of continuity for applications like IM. Full background processing is a bad idea on a quality phone/mp3 player, but some sort of compromise may just do the trick.

Here’s hoping Apple has something like this in mind.

Take a look at the Joyent response to an article about web hosts:

Joyent.com is not, and has not been down.
We have a history of 100% network uptime (that’s verifiable), and zero facility issues over 4 years.

That’s a big claim to make, especially considering Joyent’s breakup with Twitter and other recent uptime issues.

A scathing rant against Rails from the comp.lang.lisp newsgroup.

Linus rants about const:

“const” has never been about the thing not being modified. Forget all that claptrap. C does not have such a notion.

“const” is a pointer type issue, and is meant to make certain mis-uses more visible at compile time. It has no other meaning, and anybody who thinks it has is just setting himself up for problems.

Dreamhost rants about How Ruby on Rails Could Be Much Better. An interesting perspective from one of the largest vhosting companies out there.

From the horrifically god-awful (IE6) to the merely depressingly buggy, nonstandard, and incomplete (IE7)… congratulations! – IE Blog response to ‘The First Year of IE7′

I’m tired of wrapper libraries. They’re a cognitive consumerism gone awry, wrappers for wrappers wrapping wrappers. Every development team I’ve known has their own¹, each somehow better than the others, most ignoring the long history of thinking gone into libraries written throughout computing history.

What’s wrong with using the basic standard libraries, ported where they don’t exist? I mean, really, why do we need another date class, or another wrapper on file paths?² Are you or your development team so challenged that you can’t reliably use fopen or fprintf? Is your own brew of file.Open() more reliable than, say, C#’s, Java’s, Perl’s, the STL’s (or whatever toolchain you’re immersed in)?

I’ve heard the excuse that standard libraries fall short in some way: maybe they’re not available for a required platform, or maybe they’re missing a key set of functions. Then port the libraries (there are enough free implementations out there), or add a companion library, class, or unit. It’s really not that difficult. Re-wrapping the entire damned universe should be left to the crazies with their tin-foil hats and couches covered in plastic. And the standard libraries aren’t so bad that you need to be protected from them. In fact, they’re pretty damned good, once you’re willing to get over your own ego.

I think that teams are looking at the problem of abstraction the wrong way. Wrapping concepts in your product’s domain is a good thing (as long as you don’t overdo it). But where’s the value in wrapping things that have thousands of existing implementations? Why repeat what’s been thought, built, and tested thousands of times over? Just learn the fucking standards, understand that they’re imperfect, and make peace with the fact that they don’t fit your personal mental model of things. Assume that where your mental model differs that it’s wrong or unimportant, because it probably is.

And if you’re not willing to use the standards, at least use the de facto libraries for the platform. If you’re targeting Windows prefer the Posix libraries³, then default Win32 libraries for your toolkit, and as a fallback, any absurdly popular library that has a vibrant community. The same goes for whatever platform you’re on. But if you’re tempted to write your own basic-concept-wrappers, in your own brand of library magic, then you’re full of shit. Get over it: you’re not that good. None of us are.

That’s why we share standards. That’s why out of thousands of class libraries, only a few bubble to the top. Only one or two of them are good enough to be worth using. Spend your time on problems related to your application, on the things that your users will actually care about.

1. And yes, I’ve fallen to this bug myself in decades past ↩
2. Companions to the standard libraries are good, as long as they don’t repeat what’s already available ↩
3. Because it’s the right thing to do ↩

I was thinking about why I hate frameworks. It’s not a full-on hate, of course, but I find that wrapping and abstracting every aspect of an approach insulates you from what you really need to understand. I call it the inverse law of elbows: the more elbows you add to something, the harder it is to get it to do anything useful.

So while my mind was wandering around the why-do-people-insist-on-frameworks question, I started thinking about what I do like. Here’s what I came up with:

• Engines (solve a narrow class of problem with a simple interface)
• Libraries (functions and groups of functions)
• Toolkits (larger groups of functions)
• Languages (alternate ways to describe solutions)
• Domain specific languages (solve small parts of your domain well)
• Concrete, simple implementations (just the straight dope)
• And, always, always, always consider standard/common things first

It comes down to choice, orthogonality, and the smallest number of immutable constraints on how you can put the parts together.

You can replace engines easily, based on their well defined, loosely coupled interfaces. You can take or leave portions of libraries and toolkits. Languages (outside of little languages) give you some level of choice. DSLs let you express things in your domain. And simple, concrete implementations give you things that work.

I’m going to work on posting links to some metaphors of products using engines, libraries, DSLs (and the like) really well. I’ve been inspired by dozens of things that other people have written, which have moulded how I see approaches.

7 reasons I switched back to PHP after 2 years on Rails - O’Reilly Ruby. A seemingly unbalanced story of switching away from Rails.