Cars and the Idiots who Own Them

Yes, I’m talking about me.

This morning, we had a big day planned: food shopping, checking out an international market, and having some guests this evening. We decided to go to the international market first1. We had heard they had really cheap produce and were not disappointed. We picked up quite a bit of greens and herbs and were on our way. We put them in the cooler to survive the trip to the next store, I put the keys in the ignition, and…

Nada.

The key turned all the way around the ignition, without turning on the car, and it wouldn’t come out! We tried for 15 minutes with the awful thing, every gimmick we’d ever heard of for stuck keys. Then we called our insurance company and they sent a tow truck–Estimated Time of Arrival: 2 hours.

Off and on for an hour I tried jiggling and juggling and haggling and huggling. Finally, after an hour, I took off the steering column’s plastic wrapper and looked at the ignition itself–it seemed a part was loose…just need to push it in…suddenly, it turned and locked and came out and went in and ignited! I canceled the tow truck, and drove straight to the dealership.

The thing is, I was going to take it in next Saturday for a full checkup no matter what anyway. Now I have an appointment for Monday morning to do that and fix the ignition. Skip work or rent a car? It’s hard to make up work when I have night classes. I might have to rent a car if mine needs serious work anyway.

Computers I can handle (usually!), but cars are another thing entirely. We ended up going to CostCo near where we live, instead of the much cheaper (and farther) Sam’s Club, but we made it home in one piece–and now we have yet another “theft deterrent.” 😉

1 – Grand Mart International Food, 6255 Little River Turnpike, Alexandria, VA.

Code Security and Typed Assembly Language

Over the summer I’m taking a class called Programming Languages and Security. This is the first time I’ve delved into security at this level before. It’s a seminar style, which means lots of paper reading, and I am going to give two presentations.

My first presentation was this past Thursday. I spoke about typed assembly language and security automata. It was absolutely fascinating, ignoring the formality of proofs, and all the mathematical notations.

The two papers I discussed were:

The TALx86 begins by describing many shortcomings of the Java Virtual Machine Language (bytecode), including such things as:

  • Semantic errors in the bytecode that could have been discovered if a formal model had been used in its design.
  • Difficulty in compiling languages other than Java into bytecode. For example, it’s literally impossible to correctly compile Scheme into bytecode. OK, Scheme is a pretty esoteric language, but…
  • Difficulty even in extending the Java language because of the bytecode limitations
  • Interpretation is slow, and even though JIT is often used these days, that’s not built-in to the VM

My immediate thought on reading this was, “Hey! .Net addresses each and every single one of these points!”

  • The CLR defines a minimal subset of functionality that must be supported by every .Net language–allowing over 40 languages to be compiled to MSIL
  • As a bonus, MSIL is typed (as is Java bytecode)
  • Just-In-Time compilation was designed in from the beginning and generally has superior performance to Java (in my experience)

It also seems that many of the experimental features present in such early research, such as TALx86, has ended up in .Net and compilers these days. Type safety is being pushed lower and lower. Security policies are being implemented into frameworks, operating systems and compilers, and there are other tools that analyze your code for adherence to security best practices.

On platforms such as .Net, type safety is more important because you can have modules written in VB.Net interacting with objects written in C++ or Python, for example. Those languages don’t know about each other’s types, but at the MSIL level you can ensure safety.

If you’d like, a copy of the presentation is available.

Attributes and Complexity

Attributes can be seen just as a way of gaining some benefits of multiple-inheritance without the awful complexity that comes with that feature. Most languages have wisely done away with MI, and replaced with interfaces, and now attributes.

For example, let’s look at this code fragment in C#:

[Category(“Test Class”)]
public class MyClass
{
//implementation of MyClass
}

This assigns an instance of a CategoryAttribute to MyClass. The same thing could be accomplished in C++, using a base class:

public class MyClass : public CategoryAttribute
{
MyClass() : CategoryAttribute(“Test Class”) { }
//implementation of MyClass
};

However, the disadvantage of the C++ approach is:

  • How do you get the attributes for an arbitrary object? You can try dynamic_cast<categoryattribute *>(arbitraryObject) and check to see if the result is not NULL.
  • If you want many attributes, you are doing multiple-inheritance in a big way, which is a Bad Thing. You will probably get collisions eventually.
  • The whole idea of using attributes per se is kind of lost when using inheritance. By definition, it violates the inheritance principle of “is a” (MyClass is a Category? ummm… no). Classes “have” attributes (MyClass has a Category? yes)

Managing Complexity – Part 2

