Rick Minerich's Development Wonderland

More Cores Requires More Abstraction, What Does This Mean For Image Processing?

RickM — Thu, 04 Dec 2008 19:47:00 GMT

Compilers and programmers are good at very different things. This is why they must come together in order to build software. The programmer has the vision and the intention, the compiler keeps track of all of the small machine related details and optimizations. Unfortunately, this is not an ideal world. At any given time a programmer will be worrying about any number of insignificant platform details while working. However, intelligent platforms that take care of many of these details are on the way and they are coming hand in hand along with functional programming and the many-core revolution.

Introduction

Recently, Steve Hawley built a Lambda expression interface on top of our existing ImageCommand infrastructure. However, he ran into a few roadblocks. The two biggest of which were performance and flexibility. It turned out that given our existing very mutable and very object oriented infrastructure, it is all but impossible to be flexible enough to implement all of our image commands as lambdas without severe performance costs. These performance costs were directly due to having to pass back and forth a great deal of semantic information about the particular changes to each pixel. I see this as a direct result of trying to graft on functional programming onto a very procedural API.

The next big programming revolution will be one of having intelligent systems deal with the details. Things like managing threads and wiring complex objects together will disappear from the lives of the average developer and will instead be left to those developing the platform those programmers are using. We will move from describing how to do things at a low level and instead use abstractions to describe what we want to be done. This is all necessary to for the production of software on the very complex and very distributed hardware platforms that are coming.

Performant Complexity Works Well in Non-Distributed Systems

Our own representation of an image is very complex. By this I mean it has a large number of properties. This is necessary because we have many customers all of which have slightly different goals. We need to be able to support anything our customers might need to do. They must be able to directly access the underlying memory that represents an image for the fastest image processing possible. This type of implementation is performant on the dual to quad core environments people are dealing with today. However, as the number of cores increase it becomes much more important for processing to distribute quickly instead of being heavily optimized for operation on a single processor.

This may sound like a really awful burden but in reality it is a huge boon to the average programmer. What it means is that we will be working at a much higher level of abstraction than we are today. Because of all of these extra cores, we will have platforms which will optimize our abstractions on the fly without us having to handle the messy details. This is much like what modern compilers and runtime environments do today, however it will be to a much greater extent.

Mathematica has been successful with an interesting approach for abstraction. Usually in the math world an image bitmap is just a integer matrix. However, In it’s most recently release Mathematica has taken the abstraction even further; unless you need deeper access, an image is just an image. This allows mathematicians and computer scientists to not worry about the underlying code, much of what is desired is inferred. It’s this kind of innovative development that will be driving the future of our programming languages.

An Inferred World

We are all moving in the direction of inferred programming. By this I mean, systems are getting intelligent enough that they can make very accurate estimations of what you want without you explicitly asking for it. They may not always be correct, but they are in the vast majority of cases and when they aren’t you can correct them. For example, F# has very intelligent and integrated type inference. I have found that it takes much of the type safety burden off of the programmer and still enforces compile time type checking. However, I believe this is just the tip of the iceberg.

Part of the reason for the shift to inference is that functional programming lends itself to this type of analysis. Similarly, if we wish for image processing to move in this direction we must change the level of abstraction we work at in order to provide an environment similarly amenable to analysis. This can be broken down into two parts: how we represent the image and how we deal with processing an image.

The first part of this would be to change how we think about storing images in memory. To do this it will be necessary to to design an image property manager which will take care of the messy details for you. In image processing, is it necessary to have a static height, width and pixel format? All of these decisions should be inferred. In a cleverly designed system these properties would be given values behind the scenes in whichever way would lose the least precision. This can be done by deferring fixing the properties of an image until output time. In other words, lazy decision making. If they are required they should be stated as constraints instead of procedures.

The second part is to change how we define our image manipulations to be in terms of transformations instead of procedures.

Transformations not Procedures

Along with inference and functional programming will come the idea of using transformations on data instead of procedures. In the Microsoft world, this is mainly evidenced by LINQ. In LINQ one describes the transformation of a data set instead of describing the steps needed to change that data.

Right now our commands for processing an image are defined by a set of ordered steps. This comes directly from the heritage of our API which sprung directly from procedural programming. If instead, we were to view image processing as a set of transformations we would do a great number of things to speed up processing.

For instance, many image processing commands can be simply represented as matrices. These matrices can then be combined into a single matrix for almost no cost. This new combined matrix can be applied once for the same result of applying each matrix that came before. In this way many different processing commands can be combined and done all at once. This is much more efficient than doing each command separately over any image of significant size.

Some types of image processing cannot be represented as a single matrix. This could be for a great number of reasons. In some cases it is because they perform a great deal of processing in order to decide on the actual transformation; processing that would be directly affected by previous transformations. In other cases the transformation is not uniform over the entire image. However, to represent them as transformations would at the very least make them easier to parallelize.

Also, this type of abstraction could have significant overhead at the single core level. However, when looking at the vastly many-core world coming, these types of optimizations could produce a result much faster than would be possible by simple procedural case handling.

Conclusion

