Productivity and Functional Programming
I just started using NUnit(prompted by a recommendation from Tristan at least a year ago). NUnit is a framework for writing and running test cases during development. At Microsoft, like most other places writing software, developers create and run their own “unit tests” (or sometimes called DRT, or “developer-run tests” internally) at the same time as developing the code. When each dev checks in her code, she runs her own DRTs. Then when the daily builds happen, there is another set of tests which are run to make sure that people didn’t break each other (called BVTs, or “build verification tests”). And of course a whole series of tests beyond that which are done by the testing team. I’m not aware of anyone internally using NUnit for DRTs, but that’s probably because we have a huge infrastructure of tools already in place for testing. I really like NUnit for the sort of things I do, though. NUnit started as a port of the Java-based framework called JUnit, but takes advantage of Reflection and other nice .NET features to make it really simple to integrate testing with the IDE projects. It’s basically just a test driver, though. The code-covergage extensions that were available for JUnit don’t seem to have been ported. Also nice is FXCop.
I have alsobeen playing recently with functional programming. There are a number of functional programming devotees inside of Microsoft, but the buzz is spreading to the pragmatists I think. In “Why Functional Programming Matters“, John Hughes positioned functional programming as an ideal “glue” for tying software components together. Mondrian was the first programming language I saw which was designed to be a functional “glue” with .NET components in mind. Since .NET componenets can be written in many different languages, and since CLR expressly tries to eliminate the hard workof cross-language callingit would seem that the ecosystem of reusable software components will flourish, and programmers can now focus on functional glue rather than tedious implementation details like marshalling and IDL. Of course, no sane development shop would use multiple languages gratuitously in a project, but the point of CLR is to free the shops from having to use the same language that their component library vendors use, etc.
Mondrian is a very simple language, and the one(of the “functional” languages on .NET)I have used most frequently. It is based on Haskell (I think). Mondrian mixes some imperative concepts with functional, similar to F#. F# is basically a port of Caml to .NET. On the other hand, SML.NET was just recently released, and is pure, unpolluted, functional (it implements Standard ML). I feel that SML.NET is more complex the Mondrian, but I am planning to use it for awhile and decide then.
All of these implementations of functional programming languages ran into similar issues with the CLR. One of the most important is that functional languages depend on polymorphic functions. Based in large part on feedback from the functional implementations, the CLR team has started implementing “generics” as part of the runtime. Another challenge comes from integrating functional programming with object oriented software componentswithout sacrificing the purity of the functional language. Mondrian and F# decided to go ahead and pollute the language a bit to permit eaier reuse of other people’s components. Personally,I thinkthat such hybrid languages will be the only way to be successful in providing functional “glue”, but maybe I’ll change my opinion after playing more with SML.NET. Also, it seems like polymorphic functions are a primary reason that John Hughes was recommending functional programming be used as glue. Therefore, when the CLR supports generics (and a few other cool enhancements that are planned), the normal .NET languages will be able to behave in a more “functional” manner, and I think the appeal of distinct functional languages as glue (the mainreason for the buzz right now, IMO)will be less.