Scott Hanselman's ComputerZen.com

Lots of good debate and discussion on the Myth of .NET Purity from a number of very nice people as well as some nice links and comment threads.

Some people were a little taken aback and invoked Rotor and Mono to illustrate the importance of Purity and Code Portability.  I replied in a few comments posts, but re-print my position here:

One fellow agreed and said "If you want to do cool stuff the vise gets a bit tighter."

Another fellow mentioned the JVM and the CLI to which I responded: Note that you started using "CLI" in your sentence, rather than the ".NET Framework" or the "CLR." Certainly the CLI (common language infrastructure) as a concept is great and is obviously portable, having been ported as Mono and Rotor. But I'm not talking about the CLI. Rather, we should remember the underneath any layer of abstraction (leaky or not) there is an implementation. The point of my article was to remind folks that the Microsoft Windows implementation - the CLR and .NET BCL (base class library) - depend HEAVILY on the underlying behavior, libraries and services of the Windows OS. Code Portability (certainly desirable for some, less so for others) is certainly possible at the C# and IL level, but writing cross CLI implementation C# is no different than writing cross platform "C." Think about that. When writing cross platform code (often confused with 100% whatever, and there's a difference!) one has to consider: compiler behavior, interfaces, the OSs underlying implementation of the API, the level at which the API was written, etc.

One surely can't expect a very complex C# Winforms app with all the fancy GDI+ goodness and user controls to just work on Mono (unless I'm missing something) - not until the underlying implementation of ALL the dependancies are written and implementing using whatever Linux OS primitives are required to provide these features.

My rant was originally prompted by a fellow who was saying that he was writing some WinForms to ASP.NET Web Services app and that he was writing it in "100% Pure .NET" to INSULATE HIMSELF FROM RISK in some way. Like he'd be protected and have code portabilty if he just made sure to do it all in .NET. And that is a Myth. Code and life are a lot more complex than a sound bite like "100% .NET." - Scott Hanselman

I'm confirmed to speak at TechEd 2003 in Dallas in June.  I'm going to give a mid-level talk about XML Web Services with WSDL as the fulcrum.  I'll talk about the need for a contractual agreement to exist between business entities and computers.  I'll walk up the conceptual stack, transport, syntax/structure, semanetics via rich types, business messages, and end points described with WSDL. I'll do a lot of sniffing and looking at SOAP on the wire, and explore proxy generation with XSD.exe and WSDL.exe.  Probably I'll spend a lot of time at the command-line and jumping between 4 or 5 different tools that AREN'T Visual Studio.  It's nice to point out at towards the end of the talk that we have been moving seemlessly between XML tools (many not from Microsoft), creating, editing, generating schemas, making WSDL, generating proxy code.  It's a nice reminder to the people in the audience who STILL haven't used Web Services that there ARE standards around this stuff!  And while all standards evolve, in this case the wire protocol is transparent.

As promised earlier I've posted a personal rant on The Myth of .NET Purity, that I submit for your perusal.

For a long time, I've wondered why Google can search the whole freak'n internet in < 1 second, but it takes Windows minutes to search my little hard drive.  Scott has me thinking, what good are folders?  Actually, folders are great, but what good is a massive hierarchy of folders that all roll up under a common root?  Does anyone really want to find anything by starting at C:?  If you had Google for your computer, would you use anything else?  Maybe in a future version of Windows, the desktop should just be a search form.  Woogle, anyone? [Early Adopter Weblog]

Preach on my brothers!  I need to write a .NET application that lets me exploit the Indexing Service...We all have Google on our desktops...it's right here and has been for years - the Indexing Service Query Form in the MMC.  It's just not friendly and Explorer appears not to care.  What IS the sordid relationship between the Indexing Service (that obstensibly gets turned on by the Explorer Search but never used!) and the Shell? 

Application Programming Interfaces (APIs) should be designed with their specific audience in mind.  Some APIs are meant to be used by low-level developers for creation of infrastructure code; other APIs are to be used by high-level developers in the creation of user interface or workflow code.  Most APIs rely on the ambient language to provide strong typing and 'link' themselves to the function signatures.

MyFooFunc(string, int, int, DateTime, bool)

I divide interfaces into three classes and I've started using these terms when I present on architecture and design: 1st Class, 2nd Class and 3rd Class Interfaces.  In naming these interfaces 1st through 3rd I do not aim to make a qualitative value judgment, only to correctly describe the level of fidelity the interface provides.  Sometimes when a API is created as a front-end to some large mysterious 'blackbox' and that box is to be used in a language or platform agnostic way, the blackbox defines a syntax of its own.  For example, SQL Server is a large black box whose vast power can be exploited via a single method: Execute(string). The real power lies in what "string" contains, in this case, T-SQL.  Regardless of what language you choose to call Execute(), a lot of work (read: magic) will happen as a result of the SQL. 

For Example: In COM, when someone writes Dim x as new Foo, someone calls CoCreateInstance(foo), a 3rd class API, someone has to call LoadLibrary(foofilename.dll), also a 3rd class API.  This is an example of layering lower classes of APIs to present a 1st class API to the higher level developer.

Examples

3rd Class

Command.Execute("INSERT INTO employee (emp_no, fname, lname, officeno) VALUES (3022, 'John', 'Smith', 2101)")

2nd Class

Employees.Insert(3002, "John", "Smith", 2101);

1st Class

Employees.Add(objJohnSmith);

3rd Class Interfaces are usually limited to a core infrastructure functions or ".Executes" that are like procedure calls within a string.  Notable examples include Database APIs that expose an Execute method that takes a string of T-SQL as a parameter.  It is within that T-SQL command that the programmers’ intention is expressed. 

Overwhelmingly, 1st and 2nd Class APIs are built on top of 3rd Class Interfaces.  2nd Class Interfaces often “hang” off of a larger controller object or domain object.  There is also some use of Domain Objects, primarily as complex-type or "rich" parameters to the Controller. 

1st Class Interfaces are typically found in object oriented or command/message oriented designs. These are meant to describe the programmers’ intent using business objects that fall into a specific business domain.  Objects representing high level logical constructs act upon other objects.

Question of the day:

When creating APIs, particularly for use by developers in business verticals who wire up complex processes, what is the right balance between type-rich function signatures (n parameters) and type-rich internal messages (n simple types within a complex type)?

This whole rant will get me into another rant coming in a few days on "The Myth of .NET Purity"...