Rick Minerich's Development Wonderland : technology

Code Camp 12: Boston – Why F#?

RickM — Fri, 16 Oct 2009 15:18:54 GMT

A couple of months ago I was talking to Lou Franco, the head of our Software Engineering department and fellow functional programming enthusiast, about the possibility of using F# for projects in the future. Being business minded, he replied that he would need a compelling reason to bring F# on board. This presentation is dedicated to him and others who have functional programming on their radar but haven’t yet found a compelling reason to bring it in to their company.

I acknowledge that, as for now, it’s difficult to suggest anyone do more than play with F#. I have been anxiously awaiting the stabilization of the F# API which will come along with the release of VS2010. With the recent changes breaking backwards compatibility, maintaining my old F# samples has become quite a nightmare. Indeed, not a single code sample I have from a year ago works out of the box with the current release.

However, VS2010 is only a few months away. Now is the time to start learning about F# and the paradigms which make it so powerful. Functional programming has amazing benefits in terms of parallelization, code compression and overall code robustness.

At Code Camp 12 Boston, I will talk about the soon-to-be-realized world where programmers are divided into groups which each use different types of languages to build different kinds of things. This is easy to predict as it is already occurring. UI, data processing and data storage programmers are already diversifying both in working knowledge and tools.

As is evidenced by WPF, HTML and CSS it seems UI design is moving more and more to a declarative style. Similarly, the rise of F#, Scala, Erlang and Haskell indicates that algorithmic programmers are migrating to the functional programming languages. SQL has long been the language of those involved in data storage. It’s no wonder that this has happened. When your tool is better designed for your job, the work gets done faster and you end up with a better result.

Where does this leave imperative and object oriented languages? Languages like Java, VB and C# will be relegated to being used as “glue” for existing systems while abstract languages slowly eat away their market share. This will happen more and more as the number of cores per processor continues to increase and those with imperative implementations find that they are unable to scale.

When: Oct 16th, 2009 (11:50am)
Where: 201 Jones Rd, 6th Floor, Waltham MA USA (Room TBC)

Slides are available here.

Also, be sure to also check out my fellow F# User Group leader Talbott Crowell’s talk. It’s right before mine (10:30) in the same room (Thanks Chris!). You can find out more by heading over to Chris Bowen’s blog and reading his post on Code Camp 12.

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.

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.

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.

The Cursed History of Smalltalk in .NET

RickM — Wed, 18 Jun 2008 20:44:00 GMT

After my last blog post, due to some of the responses, I decided to spend some time with Smalltalk. As a DotNET developer by trade, I wanted to see what kinds of options were available for use on the CLR. Unfortunately, out of the five different DotNET...(read more)

20 Years Later IRC is Still Useful; Are You Taking Advantage of it?

RickM — Fri, 30 May 2008 18:23:00 GMT

This upcoming August the IRC protocol will officially be 20 years old. I think anyone would agree that it has weathered the years better than any other high level internet protocol. It does not suffer from the spam and abuse that have overtaken other...(read more)