Every once in a while someone voices their surprise when they try out one of my Visual Studio Color Schemes and find that all those very large fonts I leave by default on most of them [1].

I've been using Damien Guard's excellent Envy Code R font, usually at 15pt size, which I'm sure looks huge on some screens. It took some time for me to get used to it, as well, but I wouldn't change it now.

 

The reason I started using large fonts when writing was readability. I've been mostly a laptop user for a number of years now, but a couple years back I started using one with a high-resolution (1920x1200) screen.

Having that much screen real state is fantastic, particularly on a large screen, but it can be a bit hard on a 15.4" laptop screen because most things will look pretty tiny. I have good eyesight, but looking at really small text for prolonged hours can really make your eyes (and your brain!) sore.

Instead of just fiddling around with the Visual Studio fonts, the ideal solution would've probably been to adjust the screen's DPI settings accordingly (120 DPI), but the truth is that, right now, that's not really an option on windows if you don't want a lot of applications to (a) look like crap or (b) become unusable because not all the controls fit into the display. Unfortunately, most Windows applications aren't really ready to work with high DPI settings and/or large system fonts, so this isn't as good an option.

However, it turns out that you don't really spend most of your time looking carefully and closely at all applications were text might be small. Instead, you spend most of your time in a few key applications, and simply increasing the font size for those can really make a difference in how you feel at the end of the day.

In my case, those applications are Visual Studio, Vim, Console and Firefox. The first three are easy to set up, and that's why most of my VS settings files include large font sizes for all the key elements (the editor and tool windows).

Tip: If you like/need large fonts in VS, increasing the font size of your tooltips can also make a big difference. This is something I used to do but always forgot to change and make sure my theme files included this setting. The screenshot above uses 11pt Tahoma for the tooltips.

Firefox is a bit harder to set up right, because changing the default fonts used can break a bunch of sites. Fortunately most of the web sites I visit regularly are very friendly to the use of Ctrl-+ to increase the font size.

The downside of using large fonts

There's obviously a downside of using large fonts when programming: You can fit less lines on a screen. Usually, the increased width of text doesn't matter much, particularly on a screen with wide format because there's so much horizontal space. Vertical space, however, is a different matter because it means you can display a lot less lines at at time.

For example, on a full screen VS session using Envy Code R, I can view 55 lines at a time at size 10pt, but only 40 at 15pt. That's 27% less lines!

It's not that I write methods with hundreds of lines, mind you. It's just that even if all your methods are short, sometimes you do have to deal with longer code files. It might be that you have classes with a lot of short methods, or maybe you're dealing with legacy code that's not so nicely factored.

Having a large screen with smallish fonts can make it a lot easier to work on these kinds of scenarios, because navigating and making certain changes/refactorings is a lot easier (even with automated tools for that). For example, one scenario were I really wish I had a larger screen is when dealing with source files that have several shorter classes defined in it (not all people are fans of the "one class per source file" convention).

The solution, of course, is to get a larger screen. For this reason, one of my goals for this year is to get a new desktop machine (after several years desktop-less) with a decent, large LCD. I'm aiming for a 24" display so that I can keep using the 1920x1200 resolution. The downside, of course, is that they are pretty expensive around here, so I still need to save some money before I can afford one alongside with a decent desktop machine.

[1] If you were also surprised about the "15pt Courier New" font; look closely and make sure you install the right font, or replace by your favorite

Programming, Fonts

I had seen the RTM announcement but no mention on when it might be in MSDN. Took a look yesterday, and it was already available, cool . At least the Datacenter/Enterprise/Standard DVD for x86 and x64, Itanium (those are still around?) and Web Server seem to be available.

I'll need to spend some time installing it on a VM to take a good look.

WinServer2k8

Jeff Atwood has an interesting piece about applications polluting the user space, forcing their own folder and file structures and other crap into the user's home folder. He's right, but I think he stops too early.

Jeff's right that the classical Unix practice is a bit better than what Windows has always provided (even on Vista). In a lot of ways, Unix is in a better position because of things that are not directly related, but that do end up helping the issue in the end, like a better (simpler!) overall file system layout, and not having to deal with drive letters (or the stupid registry, for that matter).

However, even Unix suffers from user space pollution quite a bit, though in a different way than Windows user suffer. On Unix, the issue is mostly applications storing temporary and configuration data all over the user's home folder in hidden directories.