The programming world is about to change in a way that will make it extremely difficult for even a very savvy programmer to hand optimize software. Even today an article by Michael Swaine on the Dr. Dobbs portal proclaimed that it’s time to get ready for this and learn functional programming. Instead of mourning this change, we should embrace it as it will come along with a new layer of abstraction which will, in the end, make our lives easier and our software more performant. As for image processing, it’s important to keep the ideas of inference and transformation in mind as we head into a multi-cored future. We need to focus on defining problems in a way that makes them easily parallelizable, instead of focusing on specific CPU level optimizations.

Yes, bits will be wasted, and so will overall processor time, but get over it. In a hugely parallel system, what counts is the time it takes to achieve the needed result, not the amount of work done to get there. A five fold performance decrease is a worthwhile parallelization cost when dealing with an order of magnitude increase in the number of processing cores.

Processes in .NET Part 1 – Launching Processes and Managing the Scheduler

RickM — Tue, 25 Nov 2008 19:07:00 GMT

This is the first in a series of articles relating to the management of external processes from within .NET. In my first article I will start with the basics: using the Process class to launch external processes and play with Priority and Process Affinity.

Safely Launching Processes

It has always been very simple to launch a fresh process in .NET:

Process notepadProc = System.Diagnostics.Process.Start;

Now as far as best practices go, Process.Start will throw an exception if it for any reason can’t open the file you specify. Because of this, you should always wrap your call to Start() in a try-catch block. In most cases a Win32Exception will be thrown and in order to tell what really happened you will need to inspect it’s NativeErrorCode property:

  1: const int ERROR_FILE_NOT_FOUND = 2;
  2: 
  3: string processName = "notepad.exe";
  4: Process notepadProc = null;
  5: try
  6: {
  7:     notepadProc = System.Diagnostics.Process.Start(processName);
  8: }
  9: catch (Win32Exception ex)
 10: {
 11:     if (ex.NativeErrorCode == ERROR_FILE_NOT_FOUND)
 12:     {
 13:         Console.WriteLine("Error! " + processName + " Not Found!");
 14:     }
 15:     else
 16:     {
 17:         Console.WriteLine("System level error has occured: " + ex.NativeErrorCode);
 18:     }
 19:     return;
 20: }

For more information on Win32Exception and a list of all possible NativeErrorCodes see the this very daunting list.

Changing Priority

At this point you now have a launched instance of notepad and have a handle to it’s process. Using this handle you can do almost all of the same things available to you in the Windows Task Manager. In particular it’s very easy to change a process’s priority:

notepadProc.PriorityClass = ProcessPriorityClass.AboveNormal;

It is also very easy to toggle if a Process’s priority is boosted when it has desktop focus:

notepadProc.PriorityBoostEnabled = false;

Changing Affinity

It can also be very useful to change the CPU affinity of a process. This allows you to determine which Virtual CPUs or Cores a process is allowed to run on. To do this you need to create a bit mask where each bit represents one of the processors on your system. By toggling each bit you are controlling the ability of the process or use that Core. For example, to only allow access to the first Core on the system:

notepadProc.ProcessorAffinity = new IntPtr(0x001);

Allowing access to the first two cores would require setting the first two bits of the IntPtr:

notepadProc.ProcessorAffinity = new IntPtr(0x003);

Setting CPU affinity is useful in many cases. First of all, many older pieces of software have problems on new, multi-core CPUs. Secondly, you may not want to allow a mutli-threaded process to bog down all of your cores. For more information on CPU Affinity see Edmond Woychowsky’s blog on the topic as well as Microsoft’s MSDN documentation on the property.

Doing the Same For Each Individual Thread

For a deeper level of control you can reach into a process via the Process object’s Thread property and gain direct access to a ProcessThread object for each of it’s threads. In this way, you can externally micromanage the priority and affinity of each of the threads.

foreach (ProcessThread thread in notepadProc.Threads)
{
    thread.PriorityLevel = ThreadPriorityLevel.AboveNormal;
    thread.PriorityBoostEnabled = true;
    IntPtr threadAffintiyMask = new IntPtr(0x003);
    thread.ProcessorAffinity = threadAffintiyMask;
}

Full Source

