Serial Performance in .NET

Scott Hanselman chronicles his experiences doing timing sensitive I/O in .NET. I haven't studies it carefully, but it reminds me of some of my early Java experiences. As much as I am a fan of the higher-level programming model that Java, C#, and Ruby provide, it often breaks down for this kind of work. Then you need the ability to easily drop down to C-level.

Events and Delegates

As I've been learning C#, one of the things that has confused me is the Event construct. I understand Delegates as type-safe method pointers, and I saw Events as something related to Delegates, but I wasn't sure of the significance of the distinction. This article does a great job of explaining the difference, at least in a way that I now understand, and I had not seen elsewhere. I highly recommend it for anyone working in C# to read.

.NET Build Tools

Jeffrey Palermo has another informative article that may be helpful on my new job. This time he's talking about building .NET 2.0 projects using NAnt and MSBuild.

Winform Test Tools

I ran across this post from Jeffrey Palermo which mentions some tools for testing .NET Windows Forms (aka WinForms) applications. Since I will be working on a WinForms app, this could come in handy.

The latest tool is SharpRobo, by Vivek Singh. While Jeffrey Palermo says he wants to try using it with FIT, Vivek has a blog entry stating that he thinks FIT is too simplistic for defining tests at the UI level. He prefers using a full-strength programming language like Ruby.

Why Haskell Is Not Mainstream

Since I went from BASIC to Pascal in the late 70's, I've been fascinated by advances in computer programming languages. I don't get to follow them as closely as I would like, but I do like to see where the wind is blowing. One way I do that is by reading the Lambda The Ultimate site, which is a kind of multi-author blog with discussion forum focused on programming languages. From there, I learned about defmacro.org, which also has articles about programming languages. Although they are few in number, they are high in quality.

The latest article describes his adventures in trying to use the Haskell language to write a prototype. This is a great way to try out a new language, especially if it promises large productivity benefits, because you can quickly try out an idea in the new language, and then when you've decided on a design, translate it into your implementation language, such as Java.

Before I comment on defmacro's experiences, I want to say something about Haskell. I've run across several Haskell advocates, but I haven't run across many Haskell applications. Haskell, OCaml, and Erlang are languages that are getting some attention these days because they enable functional programming, which has advantages for maintainability, unit testing, and concurrancy. I've never tried any of these languages, but I have tried Lisp and Scheme, which also encourage a functional style, but they allow violations of pure functional programming. My understanding is that these newer languages make it easier to write in a pure functional style.

One obstacle to the adoption of these new languages is the different mindset of functional programming. I believe it is at least as big a shift as is involved in going from procedural to object-oriented programming. Also, most functional programming advocates are in the academic world, and much of their writing is not very accessable to working-class programmers. Defmacro helped this situation with Functional Programming for the Rest of Us.

However, there is another obstacle to adoption, which defmacro details. He tries to do a little bit of GUI programming in Haskell, and is unable to find a language implementation that will work. I think this is because GUIs are a low priority in the academic world. If these languages are going to see greater adoption, they need to be able to do practical things like manipulate files, implement network protocols, create GUIs, and build web applications. Not all are necessary for success. For example, Ruby is lacking in the GUI area, but it has a very good web application framework.

New Blog

I have created a new blog that combines material from this blog and my other blog that was more philosophy and theology oriented. I've moved over the posts from 2006, but not further back than that. This blog will remain for archival purposes.

Enterprise Ruby

The Rails web application framework has put the Ruby language in the spotlight. However, as some enterprise developers have looked into Rails, they find that it doesn't fit their environment very well. Rails has a focused, opinionated design which works wonderfully for programmers who are willing and able to work the "Rails way". However, there are legacy and enterprise environments that don't fit into the Rails mold.

However, the Ruby language is not as opinionated, and Martin Fowler has written a good article about the difference between the Rails philosophy, and the larger Ruby philosophy, showing that there is value to both.

Another indication of the enterprise nature of Ruby is the Enterprise Ruby Studio workshop. The stuff covered in this workshop is not as hot as Rails, but it looks like it's full of very useful techniques and tools for common enterprise tasks. I wish I could go, and I hope they put a lot of the material into a book soon.

I like an expression that I found Fowler's article, and the Studio web page, which is "Ruby is the glue that doesn't set". I think that Ruby makes it easier than some other glue languages, like Perl, to create code that has a good object-oriented design, which I believe results in code that is easier to modify and reuse.

Offensive Coding

Michael Feathers wrote an interesting article on checking for null arguments in a non-public method. Although the example that he gives is clear, it does raise the question of how defensive should our programming be where we have less control.

In a related issue, Mr. Feathers had a link in his post to an article on run-time versus compile-time type checking. This is a debate that is becoming more heated as dynamic languages such as Ruby become more popular. I'm not prepared to be dogmatic on this issue because I see good points on both sides. I guess I will be exploring the question myself since it looks like I'll be primarily working in C# and Ruby for the foreseeable future.