By riedl on
I’m home sick with a nasty sinus infection today, so we take a break from our regularly schedule program to announce that scientists apparently now have an animal model for the common cold: a mouse strain bred specifically to feel terrible, in the name of sinus — er, science.
John
Powered by ScribeFire.
By riedl on
Interesting article about the HD-DVD format wars from the Economist. Basically the article argues that although Blu-Ray appears to have won, they may be fighting a battle that doesn’t matter for three reasons: (1) The upconverters on current regular def DVD players are getting so good that consumers won’t notice the difference; (2) Streaming may get from our curb to our TV player before we start buying HD DVDs; and (3) rewritable media — particularly USB keys — may become so big and so cheap that we start using them instead of DVDs.
My favorite part of the article is the last two paragraphs where the author speculates about how many pixels it will take to fill the complete pixel-consuming ability of the human eye. It’s interesting to imagine a time when what we see in a “movie” will be exactly the same resolution as what we see in the “real world”. How will that change entertainment? Work?
John
Powered by ScribeFire.
By riedl on
Intriguing blog about the new Git system. I haven’t tried it myself yet, but sounds like it’s basically a version-controlled file system that (a) does it right; and (b) is easy to build on top of. If it’s really as cool as this author says, I’m already thinking of several apps that I’d like to port:
Has anyone tried git? What do you think?
John
Powered by ScribeFire.
By riedl on
Here’s a fun article about creating a viral app, based on a teacher’s experience with a Stanford class that wrote Facebook applications last year. The article has some interesting ideas about distribution rates through viral marketing.
John
Powered by ScribeFire.
By riedl on
Joe Konstan pointed me to this interesting debate around an essay by Dewar and Schonberg about the teaching of computer science. Many of these essays are shallow: the authors have a particular style of programming that they think will solve all problems, and they advocate that all of us ought to spend more time teaching and learning their style. Dewar and Schonberg’s presentation is much deeper, perhaps because of their experience both teaching and practicing computer science.
The basic three arguments in their article are:
1) Computer scientists should learn about many different language
paradigms (described in detail in the essay), because that gives them a
deep understanding of the approaches that might best solve any
particular problem.
2) Computer scientists should learn more about formal models and how they can be used in software construction. In particular, computer scientists should learn more of the appropriate math.
3) Computer scientists should learn the discipline from the ground up. The early use of a very high-level language such as Python — or even Java — means that students develop a too high-level understanding of programming, without the details that are sometimes crucial.
I think the authors are absolutely correct on (1), and they do a good job of presenting their arguments. I’ll say no more on this issue, since their article does such a good job.
I think the issue of formal models is a trickier one. I certainly agree with their assertion that it would be valuable for all computer scientists to understand how formal models can be part of the solution for achieving very high reliability. On the other hand, most computer scientists will never work on such systems. How much of their time should be spent studying such systems? My bias would be to create a path for those students who find such work interesting, but to require only the basics for all students.
Finally, I think the authors are dead-wrong on the idea of teaching students to program from the hardware up. I understand the temptation: that’s how we learned, and we’re all awfully good at what we do, so it must be the best way to learn. But, this argument misses the most important skill for a computer scientist: effective abstraction. The current approach of beginning with high-level languages starts students on the path to understanding the really deep issues of our discipline, rather than spending this precious formative time on problems only a few of them will face in practice. The authors argue that high-level languages are much easier to outsource than lower-level thinking. They have it exactly backwards: the most challenging problems in our discipline today — and the most difficult to outsource — are mapping from user needs to concrete requirements that are implementable. A student who knows what a high-level language can do, along with the power of its attendant libraries, is much better prepared for this sort of work than a student who has spent years learning about machine architecture and machine language.
I agree with the authors that Java is the wrong language for the first course, but for nearly the opposite reason. Java is a difficult language to learn because it requires that so many details be understood before interesting program can be built. In particular, Java suffers with opaque syntax for simple things — like the basic list, and dictionary data structures — and the lack of a lambda expression to make higher-order programming accessible. Beginning students would be much better off with a language like Python, which gives them the tools to explore both modern imperative programming and functional programming.
John
Powered by ScribeFire.