Now to bring it all together, here is a little program that will first fiddle with process priorities and thread priorities and then finally loop to display memory and thread usage information while the program is executing:

  1: using System;
  2: using System.Diagnostics;
  3: using System.ComponentModel;
  4: using System.Threading;
  5: 
  6: namespace ProcessFiddler
  7: {
  8:     class Program
  9:     {
 10:         const int ERROR_FILE_NOT_FOUND = 2;
 11: 
 12:         static void Main(string[] args)
 13:         {
 14:             string processName = "notepad.exe";
 15:             Process notepadProc = null;
 16:             try
 17:             {
 18:                 notepadProc = System.Diagnostics.Process.Start(processName);
 19:             }
 20:             catch (Win32Exception ex)
 21:             {
 22:                 if (ex.NativeErrorCode == ERROR_FILE_NOT_FOUND)
 23:                 {
 24:                     Console.WriteLine("Error! " + processName + " Not Found!");
 25:                 }
 26:                 else
 27:                 {
 28:                     Console.WriteLine("System level error has occured: " + ex.NativeErrorCode);
 29:                 }
 30:                 return;
 31:             }
 32: 
 33:             notepadProc.PriorityClass = ProcessPriorityClass.AboveNormal;
 34:             notepadProc.PriorityBoostEnabled = true;
 35: 
 36:             IntPtr affintiyMask = new IntPtr(0x003);
 37:             notepadProc.ProcessorAffinity = affintiyMask;
 38: 
 39:             foreach (ProcessThread thread in notepadProc.Threads)
 40:             {
 41:                 thread.PriorityLevel = ThreadPriorityLevel.AboveNormal;
 42:                 thread.PriorityBoostEnabled = true;
 43:                 IntPtr threadAffintiyMask = new IntPtr(0x003);
 44:                 thread.ProcessorAffinity = threadAffintiyMask;
 45:             }
 46: 
 47:             while (!notepadProc.HasExited)
 48:             {
 49:                 System.Console.WriteLine(processName + " currently has " + notepadProc.Threads.Count + " threads.");
 50:                 System.Console.WriteLine("Overall Memory Usage: " + notepadProc.WorkingSet64.ToString());
 51:                 foreach (ProcessThread thread in notepadProc.Threads)
 52:                 {
 53:                     System.Console.WriteLine( "Thread " + thread.Id + " Total Processor Time: " + thread.TotalProcessorTime ); 
 54:                 }
 55:                 Thread.Sleep(1000);
 56:             }
 57: 
 58:             System.Console.WriteLine("Process exited. Hit enter to continue.");
 59:             System.Console.Read();
 60: 
 61:         }
 62: 
 63:     }
 64: }
 65:

Conclusion

I have only just scratched the surface here on what is possible with the Process class. Almost all of the information and functionality in the Task Manager is available for quick and easy access. I encourage you to explore the MSDN documentation further. It’s also possible to interact with and control processes directly. As for that, I will be going through it in future posts.

Windows Live Writer Makes Blogging Less of a Hassle

RickM — Fri, 14 Nov 2008 19:23:00 GMT

The blog CMS we use is great in a lot of ways but it’s built in editor is really, really bad. Initially, I had used Microsoft Word to fill the gap, with disastrous results. Since then I have moved to using our blog software’s horribly antiquated text editing system but that has limited my formatting options quite considerably. Now, after a recommendation from a friend, I am giving Windows Live Writer a shot. This blog post is a recursive review of my experience writing this blog post in Windows Live Writer.

Full Featured Editing

Here is a screenshot of Windows Live Writer:

Windows live writer has everything you would expect from a html based text editor. This includes font formatting and paragraph formatting, colors, block quotes and alignment.

For comparison, this is what the Community Server 2.0 interface I have been using looks like:

It is not resizable and it has no undo between saves. Also, it has a feature set right out of the HTML 1.1 spec:

Bold, Italics, Underline, Strikeout,
Indenting and Outdenting
Linking
Pictures
Tables
What, no blink?

It lacks such basic 1990s era formatting as text size and alignment. This can make creating blog posts with any kind of real formatting really time consuming.

It’s a huge difference.

Content Made Easy

While I came for the the easy text editing interface, I stayed for the slick client-server integration and simple content management. Windows Live Writer has a number of wizards each of which take the hassle out of adding a type of content to your blog. For example, here is a screenshot of its GIS integration:

As Windows Live Writer completely manages the process for you, inserting non-text content is extremely easy. For images, you can just add them your post using the insert picture wizard and it will handle the thumbnailing, uploading and linking for you. It has native youtube and sopebox support as well as the ability to add your own local video via a wizard. As shown in the screenshot, it has out of the box integration with windows live maps for quickly inserting interactive maps into your post.

It also has a plugin interface so other types of content integration can be added. When you click on “Add a Plug-in” Windows Live Writer will actually take you to a list which currently contains 105 different live plugins. I haven't yet tried to implement my own content integration but if 105 different plugins already exist, it can’t be too difficult.

The One Downside: High Resource Demands and Sluggishness

This seems to me to be the biggest problem with Windows Live messenger:

That’s about 253 Megabytes of peak memory usage for what is essentially a text editor. Maybe it’s just that I once had a functional computer with 64 kilobytes of ram but I find this kind of memory usage from a blog editor to be absurd. That amounts to about 15% of your ram if you have 4 gigs in your box.

On my Intel Core 2 6600 @ 2.4 Ghz with 2 gigabytes of ram I have found Windows Live Writer to often be sluggish. When I click to move my cursor or highlight text it can take what seems like a whole second to respond. When typing or deleing text it sometimes will lag slightly behind my input.

Performance issues are forgivable considering that it is still a beta software package. I do hope that the development team is able to take some time to try and work through these issues.

Conclusion

Although it has some problems, Windows Live Writer is by far the easiest and most convenient blog editor I have ever had the pleasure to use. The tight client-server integration means that in the future I will be able to avoid all of the tedious resizing, uploading and pasting of html snippets and instead be able to concentrate on content. I can only hope that by the time it gets out of beta some of the memory issues and sluggishness will be worked out as otherwise this is an amazing piece of software.

I’m not the only one who thinks so. If you want to read some other opinions, you should check out a Phil Wainewright article entitled “Writer is Microsoft’s first Live Killer app” and Paul Stamatiou’s Review.

