Goal!

How do we improve the breed of collaborative programming tools? Should we have spectator programming competitions on the Internet? (The people who like those things only watch for the crashes!)

I don’t think there’s a good commercial driver for improving programmer productivity(*), but spectator sports and particularly racing has been a good driver in other fields.

  • I think there’s a lot of relevance for the game-theory outcomes of nice-sized sprint programming problems such as whether, say, Tit-for-tat or Pavlov is a better algorithm for Free-Rider scenarios, or whether that changes for a mix of Free-Rider and Volunteer’s-Dilemma.
  • I think most programmers and programming managers still have never really seen very dynamic languages and live debugging environments, and such competition would be a great way to show them off.
  • I think it would put nice stress on the collaborative environment. How many people can watch? Can they see everything such as keystrokes and mouse movement? Is that important? Can they easily see who is doing what? Can they see multiple players’ activity at once? Multiple teams? Can they record and have instant replay?

What would it take to pull this off?


(*) Me on IT management, Tech failures, and the General Theory.

Scaling to the Enterprise (Part 3 of 4)

3. HOW WILL APPLICATIONS BE DEVELOPED?
(See part 1.)

It is not practical to expect users to develop applications in Squeak. There is too much to learn. But neither is it practical to expect users to develop applications in Java or ANY OTHER COMPUTER LANGUAGE. There is no way that any community of professional developers could possibly keep up with the demand that we hope for unique applications. No matter what language they used, nor even how many developers were available. There’s simply many more users — and user needs — than there are developers. As with scalability of load, we need another approach. The answer is the same: push the load to the edge of the network.

Continue reading