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?