Edit: After I posted this blog I noticed that its formatting looked remarkably similar in both Internet Explorer 7 and Firefox 3.0.

Pros:

Slick looking.
Everything would expect in terms of text editing features.
Direct Community Server integration.
Conveniently manages inserted content for you.
Its output looks great in both Firefox and Internet Explorer.

Cons:

Keyboard input can be sluggish.
Huge memory footprint.
Beta software.

Much ado about nullity

RickM — Fri, 24 Oct 2008 14:07:00 GMT

I read an interesting article this morning by Reinier Zwitserloot on the topic of null subtypes in statically typed languages. The issue is that in Java and C# there are a number of different type modifiers for dealing with the concept of nullity. Because of this even a simple base type can be one of three separate somewhat incompatible subtypes.

Can be set to null, can return null.
Can be set to null, returns default value.
Can never be null.

I'm still not sure why we would want or need defaults for nullable types. It seems like a hack used to avoid null reference exceptions when they really should be happening. Perhaps we would all be better served by having all types be nullable and adding some precondition syntactic sugar for method definitions.

If we had two new features, we would be able to kick default and non-nullable types to the curb:

Syntactic sugar for null checks.

As long as the method is not being dynamically invoked, a compiler would be able to infer that the type was not supposed to be null and still throw errors at compile time. As for a dynamic invocation, there would be a type mismatch at call time in any case. There is no need for us as programmers to manage this at a type level. I understand that no one likes writing tons of NullArguementException checks but this is a problem which could be solved in many better ways.

Syntactic sugar for parameter defaults.

One of the features I miss most while working in C# is parameter defaults. However, I do understand why they decided to not add it to the language. If a parameter down the list somewhere needs to be set, so do all of it's predecessors. However, it would be possible to use a new keyword (like default) that could be placed where you wanted the default value and this issue could be avoided entirely.

It seems to me though that the reason we need defaults for nullable types is because of the lack of parameter defaults. With the current move towards dynamic types and invocation, it may be necessary to add a little bit of highly optimized reflection so that questions about the nullity of method parameters could be asked easily. However, with parameter defaults and a little bit of highly optimized reflection it would be easy to enforce nullity while avoiding all of these different base subtypes.

The Future of Programming Languages

RickM — Wed, 15 Oct 2008 14:18:00 GMT

Yesterday, my coworker Lou Franco pointed me to a fantastic talk by Anders Hejlsberg on the future of programming languages. In this talk Anders argues that the future of programming language development will be focused on three events: the explosion in the use of Dynamic Languages, the creation of many new Domain Specific Languages and the rising need for Concurrency.

In this article I'm going to focus on Dynamic Typing and Metaprogramming in particular. It's interesting to consider what the impact on the maintainability of our code from their increased prominence might be.

Dynamic vs Static Typing

Over the last decade the use of dynamic programming languages has exploded. Working at the higher level of abstraction that dynamic languages provide allows the programmer to spend much more time building things and much less time worrying about the details. For sure, when prototyping or experimenting the speed of dynamic languages is a huge boon. However, without type checking at compile time the potential for really difficult to track down bugs is huge.

Just think about the kinds of strange bugs that can happen when any type can be passed into any argument of any method. It gets even worse when you consider that these types may be silently converting themselves. Without great care, the number of potential execution paths in your program could skyrocket.

This can be offset by really strict unit testing and extremely high code coverage. However, I have yet to see a large real world project that had this level of testing.

For these reasons I find the new C# "dynamic" keyword rather worrying. It allows the programmer to declare variables which are only type checked at runtime instead of at compile time. I would hate to have to maintain a code base where it was liberally used.

Anders also mentions F#'s static but implied typing system. He talks a bit about the two worlds of static and dynamic meeting in the middle in this kind of way. I agree, this is really the best of both worlds. You gain the "dynamic feel" but get almost none of the downsides. The security of static types without all the extra typing.

Metaprogramming

I agree that Metaprogramming is a powerful tool, especially for testing. In a ecosystem designed around objects having meaning, it only makes sense to be able to ask questions about those objects and be able to dynamically manipulate how they operate. However, I am worried that it may in some cases become a substitute for well designed architecture.

Also, because of it's nature, in many cases Metaprogramming necessitates the use of strings to represent information about the application. Strings whose contents will not be checked at compile time. Because of this it is very easy to make breaking changes to an application which won't be caught when the program is compiled.

Take for example the idea of a class with a single property. In the code for the application in which that class lives, a code branch depends on reflection to check if that property exists. If you were to rename that property that path would no longer be taken and a bug would result. If the creator of that code had used an interface instead of reflection it would have broken at compile time.

Conclusion

I'm not saying that these kinds of powerful tools shouldn't exist. They are extremely useful in many cases. We just need to be very careful in their use. As Steve Hawley likes to say, when you have a shiny new hammer everything starts to look like nails.

Edit: I want to note that I had intended to include a subsection on the direct modification of abstract syntax trees but ran out of time. Also, a good friend of mine also pointed out to me that Lisp style macros actually do let you work with the underlying code in a much more meaningful way than C++ style text manipulation.

