Top 10 Things I’ve Learned About Computers From The Movies and Any Episode of “24”

  1. Megapixels aren’t important: What determines the resolution of a photograph or audio recording is the “enhancement” algorithm run on it. Any image, when run through the proper enhancement, will reveal sufficient detail to recognize a face, read a license plate, etc.
  2. Computer screens output text at 4800 baud and make chirping sounds while doing so: Sometimes, computers can be revved up to 9600 baud, and sometimes, for instance when printing the names of conspirators, slow to 300 baud. There is a great deal of variety in the sound computers make when outputting text, though. It used to be a sound reminiscent of a lineprinter, but modern computers seem to implement a more “boop boop boop” approach. Oh, and most computers output in a 16 x 9 font.
  3. All computer systems have backdoors: Hackers can get into any system by way of “backdoors” that are left by the people who originally designed the system. The password of the backdoor is generally the name of the programmer’s daughter.
  4. There are wireframe schematics of every building on Earth: These schematics interface with a wide variety of sensor and alarm systems. They can be manipulated in realtime and are infinitely zoomable (see #1 above).
  5. Decryption works one character at a time, while the other characters cycle quickly through all possibilities: Face detection algorithms work the same way, as do most search algorithms. Oh, and every time a detail is revealed, the computer makes a beep. You know, really, most times a computer makes a partial computation, it makes a beep.
  6. It takes 10 minutes to break into a system: A computer expert will first play coy, saying that they don’t know how long it will take. Then, in a few minutes, they’ll reveal that they can get in, but they’ll need a few minutes more (damn it).
  7. The US government surveils the entire planet, in realtime, and keeps the tapes: At first, this seemed implausible to me, but then I realized that they probably have a couple dozen Webcams in orbit amd use enhancement.
  8. People generally keep incriminating evidence in folders organized by codename: However, they often encrypt them (see #5). Oh, and computers erase data at 300 baud, in reverse (see #2).
  9. Powerful people have Webcams that record from the middle of their displays: You and I dart our eyes back and forth between the Webcam and our own screen. Powerful people have intense video conversations while staring straight into the camera and, therefore, the Webcams must be recording from the middle of their screen.
  10. Powerful people have access to very powerful PDAs: The mobile computers used by powerful people not only support full video, they have acces to the realtime wireframe schematics, decryption and enhancement algorithms, and so forth. Oh, and they can read any data in any device. Oh, and as phones? They have awesome coverage.

Lost my PDA, Going Paper-Based…

I’m not a forgetful person, but in the four days before Tina’s first surgery, I forgot at various times: my jacket, my credit card (x2), and my Pocket PC Phone Edition PDA. Must have had something else on my mind. I got the jacket and credit cards back, but my PDA is now the property of some kid living the dream in Haleiwa.

A decade ago, the Palm Professional utterly changed my working life. I was dedicated to the Palm until a few years ago, when I switched to a Pocket PC Phone Edition. The PPC-PE was a good PDA, but not a great phone. Then I bought a Smartphone, thinking it would give me the best of both worlds. It didn’t and when it died (like, a week after the warranty ran out) I switched back to the PPC-PE.

There are 4 things that I want to carry around:

  • a phone
  • music and podcasts
  • my “next tasks” to-do list
  • something into which I can enter notes quickly

The first two can obviously be satisfied with existing devices, but digitizing the last two are debatable. True, I would love it if I could (a) take notes quickly and (b) have those notes synchronize with my OneNote-based notebooks (which is how I now guide my working life). Unfortunately, there are 2 downsides:

  • Pen-based PDA input is slower than normal handwriting (absent SHARK / ShapeWriter) and is more error-prone than handwriting on the Tablet PC. Phone-based T9 input is a non starter for note-taking.
  • When you have a $300+ device, you fret about it — you don’t want to take it the beach, you worry if it will fall out of your pocket, you don’t want to scratch the screen, etc. And, well, when you forget it in a Mexican restaurant in Oahu 5 days after synchronizing, you’re really screwed (lost software, lost notes, lost time records, lost phone, etc.)

I had hoped that a phone with audio recording would give me a solution (I wrote a prototype that did voice recognition on the recorded note and added a link to OneNote, but the quality of the transcription was so poor that I abandoned the project).

I’m tempted by a PDA/Phone with a thumb-keyboard, but they still seem to be very expensive. For the moment, I’m using a 7″ x 5″ notebook. Not a fancy Moleskine for me — they’re too gorgeous to abuse: I favor Sherbert Notes 80 pages. Good ruling, good binder, low emotional content.

Premature Non-Functional Programming the Root of All Evil?

This post by Wesner Moise reminded me of my own post a few weeks back. Basically, the observation is that the “functional programming” paradigm, in which variables are immutable once bound, really seems to have something going for it.

In functional programming, the context necessary to achieve a function is passed in and the results are returned. Anything that changes that isn’t explicitly returned is a “side-effect” and one strives to minimize such things (as a practical matter, things like IO are necessarily (?) implemented as side-effects). Strings in Java or the CLR are immutable (although in use you often have s = s.Trim() or what-have-you).

Contrast:

class OopFoo{
  int bar;
  void Func1(int i){
    bar = i * 2;
  }
  int Func2(){
    return bar * 3;
  }
}
vs.
class FunctionalFoo{
  int Func1(int i){
    return i * 2;
  }
  int Func2(int i){
    return i * 3;
  }
}

In OopFoo, the results of OopFoo.Func1(int) are stored in an instance variable bar and calls to OopFoo.Func2() use that instance variable to perform their calculation. FunctionalFoo on the other hand, uses no instance variables: the behavior of FunctionalFoo.Func2(int) is entirely dependent on the parameter.

Traditional OOP design principles don’t provide a lot of guidance on selecting between these two interfaces but tends to favor the OopFoo approach, especially if the amount of context starts to get large (that is, if there were 10 variables necessary to calculate Func2, you’d likely store them in as instance variables). On the other hand, once you start unit-testing, there’s an automatic tendency to start favoring the functional approach, since unit tests generally have to construct and pass in context anyway. On the other other hand, if Func1()‘s calculation is logically internal to the implementation of the class, you certainly don’t want it visible, returning semi-logical values to external users (for instance, a function that validates the city portion of an address, but not the whole address). (Incidentally, the lack of internal visibility in modules is one of the things you note in the code of journeyman programmers: they “get” public and private, but the benefits of internal and to some extent protected are less used.)

Werner’s hesitancy about functional programming relates to another issue: resource consumption. Allocating a new data structure everytime you manipulate the structure seems fraught with peril. But one thing we learn from optimization is that programmers are poor at guessing how resource consumption plays out in the whole context of a program. Further, in some situations one can use design patterns (notably, Flyweight) to help actual, as opposed to logical, resource consumption.

I can’t say that excessive resource consumption can always be refactored away, but more and more, I find myself developing behavior in a functional manner and refactoring towards a more stateful interface over time.