On the one hand, this seems like a somewhat arbitrary name change – from System Defintion Model to Service Modeling Language. And the use of the term “Service” instead of “System” seems sketchy to me.

On the other hand, you gotta love this line from the press release: “The group plans to submit the draft specification to an industry standards organization later this year.” Given the companies involved in “the group” – MSFT, IBM, BEA, Sun, Dell, BMC, Cicso, Intel, HP and EMC – you gotta think SML has a bright future.

Here’s hoping that publishing the SML spec is the first step in a public-workshop-based revision process, a la the Web Services Protocol Workshops.

My pal Tim dropped me an email last week to let me know they (the ADO.NET team) were publishing their vNext vision around entities. Of course, they picked the week when I’m in San Diego! So I didn’t get a chance to look at it until today. In a nutshell, they are raising the level of abstraction for databases. Regular DevHawk readers know I talk about abstraction a lot around here. In fact, one of my earliest posts on this blog – 1 house, 2 kids and 5 jobs ago – was on Disruptive Programming Language Technologies. So this is a topic near and dear to my heart.

This is an amazingly good thing. Think of the impact VB had on the development industry, but bigger. The abstraction level of databases hasn’t been raised in decades. It’s about freaking time we did.

My only problem with the article is that it’s pretty obtuse. Referring to this as “Making the Conceptual Level Real” makes it sound much less exciting than it really is. Nobody refers to C# as a “conceptual” programming language. But if you use the terminology from the vision article, that’s exactly what it is. Machine code is the physical level, IL is the logical layer and C# would then be the conceptual layer. But lets say you build a compiler that compiles C# directly to machine code. Would it suddenly become the logical layer? Who knows? Who cares? Let’s just raise the level of abstraction and not get all caught up naming the level we’re currently at.

VB was introduced 15 years ago in 1991. Most developers in the industry are aware and remember the impact VB had (if you don’t, check out Billy Hollis‘ History of BASIC). The relational model was introduced 36 years ago, The first RDBMS was introduced in 28 years ago. I’d bet the majority of developers in the industry today don’t remember a time before databases. Hell, I was introduced 36 years old myself. (I’m sure my dad remembers programming before databases, but he doesn’t code much these days.)

As I said, this is going to be big and it’s about freaking time. So hats off to the ADO.NET team. Can’t wait to see this running. According to this, first CTP drop is August, so you don’t even have to wait too long.

Congrats to the team for their latest version of the DSL Toolkit, integrated into the June CTP of the VS SDK. According to the published product plans of the VS SDK, they’re suppoesd to ship their next release – including the final DSL toolkit – next month. Looking forward to it.

I spent a couple of hours chatting with Neal Ford from ThoughtWorks yesterday. Ted Neward had virtually introduced us a few months ago and he was in town for MTS, so he arranged a meeting. I had asked Ted to introduce me to some dynamic language folks for some research and public debate purposes, and Neal was one of the people he hooked me up with. Unfortunately, this was right before I changed roles and got real busy. Of course, dynamic languages in general and Ruby in particular plays a large role in Edge Architecture, so I’m thankful Neal took the time to drop me a line and meet with me.

Above all else, talking to Neal made me realize that I just don’t know enough about dynamic languages, which limits my ability to discuss them. To date, I’ve flirted with them, but haven’t made a real commitment. For example, I’ve played around with Instant Rails, but hadn’t actually installed Ruby yet. It was time to re-image my dev partition anyway, so I’m going to try using Ruby exclusively for a while.

Here’s a brain dump of some of what we talked about. Not sure what it all means yet, so I’ll try and refrain from making commentary.

• Hungarian notation for interfaces (i.e. ISomething) is a big code smell. This has nothing really to do with Ruby or dynamic languages, but it’s an important point that I wanted to include here. Neal’s point is that the interface defines the semantics of the type and the concrete class is an “implementation detail”. In other words, contract-first isn’t just for web services. Apparently, ThoughtWorks doesn’t use ADO.NET directly primarily because the interfaces “aren’t pervasive enough” and are difficult to mock out. Also, they’re using Rhino Mocks which I wasn’t previously aware of.
• For all the debate about static vs. dynamic languages, it seems like the value Ruby brings is in meta-programming rather than dynamic typing. Certainly, that’s one of the big differentiators for Ruby vs. other dynamic languages like Python. While Rails has pushed the popularity of Ruby thru the roof recently, Neal seems much more enamored with Ruby than Rails.
• There is an even bigger gulf between dynamic and static typing proponents than I had thought. I brought up Singularity, which uses static typing exclusively to deliver a provably dependable system. Neal disagreed with that approach, pointing out that “tests are the best way of encoding the specification of the system” rather than compile time checking. Given my lack of expertise in this space, I’m withholding comment (for now) but I’m guessing the truth is somewhere in the middle.
• However, while the dynamic vs. static typing gulf is big, meta-programming is potentially the bridge. I don’t believe meta-programming is exclusive to dynamic languages. Certainly, some of the new features in the “Orcas” versions of C# and VB bring more expressiveness to the languages while still remaining type safe.
• All this meta-programming leads to domain specific languages. Ruby has strong support what Martin Fowler called “internal DSLs”, but Neal thought over time the focus would shift to external DSLs as they are more expressive and not constrained by the semantics of an existing language. Obviously, we’re pretty heavily focused on DSLs. However, Neal did think our focus on graphical DSLs is misplaced. He called them a “hangover” from CASE/UML tools. He rightfully pointed out that “business analysis speak English”.

All in all, it was time well spent. Neal, I hope we can pick up the conversation again sometime.

I have been so focused on Web 2.0 stuff that I’ve been reading a bunch of new blogs and disregarding the old ones I used to read. So I didn’t realize until today that the DSL Tools team released a new drop last week. According to Gareth, the highlights include:

• Integration into the Visual Studio SDK. According to the site, they are shooting for an April release for v2 of the VS2005 SDK, so does that mean the DSL Tools will be done in April?
• Single file format and complete visual designer for all aspects of a DSL. I’m guessing this mean we no longer have to edit the designer definition by hand. That’s a good thing. But I liked the seperation of domain model and designer, so I’ll be interested to see how I like what they’ve built.
• Domain-specifiic model serialization. This is huge – previously, the domain model dictated the XML serialization format. Now, if you can customize this, you can provide a clean model syntax and even possibly read in other syntaxes as well
• Port Shapes and a revised modeling API

Update: Apparently, I can’t read. Only the VS SDK integration is done in this build. improvements to the file format and model serialization will be in the next drop.