Exception Rules

Scott Hanselman is working on some rules of thumb for managing exceptions in .NET, but some of these concepts will translate to other languages. The most important to me are:

• Exceptions should be exceptional.
• Don't catch exceptions you can't do anything about.
• Avoid swallowing exceptions, but if you have to swallow an exception, make sure it is well documented, and log it when it happens if possible. Evidently some code out there has performance problems because a large number of exceptions are routinely raised and silently swallowed.

Power Tools

Jeffrey Palermo is doing a series on producing software quickly. In part 3, he describes the importance of good programmer tools. It's all good stuff, but what is of most interest to me is his list of software tools that are applicable to the C# developer.

Scott Hanselman also has a very comprehensive list of tools. Categories in his list include:

• The Big Ten Life and Work-Changing Utilities
• Dropped out of the Top 10 for 2006 but still rockin' sweet
• A Developer's Life
• COM is Dead
• The Angle Bracket Tax (XML/HTML Stuff)
• Regular Expressions
• Launchers
• Stuff I Just Dig
• Low-Level Utilities
• Websites and Bookmarklets (that change the way you work)
• Tools for Bloggers
• Smart People and their Pages for Utils They Wrote
• Alt.lang
• Browser Add-Ins
• Things Windows Forgot
• Outlook AddIns and Life Organizers
• Ultimate Registry Tweaks
• Windows Explorer Integration (and other Integraty things)
• Continuous Integration
• TabletPC Indispensibles
• ASP.NET Must Haves
• Visual Studio.NET Add-Ins

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.