A few months back I commented that I had gone back to using Vim as my text editor when not using Visual Studio, and to be honest, I haven't regretted that at all.

I'm not a Vim power user by any measure, but I do get around and I'm constantly learning and looking for new bits and trying to get them into my muscle memory. It's a bit hard, but it's already been very productive and I'm slowly getting the hang of it.

Now, I had used Vim before this many years ago, but I now realize that I didn't really "get" Vim at that time. Sure, I could open, edit and save files, but I wasn't really tapping into the features that make Vim so powerful as an editor.

I also realized that one of the things that was seriously keeping me form becoming a better vimmer was that having to push two completely different kinds of text editing metaphors into my finger's muscle memory (and my own memory, for that matter) was simply too hard. While I tried to learn a few Vim tricks here and there, I would always fall back to the old classic text editing used throughout windows (and, most importantly, in my primary editor: VS).

I also realized that I really didn't get the power of Vim's three modes (normal/insert/visual). In particular, I never really learned how to use Visual mode effectively.

This time, however, I set out to remedy that. After learning a bit more about Vim and getting the hang of a few things, I finally caved in and got a copy of ViEmu, after having it recommended to me by both Aaron Jensen and John Lam.

This is a fantastic tool and has made, for me, all the difference in the world. ViEmu pretty much puts a substantial piece of Vim's power as a text editor right inside Visual Studio (and it works great with VS2008, by the way). This meant that I could now seriously learn more Vim tricks and be able to take advantage of them in both my main text editors.

Having that capability makes it a lot more worthwhile and encouraging to actually spend time improving my Vim skills. I'm still not even a mediocre vimmer, but I'm now using it much more effectively. Seriously, if you want to learn Vim, and are a .NET or Visual Studio developer, you ought to take a good look at ViEmu; I can't recommend it enough.

By the way, ViEmu got a slight price increase, but even at the new price it is well worth it and more than pays for itself. The licensing model works great as well: It is licensed per-user, which means I can install my copy, for example, in my three development virtual machines.

If I spent enough time inside MS Word, I'd buy the Word version as well (fortunately, I don't!). I'm sure I've left a few ":w" inside a document or two .

Vim, ViEmu, Text Editors

Now that VS 2008 is out, think we can put support for italic fonts in the Visual Studio editor for VS 10.0? That way we won't need to depend on Damien Guard having to hack fonts to give us our italics .

Visual Studio

I've uploaded a new update to my PipelineTesting library, a tool for creating automated tests for BizTalk Server 2006 pipelines and custom pipeline components. Read more about PipelineTesting, and download the code here.

The only change on this version is that the IPipelineContext.GetEventStream() method now returns a stub implementation BAM EventStream instead of returning null as previous versions did. This makes it easier to execute pipelines that require access to BAM.

BizTalk Server, PipelineTesting

Aaron Jensen has put up a short screencast on using Vim, showing some of the tricks you can use when editing text with it; very cool stuff.

Some other Vim resources that might be interesting:

• Daniel Webb has a few short videos on Vim.
• Vim: 7 Habits for Effective Text Editing. A lecture by Vim creator Bram Moolenar. A little on the long side, but some useful things here and there.
• MacVim: I don't use a Mac, but this looks way cool (I love Vim, but it is ugly ).
• A couple of good Vim tutorials.

Vim

There's a lot of talk about Domain Specific Languages lately. The exact definition of what a DSL is, however, might change depending on who you ask. Microsoft itself tends to favor significantly Visual DSLs, that is, domain specific languages that are made of visual components (as opposed to Text-based DSLs that are made of some kind of text driven representation).

Frankly, I don't expect MS to change their direction, nor am I sure it would be the wisest decision given their target audience, but I do tend to favor text-based DSLs myself, for several reasons:

1. Text-based DSLs work best during development. We have a significant amount of experience and a rich set of tools available to deal with text in an effective fashion: Source control and comparison tools, good editors, diff'ing and merging, and so on.
2. A text-based DSL is illustrative in and of itself. Anyone with a text editor can look at it, so it only requires special tooling during execution, unlike their visual counterparts.
3. If you're spending significant time using a DSL to create new things (versus, say, simply visualizing existing stuff), then a textual DSL is usually more effective.

