Latest articles

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


Why I Hate Python (Or Any Dynamic Language, Really)

A project I'm currently doing for work involves a custom server-side component. Ordinarily I would reach straight for D and Vibe.d. (In fact, D and Vibe.d are already making development go very smoothly on a light-weight "not-a-blog" system I'm developing...at least in the rare cases I can actually spend any time on it...) Unfortunately, this project came with an unwavering pointy-hair decree that I must use either PHP or Python. (BTW, If you think you know who it was, you're probably wrong.)

Naturally I didn't hesitate to choose "Anything but PHP".

But, it's worth noting the big reason behind the "PHP or Python" limit was the usual false-dichotomy bullcrap about "getting shit done" that's frequently used by dynamic fans. About the only argument that made any sense at all was that a lot of people know PHP and Python and could pick up the codebase later (It's always nice to know you're coding your way towards expendability.)

Whatever, fine. Python it is.

So, long story short, I found this page which pointed me to some relevant libs, and I figured I'd try Flask first.

I went to download Flask (BTW, if I see one more language or lib claiming on its homepage to be "fun!", I'm gonna kill someone). But Flask showed nothing but a Linux release. WTF? I thought Python was supposed to be at least vaguely cross-platform? Searched around and found some obscure corner of the net that happened to actually explain how to install it on Windows. Ok, so I installed the prerequisite PIP, I do the "pip install flask"...and the system couldn't find PIP. More digging...Oh great, back when I had to put the Python directory into my PATH manually, despite having used an actual Python installer, I was apparently supposed to also know to add the 'Scripts' subdirectory. Clear as mud.

Fine, done. Try again...And I get some big useless "Traceback" vomit. (I swear, when trying to use Python "software", I get more "Traceback" bullshit than actual "Ok boss! Done!".) Buried in that garbage is some line of sourcecode involving a string literal mentioning something about needing a "PyFlakes". Ehh, what the hell, let's just try "pip install pyflakes". Nah, no dice, just more barf.

Meh, whatever, fuck Flask for now, let's try Bottle. Apparently it's supposed to be low-bullshit anyway, so sounds good. Wow, this one actually installs. And the "hello world" source on their website works! Hot damn, we're in business.

So I modify the hello world. And I look up how to change the content type, because I know I'm going to need to spit out binary data on this project. And...uhhh...the content type didn't fucking change. It's still spitting out 'text/html'. Errghh...So I blow nearly half an hour digging through the docs for something I may have missed, go back over my code...nothing. Try to find someplace to ask, find a buried link to a mailing list (I hate mailing lists), and start writing for help. Then, by pure chance, I happen to notice it:

from bottle import route, run, request, response @route('/foo') def index(): request.content_type = 'application/octet-stream' return 'Blah' run(host='localhost', port=8181)

Do you see the problem? I mean, aside from the flawed idea of indent-scoping and the goofy underscore_naming_convention. Yea...Obviously "content_type" is a property of the response, not the request. Of course, Python couldn't have told me 'request' didn't have a member 'content_type' and ended the matter right then and there. No, it had to string me along, doing anything except let me know something was wrong.

If this is a dynamic coder's idea of "getting shit done", then they can blow me.

Oh, sure, you never make stupid mistakes like that, right? There's a term for programmers who don't make dumb mistakes: Goddamned LIARS.

After fixing it to "response" we can still have some more fun with this:

response.content_typePOOP_SHITS_FUCK = 'application/octet-stream'

Still runs! Wrongly! Even though I'm damn certain the Bottle developers didn't put any "POOP_SHITS_FUCK" into their API.

Why the fuck should any of that even compile? That's what I hate about these dynamic turds, they happily let you do completely nonsensical shit, just for the fuck it. "Oh, but this means you can stick random extra garbage into any object you want!" Gee, great. Just what I've never wanted.

Here's another wonderful feature I never wanted:

from datetime import date ... response.content_type = date.today()

Holy hell, my content type is a fucking day and Python happily spits out the resulting gibberish. Gee, it's not a bug, it's a feature! (Hmm, happily doing the non-sensical? No wonder it's named after Monty Python[1].) "But what if you wanted to..." Lemme just stop you there. The day I want to do something like that is the day I want my head bashed in.

"But it's just doing what you clearly told it to!" Great, I see we're already forgetting something about "programmers who don't make mistakes". Now, I don't like software that second-guesses me any more than anyone else, but when I fuck up (as we all do) and tell my computer to do something that doesn't even make sense, I expect it to tell me so, not use it as an excuse to run around fucking shit up. If I hand you a gun and say "Shoot the fribstitch", I expect you to say "What the fuck is a fribstitch?", not start blasting away hoping to hit it.

So let's recap: Dynamic typing helps you "get shit done" by giving you the freedom to do useless nonsensical things, write to properties that don't even fucking exist, and generally do things that are either outright bugs or are convoluted enough to invite bugs. Then, instead of letting the compiler eliminate entire classes of these bugs, you're encouraged to take the time to write extra unittests to catch some of them instead of, you know, just "getting shit done".

If I'm gonna "get shit done", then I expect my language to help me avoid bugs, not help me make them.

[1] I am indeed a fan of Python the Monty. Just not Python the Dynamic.

Read more


Dispelling Common D Myths

As a frequent user and fan of the D programming language, I've noticed a number of misunderstandings and stumbling blocks that frequently trip up newcomers to the D scene.

These are perfectly understandable confusions. Many of them have very legitimate historical causes, so it's unsurprising that certain outdated or inaccurate beliefs persist. I take these as areas where the D community could communicate better to the outside programmer community, so allow me to explain:

D has IDEs

There was a time when D didn't have much IDE support beyond syntax highlighting. This is no longer true. If you like fully-featured IDEs, there are three main options, all of them actively supported:

DSource is dwindling, but D is more active than ever

Every few months, the D community hears something like this: "Is D dead? I went on DSource and everything looked old and unmaintained, the forums seemed inactive, so I assumed D was dying."

DSource was the de-facto project-hosting site for D projects. Note: Was. These days, most of the active projects have moved over to GitHub and BitBucket. In fact, even the repositories for the official D compiler and it's standard library have been hosted on GitHub for well over a year. And in that time, contributions and growth have significantly accelerated, not declined.

There had been updates in the works for DSource to address the issue of easily finding the active projects amongst the dead ones (keep in mind, any free open-source project hosting site is inevitably bound to accumulate many dead projects). But with the incredible recent popularity of GitHub and BitBucket, such an update to DSource would be of minimal value.

It does, however, bother me a bit to say such things about DSource. I've always greatly appreciated DSource, and it was a fantastic thing to have back in the D1 days before GitHub and BitBucket had become everyday names for almost any open-source programmer. The site, bandwidth and hosting were, and still are, very graciously donated to the D community free-of-charge, so I hate to speak of DSource in a manner that sounds like a eulogy. But nonetheless, even though DSource usage is now minimal, D is not only very much alive, it's rapidly growing.

As for finding active D projects, in addition to ordinary search engines, I recommend the D Wiki. Admittedly, we haven't been as good about maintaining the wiki's list of projects as we should have been, but I hereby pledge from now on to do my part, and I'll nag other D users to do the same ;)

UPDATE 2012-12-12: In order to aid and encourage updating, D's wiki has recently moved from http://www.prowiki.org/wiki4d/wiki.cgi to http://wiki.dlang.org, and is now built upon MediaWiki (the same engine used by Wikipedia) instead of the dwindling ProWiki which a number of contributers have found awkward to use. The D community has also taken this opportunity to purge the outdated cruft from the wiki and update it. So D's wiki is indeed progressing!

The D1/D2 split is no more

D2 is where it's at. D2 has already become the stable branch, D1 is a relic. Forget D1, stick a fork in it, it's dead.

And when I say "dead", I don't mean Python 2 "dead": I mean that practically nobody is using D1 anymore. Everyone's already on D2, even the stragglers. D1 is so unused that official support will end at the close of this year, 2012 (and that was announced a year ago). Nobody cares about D1, nobody uses it. It's over.

So, there is no D1/D2 split. There is only D2.

(EDIT: I may have overstated this point. See the comments below.)

Phobos is D's standard lib, but what's up with Tango?

You may have heard about a "Phobos vs Tango" split. In retrospect, that was indeed a misstep for D, but the issue was recognized and fixed. First the summary: Phobos is D's standard lib, period. Tango is now an optional but Phobos-compatible third party library. That's all there is to it.

But that wasn't always the case. Here's the history, for anyone interested:

Back in the early D1-days, back even before Andrei Alexandrescu had come on board, D's standard library "Phobos" was in a very rough, incomplete state. This was because it was being developed entirely by one person (D's creator, Walter Bright). Unfortunately, he was too busy developing the language and compiler to be able to fully flesh-out the standard library (which was, due to various reasons, not entirely open at the time).

So a group of highly talented developers got together and undertook the admirable task of creating a complete standard library. This was called Tango, and it was so good, and so much better than the incomplete (at the time) Phobos, that it became the de-facto standard library.

Unfortunately, in order to work well, Tango needed to replace some of the very-low-level runtime portions of Phobos. This meant Phobos and Tango were incompatible - you had to choose between one or the other, not both. This, quite understandably, became a giant PR disaster.

Meanwhile, Phobos began transitioning to open-source, Andrei Alexandrescu joined up and became Phobos's leader, and Phobos finally started getting fixed and fleshed-out. And it was getting very good in its own right. But this naturally didn't help the "Phobos vs Tango" issue. Admittedly, it may have been a misstep in D's history. But fortunately, the D community heard the "Two standard libs?!?" complaints loud and clear, and set out to fix it.

At this point, D2 was underway as the main "unstable" (at the time) development branch (while D1 had become the stable "non-breaking-changes-only" branch). So for D2, the low-level runtime stuff that was creating incompatibility between Phobos and Tango was factored out and dubbed Druntime. In D2, Phobos and Tango *both* use Druntime, so Phobos and Tango are now fully compatible. There is no more split.

Which should you use? Phobos, unless you have some specific reason to pull in Tango as well. After all, Phobos is the standard library.

Why might you want to use Tango? Same reasons as any other third-party library: If you like the design of it, for example. Tango's design has a very Java-flavor, so Java users may like it. Or if you find something in Tango that's not in Phobos. For example, Tango has the world's fastest XML parser. Phobos's XML library, on the other hand, is the one module in Phobos that's known to still be in desperate need of a rewrite and might get removed. (Don't worry, the rest of Phobos is fantastic.)

D is open source

There are three main D compilers:

  • DMD: Official reference compiler
  • GDC: Uses GCC and is in the process of being merged into GCC mainline.
  • LDC: Uses LLVM.

GDC and LDC are fully open-source, period, and are even in certain Linux package repositories, and not in the non-free sections.

The standard library and runtime, Phobos and Druntime, are OSI-approved Boost-licensed.

DMD's entire source (as well as the standard library and runtime) is publicly available on GitHub. The front-end, which is shared with GDC and LDC is OSI-approved Artistic-licensed (EDIT: It's also dual-licensed under GPL).

