Frans Bouma posted an entry about Oslo’s M, and if I’m reading it right, he is highly skeptical about it actually making creating Domain Specific Languages (DSLs) any easier.

In part, Frans has a point. Yes, it is true that writing a good, complex language is hard. Yes, there’s a bunch of compiling-writing stuff that isn’t exactly trivial. And yet, this isn’t necessarily the point.

There are a couple of places where I don’t fully agree with Frans:

Yes, writing a complex, full featured language is hard. But writing a simplified grammar can get you a long way towards simplifying certain class of problems, and I do think there’s a lot you could do if the right tools where there for you. Because, let’s face it, most compiler writing tools suck.

The second part is that while Frans talks about M in general, in reality he’s only referring to a single part of it: MGrammar. There’s a lot more to M than just writing DSLs, and I thought it was important to bring this up.

The third and final part is that, well, it’s not clear if Frans has actually tried to use the M stuff. I’ve been playing a bit with MGrammar since the PDC and I have definitely been very impressed so far with how much you can do even without knowing much about writing compilers or formal grammars.

The way that MGrammar grammar’s (pardon the redundancy!) are writing is actually fairly intuitive most of the time, and the built-in conflict resolution rules actually seem to work well in the samples I’ve tried so far. So in that sense it is definitely a lot nicer than many compiler writing tools.

I also liked very much liked how you separate the parsing aspects of things (i.e. defining the grammar) and how actually doing something with the parsed stuff is a secondary step (and one you can actually tackle after that if you want). It’s very clean and works well in many cases. It also means that MGrammar is easy to use if you only want to parse some [unstructured] data and do something with it; and not necessarily “execute it”.

And finally, there are a couple of hidden gems that I thought can really make a difference once all the tooling is there. For example, I love how you can annotate your grammar to be case-insensitive with a simple attribute:

Or even annotate token definitions with colorization information that Intellipad picks up and uses right away:

In short, I agree with Frans that if you’re looking into creating a full, complex language, then yes, MGrammar by itself won’t make much of a difference. But I do think it shows a lot of promises for the slightly lower-hanging fruit of many simpler DSLs by making it easier to get started writing the grammar and seeing it work right away.

I’ve started playing with the Oslo bits a little, and I thought I’d share a couple of thoughts on the platform and its tools:

M – The Language

M is an interesting beast, but to me the most interesting part of the platform to start with. In particular, I’m looking forward to playing with the MGrammar stuff.

I’m not thrilled about the close relationship between M (and its tooling) to SQL, though. In particular, I really think that Don Box and friends really need to find a better example to introduce Models and M; it was painfully obvious (at least to me) during the M language talk that many people just weren’t getting it.

Intellipad

IPad is an interesting tool. It has some useful features for developing M models in the M Mode and MGrammar modes; there’s some good stuff on this on the Intellipad Team Blog. Right now, I’d expect IPad to continue being an important tool in the M developer’s toolkit.

However, what I have not seen really is good justification about why we needed a new text editor. I get the emacs.net analogy, but I have yet to see how creating it was a better option than adding functionality to Visual Studio, where is where most developers would expect to find that functionality (yes, I’m very well aware of the irony regarding how bloated VS already is).

Look and Feel

One thing that really caught my eye was the look and feel of the Oslo/CSD tools: It’s very minimalistic, and can be seen in the WF 4.0 Workflow designer, Quadrant and Intellipad. I actually find it rather appealing (though a bit weird at times), but I don’t expect this state to last; too clean for MS .

As many have already heard or read, today Microsoft unveiled the Windows Azure Cloud Computing Platform. Besides allowing you to host your own applications, Azure also provides a Blob storage service, a Queue Service and a Table service exposed over REST-based HTTP endpoints.

Azuli is my attempt to write a client library for these services in Ruby. Since it’s one of my first attempts at any meaningful ruby code, it’s pretty ugly, but already usable to get started with it.

Currently there’s no documentation (except a few tests), but it already has the authentication bits in place for using the default Shared-Key authentication, and some basic facilities for interacting with the Blob service: You can create/list/delete containers, /create/retrieve/delete blobs.

