Joshua Marinacci's Blog

Patterns Archives

Passive Tech on the Ocean

Last week I spent a much needed vacation in The Outer Banks. If you ever see a sticker with OBX in a circle on it, that's the Outer Banks. Beautiful and isolated barrier islands off of the coast of North Carolina, they provide great rest and relaxation. And also the opportunity to think about how technology fits in our lives. I've got lots of new ideas to discuss in my coming entries, but one in particular struck me: Passive technology.

Passive technology is, or at least I'm using it to mean this until I find a better word, technology that acts silently on your behalf. It doesn't require your active attention. It only makes itself known when you ask it to or when something unexpected happens. We have some of this philosophy in our technology now, but we need more.

I came to this realization when my friends and I rode on a boat out to the gulfstream for some tuna fishing. You see it's very quiet out in the ocean. Actually it's very loud. There's the lapping of waves and the roar of a disel engine. Always there and very repetitive. But that's it. Just the two constant noises with the occasional sound from a human. While there is plenty of audible noise the information density is low. I'm not bombarded with hundreds of different systems vying for my attention like I am in normal non-vacation life. It's informationally quiet and simple on the ocean. That's why it's relaxing!

The boat isn't simple though. It was a 65 foot ship with a huge engine, beds, bathroom, kitchen, and a deck specially outfitted with chairs and mount points for more fishing rods than I could count, but everything has it's place. All features of the boat are either designed to be flush with the boat itself or carefully hidden in a specific place. Rods are placed in special fittings built into the hull. All furniture is attached to the floor. All corners are rounded. They even have special cabinet knobs that recess into the smooth door, only popping out when you need to use them.

But back to technology. What we have is a system designed to be unobtrusive because the user can't have any distractions. They always need to be focused on the task at hand: sailing and fishing. Anything else is just overhead. I can only assume that this design is the result of hundreds of years of ocean fishing experience. In a world before GPS and combustion engines these considerations had to be made or people could die. Now that's some human centered design!

So why don't we see more of this in our everyday lives? Technology that just fades into the background, letting the user get on with the real task. Probably because it's expensive and takes time. Quality products always cost more. Better materials and better design simply cost more money and resources. But it also takes time for a solution to evolve. No matter how much money you throw at building the first version of a product it won't be perfect. It has to be refined as people use it in the real world. The first cars were expensive and hard to drive. It wasn't until the standardization of the steering wheel and the invention of the automatic transmission that driving became truly accessible. It takes time for a product to mature into something easy to use. Most of our gadgets are too new to be easy to use.

But what if they weren't? I'd like you all to choose an application you use today and imagine what it will be like with 10 years more development. Don't think about new features but more on how the existing features can become more passive and fade into the background. I'm going to choose email. Please post your ideas and I'll collect them in another column a week from now.

Have fun dreaming on the beach!

- Joshua

Strong vs Weak Typing: Can't we have the best of both worlds?

I've seen lots of arguments on the merits of weak typing. It encourages flexiblity. It lets me write code faster. I don't worry about the details until later. I can do cool runtime tricks.

I don't buy it. I use a strongly typed language because the code it produces is more robust. Typing solves a slew of common programming errors all at once. It ensures that my code will always do exactly what I mean, no more and no less.

And yet... I can see the advantages of weak typing too. Java is a better prototyping language than C++ but it's no where near the speed of Perl for whipping up something quick.

Why do we have strong typing anyway? I can only think of two things. First is performance. If you better specify what you want then the compiler can make faster code. The second is for people. The computer doesn't really care if this string really contains a number. It's all just bits in the end. The typing is for you, the programmer. To help you avoid mistakes. To express what you want the code to do to another programmer. It could be someone using your API, or someone modifying your code, or even yourself hacking on your own code in the future. Typing is a more detailed expression of what you want. But creating that expression can be time consuming and constraining.

But what if we could have the best of both worlds. A language that was both strongly and weakly typed, but at different times. What if I could declare at the top of each module (class, file, or package level?) how much syntatic sugar should be applied.

At it's loosest level you would have:

• no required variable declaration
• foreach, other loop constructs
• dynamic casting
• no required exception handling
• inline regex
• any indentation you want.

At stronger levels (less sugar) you have to declare everything:

• must declare all variables, and at the right location
• only standard looping constructs
• explicit casting
• required exception declaration
• all other syntatic sugar turned off
• Maybe bad indentation and no javadocs would be a compile error too.

Imagine if the forthcoming generics allowed anything to be stuffed in and out of a List in the weak mode and required you to declare the type of List in a stronger mode. Bingo! The ease of Perl with the robustness of Java.

I think such a system would help with three scenarios:

For managing long lived code. We have a pattern of sugar going down as the module stability goes up. Newer code is in flux and tested constantly so it's okay to have the compiler make assumptions. As the code is used more, and more components are dependent on it, we clamp down and explicitly define everything.

It's good for dealing with developers at different skill levels. Developers who's expertise lies in other areas (say graphic designers) do the prototype using sugar mode, not having to worry about the ins and outs of casting and exceptions. Then the real developers refactor it to be more solid if the prototype ends up being used.

You get the benefits of strong typing when you open up old 'hardened' code. Then if you break something you know right away because the compiler is very unforgiving.

The language would scale from prototype stage, through development, and on to deployment and maintenance. As the risk of breakage increases so does the strength of the typing to hold it all together.

This work is licensed under a Creative Commons License.