I’ve been following the ongoing discussion about typing systems in programming languages between Ted Neward and Stu Halloway with great interest. Given that I believe Code is Model, I’m eager to mine knowledge from successful tools to apply at higher levels of abstraction. And as an employee of a language vendor, I’m also very interested in what Stu describes as vendor-oriented vs. developer-oriented languages.

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…So who do you trust most: vendors or developers?
[What’s new in C#, or who do you trust most?]

With a vendor-oriented language like C#, core abstractions are much more firmly controlled by the language vendor. Conversely, developer-oriented languages like Python leave more of these choices to the developer (although they tend to provide reasonable defaults)…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.
[Developer oriented languages]

Personally, I think calling them static and dynamic language is far less misleading than vendor and developer oriented languages. Further, I think Stu is making somewhat absurd statements to garner attention. However, I believe he’s certainly onto something with regard to the language abstractions. The abstractions I and my team care about on our project are almost assuredly going to be different from the abstractions you and your team care about on your project. Having a programming environment that enables the abstractions you need on a given project is very very important.

The problem with Stu’s argument is that he’s focused on low level language abstractions. Abstractions like “inheritance, encapsulation, delegation, how symbols are interpreted, etc.” Are you kidding me? Projects don’t fail because developers can’t change the language’s concept of inheritance. They fail because the gap between the abstractions provided by the language and the abstractions needed by the solution are enormous. Modern software development is like building skyscrapers with Lego blocks. Furthermore, projects fail because business and IT don’t speak the same language. Business people don’t care about concepts like encapsulation and symbol interpretation. They care about concepts like ROI, business plans and regulatory compliance. Geeks may not feel comfortable talking about those concepts, but they are what keep a business in business

Imagine your CFO listening to Stu and Ted discuss these language abstractions. They would be thinking “What the hell are they talking about?” To Ted’s credit, he bluntly states that he doesn’t trust developers which would likely put him in well with the CFO:

I see the same concern every time a developer starts talking about doing bytecode manipulation at load-time–just because you can doesn’t mean you should. In this respect, I trust the guys who’ve been down this road before much more so than developers who are just coming to this and are starting to flex their new-found freedom and will (undoubtedly) start building systems that exercise this power.
[Dynamic languages, type systems and self-modifying systems]

I wouldn’t go so far as to say I don’t trust developers, but Ted’s point about can and should is spot on. I’m sure there are scenarios where bytecode manipulation is critical to the success of the project. Hell, in the project I’m currently heads down on (hence the lack o’ posts in the past two weeks) I’m using much more reflection and late-binding than I ever have before. Not because I can – frankly, I like static typing – but because that’s the best way to solve the problem at hand.

It’s important to keep the big picture in mind when discussing minutia such as a given programming language’s core abstractions. IT exists to serve the business, not the other way around.

Anybody have any suggestions of book and/or sites with information about programming with digital audio? I primarily care about mixing and fading, but also some effects and changing the playback speed without effecting the pitch. Feel free to leave comments or email me.

First it was at Fred Meyer a week or two ago. Next it was at my favorite teriyaki resturant last Thursday. Then this past weekend, it happened again at Remlinger Farms. I think Jeff Richter is stalking me.

It warms my heart that Toronto and St. Louis both won tonight. That means the only team without a win in the NHL at the end of the first week is the Penguins. I can hear John groaning as I type. And Pittsburg doesn’t play again until Saturday, so I can run smack at him all week.

From newly converted ARC MVP Sam Gentile, I found this interesting post from Drew Marsh about how XAML is compiled:

XAML is indeed a language, but it is never compiled into C# or IL… The truth is, it’s not “compiled” at all. If anything you can say it is “compacted” and that only happens in scenarios where it is turned into a BAML stream. That, however, is an optimization and not a necessity for XAML to work. XAML can be interpreted purely in it’s raw XML text form, using Parser::LoadXml. Even BAML is interpreted, it’s just a far more compact and efficient representation of the object graph than raw XML text.
[Drew Marsh – The XAML Experience]

Given that I just wrote about compiling, I wanted to weigh with a couple of points:

• First, by definition compilation is a translation from one format to another. Therefore, converting XAML to BAML is a compilation step. The SDM folks have a command line tool for compiling deployment reports from the models in the Architect edition of VSTS. However, I assume what Drew meant here was that XAML isn’t compiled into a directly executable format, so in reality I’m just being picky about the use of the word “compiled”.

• Second, the fact that the XAML is compiled into an efficient binary representation and then embedded as a resource (as per Rob Relyea) is fascinating from an implementation perspective, but somewhat irrelevant semantically. Drew points out that the BAML is interpreted. With VM environments like CLR, the line between interpreted and compiled blurs considerably. Rob’s post referenced above is based on the PDC 03 XAML bits, and at the time, XAML could be compiled into BAML or IL. However, at the time (20 months ago) Rob guessed that the IL compilation would be cut because the BAML perf was just as good or better, the file size was smaller and localization is easier. In the end, the XAML file is converted into a format the machine can execute – the specific choice of compilers and transformations isn’t particularly interesting from a modeling perspective since it happens automatically.

XAML isn’t the only place where the traditional compiling to executable model is being stretched. In Windows Workflow Foundation, though your workflow is defined as a type, you can actually modify running instances of the workflow. Given that WF supports declaring workflows as C# or XOML (soon to be XAML), I wonder if they are going to go the same route as WPF and eliminate the C#/IL way of declaring workflows. Another interesting example is LINQ and C# 3.0. This is interesting because you can use LINQ directly on in memory data, but when you apply it to database (via DLinq) the LINQ statements are parsed into expression trees then converted into SQL. (Check out this post from Ian Griffiths for deeper coverage of expression trees).

Anyway, it’s late and I realize I’ve written quite a bit to basically say that the definition of “compiled” is pretty blurry at this point and getting blurrier going forward. In the end, it’s much more interesting IMO to focus on the model environment you’re working in (XAML in this case) rather than the details of how that model is translated into the execution environment, unless you’re the one building those translation tools.

Update: I had one other thought on all this. It’s interesting that computing power (CPU + IO bandwidth) have improved to a point where the performance of interpreting BAML at runtime is as fast than executing XAML compiled to IL directly. I certainly wouldn’t have assumed that.