31 October 2007

links for 2007-10-31


  • Hello, India? I Need Help With My Math, by Steve Lohr, today's New York Times. The article's really about how consumer services, like business services before them, are being offshored; tutoring is just an example.

  • Pollock or Not? Can Fractals Spot a Fake Masterpiece?, from Scientific American. The verdict seems to be mixed. Pollock's paintings often contain certain fractal patterns, and certain simple images look "the same" as a Pollock painting in a certain sense. The researchers argue that their work is still valid, though:
    "There's an image out there of fractal analysis where you send the image through a computer and if a red light comes on it means it isn't a Pollock and if a green light comes on it is. We have never supported or encouraged such a mindless view."

    I'd agree with them, so long as it's more likely for the metaphorical "green light" to turn on when it sees a Pollock than when it sees a non-Pollock; there's no single way to test whether a creative work is by a particular person, other than going back in time and watching them create it.

  • On the cruelty of really teaching computing science, by the late Edsger Dijkstra. (I've had this one in the queue of "things I want to talk about" for a while, but I don't remember what I wanted to say, so here it is. There are a bunch of similar things which should dribble out in the near future.) But I can't resist commenting on this:
    My next linguistical suggestion is more rigorous. It is to fight the "if-this-guy-wants-to-talk-to-that-guy" syndrome: never refer to parts of programs or pieces of equipment in an anthropomorphic terminology, nor allow your students to do so. This linguistical improvement is much harder to implement than you might think, and your department might consider the introduction of fines for violations, say a quarter for undergraduates, two quarters for graduate students, and five dollars for faculty members: by the end of the first semester of the new regime, you will have collected enough money for two scholarships.

    I've long felt the same way about mathematical objects. There are exceptions, but for me these are mostly exceptions in which the mathematics describes some algorithm that has input which is actually coming from somewhere. Here it's not so much the program that is getting anthropomorphized as the user.

    And why are they always "guys"? How is it that scribbles of chalk on a blackboard, or pixels on a screen, can have gender? Note that I am not suggesting that mathematical objects should be female, or that some of them should be male and some of them should be female, with the choice being made, say, by the flipping of a coin. (Incidentally, the description of mathematical objects as "guys" seems to be much more common at my current institution than at my previous one.)

    By the way, Dijkstra is saying here that he thinks computer science should be taught in a formal manner -- proving the correctness of programs alongside actually writing them -- and that to de-emphasize the pragmatic aspect, students shouldn't execute their programs on a computer, since doing so enables them to not think about what the program is doing. I'm not sure if I agree with this.

3 comments:

Anonymous said...

"And why are they always "guys"? How is it that scribbles of chalk on a blackboard, or pixels on a screen, can have gender?

Guys? Maybe its a generational but usually 'things' for my generation are referred to as female.
Susan Faludi would point out that was a result/caused by sexism; and I'd probably agree.

The only inanimate I feel any 'closeness' to is my M3, a camera.

I say again if you haven't read Pynchon you should, but I doubt you have not read him.

Anonymous said...

As a professional systems administrator and programmer, I strongly disagree with a lot of what Dijkstra says here and his most radical criticisms. Algorithms should be proven, but the notion that all programs should be proven is fantasy. The example he gives of salvation through a mathematical approach to problems was a purely mathematical puzzle. This ignores all the non-mathematical engineering, artistry and trade aspects of the programming profession. I think Terry Winograd gives a perfectly apposite retort here, (within a PDF containing other stuff):

http://cs.gmu.edu/cne/pjd/GP/TeachingCS1989.pdf

Anonymous said...

As a professional systems administrator and programmer, I strongly disagree with a lot of what Dijkstra says here and his most radical criticisms. Algorithms should be proven, but the notion that all programs should be proven is fantasy. The example he gives of salvation through a mathematical approach to problems was a purely mathematical puzzle. This ignores all the non-mathematical engineering, artistry and trade aspects of the programming profession. I think Terry Winograd gives a perfectly apposite retort here, (within a PDF containing other stuff):

http://cs.gmu.edu/cne/pjd/GP/TeachingCS1989.pdf