« August 2006 | Main | October 2006 »

September 2006

September 26, 2006

Simple is hard

Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction.

Albert Einstein

Is Ward Cunningham a smart guy? After all, Ward’s most visible contribution to the world is the wiki. And that’s so simple that it’s obvious, right?

It’s hard to create something simple that people will want to use. It takes a lot of intelligence to figure out what features to leave out. Here are some of my favorite simple things and why I love them:

  • iPod + iTunes, it grabs new content automagically for me and it just shows up
  • vim, it’s a great text editor and nothing else
  • NetNewsWire, keyboard navigation of feeds and integration with iTunes
  • irb, a great prototyping environment for Ruby
  • NUnit + TestDriven.net, simple test framework with a simple user interface

What’s your favorite simple things?

September 16, 2006

On Being Happy

Today’s my 39th birthday. I had a wonderful day hanging out with my wife, the kids and the neighbors. And tomorrow my family’s coming by to spend the day.

I also don’t normally blog on the weekends, but I just found a blog that I just have to share. Via Steve Lacey who I found through an extremely unlikely set of coincidences, I discovered Gretchin Rubin. Steve linked to a post on her blog titled Tips for being a more light-hearted parent.

Wow. What a wonderful collection of advice. Tip #7 is particularly good:

Most messages to kids are negative: “stop,” “don’t,” “no.” So I try to cast my answers as “yes.” “Yes, we’ll go as soon as you’ve finished eating,” not “We’re not leaving until you’ve finished eating.” It’s not easy to remember to do this, but I’m trying.

As I read her tips, and some other entries on her blog (which is a year-long diary of her quest to become happier) I instantly became a fan. This is excellent writing, and great advice. Her portrayal of her family as characters (Big Girl, Little Girl, and Big Man) works incredibly well.

While I’m jealous of people who write so much better than I do, it’s also something to aspire to. Go take a look. You won’t regret it.

September 14, 2006

The Light at the End of the Tunnel

I’ve spent most of the past month or so working on a rewrite of the internals of RubyCLR. I got the last major set of tests to pass today, and I’m almost at feature parity with the Drop 4 release. So I finally decided to check in new bits into the Subversion repository.

Here’s a brief summary of what’s changed:

  1. Better coverage in trapping CLR exceptions and marshaling them to Ruby.
  2. Better error reporting – you will see both a CLR and a Ruby stack trace if your application crashes.
  3. Better performance, the unit tests run about 60% faster than in Drop 4.
  4. Cleaner organization of code in the C++ layer. I would say that 90% of the code was touched during this rewrite (which is why it took so long).
  5. Vastly improved support for generics and nested types.
  6. Independent set of unit tests for new reflection library.
  7. Better separation of layers. Things are very strict in this release and it’s much more obvious which layer you’re coding in.

Most of the samples work, including the prototype irb in Avalon. I’ll fix the few remaining bugs on my list and will probably release a Drop 5 tomorrow in anticipation of Beta 1 (which will include docs!) in time for RubyConf.

September 12, 2006

Joel Spolsky Abducted by Aliens

You know what? Sometimes life isn’t fair. I work hard on these blog posts, deleting words until I get to the point where (hopefully) you can understand what I’m trying to say. And then along comes DHH who writes this absolutely brilliant one-liner:

“Just after he explains to the grand jury of Smalltalkers how dynamically-typed languages can’t be fast because a method call doesn’t compile down to a single CALL instruction.”

This is in response to the latest misguided Joel Spolsky posting on Ruby Performance Revisited. I would go and read that first if you haven’t already.

Then go and take a look at Avi Bryant’s excellent explanation about how dynamic dispatch works in modern runtimes.

A really nice thing that Avi points to is Sun releasing the source code for Strongtalk, a high performance open source virtual machine for Smalltalk. Sun acquired the company (Animorphic) that created the Strongtalk VM to fold the Strongtalk dynamic dispatch technology into the Java Hotspot VM.

But perhaps the best post about this whole affair is from Jeff Atwood. I want the old Joel back too.

Will Dynamic Languages Cross the Chasm?

