July 8, 2009 spout

Dynamic Languages: A Separation of Concerns

I saw Nick Muhonen give a talk on the new language features in C# 4.0 last night at the Portland-Area .NET User Group. He did a good job in spite of the constant questions I asked. He showed one example that I found especially compelling:

object GetConfig() {
  return new {
    WindowSize = new Size() { Width = 100, Height = 200 },
    ConnectionString = "...",
    ...
  };
}

Of course, you wouldn’t hard code settings in your application — you’d load them from somewhere (ideally a database, but that’s another story : ). Anyway, in C# 4.0, I can write code like this:

dynamic config = GetConfig();
mainWindow.Size = config.WindowSize;
...

Notice the use of the dynamic keyword — this means I don’t have to know the type at compile-type — I’ll check for the WindowSize property at run-time ala .NET Reflection, COM IDispatch or VB Option Explicit Off”. Of course, this is the cornerstone of all dynamic languages, e.g. Perl, Python, Ruby, etc. These languages have been gaining in popularity for the last few years and I didn’t understand why. Tim Ewald, my close friend and compadre, kept trying to explain it to me, but I’m just too slow to get it and I didn’t ’til last night watch Nick do his thing. It wasn’t looking at the code that Nick typed that made the point for me, it was looking at what he didn’t type.

When writing dynamic code, there is no requirement to define a type.

That is, when I inevitably add another property or 10 to my app config, I have to write code to use the new properties, but that’s all. I don’t have to write a class and I likely don’t have to update the save/load code either, because it’s also going to be dynamic and just expose whatever data is part of the serialized config. Or, to put it another way:

When writing dynamic code, I only have to write the part I care about.

In the case of dealing with application config, that’s about 2/3rds of the code I no longer have to write. Of course, this isn’t a new idea — Stuart Halloway has been talking about embracing essence (the code you care about) and rejecting ceremony (the code you don’t) for a long time now. It just took Nick’s concrete example for me to understand it.

And not only does this make dynamic code good for reducing the code you type, it always makes it good for the code you’re generating, e.g. COM interop assemblies, database mapping code, XML mapping code, etc. In general, I find that most of the code we have generated for us in the .NET programming environment is code to map to foreign type systems, i.e. COM, databases, XML, web services, etc. With dynamic languages, you can write that code once and just use it. In fact, in C# 4.0, there’s no need to use Primary Interop Assemblies (PIAs) anymore — those can just be mapped to a sub-class of the DynamicObject” type that .NET 4.0 ships to provide that dynamic mapping bridge.

When writing dynamic code, you don’t need generated code layers to map to foreign type systems.

This means I don’t have to do the mapping to databases per query or to XML per XSD — I can just have an implementation of DynamicObject, point it at my configuration and go — no muss, no fuss. Of course, purely dynamic languages have a construct for DO built right in, so it’s even easier.

Around the table after Nick’s talk last night, someone was complaining that with purely dynamic languages, I give up the benefits of the compiler doing static type checking (I think it was Nick : ). I argued that this was a good thing. The compiler is really just one kind of unit testing — it’s testing names. It can’t do any of the other unit testing you need done, however, so you still need unit tests. What that means is that, with static languages, you’ve got some unit tests separate from your code and some baked into the code via types, casts, etc.

When writing dynamic code, you can separate unit tests completely out of your code.

Of course, as software engineers, we already know that separating concerns leads to better, more readable and more maintainable code, which is why we’ve long separated our applications into tiers, separated our view from our data, our interfaces from our implementations, etc. Dynamic languages let us do another complete separation of concerns with regards to unit tests that static languages don’t allow. In a static language, the ceremony is required, thereby obfuscating the essence.

And all of this is great except for one question — how do I get my list of possible code to write when I type .” if I’m using a dynamic language or dynamic features of a static language ala C# 4.0?

When writing dynamic code, I don’t get Intellisense.

My name is Chris Sells and I’m an Intellisense addict. Admitting I have the problem is the first step…

July 7, 2009 oslofeaturedcontent

Part 3 of Dana’s End-to-End “Oslo” Series: Quadrant

In part 1 and part 2 of his series, Dana Kaufman, a Program Manager on the Oslo” team, used M” to model the schema for employee information and to create a domain-specific language (DSL) for creating values of that schema. In part 3, Dana shows how to navigate the schema and models in Quadrant,” the data visualization and manipulation tool of Oslo.” Enjoy!
July 6, 2009 oslofeaturedcontent

Rocky’s MCsla on the Olso May CTP

Rockford Lhotka of several C# and VB books and the world-renown CSLA .NET business object framework has ported his Oslo”-based MCsla.NET to the May 2009 CTP. For the part that he’s made work in Oslo,” Rocky has told me that the amount of code you need to write to take advantage of his framework is down by 90% over the C#/VB.NET versions, which sounds like a pretty big win to me. Enjoy!
June 29, 2009 oslo

MGraph Visualizer Plug-in for Intellipad!

MGraph Visualizer Plug-in for Intellipad!
Ceyhun Ciper is at it again, this time taking advantage of the Intellipad plug-in capabilities in the Oslo” May 2009 CTP and adding real-time M” visualization as you type. This is a wonderful way to see both the textual and graphic abstract symbol tree of your data as you type it. Keep up the good work, Ceyhun!
June 24, 2009 oslofeaturedcontent

JavaScript implementation of “M”

Matthew Wilson is pushing M” into the land of browser client-side scripting with his partial (but growing!) JavaScript implementation, as seen in his web 3-pane M” grammar mode ala Intellipad. It’s work like this that could make M” a cross-platform solution for languages as well as data types and values. Good job, Matt!
June 23, 2009 oslofeaturedcontent

Deep Fried Bytes: Shawn Wildermuth on “Oslo”

Keith and Woody speak with the first repeat guest of the podcast, Shawn Wildermuth about Oslo and the M language.  In this episode listeners will get some real world examples and use cases for using Oslo and M along with a clearer understanding about DSLs and what the future may hold.

Be warned, this podcast uses the phrase bowled shrimp.” : )

June 23, 2009 oslo

Need a visualization of “M” in your programs?

If you want to display M” languages or values, Ceyhun Ciper from sixpairs.com has got you covered with the MGraph Object Model Display Library for WPF. It’s as simple as this:

Canvas canvas = new ObjectModel().Display(
"Person {Name=>'Ciper', 47, 'sixpairs\n.com'}");

Sweet!

June 9, 2009 oslofeaturedcontent

From DSLs & Models to “Quadrant” w/ “Oslo” May CTP

Dana Kaufman, a PM on the extended Oslo” team, has been blogging a series of articles on the definition of a set of M” types, the associated M” language definition for a domain-specific language (DSL) and concluding in how that data can be visualized and manipulated in Quadrant” (the first two parts are available now and the third is coming). Enjoy!

← Newer Entries Older Entries →