Tidying Up Old Blog Entries

RickM — Thu, 09 Oct 2008 17:41:00 GMT

Looking back it seems like complete lunacy. For a period of time my method of choice to create blog entries was to write them out in Word 2003 and then export html. The almost unreadable text has been haunting me for a long time and I've finally gone back and fixed them. Along the way I built a small utility for doing this and I thought I would share it.

It almost makes sense to me now. Our blog software features a very tempting "paste from word" button (see the paste icon with a little W?).

In order to write blogs while still getting work done it's necessary for the process to be as painless as possible. Besides that button, Word 2003 had two features that really drew me in, the ability to easily change text size and the ability to retain the color in my code samples from Visual Studio.

The problem was always that it filled my posts with strange proprietary html tags. Also, the formatting in Firefox always looked kind of off. The text would overlap just a bit. The font was also pretty terrible looking...Ok, it was just plain ugly.

I'm not the only one who suffered from these issues. Even Jeff Atwood of Coding Horror has experienced this. He wrote a little utility to clean up Word's html but it didn't work well for me. Probably because our CMS does some sort of voodoo when the "Paste from Word" button is pressed.

So in the end, with some help from Dave T the regex ninja, I was able to throw together a conversion app in C#. The goal of this app was to preserve three things while removing everything else:

The Links
The Coloring
The Text Size

It's not perfect but with 9 transforms I was able to get the documents into a state where they were easily be reformatted.

You can grab the project here if you are interested.

Avoiding the Dangers of Ambiguously Defined Data-Types

RickM — Fri, 03 Oct 2008 15:10:00 GMT

When you are handed a string, integer, or any value type, can you know what it really represents? Can you define the range of appropriate behaviors for that data? Can you tell if it's formatted correctly? The problem is, in all of these cases, you can't. You can't be sure of it's meaning, it's format or even how to treat it. This is why ambiguous types break the object-oriented programming paradigm and should be avoided whenever possible.

Forward

It's laughable to think that a Physical Engineer or Physicist would work without the aid of units. This is because, when you have undefined units, you can't verify that the thing you get at the end of a computation is defined in a consistent way.

In computing, the counterpart to the Physical Engineer is the Software Engineer. Why is the Software Engineer not held to the same type of design integrity? The use of ambiguously defined variables is one of the largest sources of bugs in modern software development and yet we ignore it. In fact, with many dynamically typed languages we are moving in the direction of more and more ambiguity.

In C# and Java, strings and value types are defined only in terms of their lexical and mathematical operations. Except from the context in which they are used, they carry no additional information about the meaning of their content. In order to perform any non-trivial operation on that data, you have to make assumptions about it's meaning, which in turn leads to bugs.

Is what you are writing really object oriented?

This may seem like a silly question to ask in the modern programming era. Almost everyone is using an object oriented language these days and its mostly taken for granted. However, as any beginning programmer knows, it is very easy to program in an object oriented programming language while completely ignoring the underlying paradigm.

We don't use OO because it's an agreed standard for implementing a programming language, we use it to solve a specific set of problems. These problems are directly related to the modeling of data and data manipulation. Groups of data subtypes are classified into a larger object and operations on that data are defined in such a way as to model behavior in terms of that classification. If the paradigm is ignored these issues become manifest as ambiguity and disorganization.

It follow that using ambiguous data-types in a public API goes directly against not only the object oriented paradigm but also the broader goal of data classification and program integrity.

Why not pass strings and value types as arguments to public methods?

Using an ambiguously defined data type instead of a well defined object means that the domain and formatting of that data is left open to question. It also means that if a user of that data formats it inappropriately it may find it's way into an operation for another type of data and cause havoc.

For a programmer that is familiar with object oriented programming it often comes down to a choice of encapsulation versus convenience. I know as well as anyone that having to define an object to carry your data when you could just pass in a string and a couple of integers can feel tedious. However, by taking the easy way out, you are setting things up to fail down the road.

Consider, is it possible that sometime in the future someone will be using the API you are defining? Will the person looking at that code know the specific format you chose for that string? What about the range of valid values for those integers? What kinds of assumptions about that data will be made that you may have not considered? If they mess up that format or get the range wrong, at what point will it become obvious?

There are a lot of advantages to using objects instead: An object which was designed to carry that same data could verify that it is well defined when it is constructed. It can hand back that data formatted or manipulated in many different ways. You can well defined questions which can be asked about that data which makes program control flow more obvious. Best of all, the code for all of these things is centralized and up to the discretion of the designer of said object. Using a well defined object, two people with different assumptions about that data but asking the same question will get the same result.

Of course, at the lowest level a CPU will be operating on basic value types and so our code will always reflect that to some degree. However, because ambiguous types are extremely dangerous, they should almost always be encapsulated and well defined.

What tools are available to me in .NET?

If you are a .NET programmer the best thing you can do right now is to become familiar with the already existing classes available for making your strings more well defined such as System.Uri and System.IO.FileInfo. I've put up a question on stackoverflow in order to try to build up a list of available container classes.

Beyond the use of predefined classes, it's best to make your own encapsulation objects with heavy up front validation. You can then use extension methods to make native .NET classes take your new validated type. It would be worth putting together a library of free encapsulation classes, structs and extension methods to allow for easy interoperability.

