RSS
 

Posts Tagged ‘programming’

F*cking programming

17 Dec

Yesterday I stumbled onto a delightful tool from Google Labs: Code Search.

Turns out Google is now crawling through source code. The GoogleBot, in its never-ending quest for sentience, searches inside tars, zips, and even dives into CVS and Subversion repositories. As Code Search is targeted at programmers, you can perform fantastically powerful queries using POSIX extended regular expressions.

Granted access to billions of lines of code and the awesome power of Google’s search technology, I did what any rational, thinking programmer would do: I typed in some profanity and hit enter.

In tribute to the valiant struggles of coders everywhere, please enjoy:

The best in programming profanity

/* We will NOT put a fucking timestamp in the header here.
Every time you put it back, I will come in and take it out again.
I’m sorry. This field does not belong here. We fill it with a 0 so
it compares the same but is not a reasonable time. */

/* Dear free software world, do you NOW see we are fucking
things up?! This is insane! */

# This job would be great if it wasn’t for the fucking customers.

/* Boy, would I like to make the thing expire one second ago, or what? Of course I would. But that slimy, stinking, load of pig manure that is called Netscape/1.1N doesn’t pay any attention to the seconds part of the time… after all, what’s a second or two amongst friends? So, I thought to make it expire one minute ago, but naturally, that didn’t work on 1.1N either. Losers. So, I made it expire 24 hours ago, which, if you ask me, is most heinous, considering the Last-Modified date could be later than that. I fucking hate you, you monopolizing piece of Netscape feces. */

# However, this only works if there are MULTIPLE checkboxes!
# The fucking JS DOM *changes* based on one or multiple boxes!?!?!
# Damn damn damn I hate the JavaScript DOM so damn much!!!!!!

# Trillian, again, is fucking stupid and crashes on just
# about anything its homemade XML parser doesn’t like.

/* TODO: this is obviously not right … this whole fucking module sucks anyway */

// gratuitous hack for Adobe SVG 3, what a fucking POS

/* if we get here, there are massive fucking problems, for a start our stack is fucked up, and we can’t return(). Just crash out. */

/* FIXME: please god, when will the hurting stop? Thus function is so
fucking broken it’s not even funny. */

/* XXX toshok why oh *why* god WHY did they do this? no fucking
sense */

# Note to self: I have no idea what this does anymore
# It looks like a cool fucking segment of code though!
# I just wish I remembered writing it… :-\

/* Outlook can’t fucking follow RFC if someone PAID them to do it…
oh wait, someone paid them NOT to do it. */

/* don’t fire dem packets too fucking fast */
usleep(1000);

## fucking imap fucking sucks. what the FUCK kind of committee of
## dunces designed this shit.

Fuck me gently with a chainsaw! Will someone please tell me how the fuck you resize a fucking widget?? Why, when I call whatever resize method I try with 64×64 does the fucking window end up 64×82? WHY???????? WHY???????? WHY???????? WHY???????? WHY???????? WHY???????? (why..?)

/* No we fucking don’t! DB entries should be stored in the same order
as they are in the file ! I can’t belive I was so fucking stupid !

# no, no, no, no, no, no, no, no
# no. fuck no. I am a fucking
# moron.

## aaahhh, user input. who would have though that such a simple
## idea would be SO FUCKING COMPLICATED?! because apparently
## Ncurses.getch (and Curses.getch), even in cbreak mode, BLOCKS
## ALL THREAD ACTIVITY. as in, no threads anywhere will run while
## it’s waiting for input. ok, fine, so we wrap it in a select. Of
## course we also rely on Ncurses.getch to tell us when an xterm
## resize has occurred, which select won’t catch, so we won’t
## resize outselves after a sigwinch until the user hits a key.
## and installing our own sigwinch handler means that the screen
## size returned by getmaxyx() DOESN’T UPDATE! and Kernel#trap
## RETURNS NIL as the previous handler!
##
## so basically, resizing with multi-threaded ruby Ncurses
## applications will always be broken.
##
## i’ve coined a new word for this: lametarded.

/* Sun, you just can’t beat me, you just can’t. Stop trying,
* give up. I’m serious, I am going to kick the living shit
* out of you, game over, lights out. */

/* Holy shit, we just updated more than one row!
What do we do now? */

/* 2,191 lines of complete and utter shit coming up… */

if (!(ptr = malloc (size)))
/* SHIT! SHIT! SHIT! */
die (“malloc failed”);

And my personal favorite:

# code below replaces code above – any problems?
# yeah, it doesn’t fucking work.

(Links are to the original sources)

Stay tough out there guys. Happy Monday.

 
122 Comments

Posted in humor

 

On the fundamentals of programming

14 Dec

Let’s start with a story.

I am a volleyball fanatic. I enjoy the game in a way that borders on obsession. Lately I play three times a week for hours at a time. Now, my position is known as middle hitter. As you might have guessed, I’m the guy who stands in the middle of the court and tries to pound the ball through the other team’s floor.

A few months ago, I was going through an athletic crisis. Despite many hours of play I still wasn’t that good at hitting. In fact, I kinda sucked at it. My other skills were decent, but when it came to spiking the heck out of the ball, something wasn’t right. I just wasn’t getting the power other people were and I didn’t know why. I experimented constantly: different arm swings, changing my hand shape, snapping my wrist. Nothing worked. Sad and ashamed, I enrolled in a clinic hoping to cure my hitting dysfunction.

On the first night, the coach ordered us into a hitting drill. No problem. I’m focused, I’m ready; I’m going to crush this ball. I went up for my approach and, well–tapped–the ball over the net. Not impressive. I tried again but with similar results. Discreetly, the coach pulled me aside:

“Did you know you’re taking an extra little hop before you jump?”

“I am?”

“You are. It’s taking away all your momentum so your jump is all wrong. Get rid of that and try again.”

On my next attempt, the set was perfect: high and tight, and I smacked it the same way you’d high-five your grandmother. But that time, I felt the extra hop I was taking. Suddenly it was so obviously there.

I lined up once more. I took three strong steps, leapt in the air, and pounded down the best shot of my life. WHAM! I was elated. The problem I had with hitting was simple: I was deficient in the fundamentals. Everything I’d been tweaking was the minor stuff. Fundamentals are the rock-solid road bed you build on. I’d been rearranging the mile markers on a strip of sand.

The point here is important: mastery of any complex skill requires mastery of its fundamentals. I think this idea just might tell us why there are so many bad programmers out there. And I also think it tells us it’s our fault.

How does one acquire the fundamentals of programming?

I don’t think the answer lies in obtaining a computer science degree. I once interviewed a recent MIT graduate who’d majored in computer science. She was articulate, had a strong GPA, and couldn’t write the pseudocode to sort an array. Really. This is actually a familiar phenomenon. A CS degree tells you how, theoretically, you might spike a volleyball, but that doesn’t mean graduates have ever actually hit one. Of course computer science isn’t really about programming, it’s not even about computers. Now, there are lots of strong coders with CS backgrounds, but that strength is almost always acquired through their own work–they are self-taught.

Academia isn’t much help, so we’re going to have to become deadly code-ninjas on our own. Fortunately, there is a wizened master who can point us in the right direction: Peter Norvig, whose essay “Teach Yourself Programming in Ten Years” wins my personal Nobel for Programming Literature. It’s probably the best advice out there on the subject, and we’d all do well to follow his recommendations. However, despite the fact that Peter is so smart his brain has its own gravitational pull, I think his essay glosses over an important point.

Let’s look at the main thrust of Norvig’s advice:

Program. The best kind of learning is learning by doing. To put it more technically, “the maximal level of performance for individuals in a given domain is not attained automatically as a function of extended experience, but the level of performance can be increased even by highly experienced individuals as a result of deliberate efforts to improve.” (p. 366) and “the most effective learning requires a well-defined task with an appropriate difficulty level for the particular individual, informative feedback, and opportunities for repetition and corrections of errors.”

This is clearly good advice. Surely that MIT graduate could have written me that algorithm if she’d, you know, written code before. But check out the quotation Norvig cites. Where exactly does one find well-defined programming tasks of an appropriate difficulty level? How about informative feedback and corrections of errors?

Well?

It turns out that there’s a shortage of things like this for programmers. Especially new ones. This is a serious problem, and it is this I blame for the huge numbers of coders who lack the fundamental skills of our craft. Worse, this is our own fault: only people already skilled in an activity can devise effective training for newcomers. Even worser: when you lack skills in the fundamentals you almost never know it. I had no idea why I couldn’t spike a volleyball.

So how do we fix this? We do what all great thinkers do: steal a great idea from somewhere else and reuse it. So here’s my solution, shamelessly grabbed from a different, but related area of my life:

To become a better programmer, one should practice like a musician.

Bear with me…

A beautiful piano sonata is the product of thousands of perfectly executed notes. If even one note is misplayed you have cacophony. However, the consideration of individual notes never enters my mind while playing. Instead, I’m thinking about making the phrases flow together, the winsome arc of the melody, or keeping the steady beat of the bass line. It is these things that create music from mere notes. I’m able to think of these things because my mind is free from worrying about playing individual keys, and my mind is free because of my mastery of the fundamentals. The study of classical piano (and every other musical endeavor) devotes ample time to performing exercises. There are perhaps hundreds of books full of them. Compared to a real piece of music they are simple and repetitive, but each exercise isolates and drills a vital skill. This focused practice makes such skills automatic–I can play a very fast run of notes smoothly and accurately because I’ve quite literally practiced it thousands of times. I no longer need to think about it. Because of this, I am a better pianist.

The application of these ideas to programming should be clear. When I’m focusing on the overall musicality of a piece, I’m operating at a higher level of abstraction. Individual details have faded away, and I’m able to focus on making something beautiful. The same skill is required for creating beautiful programs. If you must spend brain cycles struggling with minute implementation details you have no hope for making your solution elegant.

So let’s take this musical idea and alter it slightly. After all, when it comes to programming exercises, coverage is more important than repetition. Not remembering how your language retrieves values from a hash is far less damaging than not knowing hashes exist in the first place.

Fortunately, I can already point to an excellent example of these sort of problems. I believe newcomers would learn more about programming per unit time by working through Ninety-nine Prolog Problems than almost anything else. (Replace Prolog with your language of choice). With the ability to check your answers and also post questions on a wiki, we’ve even covered the “correction of errors” and “informative feedback” requirements mentioned above. Also excellent is The Python Challenge, a series of riddles with programmatic solutions that get progressively harder over time. The site is massively popular and makes people better programmers. Truly, this is a phenomenal start, but there’s much more to be done.

So how about it guys? What are the first fifty programs someone should write to break out of that painful newcomer phase? What topics would they definitely have to cover? Later, what programs must one write to reach hacking virtuosity? I also like to think about this a different way: what problems would you be embarrassed to tell your coworkers you can’t solve?

I think these questions are important, and they just might help improve the overall quality of programmers out there. If you accept programming as an art, why don’t we treat it like one? Let’s start practicing like musicians, and maybe we can create something beautiful.

 
38 Comments

Posted in coding