I’ll be adding support for the Queue service soon and eventually for the Table service. Any feedback (particularly of the constructive kind) would be appreciated.

Code is at GitHub, so feel free to play with it, hack at it or whatever you want.

In the latest entry in the official PowerShell Blog, Jeffrey Snover leaves a little tidbit about a change coming on the next CTP of PowerShell V2:

The cmdlet keyword is going away and we'll just have function. Notice that now you can specify the [Parameter()] attribute on parameters.  When you do that, we treat the function like a cmdlet.

I don’t mind getting rid of the cmdlet keyword; honestly, but is the new syntax that much of an improvement? So now instead of an explicit keyword telling you whether something is a function of a cmdlet, you have an attribute spilled around the function parameters? Not sure if that’s good or not, but sounds confusing to me, at first glance.

Maybe what rubs me the wrong way, however, is the [Parameter] attribute. I’m OK with using an attribute to specify the metadata associated with the parameters, honestly. But the whole Param + [Parameter] thing just reads redundant and ugly:

Can anyone more familiar with this chime in? Am I the only one slightly bothered by this?

Back in the good old days I spent far more time writing C++ code than other things (well, there was no C# back then!). In those days, the initial support for 64-bit compilation was added to the Platform SDK (now the Windows SDK… again!).

At that time I couldn’t even dream of getting access to a 64-bit machine, and only very recently was able to get one. However, I still thought that learning to write portable 32/64-bit code the way the SDK prescribed was a good idea and so got used to it a bit.

It wasn’t actually all that hard. A big chunk of it was just being careful about integral/pointer conversions, using the new SDK data types like INT_PTR, ULONG_PTR and friends, and being wary of memory alignment issues. Just that would take you a long way on the right path. It was particularly easy when you were starting from scratch.

Since I do a lot less C++ these days, I had put a lot of that knowledge in the back of my head. Recently, however, I started looking into making some initial changes to an existing C++ code base to start cleaning up stuff for porting to 64-bits.

On the plus side, the Visual C++ compiler gives you a lot of really good warnings on problematic spots, either by actually compiling with the 64-bit compiler or by using the old /Wp64 switch on the regular 32-bit one (though the switch is deprecated now). Documentation on the Windows SDK about 64-bit porting issues is also fairly good.

On the negative side, it can still be a bit of a drag; it’s a lot more challenging to modify an existing, complex code base than starting writing portable code from scratch. Still, it’s been an interesting experience .

One of my development Virtual Machines has Visual Studio 2008 installed with SP1. For several reasons, I had not done a complete installation originally, but only certain pieces of it, like Visual C# and Visual Web Developer and some of the Team Developer tools.

A couple days ago turned out that it would’ve been really nice to also have Visual C++ install as well. I figured I could probably install the missing pieces and then apply SP1 again.

When I tried to do this, however, ran into a snag: I fired up the Visual Studio 2008 setup again, went into Add/Remove components and then, when the setup was initializing, I got an error to the effect that some components could not be loaded, and installation would cancel.

After trying a few times I gave up, started an older copy of the VM I had without SP1 installed and so was able to work around it after all, but still, I’m a bit curious. Has anyone else seen this? Is setup just foobar’ed after the installation of SP1?

After a few years, people still ask about my old FileMap library, a .NET wrapper for the Memory Mapped Files Win32 API, and I get occasional bug reports about it. It’s hard to believe I wrote the original code over 5 years ago!

Anyway, I’ve now cleaned up the code (alongside some of those fixes), and posted it to a GitHub repository as well. I’ve now updated the code to Visual Studio 2008 and cleaned up the unit tests.

I’ve been working on organizing the code for my old custom Symmetric Encryption Pipeline Components for BizTalk Server 2006 and I’ve posted the updated code on a new GitHub repository. Be aware that I renamed things a little bit and cleaned other parts of the code.

The code includes both the encryption and decryption component, some basic tests using PipelineTesting, and the Windows Forms Configuration Utility that stores the crypto keys used by the components in a custom Configuration Application in Enterprise Single Sign-On.