Beware, the .NET Framework encourages ambiguous types.

Unfortunately, as well designed as it is for many things, the .NET Framework is pretty bad about ambiguity. Based on classes such as System.IO.Path and System.IO.FileStream which for some reason take paths represented as strings, you might even say that ambiguity is encouraged. Consider the vast number of methods in .NET classes which take unencapsulated strings and scalar types.

The most unfortunate side effect of this design is that users of the .NET API may come to believe that this is the way things should be in a proper object oriented API. Also, as a consequence, if you want your own product's API to be easily understood by a .NET user you have to follow the same destructive conventions.

F# helps to solve this problem with Units of Measure.

In most object oriented languages, if you were to encapsulate every single scalar value that was passed into a method, it would be quite a lot of extra coding. Microsoft's newest programming language, F#, has a feature called Units of Measure which allows a programmer to optionally specify both meaning and behavior for classes of scalar types.

A scalar with a unit of measure is a real type which is enforced by the compiler. When an operation is performed the resulting type is that of the combined units used for the calculation, just as they would be in physics or engineering. This is because F# is designed in part to be used by engineers and scientists. As a side effect we as programmers get to reap the same benefit.

This type of scalar type classification has long been missing from object oriented languages. It's a huge step forward and I hope other programming languages move to adopt it quickly.

Addendum

@Mark and Jon:

I think I may not have fully expressed what I meant by "handed a string or integer". The context am talking about is post-compilation when variable names no longer have real meaning. In this context (discounting reflection on variable name) all you can tell about an integer is where it is coming from and it's value. An executing program does not have access to documentation.

It's also important to consider reflective programming. It is generally agreed that reflective programming is where the object oriented world is headed. However, when you have a scalar value, you can tell very little about it through reflection. While it is possible to retrieve the variable's name using reflection, actually using the name of said variable to carry type information is a methodology which is extremely prone to errors from mistyping. Errors which will not be caught at compile time and which may lead your program to incorrect paths of execution.

Also, I want to note that while a string is not a scalar value it does suffer from the same type of ambiguity. For this reason it, and other "base" types, should be handled similarly.

F# at Code Camp 10 In Waltham, MA

RickM — Fri, 19 Sep 2008 20:02:00 GMT

I'll be at New England Code Camp 10 tomorrow giving another talk about functional programming and concurrency in F#. It will be fairly similar to my previous talks in terms of ideas and content, however, I have put a lot of work into making the functional programming ideas easier to understand. The code samples have also been updated and are now 100% compatible with the F# CTP Release.

~~Our internet connection is going down soon for testing. I'll be updating this post later on tonight with more information. I'll be posting my slides and updated code examples.~~

I did manage to get my slides and new code samples uploaded on Friday but I didn't have time to change my blog text. You can find them here.

The sites of interest for my presentation:
Microsoft's F# Developer's Center ( Download F# here. )
F#'s Microsoft Research Site
hubFS: THE place for F# ( The forums here are a great resource. )

Here are some additional links you might find interesting:
Don Syme's Blog
Robert Pickering's Blog
Matthew Podwysocki's Blog
My F# Ant Colony Work

How to set up your own free VSLab-based Matlab/Mathematica replacement

RickM — Mon, 08 Sep 2008 14:48:00 GMT

VSLab has just been updated with full support for Visual Studio 2008 Shell and the F# CTP release. It has been a rough couple of weeks for the VSLab team as F# CTP changed a number of things and they have been working hard to put together a compatible release. In this article I talk about a bit about what exactly VSLab is and walk you through creating a free VSLab installation.

What is VSLab?

VSLab is a Matlab-like interactive environment which is implemented on top of Visual Studio 2008 and F#. It is designed to speed the development of scientific applications and make visualizing data quick and easy. One of the great benefits, besides being free, is that VSLab allows you to compile your applications into binaries which can be easily redistributed. Also, because the code is being run on the CLR it is, in most cases, much faster than the notoriously slow Matlab and Mathematica.

The F# CTP was updated a few days ago in order to fix a number of bugs. Even if you aren't interested in VSLab, now would be a great time to update your CTP installation.

VSLab Quick Installation Instructions

With these two releases it's very easy to create your own free Matlab-Like Visual Studio environment. It's important that these steps are performed in order as each step depends on the previous step. Installing Managed DirectX is not strictly necessary but you will not be able to use the VSLab visualizations without it.

Prerequisites
If you already have a version of Visual Studio 2008 installed, it must be updated to SP1 before you can continue. The SP1 update package is available here.
All previous versions of F# and VSLab should be uninstalled as well. I had some problems because I didn't start fresh.

1) Install Visual Studio 2008 Shell.
1a) Download Visual Studio 2008 Shell (integrated mode).
1b) Run the installer to Extract VS 2008 Shell Package to a temporary directory.
1c) Inside that directory, run vside.enu.exe to launch the actual VS2 2008 Shell installer.

2) Install F# CTP
2a) Download F# September 2008 Release Installer (InstallFSharp.msi)
2b) Run the F# September CTP Installer, the default settings work great.