Last time, I covered some generalities and anecdotes about minimizing complexity in my life. Today, I have a few more thoughts about complexity as it relates to software.

Software engineering has continually evolved since the inception of computer programming languages. One way of looking at that evolution is to see it in terms of improvements on complexity management. (This is a bit simplistic, since computers have simultaneously become much more complex.)

The first computers were simple by today’s standards, but the programming methodology was very complex: dials, levers, buttons, or physically connecting wires. Then machine language was developed binary code could be entered on a card, later memory, and interpreted.

These early languages required a perfect familiarity with the machine. If the machine changed, the code changed.

Over the years, the advances in languages have largely been a process of hiding the machine’s underlying complexity. ALGOL came around and hid the machine code and provided the foundation for FORTRAN and C. C built further by providing both structured programming tools and an abstraction of the machine’s language–one foot in each world.

Terminals began to have graphics capabilities and SmallTalk was developed to further hide the complexities of both growing code modules and user interface elements. Java hid the complexities of lower-level code like C and C++, and even took away the concept of a physical machine and substituted its own virtual machine, theoretically consistent across all physical platforms. C# has done much the same for Window–hiding the complexity of thousands of APIs in a hierarchical, intuitive framework of managed code.

Modern processors are beasts of infinite complexity and power compared to the early hulking iron giants, but the languages which we use hide nearly all of the complexity that our forebearers had to deal with on a daily basis.

Now it looks I’ve been really writing about abstraction. It’s extremely strongly related, but I don’t think it’s exactly the same thing. Abstraction is thinking at a higher level; minimizing complexity is thinking less.

Modern languages both abstract away lower level concerns and provide tools to minimize the complexity of things at the highest level.

There is increasingly a proliferation of visual tools, begun with GUI editors, but now including visual code designers.
Aspect-oriented programming and attributes are allowing complexity to be further minimized.

In the future, tools such as these, and increased use of COTS will become vital to accomplishing anything. Software complexity will only increase, but hopefully the trend of tools that minimize complexity will also continue.

Perhaps somebody (not me!) should investiage the theory of a total complexity quotient–a measure of the complexity of a system and the complexity of the tools to develop and manage that system. With this number we could measure if complexity overall is increasing or decreasing, and what/when is the crossover point.

Managing Complexity

Software engineers know that one of the keys to achieving development goals is effective complexity management. The single best way of managing complexity is to remove it from the system completely.

As a simple example, in an earlier version of my BRayTracer project (I really need to come up with a better name!), scene objects were edited by double-clicking on them in the tree view, which opened up a dialog window that displayed the properties of the scene object. The user could make changes and then click OK or Cancel.

This data flow introduced complexity by requiring:

  • An additional window to manage
  • Moving data between the main window and the dialog
  • Making a copy of the scene object
  • Allowing the user to cancel or undo previous actions

The functionality of being able to cancel changes necessitated most of that complexity.

While this example wasn’t overly complex, I still felt there was a better, simpler way. You can probably see a number of possible solutions:

  1. Implement a general undo system (more complexity)
  2. Don’t allow users to cancel changes–they’re committed! (possible, but wise?)
  3. Eliminate the dialog by having a child window on the main form (does not allow cancelling, but removes the additional dialog)
  4. Rethink how objects are edited from the ground up (expensive)

I went with option 3. Obviously, there’s a tradeoff here. I sacrificed some functionality for the sake of simplifying the interface and the code. In fact, in usability testing, many users wanted a way to cancel or undo changes. Someday, I’ll have to go back and add a way of doing it. This illustrates the principle that sometimes complexity is unavoidable for certain features (Undo support, for example, is nearly always very complex to implement effectively) and that often what is really going on is shifting the burden of complexity somewhere else.

Minimization of complexity is also tightly coupled to the principle of optimality (ah…but optimality of what?).

The tendency of developers (at least I assume it’s a tendency–I am, of course, generalizing from my own experience and those people I’ve observed) to minimize complexity is something that can carry over to our normal lives. I notice this myself in a number of ways, most of which probably aggravate Leticia to no end 🙂

  • When driving, I almost aways get in the “optimum” lane as soon as possible, that is, the lane from which I’ll have to make the fewest changes. Changing lanes adds to complexity. Having to worry about changing lanes when it becomes crucial adds too much complexity. While there are exceptions for painfully slow people, I change lanes only about 6 times on my 35 mile commute (4 roads and 4 highways).
  • When I cook, everything is optimized for minimal disruption. All ingredients and equipment are pregathered and then prepared in a way which minimizes work, time, and coordination.
  • When I watch movies at home, I try to optimize the experience by first queing up the movie, setting up the environment, volume, and then making popcorn. That way, once the popcorn is done we can begin watching immediately, while it’s hot. I almost can’t watch a movie without popcorn.

