Making some headway.

coders

Joe Armstrong created Erlang in 1986, which is quite some time ago, and he learned to program even before that. You’d write a program, then somebody else would type it onto punch cards, then you’d feed it to the computer, and then you’d get an error. One error, the first encountered, after which your program was done. And that was with about a one week turnaround time. So he very quickly learned the advantages of concurrent programming, writing many small test programs for every function, and submitting that as a batch. Then, once all the parts worked, submit the final program that ties it all together.

These days we have filesystems with directories and filenames longer than ten letters, and do we really need all that? Has it made us productive or just lazy? I think he’s got a good point that we’ve adopted this culture of if it compiles, it complies. Compile times are so fast, just keep throwing text at the compiler until it accepts something, then keep running the result until it looks acceptable. But how many bugs and unhandled edge cases remain? I would surely spend more time contemplating my code and examining it for bugs if it took a week to compile.

He’s got a good story about peeking inside the black box and learning what’s happening at all levels. He wanted to connect some Erlang code to X. The normal way to do this is via Xlib, but that can be kind of messy from Erlang. Then he looked a little closer, at the X protocol, and of course it’s just messages back and forth between client and server. Erlang is very good at sending and receiving messages, so he programmed directly against the X protocol, stripping out the abstraction. I think a lot of the time we either forget or don’t bother to look at what’s on the other side of the abstraction layer, to see if maybe it’s not a better fit for what we’re trying to do.

On debugging, he makes two recommendations. Explain the problem to somebody, which tests your own understanding. And bugs are often in the vicinity of the most recent change. Write a specification. The code only tells you the answer to a problem, making you guess the problem; the spec should identify the problem as well.

Joe converses a bit about remembering programs and being able to retype them from memory. Maybe not an exact replica, but something similar. No worries about losing code. This probably gets back to the way he spends more time thinking about the solution. I know I’ve worried about losing code quite a bit. Spend a few hours trying to solve a problem, finally get it working, and then immediately make a backup in case I lose it. Upon reflection though, I think this is a sign I don’t understand what I did. The code, the text of it, should be an expression of my understanding, but it’s a bad sign if the understanding itself is somehow locked inside the text.

founders

Arthur van Hoff founded Marimba. Kleiner Perkins wouldn’t let them spend any of their funding on an espresso machine, which seems really quaint because today I’m not sure VCs would allow you to start a company without an espresso machine, if not a full time barista and smoothie bar. They were in the automatic software updates business, which also sounds not very exciting now, given that pretty much all software is constantly auto updating, whether I want it to or not. Thanks, guys!

Paul Buchheit created Gmail. At the time, this was something of a new direction for Google. Unlike a search index, you can’t discard somebody’s mail spool and simply recreate it a few days later. Similarly, when mail is received, people don’t expect to wait until the index is updated before they can read it. So offering a product like this is signing on to deliver a level of service they hadn’t worried about. Sometimes it’s possible to operate at enormous scale, but only given certain assumptions and shortcuts, and taking those away means you’re starting over with much less confidence.

Gmail is definitely among the newest products in the book, but even so, it spent two years in development before the public launch. I find that pretty remarkable, in a climate of launch first, develop later.

man-month

What went wrong with the Tower of Babel project? They had plenty of resources, engineers, and focus. But alas, they lacked communication, setting space exploration back about 6000 years. To solve this problem today, for large projects, one keeps a workbook, containing all the specifications, internal and external, for a project. This allows even very large groups to know what everyone else is doing. Keep a changelog as well.

Brooks is talking about a project with five feet of printed documentation. And two inches of daily changes! I can’t even imagine. Eventually they switched to microfiche. Of course, today, you’d keep everything online, but the scope of the specifications involved just seems enormous.

Every project needs a producer and a technical director. One or the other may be the boss, but it’s vital that they work together and divide labor efficiently.

pragmatic

18. The section on debugging could probably be a whole chapter itself. It covers a range of topics. First things first, understand the problem. Find a way to easily reproduce it. Talk things through, with a rubber duck if necessary. Eliminate possibilities.

19. It’s all text, so learn some serious text manipulation skills. awk, sed, perl, python, ruby. You can generate tests, code, documentation, anything and everything.

20. In fact, there’s a whole section devoted to code generators. Sometimes you just need a one shot generator, either to convert from one format to another, or to generate a template that will be further edited by hand. Other times, you keep your database schema in a text file and constantly generate new code to access it.

code

We start by taking a look at the new logic of George Boole. He invented an algebra that has addition and multiplication, but maybe it’s easier to call them union and intersection. The rules are also a little different from normal algebra, but they’re very helpful. We can prove Socrates was mortal. Or we can go to the pet store and find just the cat we want, one that matches all our criteria, which we express in Boolean logic.

Next we return to our study of circuits and light bulbs. With the proper arrangement of switches, we can make the light go on whenever we see just the right cat. Boole himself lived somewhat before the time of the light bulb, but telegraph relays were available to him, as well as Charles Babbage. But it took a while for the connection between logic and circuits to be made.

That would have to wait until 1938 and Claude Shannon, who incidentally invented the word bit as well. If we wire together some relays (remember the telegraph?) in the right way, we can make an AND gate. Or an OR gate. And combine them. Maybe make some NAND and NOR gates, too. If we return to the past, Augustus De Morgan came up with a set of laws that explain how we can translate one Boolean expression into another. Similarly, this will let us translate one circuit into another, which sounds like it will be very useful.

coda

Rubber duck debugging made two appearances this week. Actually, the general idea that one can peel things apart and understand them was a big theme. Don’t just stumble around assuming the black box must remain inscrutable.