So I wanted to buy a specific title for a friend (The Soul of a New Machine, in fact) who would be in town in just 2 days.  Not wanting to pay 2-day Amazon shipping, I went online to Borders and “reserved” the book at a local Borders outlet.

When I went to pickup the book, there was nobody at the customer service desk.  While waiting for someone to show up there, I went over to the Search terminal to see if they had a copy of the DVD Triumph of the Nerds.  Searching for ‘triumph of the nerds’ returned over 13,000 hits (even when narrowed to Movies & TV).  Searching for the whole phrase returned 0 hits.  When the customer service person finally arrived (I had to go to the cashier and ask to have someone sent there), and told me that the book I had reserved would be at the cashier station, I asked him to help me with the search.  He tried without success and asked me whether I was sure the item was still available for sale.  (It is.)  I then asked if he could direct me to the section where I might find other books on the history of computers and technology.  He needed an example title to answer the question, so I suggested Insanely Great.  He did some unsuccessful searches and asked me whether I was sure the item was still available for sale.  (It’s in its second printing.)

I went home and ordered all the items from Amazon.  I’ll have to wait a couple days to get them, but (a) the search function found every item as a top hit on the first search attempt, and (b) I am paying less, even without considering sales tax.

Borders is fcuked, and probably so are the other big box stores. From now on it’s my neighborhood independent bookstore when possible, and Amazon otherwise.

A colleague recently asked if I had any thoughts on what would be “a good first programming language” for a precocious 9-year-old who was very  much into computers and wanted to learn programming, giving me an excuse to agonize about this again.

The executive summary of my current opinion is probably “Scratch if you want training wheels, Python otherwise”, but if this sort of thing interests you, read on.

My colleague’s question gave me an excuse to wring my hands about it some more, and even talk to some other people about it seriously, including Colleen Lewis, a Berkeley computer scientist and educator whose opinion I respect tremendously on such matters, and a bunch of smart colleagues from industry who attended the recent RAD Lab retreat.

We concluded that there’s a handful of absolutely fundamental concepts that are (a) common to the vast majority of programming paradigms/languages and (b) not “natural” in the sense that they have no obvious analog in non-programming-based activities and simply have to be internalized:

• variables and assignment
• manipulating collections of elements (arrays exist even in languages that don’t support user-defined data structures)
• conditional evaluation
• control flow
• iteration
• subprograms (i.e., procedural abstraction)

(I’ve deliberately omitted OO; while really important, it’s not fundamental in that there’s lots of programs you can write without it.)

Beyond focusing on absorbing those concepts, a “good first language” should make the young programmer feel empowered at being able to do stuff, gradually stripping away the “mystique” of how computers do the cool things they do.

Hence my concerns about Scratch, a popular GUI-based programming environment designed for teaching that we are starting to use at Berkeley for the intro-level CS class.  Colleen reassured me that it’s possible to write non-toy programs in Scratch once you ditch the GUI, that it supports constructs like lambda expressions that let you teach important concepts like closures, and that students who complete the new intro course also understand things like objects and class inheritance and are more than ready to tackle any programming language.  My concern is that the Scratch GUI environment is so amazingly rich and polished that it might diminish the sense of empowerment—even if you write a cool program, there’s still just too much magic between your program and the machine.  The nice thing about Scratch is that it’s widely used in education so (I assume) there’s lots of freely-available supplementary materials to go with the software.  (Wearing my “productivity programming” hat, I’d say Scratch is almost too productive because so much is happening beyond the code you wrote.)

The alternative seems to be Python, probably the closest thing to BASIC these days (albeit a much better language, of course).  And in fact I found a pretty good book—Hello World: Computer Programming for Kids and Other Beginners—co-authored by a programmer and his young son and written in a kid-friendly yet noncondescending way.  The downside is that while Python is a pretty nice language, like all languages it has a few quirky notations, idiosyncrasies, arbitrary-seeming behaviors, etc. While the book goes out of its way to clarify these only as much as needed, their presence might detract from a learning experience…but then, to be fair, the same was true of BASIC way back when, and probably those of us who glamorize learning it have selective amnesia about getting bitten by those idiosyncrasies and learning to work around them.

So maybe my current recommendation is: for a gentle introduction with training wheels and rubber bumpers, Scratch; for something a little more hardcore that you won’t outgrow (Python is used for lots of real programs) but comes complete with real-life idiosyncracies, Python with the above book.

The good news is that while neither is “built in” to today’s PCs like BASIC used to be, they’re both open source free downloads.

Ideas from anyone who’s actually helped their kids learn to program?  (I have no kids, only a toucan, and it’s unlikely she’ll learn to program anytime soon.)

http://www.tuaw.com/2010/04/26/found-footage-twitter-on-an-apple-iie-kind-of/

…now if only it had an actual Ethernet card and was crawling the actual Twitter site!…

The old Star Trek episodes are wonderful morality tales. And hey, it’s not their fault that special effects in the late 60’s weren’t very advanced, and the effects budget per episode was apparently about $50.

I smile at the cheesy effects and appreciate the storyline, but I can’t help but enumerate a few effects things that particularly tickle me as a computer scientist.  I’m blogging these so that someone blogging in 2020 can smile at my comments, and all while giving the original Star Trek the largest possible credit for couching great stories in something that the 60’s thought the future would look like (remember, the final Star Trek episodes were taped a full 2 years before the moon landing):

1. The analog dials on the ship’s computers
2. Computers with AI-complete speech recognition, but synthesized voices that sound terrible
3. Computers that actually emit smoke when they fail
4. Audio communications that fail as analog radio would (analog static and high-Q artifacts, not digital dropouts)
5. Video that fails by getting snow or loss of analog sync (I still can’t believe people used to do all this with analog signals.  That is some studly engineering.)
6. “Video” displays that are clearly posters
7. Mechanical switches for controlling electronic devices, including the transporter and the “computer”
8. Mechanical printer noises (ie, dot matrix and band printers)
9. The presence of physical books rather than ebooksat various official proceedings
10. Ship’s avionics that fail by bursting into flame, yet are apparently repairable at the board or component level

Note that a great many of these effects were actually accurate when viewed from the standpoint of the first computers in spaceflight—see Computers In Spaceflight: The NASA Experience for a most excellent overview and retrospective.

• Peter Bodik’s paper on “Fingerprinting the Datacenter” (joint work with Moises Goldszmidt at Microsoft Research Silicon Valley and Dawn Woodard at Cornell) was accepted to EuroSys 2010, where I’ll also be giving a tutorial on Web 2.0 applications;
• Wei Xu presented an online version of his work on data mining of console logs (joint with Ling Huang at Intel Research Berkeley) at ICDM 2009 last month;
• Dr. Archana Ganapathi filed her PhD dissertation (yay!!) and just had a paper accepted to the Self-Managing Database Systems workshop (SMDB 2010) on statistics-driven workload modeling for cloud jobs like Hadoop (joint work with Yanpei Chen)
• The RAD Lab will be featured in the VMware GoVirtual webzine later this month, stay tuned!

…and of course we are planning submissions to SOCC and WebApps as well.  See the students’ pages or my project pages for more details!

These were quickly dashed. The Amazon VoD UI embedded in TiVo is unresponsive, clumsy, cumbersome and unpleasant—everything the TiVo UI itself is not. When one chooses “Video on Demand” from the TiVo menu, one arrives at a menu screen featuring something like 8 different VoD vendors whose delivery medium is TiVo. Never mind the fact that as a movie watcher, I could give a flying fork whether “Jaman Movies and Shorts” or “Disney Video” or “Blockbuster” or “Amazon Video on Demand” supplies the title I want to watch; as a customer, I’m focused on content, not content vendors.

Yet amazingly, not only is the TiVo UI organized by something as meaningless as vendor, but each of the vendor submenus takes you to a different, yet uniformly awful, user interface. Here are some misfeatures common to all of them:

• Each button press on the TiVo remote has a UI response time between 700 and 1500ms. Yes, that’s right, it can take more than a second to get any visual or auditory feedback that your button-press actually did anything. This is far above the established thresholds for perceptual causality (~100ms). In contrast, when using the “native” TiVo UI, it feels snappy and responsive.
• Each VoD source has a different menu-driven UI for search, “top titles”, browse by genre, etc. The user has a simple goal: “I want to find (or browse) movies.” Yet each submenu has a different structure, for no defensible reason. As a user, what do I care which of the vendors is providing the content?
• The GUI is not only entirely textual, it is designed in such a way that less than 50% of the already-scarce screen real estate is actually devoted to browsing. The rest is devoted to TiVo templated elements and blather from the VoD vendor about how thrilled I should be that I had the wisdom to select them.

The UI is, in short, astonishingly bad.  It is all the more frustrating because this truly awful UI, which makes me want to hurl the remote at the screen, emanates from the same device that gave us the effortlessly superior TiVo UI.

What happened?

Bottom line: when it comes to video on demand, TiVo has provided an unresponsive, inconsistent, confusing and non-thought-out GUI in which various competing vendors of VoD media fight for your eyeballs with unattractive, unintuitive, arbitrarily-different GUIs that violate every basic GUI tenet, including those to which the original TiVo GUI hews so faithfully and well.  In contrast, AppleTV, for all its bashing, has a nicely-thought-out, consistent, aesthetically appealing GUI that does the one thing you want to do: find the damn movie easily, and start watching it as soon as possible. The search interface is fast and responsive; the user experience is,well, Apple; and you can usually start watching movies within 1-2 minutes of clicking “Buy”. (The last time I used Amazon VoD on TiVo to watch a 30-minute TV sitcom episode, I had to wait 20 minutes before I could start watching, even though my TiVo enjoys access to exactly the same broadband network as my AppleTV. How is 20 minutes “video on demand”? I could have made a trip to the local video store and been back in less time than that.)

Shame on you, TiVo.  DVR hardware is commodity; what had set you apart was your UI. As you continue to add vendors to your hideous VoD user experience, you will start running out of feet in which to shoot yourselves.

But hey, with disk space being free now, if I was graduating now I would also “file” a copy of the VM images used to format my thesis and run the experiments. Some of my students are doing cloud computing research so some of their VM’s are already being stored as Amazon AMI’s, but why not snapshot a VM image of their laptop as well? We’d be one step closer to truly reproducible results in CS research.