Countering an Apple-favoring .NET critic
I've made a few noises about my recent interest in learning more about about Mac development, and not all of them have been positive. That was sure to rub the true believers the wrong way, for whom my generally positive comments regarding the user interface and hardware design aspects of an Apple computer were simply not enough (heretical beliefs of any kind are simply not welcome in the church of Apple).
In response to some of those comments, long-time reader and president of my fan club, Richard Flude, pointed me towards a three-part series of articles written by Peter Bright, a programmer in the UK who declares he is leaving the world of Windows programming behind, devoting himself to exclusive (or nearly so) Mac development.
Some of his criticisms of the Windows development APIs are on the mark, if you accept some of the underlying premises. The organization of APIs loosely grouped under the moniker WIN32 can seem like a document written by hundreds of people none of whom speak the same language. The API cacophany can be confusing at the WIN32 level, a fact exacerbated by Microsoft's emphasis on maintaining backwards compatibility. The fact that WIN32 has evolved upwards from WIN16 has left a legacy of APIs with arguments that seem somwhat martian, and that process has continued into 64-bit computing.
As a random example gleaned from Bright's article, when Microsoft shifted from WIN16 to WIN32, they made a new folder under the Windows directory (named System32) to house all the new 32-bit versions of dlls. In the shift to WIN64, 64-bit dlls are dumped into the same System32 folder so as not to confuse programs that have naively chosen to assume that all system dlls appear in a directory titled System32 (which, consequently, I have never done; why would you need to assume the location of System32, unless you are putting your own dlls in that directory, which to my mind, should qualify the developer for rotten tomatos and the stockade).
First, backwards compatibility is not usually considered a bad thing from the standpoint of companies and developers who make programs for Windows. I would argue that part of the reason that Microsoft managed to maintain such a market share difference vis a vis Apple for as long as it did was that Microsoft has avoided invalidating the investment of its much larger group of customers than Apple has over the years.
Granted, there are advantages to wiping the slate clean, but keeping older APIs around to support legacy applications is only a problem if it constrains future developments. There is an argument to be made that this has been somewhat the case in the Windows platform, but Mr. Bright doesn't really make it. Yes, it's weird that file lengths longer than 32 bits must be retrieved in two 32-bit chunks (albeit through one GetFileSizeEx calls), but that hardly constitutes a barrier to higher level APIs or the advancement of the platform.
More to the point, however, the problem in WIN32 is only an issue if you accept the premise that programmers who are writing programs that compile down to native code (versus programmers using a more modern API, such as Java or .NET) should be using low-level WIN32 APIs as a matter of course. In my opinion, that is nonsense. Few programmers would write a windowed program using low-level WIN32 calls anymore unless they have a fetish for writing WNDPROCs, and stacks of APIs exist that are designed to provide a proper object-oriented framework for Windows development, both from Microsoft and third parties. Trolltech has a rather clean API in the form of Qt, and what's more, the resulting application runs on a number of platforms...including Mr. Bright's new favorite, the Mac OS.
For that matter, if you are doing things the way Microsoft intends, you are writing programs using .NET, an API that does away with the inconsistency that typifies the low-level APIs and enables the programmer (with one notable exception, explained later) to avoid the low-level ideosyncracies of WIN32.
I was thinking of .NET when I said, in my most recent blog post, that programming to the Cocoa APIs feels like stepping back in time about 10 years. It is also here that Peter Bright's desire to counter the positives of .NET (which is necessary, as Apple has nothing like it) drives his arguments off the rails.
After a few hesitant broadsides which damned .NET with faint praise (.NET is technically "fine," C# is "adequate"), The real criticism starts with this line in part two of his three-part series:
The library is extremely bad. It is simplistic and inflexible and in many ways quite limited.
This is what one might consider a thesis statement, to be followed by details as to why .NET is "bad" and / or "simplistic and inflexible." At least, that is what one would expect if the author had details with which to back up those claims. Since he doesn't (at least, not in this series of articles), he must start into what I can best describe as a stealth "ad hominem" attack whose intent is to obscure the lack of such details.
Feel free to read the flow of his argument yourself, but I will summarize the gist here for the sake of continuing the flow in my own post:
- .NET was designed for enterprise developers
- Enterprise developers are monkeys
- Ergo, .NET was designed for monkeys.
Mr. Bright followed his rather bold claim not with details as to the inadequacies of .NET, but with a long explanation of how .NET was supposedly targeted primarily at "middle of the road" programmers with poor development skills (who, in Peter Bright's words, don't "know any better.") The problem with that line of attack is a) it's not true, and b) it has absolutely nothing to do with the quality (or lack thereof) of the .NET API. How, exactly, is .NET "bad" or "simplistic and inflexible?" No details are provided. In my PERSONAL opinion as someone who spends most of his time programming with .NET (backed up by long experience in both C++ and Java), the only way someone could conclude that .NET is inflexible is if they don't know .NET very well, which may be the case here, as its pretty clear that Mr. Bright vastly prefers doing native code development.
The smokescreen includes a few carrots by which to draw readers down the path. He speaks of a "third category" of developers (for whom .NET was supposedly not written, but again, no evidence of that) as the "conscientious" ones who only rarely do something so greasy as enterprise development and whose best work occurs when they are sitting at home in their office hacking away code in their free time. Who doesn't want to be in that category? Aren't you glad you are an alpha in an Aldous Huxley-inspired "Brave New World" of programming and not one of those betas and gammas running the elevators and cleaning up the enterprise bathrooms?
The second part of his attack consists of the claim that .NET allows a lot of its WIN32 underpinnings to show through, though the only example he provides is WinForms. I think that's telling, as it may be an indicator as to the type of application he has built with .NET, and thus, the basis of his opinion of the framework (ASP.NET, Microsoft's API for web development, can't be accused of being WIN32-oriented, and I would bet a lot more programmers use that API over WinForms in any given day).
The first problem with using WinForms as the stick by which to beat .NET is that WinForms was explicitly designed as a .NET wrapper around the low-level (and antiquated) Windows UI controls. Blaming WinForms for reflecting design decisions in WIN32 / GDI land is like blaming an XMPP / Jabber API for reflecting design decisions in the XMPP / Jabber world. Of course it does...because that's the point of the API.
This leads right into the second problem with using WinForms as a point of critique, which is that WinForms isn't the only API with which to write desktop user interfaces in .NET, and isn't even the best one on offer from the company who designed WinForms in the first place. Mono is an open source alternative to the .NET Framework, and they emphasize use of GTK#. GTK# was not designed as a thin layer around WIN32, and thus, doesn't reflect any of those design decisions.
More importantly, WinForms is not the most current API Microsoft has released for UI development. That honor goes to the Windows Presentation Framework, a component of .NET 3.0 that was released in November, 2006.
That, I think, consitutes the single most glaring oversight in Peter's article. The article related to .NET appeared in May of 2008, and somehow, he manages to completely avoid any mention of .NET 3.0, never mind .NET 3.5. I think you'd be hard pressed to find legacies of WIN32 in any aspect of .NET 3.0, particularly given that a subset of WPF serves as the foundation for Silverlight, Microsoft's Flash competitor that runs on a Mac as a Safari plugin.
Paper tigers make easily squashed pets, and even worse attack dogs.
So, let's wind things down.
I am interested in learning the Cocoa API because I wish to program for a Mac OS that spans from desktop computers through cell phones and music players, and in certain details (e.g. audio / video applications) has some real standout benefits. That is a testament to the emergence of Apple as a platform that captures my interest (for some, it's a re-emergence; that was never the case with me). 5-10 years ago, I couldn't imagine ever saying such a thing.
Saying, however, that I, as a programmer, will only program using Cocoa APIs from this day onwards is like saying that I will only drive on roads that begin with the letter "D" (given Apple's comparative market share, I don't think that's an unfair comparison). Apple does some important work, but so does the Linux world (a topic about which the author of said article is completely silent), and I have a sneaking suspicion that many fans of that non-Window platform would hesitate to call Apple's "Objective-C"-oriented development island the pinnacle of software development technology.
Perhaps my opinion of the merits of .NET would be somewhat lower if I had a negative view of managed runtimes in general, a glimmer of which I read into the subtext of Peter Bright's series. I think that constitutes very short term thinking in a world where cores are proliferating like mice as we run up against the limits of Moore's law.
But, one man's shiny new car is another man's Gremlin, and that's a long discussion for another day. This one has gone on long enough.