Bad Code Contest!

They don't know it yet, but several of my fellow geeks at Drexel are about to be the recipients of some Bad Code Offsets.

They're like carbon offsets, only for lazy geeks who take the easy (and often ugly) way out when writing code. Things like allocating a huge honkin' array at runtime instead of coding a linked list, or doing a sort in n² time instead of n*log(n), just because you couldn't be bothered to implement Quicksort.

I know I'm guilty. My code gets more maintainable as I get older, but not very quickly. If style violations were actually illegal, I'd be on a first-name basis with most of the folks at the Criminal Justice Center downtown, just on the basis of the last microcontroller project I did alone. It's part assembly (some of it autocoded by a hacked-together FreeBASIC program), part macros, and there would have been some C thrown in for good measure if I hadn't run out of time. Prior to that, I did another project where a VBasic GUI running on one machine worked alongside a QBasic program running on another, driving a microcontroller running a program written in assembly -- and none of it presentable. (I guess I'm one of those programmers that Dennis Ray warned us about, way back when!)

The best part about these offsets is that the money goes to open-source projects. (I chose Apache as the beneficiary for the offsets I bought.)

I plan on putting these offsets to good use by starting an impromptu Bad Code Contest. No rules, except that the badness has to be confined to one egregiously bad line of code in the language of your choice. Something of such horribleness that it would make Dijkstra shudder from half a world away, in the same way Obi-Wan Kenobi felt a disturbance in the Force.

Bonus points for the Bad Line Of Code being implemented in assembly!

Linus Has Spoken

I was reading a recent article ("Real Men program in C") recently, and came across a link in the comments to Linus Torvalds' opinion on the whole C-vs-C++ thing. Let's just say he doesn't mince words. (This is an excerpt, but it captures the flavor of the original post.)

What Linus said.

C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.

In other words: the choice of C is the only sane choice. I know Miles Bader jokingly said "to piss you off", but it's actually true. I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really *would* prefer to piss off, so that he doesn't come and screw up any project I'm involved with.

C++ leads to really really bad design choices. You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap, that may "help" you program, but causes:

- infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny)

- inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app.

In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic "object model" crap.