At the recent supercomputing conference in Seattle, Bill Gates gave a keynote address (transcript) where he announced that Microsoft had re-discovered its interest in scientific computing. (Microsoft’s second product was a Fortran compiler for CP/M, released in August 1977.) The motive is obviously commercial, but the statement is still significant. Microsoft has treated technical computing as a second class citizen for too long.
A couple of points I found of particular interest:
- The primary interest appears to be in smoothing out the process of scientific discovery, with a lot of emphasis on data integration (using XML, of course), transparent distributed computing, and enhanced collaboration.
- There is no mention at all of the nuts and bolts programming of numerical applications. He briefly mentions ‘visual programming,’ but that’s about it.
Improving workflow is one of Microsoft’s strengths. Scientific computing, on the other hand, is not, which probably explains Gates’ silence on the subject. Many people applauded DEC’s acquisition of Microsoft Fortran, which is now being phased out in favour of Intel Visual Fortran.
The .NET platform doesn’t exactly make it easy to write good numerical software. Even aside from the lack of support for rounding modes and standard floating-point exception mechanisms, the standard .NET languages (C# and Visual Basic) are not technical-computing friendly. There is no doubt in my mind that the .NET platform delivers a major improvement in developer productivity for general line-of-business applications.
Unfortunately, where technical computing is concerned, the productivity promise remains largely unfulfilled. It takes more than a keynote speech to win over the hearts of a community that has been ignored for so long. “Developers, developers, developers!”, Bill. Make writing numerical software for .NET a joy for developers.
What we need is a .NET language specifically targeted at technical computing. Will F# be it? Don Syme is obviously doing a lot of great work there. But functional programming for everyone?
One of the biggest issues facing developers of reusable libraries is backward compatibility. When you get to work on version 2.0 or later, you will inevitably regret some of the choices you made in the previous version. Typical issues include:
- We should have named this method XXX instead.
- This should have been a method, not a property.
- We should have put these types in their own namespace.
- We should have used an enum instead of a bool for that parameter.
Unfortunately, fixing any of these issues could break existing code. Even though you may have very good reasons to change the API, your customers won’t be happy.
I read a suggestion recently to use the Obsolete attribute to aid in the conversion. This class has a Message property that can be used to inform the user of the recommended alternative.
Now, wouldn’t it be nice if, in addition to this message, you could specify the required changes in a formal manner using attributes. With Visual Studio 2005’s refactoring support, it should then be relatively easy to write an add-in that interprets this information and performs the necessary changes for you. This would work only for relatively simple modifications. But it would still be a big help, and make the transition to compliant code a lot easier.
If this trend continues, and the number of blogs doubles every five months, then within the next four years, every person on this planet will have a blog…
With the creation of the .NET platform, Microsoft has taken the potential for developer productivity to the next level. .NET is much more than a Virtual Machine environment with an extensive class library. It is a platform for efficient programming. Here at Extreme Optimization, we have completely embraced this side of the framework.
Yet, as the comments to a recent blog entry from Brad Adams show, not everyone cares like we do. (He rightly points out that compliance with the Design Guidelines should be a requirement.)
What is surprising is that even some of the big names in component development, like Infragistics and ComponentOne, get bad marks.
Currently, Microsoft’s partnership programs for ISV’s are based solely on what the ISV is prepared to pay for the co-marketing opportunities that come with them. There is no consideration whatsoever for the quality of the products.
I believe it would be in the interest of Microsoft as well as the developer community as a whole to create some kind of “Built for .NET” logo program, with strong quality and guideline compliance requirements. This would encourage good design, and increase the effectiveness of developers across the board, giving the .NET platform a distinct advantage over its competition.
Now, software design is somewhat subjective, and the design guidelines should not be taken as absolutes. Our own libraries violate some of the guidelines, because some general assumptions simply don’t work well for numerical software. However, a core set of design rules should be mandatory (for example: require enums instead of numerical codes), while a certain number of violations of less stringent requirements would be allowed. Alternatives should be provided for violations, and the violations themselves should be marked with the Obsolete attribute. Etc., etc.
Just my 2 cents…