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:
Compare this to, e.g, Ruby:
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:
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:
And some meta-questions too: