« July 2007 | Main | September 2007 »

August 31, 2007

"Knowing" a Language

While obsessively trolling the Web for mentions of Find the Bug, I came upon this post from a fan of python, which is one of the 5 languages I used in the book.

He discusses one of the Python problems from the book where the code splits a buffer into words and then sorts the result, but does it in a low-level way: by walking through the buffer one character at a time to split the words and walking through the array one element at a time to find where to insert the word in its sorted spot. He is slightly annoyed that I don't simply call the split() function to split the buffer, and the sort() function to sort the array--although he does point out that it wouldn't make sense for me to do it this way since there is so little potential for bugs in the 3 lines of code (I have sometimes seen people discussing Microsoft interview questions on bulletin boards claiming that if somebody asked them to sort an array in C, they would call the qsort() library function, and if the person asked them to write it out themselves, they would refuse because that wasn't what a real programmer would do. Although I never actually had an interview candidate who refused, on those grounds, to write out the implementation of strlen() or itoa() or various other standard library functions we ask them to write).

I find this interesting because it involves a trend I have noticed: more and more, it seems that "knowing" a language involves the set of functions that are built-in, as opposed to knowing the syntax and semantics of the language. Meaning: for me, "knowing" Python means you understand how slices work, the difference between a list and a tuple, the syntax for defining a dictionary, that indenting thing you do for blocks, and all that. It's not about knowing that there is a sort() function. I suppose the basic thing is that if you know the syntax stuff you can read code in the language and understand it; if you see a function you don't recognize, you can look it up in the documentation. Whereas if you don't know the syntax, you'll just be lost.

Of course as you write more code in Python you will start to learn more of the built-in functions, and this would be expected of someone calling themselves an experienced Python programmer; even in the space of Find the Bug, as you work through the Python chapter I eventually mention index(), ord(), find(), count(), pop(), and a few others. But I wouldn't call that a part of knowing the language.

Jonathan Ellis, the poster I linked to, says I am writing Python that looks like C, and then says "Actually it's painful to read any language written at such a low level of expressivity, which is why I prefer not to use languages that really can't do any better". Of course, a language like C could do better; if you write managed C++, which is "like" C, you can call all the built-in functions provided by the .NET Base Class Library. But again, I wouldn't call knowing all that part of knowing C++; it's extra information you pick up over time (I actually do think Python is more expressive than C#, but it's because of things like slices and dictionaries, not because it has split() and sort()).

Nonetheless people do seem to associate knowing a language with knowing its standard calls. Even C, I suppose, has a couple of functions in the standard library that are basically part of "knowing" the language (printf(), in particular, and malloc() and free()). That's just because C is so stripped down that it includes none of this as built-ins (and of course you can write C programs that don't allocate memory with malloc() and don't print with printf()). I think perhaps what this really shows is that languages are becoming more similar in what they basically can do, so their built-in libraries become more of a differentiator. There's a basic jump up from a language like C to a modern language like Python that has foreach-type loops and automatic array handling, but once you make that leap it's mostly frosting.

Posted by AdamBa at 10:43 PM | Comments (14) | TrackBack

August 25, 2007

Houses of Dreams

We like to go to the Seattle Street of Dreams, which runs in the summer (this year's version ended a week ago). The homes are somewhat over the top (piano in the kitchen, six-car garage), and one of the ways they demonstrate this is in the amount of home automation they contain. Almost every house has a panel in every room that lets you control the music, lights, view the front door, be an intercom, etc.

Meanwhile, Microsoft has a location in Building 33 called the "Home of the Future", where it shows off the latest technology for home use. The HOTF is remodeled every couple of years; the current version includes RFID tags and speech recognition among its bag of doo-dads.

The Home of the Future is designed to show off Microsoft's vision of a home 5-10 years out. But, since Microsoft has been creating incarnations since back in the mid-1990s, we can now start to see how accurate the predictions were. The technology in the Home of the Future back then should roughly match up with the technology in a Street of Dreams house today.

The first Home of the Future, as far as I know, was the one described in the "yurt" article in Wired from July 1995. A quick excerpt: "Every room has a screen, from the multimedia PC in the kids nook, to the financial news tube in the office, to the recipe tablet for 'cooking apps' in the kitchen, to the projection screen in the den." I worked on the interactive television project described in the article, and visited that Home a few times. It did, in fact, have computer screens scattered around; some of them were mounted in the wall to look like pictures (since this predated consumer flat-panel screens, they were actually regular monitors supported by extra framing behind the walls).

The Home back then accurately predicted that there would be more technology than was common in 1995; houses would have multiple computers, people would use computers for more things, a larger percentage of friends and family would communicate with you over a computer. But I think it misjudged how much the technology itself would change. The cooking apps thing is as bogus as ever; the video email application that was part of the demo has not come true; we certainly have not achieved the vision of "the extended family mediated though technology", whatever that ever meant.

I suspect today's Home of the Future is also a bit off. I know Bill Gates has had a rocket in his pocket about speech recognition for years, but I still don't see it catching on for home automation. The notion of all the computers in a house linking together to provide an immersive experience that is greater than the sum of their parts seems impossible to properly specify beyond a canned situation like the Home. My older children recently had the opportunity to visit the Home and they did like the house-enhanced reading of "Goodnight Moon" that ends the tour, but again it seems hard to make this generic enough to move beyond demo phase.

Touring the Home is fun, and touring Street of Dreams is fun, but I don't think one is a preview of the other.

Posted by AdamBa at 10:25 PM | Comments (3) | TrackBack

August 24, 2007

Interesting Possible Moment for Blogging

Perez Hilton, the celebrity gossip blogger, is reporting that Fidel Castro is dead. But the mainstream media is saying nothing. Could be another breakthrough for the Internet, a la when Drudge Report broke the Lewinsky scandal. Or maybe not, if it turns out to be hooey.

Posted by AdamBa at 05:20 PM | Comments (0) | TrackBack

August 16, 2007

What If Bill Gates's Signature Was On Our Software?

You can file this one under "crazy", but I thought of something today. If you look at any Mercedes-Benz, you may notice that in the corner of the front windshield is the signature of Gottlieb Daimler, founder of an antecedent to today's company. The signature is just a sticker that you can buy for $3.50, but you must suspect that as the masses in Stuttgart toil away building the cars, they are at least somewhat inspired towards quality because the car will bear Daimler's signature.

So I had this geniotic idea that Microsoft should put Bill Gates's signature on all of our software. Just a small tasteful version on the back of the product box (Bill is of course on his way out at Microsoft, but it's certainly his company; for that matter, Daimler's been dead for over 100 years and nobody seems to worry about that). Would this inspire us all to produce better software, so as not to disgrace the name of Bill? I sure don't think it would hurt. AND how long before Steve Jobs tried the same thing?

Posted by AdamBa at 08:37 PM | Comments (5) | TrackBack

August 15, 2007

The Era of Operations

In the book Proudly Serving My Corporate Masters, I talk about how Microsoft has been through three periods in its existence: the era of the developer, the era of the PM, and the era of the tester. In each era the respective job discipline (dev, PM, or test) had the most "important" job and the most say in what we shipped.

It's really more like two and a half eras, because the era of the tester never quite caught on. We did start focusing on things like quality and reliability, but while test has come a long way, it is still working to reach the stature of dev and PM. You do hear of people moving from dev to test, which was unheard of ten years ago, but it is still unusual (to be clear: I blame dev, not test, for not granting test the respect it deserves). Another thing is that the responsibility for "quality" is now viewed as shared between dev and test (and some other jobs also).

Now, I think a new era is approaching as Microsoft moves to provide more services: the era of operations. That is, what will differentiate companies is operational execution, and operations will become the job that has the most say in the products we create. As it happens, Microsoft classifies dev, test, and PM as "disciplines" in the engineering "profession", while operations is a separate profession. So arguably I am talking about a shift from the era of the engineering profession (dev/test/PM) to the era of the operations profession.

I think this shift is also somewhat theoretical, because I don't think engineering is ready to give up any ownership. Unfortunately, each successive era beyond the dev one has been noted by dev treating the namesake of the new era with scorn. In the era of the PM dev would write code, then tell PM to spec it; in the era of the tester, dev would write code then tell test to test it. Now that test has been mostly pulled up, I get a feeling that some teams are throwing the released product over the wall to operations and telling them to deal with deploying it. Hopefully we can nip this sentiment in the bud; although it might prove my point, since the upturned nose of a developer points to the key player on the team as surely as the end of the Big Dipper points to the North Star, as an employee and shareholder I hope we can move to the era of operations without stumbling as much as we did the last two times.

Posted by AdamBa at 09:06 PM | Comments (1) | TrackBack

August 11, 2007

The Pythagoreon Formula (of Baseball)

Bill James once invented a theory that a baseball team's expected record is proportional to the ratio of the square of runs scored to the square of runs allowed. It's called the Pythagorean Theorem because the real Pythagorean Theorem has something to do with squares and addition and all that, so why not?

The Mariners, who are at this moment one percentage point ahead in the AL wild card race, are having a particularly surprising year based on this theory. They have scored 560 runs and allowed 549, which creates the expectation that they will basically be playing .500 ball (actually .510 as of today, they are expected to be 58-55 instead of 63-50). ESPN has a Relative Power Index page which shows, among other things, the Pythagorean expectations (listed in the last two columns as "ExpW-L" and "ExpWP").

The Mariners are 5 games over their ExpW-L, but they aren't the "best" at that. The Diamondbacks are 66-51, with the best record in the National League, despite having been outscored 516 to 495 by their opponents. Their ExpW-L is 56-61, so they are 10 games over.

The team that is furthest UNDER their ExpW-L is the Yankees. They have scored 684 runs and allowed only 532, so by rights they should be in first place with a 72-43 record, one game ahead of the Red Sox. The Mets, by comparison, who happen to have the exact same record as the Yankees right now, are only up 535-489 in runs, for an expected 63-52 record (nine games behind the Yankees expectation). And Seattle, which has essentially the same record, is even worse.

James claims that teams tend to revert to their expected Pythagorean record over time, although not necessarily in the span of a single season. It does seem reasonable to feel that the Mariners have gotten "luckier" this season than the Yankees, but like many of these kinds of calculations that James has come up with over the years, there's no real logic behind it, except some hand-waving and the fact that it seems to play out historically (before I continue, I'll point out that I think Bill James is great, and the statistical approach he has taken to analyzing baseball is light-years ahead of the gut-feel approach of old). For example, you could argue that won-lost records should be proportional to runs scored vs. runs allowed (as opposed to the squares) or to the cubes of those. These would all work if you consider the league as a whole, where runs scored equals runs allowed and the record is .500. Or you could say that it is proportional to batting average vs. batting average allowed, or batting average vs. league average compared to ERA vs. league ERA, and maybe you could square those for good measure, or take the square root, or who knows. I know that James has stated that the goal of a baseball team's offense should be to score runs, and the goal of defense is to prevent runs, so I see why he focused on a run-based calculation when he posited the Pythagorean Theoreom. But the focus on runs is debatable; arguably the goal of a team should be to win games, not score runs (most people would agree that Arizona, whose actual record is one game ahead of the Yankees, has had a slightly better year than the Yankees so far, despite the fact that the Yankees are 173 ahead in run differential and 17 games ahead in ExpW-L). Or maybe the goal is to win championships, or generate high attendance. The Pythagorean theory is fun and interesting, you can impress baseball fans by spouting it, and if the Yankees wind up stomping the Mariners in the standings it will have proven itself again, but as a theory it has some clunky underpinnings.

Posted by AdamBa at 12:39 PM | Comments (0) | TrackBack

August 10, 2007

More on Liskov

Last month I wrote about the Liskov Substitution Principle and how I thought it was bogus that it implied a square was not a rectangle. I had several followup comments about that where people started about by saying "Well, of course" but then when I asked for specifics they all stopped frustratingly short of explaining why.

A mathematician named Charles Wells, who wrote a couple of books with my father, wrote a blog post where he used my post as a launching post to discuss special cases in mathematics. He pointed out that if you Google "square rectangle Liskov", then you will find lots of discussion about this.

Well, I did. The first thing it finds is evidently the canonical Liskov-based square-is-not-rectangle (PDF) by Robert Martin. He makes the exact argument that I talked about before, that calling SetWidth() and then SetHeight() on a square won't behave as expected. James Waletzky, who was the person from whom I originally heard the argument, is a Robert Martin fan, so no surprise there. You also find a bunch of people repeating Martin's argument. There was a different one I found a few days ago related to a method that returned the area of the rectangle, which I can't find now, but it's basically the same thing.

I still don't like these. Because remember A SQUARE IS A RECTANGLE. I mean really, it is. Although you may win points from your object-oriented friends for "proving" something so non-intuitive, I fail to see how it makes programming easier if you violate someone's real-world model in such a basic way.

Right, but what about SetHeight()? Well, what I think now is that applying Liskov to this particular class design shows that designing a Rectangle class with Set() methods is bad design. A rectangle is simple enough that you can simply define it with constructors that take height and width, methods to get the height and width, and that's it. 99% of time that's how you want to use such a class, as a way to pass around information about a rectangle, and if you need to change the dimensions, just construct a new rectangle.

Then with your Square subclass you are free to add a constructor which takes only a single parameter, and override the base rectangle constructor so it fails if the height and width are not equal. This is fine since the code that is constructing the class knows the exact type it is and should therefore be expected to handle the case where they construct a Square by calling the two-parameter constructor from Rectangle and pass in a height and width that aren't equal.

So while Liskov has demonstrated why the Rectangle with Set() methods is bad design, a Square can still be a Rectangle.

Posted by AdamBa at 07:14 AM | Comments (4) | TrackBack

August 05, 2007

Touring Microsoft

Some friends were visiting us from out of town and the husband asked if I would give him a tour of Microsoft. He's not a geek by any stretch of the imagination, but he still wanted to see Microsoft. I'm always somewhat amused/puzzled/charmed by such requests, but off we went to check out the campus (this was yesterday evening).

Of course Microsoft's campus is now huge, so we mostly just drove around and marveled at the number of buildings. For example we were driving past the soccer fields and I pointed out that everything you could see (40/41, 19, 16/17/18, 25, 33, 8) was all Microsoft. And even that construction crane in the distance was Microsoft.

Then we got out and I showed him the original buildings 1-4, including my old office in 2. Also Lake Bill, former home of the rooster, and the cafeteria in Building 4 (site of another former office before they redid it to make it much bigger). Then we walked over to 5 so I could show him the patterns&practices Workplace Advantage remodel. Building 2 was redone at some point and the wood is much darker but Building 5 (the old parts) has the authentic late-1980s look. Then we took a quick glance at Building 37 (nee Building 7). After that we drove to Building 21 (with a quick wave towards 34 on the way) to check out the remodel of our space, which is now complete enough that it's no longer a hard-hat area and you can wander around if you want. They have the raised floor in and the channels for the glass walls, so you can get a good feel for the space. They are now scheduled to be done on September 28. Finally I showed the wreckage of Building 100, soon to house the second-largest underground parking garage in the Western hemisphere, and the house perched on top of the parking garage by RedWest, and the tour was done.

We experienced a somewhat strange coincidence. As we were driving up to Building 2 (approaching the underground parking ramp, if you know where that is), I was describing how at that very spot, about 15 years ago, somebody had backed up the ramp into my car and crumpled the hood. Well wouldn't you know it, as those words left my lips, somebody backed out of a parking spot and crunched the side of our minivan (fairly minor since he was moving about 5 miles an hour). So in my life I've had exactly two accidents that require body work and they both happen in the exact same spot on Microsoft campus (and in a place I probably hadn't been back to in 10 years)?

Another tidbit is that besides the intern who was driving that car, in half an hour of wandering through buildings I saw exactly one other person in their office at 8 pm on a Saturday.

Posted by AdamBa at 05:48 PM | Comments (0) | TrackBack