Different Kinds of Data

There are several problems that affect how Windows and Windows Applications handle the users directory. For me, however, the lack of good, clear guidelines and the way that application developers abuse the user's home folder are secondary issues.

The real problem to me is that very few developers (or the OS providers, for that matter) realize that there's different kinds of user-specific data, each one with different requirements and storage needs.

I see at least three different kinds of data you might want to store in some user-specific location:

1. The user's own data (documents, videos, music, projects, etc.). Applications will produce and manipulate this data but they should not dictate where and how it has to be stored; that's the user's problem.

   I hate it when applications insist on forcing a specific folder structure on me or on creating their own folders in my documents folder. Exactly because of this is that I've completely given up on using the "My Documents" folder on windows; and consider it pretty much a storage for temporary or throw-away data I don't care about (too many applications putting their crap there).

   I should point out that this category, for me, is, for the most part, about data the user is explicitly aware he is creating, not about other crap the application might be producing as a side effect. In other words, if you're thinking about saving a new file without asking me for a location, don't even dream about storing it here.

   Everything in this location is stuff I want to backup easily, without having to go around excluding folders created by tyrant applications.

2. Application configuration data: This is basically your typical application user-specific settings. To me, data belonging here should be, unless something extraordinary is required, machine independent. This is the settings I simply want to take with me when I switch machines, or that I want to keep synchronized between machines to keep my applications working the same everywhere. Again, this is stuff I want to be able to backup easily without carrying extra loads of crap, but at the same time I don't want to have to deal with it (like navigate through it) unless I explicitly want to modify something here.

   I very much prefer applications store their settings in the Unix-fashion: using simple text files (whatever the format). Even though windows stores the user registry hive file inside the user's profile directory, backing it up is mostly an exercise in futility and it is non-portable for the most part.

3. Other stuff: This will be mostly temporary or cache data used by applications, that I should never have to backup or care about. If it's gone, the application should be able to recreate it as needed or simply work without it. Classical example: a browser's cache and history files.

   Some Unix applications, for example, intermingle this data with their applications settings, which is a big no-no. You don't want to have to worry about backing up your browser settings and ending up with 200MB of its cache in it.

There are probably other kinds of data I'm missing, but the key point is that they are different and should be stored separately. I really wish more application and OS developers started using something like the above discrimination. It would make our lives oh, so much simpler.

Operating Systems

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

I've been trying to learn more about functional programming in general lately, and there's a lot of good stuff around to read on it. Unfortunately for me, a lot of the content on the web on the topic uses Haskell to explain the concepts, and I find the Haskell syntax to be somewhat intrusive when trying to get a grip on the core concepts. Still, I probably should make a bigger effort in understanding Haskell .

While reading up on this topic, I ran across the Functional Javascript library, which I think is pretty cool. I'm constantly surprised just by how flexible and powerful JS is, and it's a real pity that such a great programming language has been so closely associated with the browser throughout its history. I still suck at JS programming, but that doesn't mean I can't appreciate the elegance and power some of the libraries and constructs for the language have to offer.

By the way, I've also become a great fan of programming.reddit.com; it's been a very valuable source of interesting links, blogs and articles focusing on dynamic and functional programming, among other topics.

(While on the topic of functional programming, it's good to know I wasn't the only one confused by wikipedia's entry on currying).

Functional Programming on .NET

Now that .NET 3.5 has RTM, some of the constructs in C# 3.0 make it possible to adopt a more functional style of programming on C#. Some of it was possible in C# 2.0, but the anonymous delegate syntax was still a bit too cumbersome. The new lambda syntax makes it a lot nicer, easier to read and easier to code (though because of the static typed nature of the language it can still be a bit cumbersome at times). Eric white has a lot of interesting tutorials on functional programming with C# 3.5 and LINQ on his blog, in case you haven't yet run across them.

Obviously F# is the functional programming on .NET for now, and it has tons of really good stuff, though personally I'm still trying to wrap my head around it.

I think that, overall, there's ton of good things to learn from other programming paradigms that can helpo make you a better developer even if you're writing your code in a language favoring a more traditional approach. It's certainly very valuable to understand and learn different approaches to problem-solving and incorporate them into your arsenal.

Functional programming