In certain domains, such as client-side AJAX development, JavaScript (an under-appreciated dynamic language) has most definitely crossed the chasm. It has kicked statically typed languages such as Java (remember Duke?) and VB/C++ (remember ActiveX?) out of the browser. But what about mainstream business applications? Here, Python and Ruby are the main contenders yet we still haven’t seen a lot of movement.

Currently, Ruby is the belle of the ball – today’s fashion statement in programming. It’s strapped onto the Rails rocket/catalyst, which got a lot of people to look at Ruby, myself included. Once you look at Ruby, its benefits are clear: it reduces the activation energy required to write clear, beautiful code. And this characteristic appeals very strongly to the early-adopter / alpha-geek market.

Witness Steve Vinoski’s recent encounter with Ruby:

“It looks like Tim Bray and I currently happen to be in very similar places with respect to Ruby. I too am just starting to use Ruby in real production applications, and like Tim, I too have been ridiculously productive with it over the past few weeks.”

Steve and I met a couple of years ago at the ACM Middleware conference that Werner Vogels helped to organize (back in the day when Werner was just a ‘lowly academic’). Back then both Steve and I were on a similar trajectory around Python. I had just written Matthew’s first birthday present, an internal DSL for writing scripts to get Microsoft Agent characters to tell animated stories, as well as sing songs. We spent a lot of time at the conference talking about how great dynamic languages were, and how much more productive we were when programming using them (in stark contrast to C++).

But back to the original point: the productivity gains, the beautiful code appeal to the alpha geek aesthetic (and Steve’s far more of an alpha geek than I am – just look at what he’s accomplished in his career). I’m not convinced that they appeal to the early mainstream market which is what you have to target if you want to have a hope of making it across the chasm that most technologies die in.

That market craves relatively safe decisions. In Geoffrey Moore’s own words:

“The early majority share some of the early adopter’s ability to relate to technology, but ultimately they are driven by a strong sense of practicality. They know that many of these newfangled inventions end up as passing fads, so they are content to wait and see how other people are making out before they buy in themselves. They want to see well-established references before investing substantially. Because there are so many people in this segment – roughly one-third of the whole adoption life cycle – winning their business is key to any substantial profits and growth.”

This is why last week’s announcements by Sun (JRuby), and Microsoft (IronPython 1.0) are so significant. Sure, Python is used a lot by Google, but to most early mainstream business application programmers Google is alien technology that bears no resemblance at all to the applications that they are paid to write. On the other hand, Sun and Microsoft are platform vendors that speak their language. Their explicit endorsement of dynamic languages is a very important step toward early mainstream adoption.

Hopefully we’ll see dynamic languages cross the business application chasm. We’re not there yet, but when we do get there I believe that we’ll find far more happy programmers out there (and happy programmers == productive programmers).

September 08, 2006

I Need More Hours in a Day!

RubyCLR will only compile on Ruby 1.8.2. There, I said it. The pre-built runtime.dll will run on 1.8.4, but you will not be able to build. There are a whole pile of issues around getting it to build on 1.8.4 (and I believe on 1.8.5 as well).

I took a quick look last night during a break from my current battles in refactoring the existing RubyCLR codebase. In short, it’s not pretty. It also won’t be resolved until I finish refactoring the current codebase and writing some long-overdue documentation.

I would love to make it a higher-priority item, but unless someone can donate some time to figuring out what’s blocking compilation (and execution – there’s a nasty seg fault that happens when running nmake) this will have to go on the back-burner.

Now where did I put that human cloning book?

September 07, 2006

Sun Shines on Ruby

Today, Sun Microsystems announced that they have acquired the JRuby development team. Both Charles Nutter and Thomas Enebo have joined Sun as full-time employees to continue their excellent work on JRuby. Congratulations, guys – isn’t it great to be able to work full time on what you love doing? Kathy Sierra summed it up today with this diagram (click on the picture to see her blog entry):

Tim Bray was a major force behind the scenes, and he wrote up a nice FAQ regarding what happens next with JRuby.

Exciting times for dynamic languages on popular virtual machines.

September 06, 2006

You can have your language cake and eat it too

Why are dynamic languages on the CLR (and the JVM) such a hot topic these days? Jon Udell wrote a very insightful article on this very issue called Why argue about dynamic versus static languages when you can use both?.