I should say at this point that XML-based languages don't necessarily fit this descriptions. XML can be clunky at times, and a lot of people hate having to manually crank XML to do something. For example, many people dislike manually editing NAnt or MSBuild build files.

What's not to like about Visual DSLs

Many Visual DSLs are very appealing at first to create new things when you're unfamiliar with the language, as they can be very didactic. But once you're familiar with the language, Visual DSLs, as implemented by most tooling out there, will usually get in the way instead of boosting your productivity.

Don't get me wrong; there are a lot of things to like about Visual languages. In particular, they can be great tools for visualizing things. In some cases, they are great tools to editing existing things and occasionally, even creating new things.

The last one, however, is pretty rare. I've been thinking a lot about this, and I've started to think that one of the reasons this is so is that there's a fundamental disconnect in how we usually think about Visual Languages and Tools.

The disconnect is that we tend to assume that the visual representation of the underlying domain that is best for visualizing and describing the language is actually an acceptable choice for "writing" in that language.

For example, let's consider Windows Workflow Foundation workflows or BizTalk Orchestrations. Both could be consider DSLs for building processes and workflows, and they are actually pretty effective at that. Both use a visual representation that feels more or less natural to people used to working with processes (or state machines, in the case of WF). Both of those representations are great for working with existing processes, as they allow the reader to quickly grasp the flow of it, and it even works very well when debugging a running process.

But, to be honest, both leave a lot to be desired when you're actually sitting down to create and define a new process, and both tend to get a lot in the way. I personally feel that WF is a lot worse in this respect.

XAML

I should mention that I do not consider XAML a text-based DSL (even if it is "just text"). Fundamentally, XAML is just a serialization format, and that shows in a number of places. It is build to be created and consumed by software tools, not the human developer (though it is possible to do so, as many people found out with WPF in the early days).

More importantly, these kinds of XML/XAML languages that are aimed at tools don't necessarily work great with the tooling we have for dealing with text (see the all-important point 1 above). For example, a lot of people have found the hard way that trying to do a diff or trying to merge two copies of a tool-generated XML/XAML file can be nearly impossible at times.

It's pretty evident that Microsoft is working on a lot more tools based on XAML, so that's here to stay, but it remains to be seen yet how that is going to work out. I'm sure there's going to be good Visual tooling around it, but, as usual, the problem is that it just isn't enough.

What about Oslo?

A lot of my fellow MVPs and a bunch of people that attended the recent SOA and Business Process Conference have mentioned Microsoft's Oslo initiative that was announced at the conference.

From what little I know of it, it is a far reaching initiative, touching multiple key products in the Microsoft development platform. A significant component of this effort is investment in models and, you guessed it, modeling tools around them. I think it's obvious to everyone by now that a substantial set of those tools will be built around visual DSLs and visual designer tools (that XAML's in there somewhere is probably also a safe bet). Some people will think this is a key advantage, others will probably hate it.

The one conclusion I've reached so far regarding Oslo is that will likely mean a significant shift in how we do development on the MS platform (at least for those of us involved in connected systems). However, I'm holding my thoughts on what will be good or bad about those changes until we know more precisely what the Oslo technologies will be delivering and we have a clearer picture of how we will interact with them. Also, it's clear that this is an initiative that will be gradually rolled out, so it will probably be a long transition period around it (which is both good and bad in itself).

As customers, and users of those technologies, however, we have a big opportunity, and a big responsibility in letting Microsoft know what kind of tooling we want/need to have around the modeling tools and other technologies. Like I told someone at MS recently: "I don't expect MS to shift its position on visual tooling and Visual DSLs, but I do wish the hooks and infrastructure was there for us in the community, creating our own, non-visual DSL tools around it that allow us to work more effectively with the technology". Hopefully, that little thought will not be forgotten.

DSL, Oslo, XAML