Narnia

At the Star Wars movie the other day, we happened to see the teaser trailer for the upcoming movie: The Chronicles of Narnia: The Lion, the Witch, and the Wardrobe.

The Chronicles of Narnia are perhaps some of the best books I have ever read. I read them as a young child, and reread them again a couple of years ago. They are wonderful stories in their own right, but they are so full of rich symbolism and meaning that they are eminently more enjoyable now.

My wife read the series after me and loved them as much as I did. She had tears in her eyes during the trailer. She wants to see it NOW. (It will be in theaters on December 9)

I hope the movie is a faithful rendering of the book. The creatures and effects are being done by WETA (of LOTR fame), so it will be spectacular in that regard. It’s also being shot in New Zealand. I think it’s a nice coincidence (?), given that Tolkien and Lewis were wonderful friends for much of their lives.

Something fascinating that I learned in biography of C.S. Lewis by A.N. Wilson is that Lewis is credited for pushing Tolkien to finish Lord of the Rings.

I just hope that they eventually decide to do all of the books. The stories are amazing, and the images I see in my head are only possible now with the magic of computers. The children they’ve picked for this movie look solid, too.

We’ve also been very fascinated with Lions as a result of the books.

Memorial Day in Arlington Cemetery

Leticia and I went down to Arlington Cemetery this morning to view the Memorial Day proceedings. We got there just in time to see the presidential motorcade, and we saw President and Mrs. Bush. My camera couldn’t catch it because they were driving fast and my camera’s cycle time is a little slow.

We listened to the President’s speech, and he was very well received.

I also got THIS close to meeting Secretary Rumsfeld–I was sticking out my hand when he turned around and went the other way. I got some decent pictures and pictures, though. Check them out here.

Star Wars Epsiode III: Revenge of the Sith

Leticia and I went to see this movie this Friday, and we loved it.

Apparently, Spielberg and many others cried during episode 3 of Star Wars. It is a very moving, very sad tale of the demise of the Jedi, and Anakin and Padme in particular.

I’ve read that many people don’t like it. I don’t understand why. I think it’s because of “old fogey” syndrome–a tendency to romanticize the past to be greater than it was, and to denegrate the present as not living up to it. I could be wrong, but that’s how it seems to me.

I loved the fighting, the drama, the music, the introspective scenes, and all the rest. It is easily the best of the current three, and may be as good as the original, IMHO. Although, I didn’t think that Episodes I and II were all that bad either. I think there are fundamental differences in the types of stories that needed to be told, and George Lucas pulled it off pretty well.

People like to complain about Hayden Christensen. I don’t think he’s that bad of an actor: he was exactly what the part required (and very similar to Mark Hammill, it seems). I think the problem is Natalie Portman and Hayden Christensen together: they don’t mesh on-screen at all. Natalie doesn’t seem quite comfortable in the role. However, her final scenes in Episode 3 were absolutely wonderful.

It didn’t make me cry, but it was close. If we didn’t know that it was all going to turn out OK in the end, I think this movie would be even sadder and harder to watch.

BRayTracer Version 0.8 Released!

I’ve been having some very bad back pain today, and so today took some time off from work and class (it was the first day today!) to lay in bed and work on finishing up version 0.8 of BRayTracer.

I’m very proud of the improvements I’ve made to the latest version. Usability has been increased significantly and there are probably over a hundred bug fixes.

As always, feedback is appreciated. Check out the BRayTracer page to learn more and download a copy.

Math can be freaky…

To preface, I am not a mathematician. I can hold my own in most college-level math (I’ve taken 3 years of algebra, trig, geometry, 3 years of calculus, and 1 year linear algebra: where is all that knowledge now?), but I’m still easily impressed.

I’ve been working through an algorithm textbook (more on that later), which mentions a number of very interesting mathematical equalities:

I.
13 = 1
23 = 3 + 5
33 = 7 + 9 + 11
43 = 13 +15 + 17
etc.

II.
13 + 23 + … + n3 = (1 + 2 + … + n)2

III.
12 = 1
22 = 1 + 3
32 = 1 + 3 + 5
42 = 1 + 3 + 5 + 7
etc.

To be honest, when I first read these it blew my mind. There is a beautiful correspondence demonstrated in these ancient forumlas that is nearly breathtaking when you first learn of them.