The Berkeley Hackathon 2010
Every so often, I will realize how awesome Berkeley is, and how much I love being here. My first Hackathon initiated one of those realizations earlier today (after I caught up on my sleep, of course). The Hackathon is, quite simply, a very open-ended programming contest. The rules are simple: start at 6 pm Friday, finish by noon Saturday. Beyond that, the sky’s the limit. Just make sure to have something to demo for the judges at noon. Food and energy drinks are readily available and generally disappeared very quickly.
Friday night: Roughly 100 hackers in some 30 groups met in the Wozniak Lounge in Soda Hall, but soon spread out throughout the building as the night progressed. Project ideas began flying wildly as teams start searching the Web for libraries and how-tos. My team was comprised of four Rubik’s cubers and we split in twos to work on the two main parts of our app. Two guys set out to use voice-recognition technology to translate cuber-given instructions into cube notation and algorithms. My partner and I set to work on an ASCII 3D engine for use in a console window.
In order to output graphics to a text-only screen, we knew we would have to make use of the curses library. Our initial plan to use Java for everything failed when we ran into problems getting the JCurses library working cross-platform. We then switched to Python to use its curses library. Once that was settled, we began working on the 3D engine, mostly dividing the labor between the printing of polygons and lines and the somewhat more annoying task of performing the computations to transform a 3-dimensional model into the 2-dimensional polygons and lines.
My task was to get the 2D drawing to work, while my partner in crime worked on the underlying 3D modeler. By midnight, we could draw a 3D wireframe cube in the terminal window. Soon thereafter, I finished polygon filling, enabling opaque polygons. A few hours later, the 3D graphics guru coding next to me had finished the matrix operations necessary for rotating and translating points and polygons. With this API in place, we set out to write a Rubik’s cube using our ASCII 3D library.
By this time, the pair on the other side of the table had made considerable progress on their speech-recognition program, and could control an already-made Cube program with theirs. All they needed to do was add a few more voice commands, try to improve the accuracy of their recognition, and then they could pipe their output into the currently-unfinished ASCII cube.
18 hours and countless sodas after we started, and with minutes to spare, the ASCII vision had come true, with one small problem. Since curses block the main thread, we had to create a second thread to take input from a stream (in our case, the voice-recognition program). However, the code, as written by noon, was not thread-safe, so the input streaming in was very often ignored by the Cube program.
One of the biggest lessons I learned from Hackathon was just how annoying Python’s object-oriented features are. Passing
in to every method is simply annoying, but less annoying than having to remember to use
for every instance variable inside the class definition. The biggest problem, however, is the limitation to one constructor. Most OOP languages allow function overloading, that is, methods with the same name, but different number/type of arguments. In Python, since methods can have optional parameters and Python lacks static typing, two methods with the same name but different numbers of arguments can be indistinguishable when invoking the method if one has optional parameters.
Python OOP rant aside, the program works wonders. It earned us an honorable mention from the judges and is one of the coolest things I have ever done with a computer.
What’s more, the 18 hours of hacking were some of the most fun I’ve had in a very long time. And that is why Cal is the right place for me.
Until next time,
You are cleared for launch!