Lost Conversations is the title of a series of blog entries that have been sitting in draft form for too long; it's my attempt to do some "spring cleaning". This is the fourth in a series -- the other three are: Please note: this one's rather high in technical content. It's also been cross-posted to The Farm.

Hindsight, Guy Kawaski and Ice

One of my favourite speeches is a high school commencement address titled Hindsight, which was made at Palo Alto High School by one of my role models (especially given my line of work): former Apple evangelist Guy Kawasaki. It was a "top ten list" of advice to the graduating class, and item number eight was "Challenge the known and embrace the unknown". It went like this:

One of the biggest mistakes you can make in life is to accept the known and resist the unknown. You should, in fact, do exactly the opposite: challenge the known and embrace the unknown.

Let me tell you a short story about ice. In the late 1800s there was a thriving ice industry in the Northeast. Companies would cut blocks of ice from frozen lakes and ponds and sell them around the world. The largest single shipment was 200 tons that was shipped to India. 100 tons got there unmelted, but this was enough to make a profit.

These ice harvesters, however, were put out of business by companies that invented mechanical ice makers. It was no longer necessary to cut and ship ice because companies could make it in any city during any season. These ice makers, however, were put out of business by refrigerator companies. If it was convenient to make ice at a manufacturing plant, imagine how much better it was to make ice and create cold storage in everyone's home.

You would think that the ice harvesters would see the advantages of ice making and adopt this technology. However, all they could think about was the known: better saws, better storage, better transportation. Then you would think that the ice makers would see the advantages of refrigerators and adopt this technology. The truth is that the ice harvesters couldn't embrace the unknown and jump their curve to the next curve.

Challenge the known and embrace the unknown, or you'll be like the ice harvester and ice makers.


You Couldn't Give Away Visual Studio Here

A couple of weeks back, I placed an order for the beta evaluation version of Microsoft Visual Studio 2005, which consists of the upcoming version of the Visual Studio IDE, the Visual Studio Team Server (which I assume is some software to assist with versioning and collborative programming) and Microsoft SQL Server 2005. For those of you who aren't terribly into techie stuff, this is the Microsoft equivalent of a fully loaded Snap-On Tools truck, minus the free calendars with the girls in bikinis holding wrenches.

I received the discs a couple of days after placing the order and then sent out an office-wide general notice to my co-workers saying "Hey, if you want to try out the Visual Studio 2005 beta, come by my desk and I'll loan you the discs." Not only is it my job to make sure that the tech world is aware of what Tucows is doing, it's also to ensure that Tucows is aware of developments in the tech world.

The response: almost none, save for two comments.

One comment came from a sales engineer who passed by my desk and said "Heh. Good luck getting anyone interested in that."

The other was a short and perfunctory email from the IT department reminding me that it is a violation of company regulations to install unauthorized software onto company machines.

(Of course, the joke's on IT -- I brought in my own Windows box. As someone who isn't in the development department of the company, I got issued a non-developer machine. It's quick enough for writing TPS reports, but not up to the task of development. I use it as a monitor stand. I did what any half-decent hacker would do -- I brought in my own box.)


COBOL for the 21st Century

Of course, I installed Visual Studio 2005 on my machine. A number of our customers build their web services on the Microsoft platform and I should at least maintain some passing familiarity with Windows development (in a former life, I wrote VB apps for small-to-mid-size businesses). I wouldn't be doing my job if I didn't install it and build some basic apps, both desktop- and web-based.

However, for the development of the Tucows platform -- our domain name registration service, email and email defense, Blogware, Blogrolling, Start -- there is no compelling set of reasons to switch from the LAMP platform.

On an even more fundamental level, there's a reason for a lack of interest in Microsoft's languages (C# and Visual Basic) and even their Sun-based kissing cousin, Java: they're not where the interesting stuff is happening.

C#, Visual Basic and Java are going through an "ice maker" or "ice harvester" phase. The improvements to these languages are now incremental and seem to be aimed at making sure that they have more items on their feature lists than their rivals. Improved IDEs? Nice, but nothing major. Generics? After trying to improve away from C++, both C# and Java went back and aped the unwieldiness of C++'s templates. These new features are knowns; they're the software equivalent of ice harvester thinking: faster ships, better ice storage, sharper saws.

The really interesting stuff is happening with open source dynamic languages, namely PHP, Python and especially Ruby, all of which are pushing little-known possibilities of programming, such as metaprogramming, generators, higher-order functions. These languages are more about getting things done and less about getting in your way.

Consider the difference between the code required for the Order class in this developerWorks article. In the Java version, you need this XML:
01 <hibernate-mapping>
02    <class name="models.Order" table="ORDERS"
03        dynamic-update="true" dynamic-insert="false"
04        discriminator-value="null">
05
06 	<id name="id" column="id" type="java.lang.Long" 
07             unsaved-value="null">
08             <generator class="identity"/>
09         </id>
10 
11         <set name="items" lazy="false" inverse="false"
12            cascade="none" sort="unsorted">
13             <key column="id"/>
14             <one-to-many class="models.Item"/>
15         </set>
16 
17         <property name="name" type="java.lang.String"
18             update="true" insert="true"
19             access="property" column="name"/>
20     </class>
21 </hibernate-mapping>

...and this Java code...

01 public class Order {
02    private Set items;
03     private String name;
04     private Long id;
05 
06     public Long getId() { return id;}
07 
08     public void setId(Long id) { this.id = id;}
09 	
10     public Set getItems() { return items;}
11 	
12     public void setItems(Set items) { this.items = items; }
13 	
14     public String getName() { return name; }
15 
16     public void setName(String name) { this.name = name; }
17 }

The XML is necessary in the Java implementation because it allows you to change the Order object without having to recompile the Java.

Now let's look at the equivalent class in Ruby:

01 class Order < ActiveRecord::Base
02	has_many :items
03 end

Note the lack of XML and "scaffolding". Note the lack of code, for that matter.

Which would you rather code? Which would you rather maintain? Which method seems like archaic ice boats and saws, and which seems like a refrigerator?

Yes, I'll keep up with the Visual Studio and Java worlds, and maybe crank out an app or two using them, but for me -- and my fellow developers here at Tucows -- the really interesting programming tools are elsewhere.