3) Install VSLab
3a) Download VSLab
3b) Run the VSLab Installer, the default settings work great here too.

4) Install Managed Direct X
4a) Download the latest DirectX End-User Runtimes (August 2008)
4b) Run the installer to extract the DirectX End-User Runtimes to a temporary directory.
4c) Inside that directory, Run DXSETUP.exe to update your DirectX drivers.

You now have a complete VSLab installation.

Quick Start Information

1) First off, launch Visual Studio 2008 to get started.
2) Go to File->New->Project
3) Select Project Type: Visual F# and the VSLab Template
4) Hit Shift+Alt+V To activate the VSLab Interface
5) Right Click on your project and Click Add->New Item
6) On the left select the VSLab Category and Select the a the Viewer3D template.

Select all of the code before the calls to Close() and hit Alt-Enter to execute.

The real version is even animated.

Congratulations, you are now all set up to play with VSLab and F#.

Keys:
Shift+Alt+V: Starts The VSLab Interface
Alt-Enter: Send selected code to the F# interactive tool window

References:
The VSLab Tutorial is a great resource but has not yet been updated for the new VSLab release. Note that the key bindings have changed as mentioned above and keep an eye on the VSLab Blog for updates.

edit: fixed a link and added a picture from VSLab.

Visual Studio Shell 2008: Bringing More .NET Languages into the Visual Studio Fold

RickM — Thu, 28 Aug 2008 18:29:00 GMT

Visual Studio Shell was released in January of 2007 without much fanfare. Even though it's free to download, at the time it was not very useful for most developers as few packages had yet been written for it. Now eight months have gone by and quite a few projects are sporting free Visual Studio interfaces. In this article I discuss Visual Studio Shell itself as well as several of the languages which are currently developing shells.

About Visual Studio Shell

When Microsoft released Visual Studio Shell many non-Microsoft based .NET languages had, or were working on, their own IDEs. This was a big problem as even though there are a very large number of .NET languages, integrating them required juggling different IDEs and moving around assemblies manually. The core promise of Visual Studio Shell is simple: every .NET language can easily have a Visual Studio 2008 environment.

This means a familiar, easy to use environment for those used to working with .NET as well as access to all of the tools we are used to. And so, by building a Visual Studio Shell implementation, a language project is much more likely to see existing .NET users try it out and maybe even stick around if they like the language. At the same time Microsoft gains much more here than encouraging .NET language projects and in so doing growing the .NET platform. When a language project builds a Visual Studio shell package it automatically gains integration with all of the pay versions of Visual Studio as well. It's a big win for everyone involved.

Visual Studio Shell does much more than helping new .NET languages to integrate. It takes the whole Visual Studio environment and turns it into a platform which is easy to extend and develop tools for. With this ideal in mind Microsoft created two versions of Visual Studio Shell: Integrated mode and Isolated Mode. Integrated mode is designed to integrate new languages while Isolated mode was designed around creating external tools. The technical difference between the two versions is that integrated mode integrates with existing Visual Studio 2008 while isolated runs in it's own separate instance.

Visual Studio Shell Implementations

F#
Although only sparse documentation exists, the current F# install package has built in support for Visual Studio Shell. It includes IntelliSense, debugging and interactive mode, all for free. Even better, you can install the VSLab project on top of that and get a full interactive Matlab-like F# development environment. Tutorials and documentation are available on the VSLab CodePlex page.

IronPython
IronPython Studio is the first and generally the most well known Visual Studio Shell implementation. Version 1.0 was released in March and from all accounts is quite stable and usable. One of the coolest things about it is that it lets you use the WPF editor to build interfaces right inside your IronPython project. Being able to leverage already existing features like that is what makes Visual Studio Shell much better than custom IDE implementations.

IronRuby
A company by the name of SapphireSteel has created a visual Ruby on Rails .NET workbench called Ruby In Steel. Recently added to the Text Edition was support for Visual Studio Shell allowing it to be sold to those without Visual Studio. It is interesting to note the commercial implications here: Huw Collingbourne of SapphireSteel was quoted as saying Visual Studio Shell will finally allow them to compete with Eclipsed-based Ruby on Rails IDEs.

Nemerle
The Nemerle installer comes with Visual Studio 2005 and 2008 integration as well as a free Visual Studio 2008 Shell implementation called NemerleStudio. The only documentation on Nemerle's Visual Studio integration I could find was for Visual Studio 2005 and seems to suggest broad-ranging support for many features, including code completion and the WinForms designer. If you speak Russian and have a few extra minutes I would love to see a translation of a more recent feature list.

Boo
Boo has been traditionally known to have tight integration with SharpDevelop and so SharpDevelop is what most of the Boo developers are currently using. However, BooLangStudio Alpha 1 offers integration with Visual Studio 2008 Standard Edition (and better) via a VSIP package and is still under very active development. Hopefully BooLangStudio will soon move to Visual Studio Shell and open the door to a free Boo Visual Studio edition. If this were to happen it is likely that Boo would see a large influx of users as language oriented programming is all the rage with the academic types.

World of Warcraft?!
Over a CodePlex there is a "AddOn Studio for World of Warcraft" project. It's a Visual Studio Shell package designed for writing World of Warcraft Addons in lua. I must say, even though I don't play WoW, this looks really impressive.