The only thing that isn't strictly OSS is the backend of DMD, because the rights are licensed from Symantec. But the source for it is publicly available on GitHub and open for pull requests. Worried about redistribution? Don't be: Just ask Walter. He may be under obligation to require his permission, but it's only a technicality. Ask him, and he'll grant permission. He hasn't been known not to. And note, that's only for DMD, and specifically DMD's backend. Everything else is fully-OSS including two complete D compilers: GDC and LDC.

D is open-source. It wasn't always, but it definitely is now.

D allows manual memory management

D may have a garbage collector as standard, but that doesn't mean you can't control it, stub it or replace it or use manual memory management.

D supports pointers (neatly limited to a memory-safe subset of operations if you're using @safe mode) and calling C functions. So you can call malloc/free, and stick anything you want in the resulting memory using the emplace functions. Or you can use stack-allocated auto-scoped classes. Or reference counting. Or no-clutter RAII. Additionally, there's a whole custom-allocator system in the works.

Static-typed does NOT mean unproductive

D may be static-typed, but that shouldn't make you think "C++ and Java":

% cat funWithRanges.d import std.algorithm; import std.range; import std.stdio; void main() { // All done lazily: auto squares = sequence!((a,n) => n^^2)(0); auto fibonacci = recurrence!((a,n) => a[n-1] + a[n-2])(1, 1); auto fibEven = fibonacci.filter!(x => x%2 == 0)(); foreach(v; zip(squares, fibonacci, fibEven).take(6)) writeln(v[0], "\t", v[1], "\t", v[2]); } % rdmd funWithRanges.d 0 1 2 1 1 8 4 2 34 9 3 144 16 5 610 25 8 2584

And it's not just clean and fast, it's also safe and correct.

Plus there's some nifty concurrent processing toys, easy templates and metaprogramming, and the usual lineup of expected modern niceties.

Read more


It's A Bad Workman Who Blames His Tools...

...Because a good workman knows the difference between the right tool and a piece of shit.

Oh sure, a good carpenter could use a damn saw to drive a nail. But only a lousy carpenter would try. And only a bad manager would expect him to.

Now I'm all for personal responsibility and whatnot. And I know that handing a professional tool to an idiot monkey probably won't get you good results. But when a someone's expected to do a job with a shitty tool, or simply the wrong tool, and the results suck...well then let's cut the crap and put the blame where it belongs: On the tool, and on the idiot who chose it.

Perhaps more importantly, let's quit abusing trite sayings to rationalize idiocy.

And speaking of bad tools: Anecdotal appeals to accomplishment do not demonstrate a tool doesn't suck. (I'm looking at you, PHP apologists.)

Read more


Why prefer non-JS solutions if I don't care about non-JS users?

Great question, I'm glad you asked!

Aside from the fact that not caring about users who prefer to keep JavaScript disabled is extremely douchebaggy (which you're obviously ok with being, otherwise you wouldn't have asked the question), here's why you should still use pure-HTML/CSS solutions whenever they exist:

  1. No matter how fast your user's JS engine is (and, no, they're not all top-of-the-line), a lack of JS will always be faster than fast JS (and use less battery, etc.)

  2. Better compatibility: It's just one less thing to trigger cross-browser compatibility issues. One less thing to go wrong.

  3. There's no guarantee that unneeded JS won't trigger explosive flatulence, male pattern baldness and impotence...Better to be careful, right?

Read more


Apple: Final Proof The US Is Completely Corrupt

Apple has successfully solidified the *cough*legitimacy of software patents. Welcome to 1984. Who needs SOPA to destroy freedom when we have Apple?

I take back what I said about Steve Jobs. I'm glad the fucker's finally a rotting corpse. What I'm not glad about is that 1. It took so goddamn long for the bastard to die, 2. He didn't suffer more, and 3. The rest of Apple is still allowed to live freely after blatantly murdering any last chance of true freedom.

Any Apple employee with any shred of moral integrity would be jumping ship by now. Any who choose remain, for any rationalization, are now necessarily every bit as evil as Jobs was. And that's a hell of a lot.

And no, this is not any form of threat, you dumb shits.

The only good that could come of this is that Android might actually be forced to be less of a piece of shit by aping fewer of Apple's retarded ideas. But this total corruption of the formerly free world is far too high a price for such a trivial win.

R.I.P. Justice and Freedom: Died August 2012, not at the hands of terrorists, but at the hands of Apple, all thanks to the personal grudge of a dead CEO.

I hope you iWhores all choke to death on your phones. We have all of you to thank for this mess, after all.

Read more