On Scheme, Python, and 6.001

Tags: , , , , , — Jeff @ 09:10

From a day at a Lisp conference (emphasis in original):

Costanza asked Sussman why MIT had switched away from Scheme for their introductory programming course, 6.001. This was a gem. He said that the reason that happened was because engineering in 1980 was not what it was in the mid-90s or in 2000. In 1980, good programmers spent a lot of time thinking, and then produced spare code that they thought should work. Code ran close to the metal, even Scheme — it was understandable all the way down. Like a resistor, where you could read the bands and know the power rating and the tolerance and the resistance and V=IR and that’s all there was to know. 6.001 had been conceived to teach engineers how to take small parts that they understood entirely and use simple techniques to compose them into larger things that do what you want.

But programming now isn’t so much like that, said Sussman. Nowadays you muck around with incomprehensible or nonexistent man pages for software you don’t know who wrote. You have to do basic science on your libraries to see how they work, trying out different inputs and seeing how the code reacts. This is a fundamentally different job, and it needed a different course.

Really? I can’t ever ever ever remember a time when Mozilla code hit a bug in Uniscribe, or Pango, or Cairo, or the Microsoft CRT (but only under some versions), or Core Text (but only under older, almost-unsupported versions) and had to determine exactly what caused the bug so it could be fixed or avoided (this latter in the case of non-free and open source libraries). Every time we’ve interacted with external libraries it’s been fairies and ponies all the way down.

A feral pony in Mount Rogers National Recreation Area in southern Virginia

Oh yeah. Except those ponies are feral and will quickly eat sugary things out of your hand with their sharp, pointy teeth if you put them right in front of their mouths, or they’ll nibble on salty backpack belts if you leave them at ground level and unattended. And those fairies? They’re really just cardboard cutouts.

Continuing on:

And why Python, then? Well, said Sussman, it probably just had a library already implemented for the robotics interface, that was all.

How droll. I suspect it was more than that (more human-readable syntax and structure, almost pseudocode, without lots of insidious silly parentheses, for the obvious starter), but having a library ready is a substantial boost up.

Sussman has a point that we don’t construct programs from the simplest parts to the complex whole. My first substantial code patch for Mozilla was perhaps large, but much of it was bits-and-bytes hacking with an occasional foray into almost-trivial data structures with no non-trivial behavior. Much of the patch could be written in isolation of knowledge of the surrounding code, except to the minimal extent needed to modify the right XPCOM objects to get the desired behavior. In contrast my work on httpd.js often requires interaction and knowledge of foreign components, even beyond their meager-to-nonexistent documentation. A case in point: I needed a simple way to copy data from one stream to another, so I used an nsIAsyncStreamCopier to do it. I later returned to this code to implement keep-alive support to discover that our only such copier in Mozilla closes the target stream when the copy completes, not that you could tell that from its documentation; that interface will probably change in the Firefox after 3.5 to make it possible to change this behavior. Sometimes you work at the low levels, but there’s so much less to do there; we engineers fit puzzle pieces together more often than we make them.

I was fortunate (more fortunate than I thought at the time) to take 6.001 before its demise and replacement with 6.01, the Python-based class. Scheme was a new and foreign concept to me, and it forced certain methods of thought and attack to be used to their fullest. Consider (of course) recursion:

