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:
- Lost Conversations #1: Matchmaker
- Lost Conversations #2: Two Fandoms, One Approach
- Lost Conversations #3: Toronto the Good or Toronto the Redoubtable?
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.