Not to be confused with the movie of the same name, this book is a decade older, and presents a view of the MIT hacker culture. Arising from the Technical Model Railroad Club, in the days of the Programmed Data Processor (PDP), where computers were so large and costly that they had to be shared by entire departments. The Technical Model Railroad Club was utterly fascinated by what could be done with this new technology, and spent waking nights hacking on the computers.
Since computer time was scarce you had to book in advance for a specific time slot to run your “Official Sanctioned Programs”. Bookings were taken around the clock, and the enthusiasts chose to hang out at all hours, being ready to jump into any time slot that people didn’t turn up for. (Unsurprisingly these were the late night time slots.)
In these nights they explored the capabilities of this early technology, they wrote games, they wrote the first interactive debuggers. Things were low-level; programs were written in assembly, and the hackers were obsessed by succinctness and efficiency. On one occasion the impromptu “Midnight Computer Wiring Society” actually rewired the mainframe (against all sanctions) to implement a new instruction at the hardware level!
Things were different for computing in those days: Rather than each person having a computer on their desk, and another on their lap, and another in the mobile telephone in their pocket, there was only one terminal. And when you were on the terminal, you often had an audience. (No pressure!)
People would sit at all hours of the night and argue what to an outsider would be bafflingly arcane points. These arguments were the lifeblood of the hacker community. Sometimes people would literally scream at each other, insisting on a certain kind of coding scheme for an assembler, or a specific type of interface, or a particular feature in a computer language. These differences would have hackers banging on the blackboard, or throwing chalk across the room. It wasn't so much a battle of egos as it was an attempt to figure out what The Right Thing was. The term had special meaning to the hackers. The Right Thing implied that to any problem, whether a programming dilemma, a hardware interface mismatch, or a question of software architecture, a solution existed that was just ... it. The perfect algorithm. You'd have hacked right into the sweet spot, and anyone with half a brain would see that the straight line between two points had been drawn, and there was no sense trying to top it. "The Right Thing," Gosper would later explain, "very specifically meant the unique, correct, elegant solution ... the thing that satisfied all the constraints at the same time, which everyone seemed to believe existed for most problems."
From here grew the personal computer revolution. Computers got smaller and more affordable, and entered the mainstream. The classic computer games companies Sierra On-Line, Sirius, and Brøderbund Software (now all sadly defunct) emerged, as well as the very beginnings of companies such as Microsoft, Apple Computer, and Atari.
Given that I spend a significant proportion of my waking hours thinking about, working on, and discussing technical programming-related issues I figured it's about time to start blogging some of the interesting things I come across in that sphere.
For the benefit of my 'normal' friends (who prefer that a "delegate" is "a person elected to the United States House of Representatives", rather than "a type that references a method") I've decided to isolate this technical writing to a separate area.
If this prospect sounds appealing, check it out at www.danielfortunov.com/software.
Since an overwhelming majority of poll respondents indicated that they "get paid to do geeky things" I figure I it is safe to post on some more technical subjects, such as the book which I recently finished reading at work. (I've been struggling to find chunks of time to read this book, having started it over a year ago, so I'm glad to finally have finished it.)
Framework Design Guidelines, by Krzysztof Cwalina and Brad Abrams, encompasses a lot of the hard lessons that were learnt in bringing the .NET Framework to us. Building an intuitive and powerful programming API is a non-trivial activity, and a lot of people underestimate the importance of framework design and design testing.
This book explains a lot of concepts that are relevant to .NET developers (even if you're not explicitly building a framework) and boils each area down to a set of easy-to-understand "Do" and "Do not" rules (a lot of which are captured by the automatic analysis of FxCop and its successors).
If you want to learn from the mistakes at Microsoft, understand design principles, and build robust, easy-to-use APIs with .NET, then I'd recommend you read this book.