(define (factorial n)
  (if (or (= n 0) (= n 1))
    (* n (factorial (- n 1)))

The recursion and its concept are precisely clear. The function returns a value. In the base case that value is 1. In the recursive case that value is n times the factorial of one less than n. Can recursion be made any sparer or more precise? An imperative language requires some understanding of an entire method to grasp its recursion (if only to examine every return throughout it); in an expression-based language entire trees of expressions and method calls may be ignored completely.

All that said I still prefer Python to Scheme, not least because forcing the expression of iteration as recursion is an excellent way to obscure complexity costs. That said, 6.001 and CS152 were two of the best classes I ever took for forcing me to think differently, making me a more flexible programmer.



Nanny state watch: Scottish edition

I generally take a dim view of laws and regulations intended to protect people from themselves. I believe that responsibility for a person’s health and well-being ultimately resides with that person; a person who engages in risky or dangerous behavior must accept the consequences of his actions. Society should not take that responsibility and allow the misdoer to derive advantage without concomitant disadvantage. That way lies moral hazard, a phenomenon with which all discerning members of society should be familiar (and of which they should be justifiably wary) through the economic news and events of the last year or so.

In that vein I direct your attention to the latest attempt to extend the nanny state: a Scottish tax on chocolate in a proposal defeated by only two votes in a meeting of the British Medical Association. Dr. David Walker, its chief proponent, says:

“Chocolate has lost its status as a special treat and I think that if we charged a tax on it then, over a number of years, we could restore that status.”

He had earlier told the BBC news website that obesity was a “mushrooming” problem, and Scotland risked heading the same way as the United States.

He added: “There is an explosion of obesity and the related medical conditions, like type 2 diabetes. I see chocolate as a major player in this, and I think a tax on products containing chocolate could make a real difference.”

There is much that is wrong with this from economic and personal freedom standpoints. However, in the interests of concision and minimal scope, I will limit myself to taking issue with these later lines in the story, also from Dr. Walker:

“After eating a bag of chocolate sweets you would have to walk continuously for three hours to burn off the calories consumed.

“It is simply not enough to say people should get more exercise.

The regular reader will know that last year I completed a thru-hike of the Appalachian Trail. Backpacking requires a tremendous amount of energy (moreso for a trip of that length and duration), and I fueled myself using a variety of methods: gorp, granola bars, beef jerky, and candy, among others. For roughly the last 1300 miles of my hike, my primary fuel between meals was the large or king-size candy bar — usually Snickers for its high calorie-to-weight ratio but often Milky Way or 3 Musketeers for an attempt at variety. A large Snickers bar contains 280 calories, while a king-size bar contains 510 calories; Milky Way clocks in at 260 and 460 calories respectively.

Each day while thru-hiking I typically would eat the equivalent of five, six, or more large-size bars (ten is the maximum count I can remember, although I probably exceeded this when completing the Four State Challenge) while hiking twenty to thirty miles daily. (NB: my chocolate bar rate of intake effectively dropped to zero when I finished the hike.) Dr. Walker would likely agree that this rate of intake in this exceedingly unusual situation is much less likely to be harmful than it would be for an average person and situation, but if he did not, I could assure him with absolute certainty that while I was hiking this prodigious consumption of chocolate was in no way calorically harmful. Further, in the four months since I completed the thru-hike I have noticed no other lasting ill effects. Indeed, it was necessary to travel those distances without courting malnourishment and unhealthy weight loss; I have heard of thru-hikers who could not carry enough food to avoid losing weight in the final stages of their thru-hikes (at which point all discretionary weight would have long since disappeared). Would Dr. Walker punish me for what it was necessary for me to consume while hiking? A chocolate tax across the few hundred bars I likely consumed would have summed to a meaningful value — perhaps a couple handfuls more candy bars or a small meal in a town I passed through.

Dr. Walker may be right that for most people more exercise cannot adequately combat excessive chocolate intake. However, that his assertion is only usually right means that sometimes it is wrong; it is a clear example of the folly of not recognizing personal responsibility to avoid harmful choices. If this tax were real, the people who consume chocolate in moderation with respect to their situations (I include myself in this group) would only be harmed, while the ones who consume to excess, perversely, have an incentive to consume even more as they can take advantage of the newly-funded programs “used by the NHS to deal with the health problems caused by obesity” without paying the full costs to use them.

If Dr. Walker wishes to see more healthy intakes of chocolate, he would do better from a personal freedom standpoint to improve educational efforts that warn of the dangers of excessive sweets, which would neither inhibit individual responsibility nor tax the responsible chocolate lovers to pay for care for the gluttonous ones.


When good tests go bad: Firefox on Acid(2)

Tags: , , , , , , , — Jeff @ 00:43

This is what the Acid2 test looks like in the very very super-duper-latest Firefox builds (slated for the version after 3.1, mind, not for 3.1):

Acid2 in bleeding-edge Mozilla, to be seen in the next Firefox release after 3.1; the chin is red whereas the reference image would have it yellow
Acid2 in bleeding-edge Mozilla, to be seen in the next Firefox release after 3.1

Bug, you say? No! The last test in row 13 tests that this CSS doesn’t apply:

.parser { background: red pink; }

Two colors for a background as valid CSS? Surely you jest!

Actually, we don’t. CSS3 says background-color takes two colors, one for normal use and one for use if a corresponding background-image doesn’t load. The red ends up getting used as the background color, and the yellow that would have been present if the property hadn’t applied no longer shows. CSS3 makes previously-invalid CSS valid, and that’s okay, because CSS error handling is explicitly designed to allow it.

So no, “failing” Acid2 for now isn’t fail, it’s WIN. Hopefully the test will be updated soon so that that particular rule is invalid again.

Incidentally, the specification for this changed recently, which I presume is why WebKit/Safari/Chrome et al. don’t fail. I don’t know whether they implement the fallback color process or not, presumably not given how they handle this testcase, which should show a green square if CSS3 background colors are implemented to latest spec, but in any case they won’t trigger it even tho they’ve implemented a bunch of other parts of the CSS3 backgrounds spec.

Update: As Dan notes in comments, the once-invalid syntax is now invalid again, as fallback color support has been removed from CSS3 partially over syntax concerns and partially over its lack of generalizability to other cases in CSS. Now that support for fallback colors has been removed from trunk, Acid2 in bleeding-edge Firefox now displays as it was intended to display.

« NewerOlder »