Gabe was born Friday, Oct. 28th, at 2:26pm . Mom and baby are both well, and older sister Zoe is very pleased that the “cute baby” is coming home with us soon.

Here at Relevance, we are committed to organically growing the business. To that end, I am pleased to announce our newest junior member: Gabriel Gehtland, 6lbs11oz, born today at 2:20pm. Congratulations Justin and Lisa!

Justin, we’re expecting a photo or two once you’re home and reasonably sentient again. :-)

I’ve finally posted the slides and code samples for the Ajax presentation I gave at Java in Action in Orlando. They can be found on the Resources section of our website. They are called “JIA: Ajax Slides” and “JIA: Ajax Demos”, respectively.

Be forewarned: the slides are 16.9mb and the demos are another 10mb. What can I say, I never said Ajax was SMALL, did I?

Man—I didn’t know how a three-hour extravaganza on Ajax was going to fly down at Java in Action. I mean, people like hearing about cool stuff, and Ajax qualifies, but three hours? I didn’t know if the audience would revolt or something.

My fears, it seems, were unfounded. I got some really good responses to the talk, and feedback from the crowd that will directly influence “Pragmatic Ajax”. In fact, Dion has already gone ahead and written the PHP chapter, which several of the attendees were asking about, so we’re really proving out this Agile book writing thing. Good job, Dion!

For those who actually attended, I’m busy packaging up the live code demos I did, which I’ll post here in our Resources section by tomorrow.

Thanks to everyone who came to the talk; it was a great crowd.

I have been catching up on reading lately and have particularly enjoyed Martin Fowler’s Bliki. Reading CollectionClosureMethod helped me crystallize me why I much prefer blocks/closures over list comprehensions. In fact, I’d take things a step farther. The article argues that while closures are more general, list comprehensions offer a convenient syntax in some cases:

List comprehensions make it easy to combine the two.

managersOffices = [e.office for e in employees if e.isManager]

You can also do this be chaining block methods together (which looks a little more clunky to my eye).

managersOffices = employees.select{|e| e.manager?}.map {|m| m.office}"

Let’s make the block form look nicer:

# usage: employees.mapsome {|e| e.office if e.manager}
module Enumerable
  def mapsome(&blk)
    self.map {|e| blk.call(e)}.compact
  end
end

Ruby already has something quite similar to mapsome: Nano Methods’compact_collect. I love the implication that Nano makes about Ruby: the language is so concise & powerful that the useful unit of component reuse is the single method.

The Beta Book of “Pragmatic Ajax” is now available. Pick it up at The Pragmatic Programmer. I’m personally just thrilled with the beta process; I hope lots of you will take advantage of it, and help us along the way. With the beta program, the feedback from the readers helps shape the final version of the book. We’ve called it Agile Bookwriting here in this space before; now its time to put it to the test directly.

Hop on over and have a look!

Ted Neward has responded to my post about the new C# features and how C# compares to more developer-oriented programming languages.

We seem to be talking past each other, so let me tighten my argument by reponding to a few specific points. Ted says

...the idea that a dynamic language doesn’t have specific and detailed rules regarding inheritance, encapsulation, delegation, and so forth, is a fallacy: they have them, they’re just not the same rules as those for a statically-typed language.

You’re right Ted. That’s a fallacy. It’s also not what I said :-). Of course Ruby, Python, Lisp, et al provide the abstractions in question. The criticial point is that these abstractions are implemented in the language itself. Developers can (and do!) modify these core abstractions to work in different ways. To use C#’s new extension methods as a point of example:

• Prior to C# 3.0, extension methods did not exist
• Microsoft sees the need
• Now, in 3.0., we get extension methods

Compare this to, e.g, Ruby:

• The rules for adding new methods to existing classes aren’t (for the most part) in the core of ruby—they are implemented in Ruby source code
• The default rules make it trivial to add new methods
• Developers can easily change this default by writing a few lines of Ruby code. You can create a different “extension method policy”, and you could choose to enforce it at the system level, or by class, or by instance, or any other criteria you could imagine.

It’s all about control. With a vendor-oriented language like C#, core abstractions are much more firmly controlled by the language vendor. Conversely, developer-oriented langauges like Python leave more of these choices to the developer (although they tend to provide reasonable defaults). So, again, who do you trust? Ted thinks I don’t trust vendors:

I find this argument highly unfair and totally bigoted. It essentially suggests that vendors can’t do anything right, and portrays them in the traditional “corporations are the root of all evil” that right now so deeply permeates the American social landscape. It also portrays everything done by “non-vendors”...

But I never suggested any of that. Competency and trustworthiness are sprinkled all over our industry, both among language vendors and application developers. My concern is who controls the abstractions. Developer-oriented languages (like Scheme) give a lot of control (and responsibility) to developers. Vendor-oriented languages (like Java) leave that control more firmly in the hands of the vendor. Ted and I actually share a lot of common ground. We both know it is about trust and control:

all this “expressiveness” is like putting craftsman’s tools in your hands; in the hands of a master craftsman, amazing things can result, but in anybody else’s hands, it’s putting a loaded gun into the hands of a child.

If I understand the analogy correctly:

• We (readers and writers of blogs) master craftsmen
• Developers small children
• JavaScript (et al) loaded gun
• C# (et al) board with a nail in it (?)
• IT decision makers == adults

This argument certainly pulls no punches, and there are plenty of people who see the software world this way. But I actually think there are more nuanced defenses of “vendor-oriented programming”. Here’s one: Vendor-oriented languages help keep developers focused on their solution space. Company X builds widgets, not programming languages. Their developers are plenty smart enough to create (or improve) a programming language, but company X doesn’t sell programming languages. Working in C# or Java imposes a structural barrier in front of non-productive activities. The Company X example pushes the conversation toward the debate I’d like to have, with questions like these:

• Are statically-typed languages the best way to safeguard key language abstractions?
• Is it more effective to have a separate meta-layer, or have all the language there, all the time?
• Exactly which abstractions should be controlled by developers?

And some meta-questions too:

• Does a strong culture of automated testing on a development team change your answers to the previous questions?
• One size does not fit all. What non-technical factors guide platform choices in the real world?
• How big a project (or team) does a company have before it becomes worthwhile to spend time improving languages, rather than just building with the tools we have?

Ted Neward has written a nice summary of the language innovations that we can expect be in C# 3.0. Obviously the success of various dynamic languages is having an impact—all five of the features that Ted highlights have obvious (and simpler) analogs in dynamic languages.

The argument that I infer from Ted’s piece is “Look! now we can have (some of) the expressiveness of dynamic languages with (most of) the safety of a statically typed language.” Let me be clear that this is a good thing—I am always looking for ways to be more expressive in statically typed languages.

But just because C# now looks a little more like some dynamic languages, don’t make the mistake of assuming that two worlds are converging. In the most important ways, they are as different as ever. Here’s why: Languages like C# “bake in” specific and detailed rules for inheritance, encapsulation, delegation, how symbols are interpreted, etc. In dynamic languages, similar rules exist, but they are not part of the language core. Instead, they are idiomatic extensions built within the language itself. Development teams can follow these idiomatic rules. Or, they can build (and enforce!) their own rules, specifically tailored to their needs. This has huge implications for productivity. In dynamic languages, you get to build the language up toward your domain, while you build the solution down.

So why has the static/dynamic debate staggered on for so long? I think we could get closer to some answers with better choice of terms. “Static” vs. “dynamic” is highly misleading. I propose we use a new set of names: vendor-oriented vs. developer-oriented programming, or VOP vs. DOP.

So who do you trust most: vendors or developers?