References

Microsoft Visual Studio 2008 Shell (Integrated Mode) Download
Microsoft Visual Studio 2008 Shell (Isolated Mode) Download
Microsoft Visual Studio 2008 Shell Landing Page

CoDe Magazine: Introduction to the Visual Studio 2008 Shell
MSDN: Visual Studio Integration SDK Documentation

Changing Your Garbage Collector Settings on the Fly (.NET Memory Management: Part 5)

RickM — Wed, 20 Aug 2008 20:39:00 GMT

It has come to my attention via a recent DZone article that .NET 3.5 and 2.0 SP1 jointly included a new feature which lets you manipulate the way your garbage collector acts programmatically. This can be done through changing the value of a new property of the System.Runtime.GCSettings class named LatencyMode. In this article I will walk you through this new property and the different effects of each of it's possible settings.

Other Articles in This Series

Part 1 – Basic Housekeeping
Part 2 – Improving Performance Through Stack Allocation
Part 3 – Increasing the Size of your Stack
Part 4 – Choosing the Right Garbage Collector Settings
Part 5 – Changing Your Garbage Collector Settings on the Fly

LatencyMode

The new LatencyMode property accepts three different enumerated values. The first two of which are Batch and Interactive which correspond to turning <gcConcurrent> on and off inside of your application configuration. However, the effects of the third value, which is named LowLatency, were previously unavailable by any means. By setting this the LatencyMode to LowLatency you can now put the Garbage Collector in an ultra-conservative mode which will insure the application will be interrupted as infrequently as possible.

There are a couple of things you should take note of before changing your Garbage Collector's LatencyMode:

LatencyMode settings are process-wide and so all of the threads in your application will be effected.
Changing LatencyMode will have no effect if your application has <gcServer> mode set in its configuration file.

Now, let’s explore each of the possible values of LatencyMode in detail:

Batch

When it’s useful:
It’s useful in applications without a UI and in Server Based Software. It may also be useful to switch your garbage collector into Batch latency mode if your application has a data crunching mode which occurs after a user interface.

What it does:
This is the most intrusive setting. Garbage Collection is done non-concurrently in one big batch call. Your program will be suspended while garbage collection takes place.

Defaults:
This is the default value when <gcConcurrent> is disabled.

Notes:
Even though this will be the enumeration which will be set if <gcServer> is enabled, the garbage collector will act as described in my previous article. In fact, if you have your application defined to be in <gcServer> mode the LatencyMode property cannot be changed from its default of “Batch”.

Interactive

When it’s useful:
It’s the best mode for most any UI-based application.

What it does:
This is the most balanced setting. Garbage Collection happens concurrently with your application. Most of the work is done in a separate thread and although your application will be suspended it will not happen very often and for only very short periods of time.

Defaults:
This is the default value for garbage collection on workstations. If <gcConcurrent> is left at its default value, this is the type of garbage collection that will occur.

LowLatency

When it’s useful:
It’s useful for time sensitive applications such as 3d rendering or data acquisition.

What it does:
This is the least intrusive mode the Garbage Collector can be set to. As in Interactive, garbage collections happen concurrently with your application. However, collection of older objects will only happen when memory pressure becomes high. Collection of generation 2 objects is kept to a bare minimum.

Defaults:
This is never the default setting.

Notes:
LowLatency mode was designed for short time use only during time-critical sections of your application. Leaving an application in LowLatency mode for an extended period of time will cause unused objects accumulate. Before using low latency mode, you should take a look at the guidelines laid out at the bottom of the MSDN Latency Modes page.

References
MSDN Visual Studio 2008 Developer Center – Latency Modes
MSDN .NET Framework Developer Center – GCLatencyMode Enumeration
DZone - Low-Latency GC in .NET 3.5

More F# At Code Camp Hartford

RickM — Sat, 16 Aug 2008 18:03:00 GMT

I am down in Bloomfield, CT today at Hartford CodeCamp which has been put on by the Connecticut .NET Developer's Group . I just gave a very similar version my talk on the 5th. The room was completely full and I was a bit weak and foggy from my recent...(read more)

Talkin Bout' F# - Presenting at the Western Mass .NET Users's Group

RickM — Tue, 05 Aug 2008 13:36:00 GMT

I'm going to be giving a presentation at the my local .NET User's group tonight. The goal of my talk will be to expose the audience to F# as well as some Functional Programming Ideas. Here's a basic rundown of what the talk is about (in order): - What...(read more)

IPCV 08' Part 2 - Novel Approaches

RickM — Thu, 17 Jul 2008 17:15:00 GMT

I've managed to rig up Steve's cell to my laptop and I once again have Internet Access. From the time of my last post, most of the talks have been about applications of machine learning. This usually involves a neural network, PCA (Principle Component...(read more)

IPCV 08' - Day One Through One Point Five Rundown

RickM — Tue, 15 Jul 2008 18:03:00 GMT

As you might have seen in Steve's Blog , we ended up getting stranded in Milwaukee overnight and missed most of the keynotes. We did manage to catch the last one which was on a company called Element CXI's very interesting reconfigurable hardware model....(read more)