With yesterday’s release of IronPython, the story of dynamically-typed programming languages comes more clearly into focus. A core virtue of such languages is that they enable individuals or small teams to work in a rapid and exploratory way. A core virtue of statically-typed languages is that they enable larger teams to work in a declarative way that’s friendlier to large-scale collaboration. Much virtual ink has been spilled debating the pros and cons of these two approaches, but why argue if you can have the best of both worlds?

If you have a VM that can run code written in dynamically typed and statically typed languages, you can focus on using the best tool for the job. Right now if you’re writing a Ruby application, you can write parts of it using a strong, dynamically typed language (Ruby) or a weak, statically typed language (C). If you’re using RubyCLR/IronRuby/Ruby.NET you now have the additional choice of a strong, statically typed language (C# / VB / F#).

You can and should write different parts of your application using the most suitable technology. Things get even better if your entire application can run inside the same virtual machine, since you can leverage the platform benefits that come ‘for free’ with the VM: tools, debuggers, performance, and security.

I for one believe that this is the way we’ll be writing our applications in the near future. And I’m doing everything that I can to make this happen for Ruby and the CLR as quickly as possible.

The Joy of Deleting Code

You know how it is. At first you have to rip things apart before you can begin building things back up again. There’s been lots of ripping apart happening in RubyCLR over the past few weeks. A brand-new and very high performance reflection layer now lies underneath everything. And tonight I got the first vertical slice to work.

Here’s the unit test that now passes:

def test_default_ctor a = ArrayList.new assert_equal ‘System.Collections.ArrayList’, a.clr_type.full_name end

Here’s what the code used to look like for defining a method shim:

def self.method_shim(klass, method_info) method_labels = (1..method_info.signatures.length).collect { |i| (“l” + i.to_s).to_sym } create_safe_ruby_instance_method(klass, method_info.ruby_member_name) do match_sig method_info.member_id switch method_labels throw_clr ‘Cannot find method that matches Ruby parameters’ method_info.signatures.each_with_index do |sig, i| label method_labels[i] ld_this klass ld_params sig inst_call method_info, i ret_2rb method_info, i end end end

Here’s what it looks like now:

def self.method_shim(klass, method_name, members) method_labels = (1..members.length).collect { |i| (“l” + i.to_s).to_sym } create_safe_ruby_instance_method(klass, method_name) do match_sig add_members_to_signature_cache(members) switch method_labels throw_clr ‘Cannot find method that matches Ruby parameters’ members.each_with_index do |member, i| label method_labels[i] ld_this klass ld_params member.get_signature inst_call member ret_2rb member, i end end end

The new code is much better than the old code. In the old code, all type information was expressed using strings. This made things quite flexible, but at a severe performance penalty. There were many type lookup operations (to be fair, some of which were cached), but these are now eliminated in the new code.

I was also rather ashamed of the method_info data structure. It’s a rather central data structure in RubyCLR and it became the kitchen sink of metadata. It evolved over time and was never redesigned. In the new code it doesn’t exist anymore.

Tomorrow should be a fun day – I get to delete a ton of code that isn’t used anymore. I have far more fun deleting code than writing it.

September 05, 2006

IronPython turns 1.0

Congratulations to the IronPython Team for shipping 1.0 today! They’ve really done a lot of work not only to ship a fast and compliant implementation of Python on the CLR, but they’ve also blazed the dynamic language trail for those of us who are trying to do the same with different languages.

The team has really helped the RubyCLR development effort as well. For example, Shri Borde came up with a very clever way to marshal value types efficiently across the interop boundary. Jim Hugunin helped me think through some corner cases in generics as well as providing an answer to my interfaces breaking identity problem. Mahesh Prakriya has been a huge supporter of RubyCLR within Microsoft. He even graciously gave up half of his IronPython talk at Tech Ed to give me a chance to present my project to the world.

There’s a lot more work to be done in the dynamic languages space at Microsoft. Iron Python really is just the beginning, and I’m looking forward to seeing what these guys come up with next.

Photos

  • www.flickr.com
    This is a Flickr badge showing public photos from John Lam. Make your own badge here.

Recent Comments

Recent Posts

May 2008

Sun Mon Tue Wed Thu Fri Sat
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
Blog powered by TypePad