Less Rambling Venting about Developing for .Net

Dare's comment on my very rambling post yesterday made me realize how rambling it was. I had hoped to post a follow-up last night, but didn't quite find the time. I had a few points in my rambling vent.

1. NDoc is dead, and that saddens me... this lead to my venting points 2 & 3
   
2. Lack of developer community for .Net - the primary proof of this (for me) is the lack of open-source tools.
   
3. Lack of developer community is directly tied to Microsoft's insistence to limit .Net to Windows.
   

The .Net platform is a great platform. It is fast, and C# is a briliant compromise between the tensions of easy-of-development and developer-control. What I have noticed in spending most of the last year working in Java, is that despite this, I prefer to program in Java. So I ask the question why? NDoc's demise is related to some of my answers, so I slapped it all together in a single entry. Back to my points.

(1) NDoc is Dead: NDoc died due to lack of development support. Too much work and too few developers contributing. Version 2.0 update to the framework included some significant changes. Generics aren't just something slapped on. They are the result of man-years of thinking, planning, and work. They also have nontrivial impact on something like NDoc. I'm not surprised one guy can't just bang out an new version of NDoc that adds support for all the new v2.0 features. Microsoft made things worse by announcing Sandcastle which removes much of the need for NDoc. Take a project that already has had a hard time finding support and announce a free compentitive prodoct from Microsoft and you can smell doom in the air.

(2) Lack of developer community for .Net: One of the things that I love about Java, is that there is some many great open-source tools, and an excellent culture of support has developed around sites that support those tools. Back in the olden days, when I had a IBM XT clone and a 1200 baud modem so I could log into the local BBS, there was a great collection of tools for MS-DOS. Between then and now, the Microsoft development community has become very business oriented. There are some great tools out there, but they are proprietary. Go on SourceForge and look for C# projects. It seems that Microsoft has created a culture that encourages people to create and sell their custom ActiveX grid-control. What is missing is the college and graduate students creating a cool new tool as part of their thesis. There are a few exceptions, but they are rare. Coming back to work on C# developement, the lack of tools (compared to Java) is palpable and irksome. Microsoft makes this worse by failing to leverage the community when extending VisualStudio. Does VisualStudio ship with NUnit support? No. NAnt? Nope. Show me one (non-commercial) external tool/standard that Microsoft didn't develope that has been integrated into VisualStudio. I can't think of any.

(3) Lack of developer community is directly tied to Microsoft's insistence to limit .Net to Windows: So why are people creating cool tools for Java, but not .Net? I can think of 2 reasons: (1) Java has been around much longer. (2) Cross platform support. #1 is obvious and there is nothing that can be done. #2 is where I think Microsoft is shooting itself in the foot. For a long time, Microsoft needed to leverage tie-in as much as possible to realistically create Gates' visions of a PC on every desktop. It was necessary to keep prices down and avoid fragmentation. That vision is accomplished, and now we are on to new things. Time to let tie-in be less of an issue. Multi-platform networks and cross-platform development are the normal now. Accept it and move on. Do you want C# to out-shine Java? Let your child have wings and be free. What is good for .Net is good for you. I'd be much more interested in using C# if I could use it on my Mac PowerBook. Sure there is Mono, but there are still issues with UI and most of the home project apps I play with have UI.

I'm not asking Microsoft to Open-Source .Net. I'm asking for a cross-platform CLR with enough libraries that I can write a real application and have some hope of running it on a Linux box and a Mac box. Given that and a decent, cros-platform C# IDE, and I think the community around .Net would improve dramatically. If Microsoft then showed a hint of interest in working with the community, rather than just producing it's own independent clone of every successful community tools, and the .Net community would explode.

NDoc demise

According to a number of sources, NDoc is dead. The project owner claims that a large part of the problem is lack of community. I mentioned lack of a supportive community in a previous entry. The overall community is one of the reasons that I actually prefer working in Java vs C#, despite my preference for the C# language.

Microsoft needs to understand that Community is more than just lots of vendors creating commercial components, or MVPs answering questions on newsgroups. The .Net platform is an amazing platform. Microsoft needs to figure out how to make it _fun_ to write tools and libraries. Part of the problem is the lack of Linux/Unix support. Platform tie-in is dead! Give up on your Windows glory days. Windows won the desktop. Linux is not poised to steal it anytime soon.

Microsoft needs to stop weighing down it's products with 'tie-ins' that just hurt customer adoption. XBox is a great example. XBox did as well as it did because it leveraged existing Microsoft assets without crippling itself. The XBox OS is based on Windows NT, but they stripped it down to the bare minimum. Compare that with Windows CE/Windows Mobile? Have you ever done a true head-to-head daily-usage comparison of Windows Mobile vs Palm? I have. I'll take Palm every time, despite Windows Mobile's greater choice of applications and richer platform. Why? Because it's my phone. It should be just as easy to use as a phone as my girl-friend's Samsung phone. Windows Mobile just feels clunky, less intuitive, and less polished.

I forget who was posting those love reviews of Windows Vista with all the complaints about fonts and different UI control styles, button placements, etc... but his comments capture why Mac laptop sales are up, why the IPod is such a run-away hit, and also why I prefer to program in Java. Its all about the little details.

Microsoft needs to step away from it's long habit of tying everything back to Windows and Office, and making that a primary selling point, and instead make great products that integrate well with Windows and Office. The difference is subtle but key. I can't wait to see how they package Zune. Will it be chained at the ankles with Windows leashes, or will it be proof that some people in Redmond can see beyond that?

Anton Lapounov is blogging!

One of Microsoft's XSLT best experts is spreading the word about XSLT in System.Xml. I worked with Anton on and off for a number of years and have immense respect for him. It is great to seem him educating people about System.Xml v2's XsltCompiledTransform, which he had a huge part in delivering. This was a huge effort by a number of people and it should be of great value to anyone who need to execute XSLT on a windows machine.

Power Tool Races

I spent Saturday getting sunburned and helping out Hazard Factory host Power Tool Races in Georgetown (a neighborhood in south Seattle). Insane fun, insane heat, and power tools racing at breakneck speeds. What could be better?

Java vs C# .. take 42

I just spent the last few weeks back in the depths that are C# development with VisualStudio. I've spent most of the last year doing Java development in Eclipse (after almost 3 years of C# development at Microsoft) and bouncing back and forth has really called out some of the differences between the platforms and communities.

Lets start with tools: VisualStudio... VisualStudio is a mammoth application, that predates the Java platform. Modern VisualStudio installs are huge and include an immense set of tools and documentation. The downside is that having so much legacy and such a huge feature set, the application no longer feels cohesive. Despite having many of the same features and being more responsive than Eclipse (since it is mostly c++ code), VisualStudio comes across as less modern, less current. Also, strangely, VisualStudio development seems to sap battery much faster than Eclipse development does. The plug-in community is virtually non-existent. I tried to find CVS (and Subversion) support, and found nothing that didn't look like a weekend hack. There is no real community around extending VS, although there are a number of commercial vendors whose products integrate. As VS is a C++/COM app, building extensions is more complicated than extending Eclipse.

Eclipse also suffers from cohesion issues, but for different reasons. The 'perspectives' modalities feels like it creates more problems than it solves. There are annoying pauses as the GC tries to keep up with the UI. The live compilation is amazing, and the run/debug menu is possibly my favorite recent IDE innovation. I find the development environment noisy and the context menus over-busy, but basic functionality is easy to adjust to and amazingly productive. Also, the plug-in community is lively and moderately organized, and as Eclipse is a Java app, extension development is much easier and more productive than VisualStudio. Finally, the CVS support is excellent and the Subversion support is comparable.

One of the big difference I notice between the 2 communities, which is also reflected in the tools themselves, is how open they are. Eclipse is open-source, and actively encourages others to develop extensions. VisualStudio is proprietary and the SDK for building extensions is not well documented. Eclipse is all about anyone and everyone being able to build an extension. VisualStudio is all about companies selling their extensions.

Java's community has included a strong open source trend since before open-source was even trendy. The java community has produced some very strong community sites that support the Java developer. Microsoft's C# platform has never managed to engender the communal spirit that Java has. Part of that can be blamed on C#'s relative youth. Partly it is the result of a general Microsoft attitude to prioritize the corporate client. Eclipse does nothing to stop someone from charging for their extension, but it makes it so easy to build an extension that the bar is set rather high for a commercial entrant. The strong community has also meant that developing an good extension can be an excellent career strategy. Microsoft may have it's MVPs, but I feel that the community just isn't there. Microsoft products aren't designed to make you want to extend them, they are designed to themselves be the end-all-be-all.

The net effect, is that I prefer java development. This surprises be, as I prefer C# as a language, and I find many of Microsoft's libraries easier to use than the Java equivalent. Eclipse just feels friendlier and more open to me. If I didn't already have too many unfinished projects, I'd be contributing to one of the C# extensions. But that is part of the draw, the open-source lure. "Don't like it? Come help make it better!" There are a number of things I'd love to tweak in VS (mostly copying Eclipse) but ... well, I can't. Worse... I really just don't want to. I did some C++ development recently and after spending an evening tracking down a crash related to a typo while implementing a custom resizing array, I came to remember how productive I am in Java and C#. Sure I can write code that has 2x faster inner loops in C++, but it takes me 4x as long to get it all working!

As a close, here is my feature request to the VS team:
- 'run' menu like Eclipse. I often am building cmd-line apps to test an algorithm or library and need to be able to run multiple configurations. I love that this is just 2 clicks. In VS I need to get to the debug properties page for the project and change the args each time.
- Better interactive error reporting (background compile). The C# gives me red squigglies for some things, but it seems that there are still _many_ errors it does not catch.
- Faster build. This ties to good incremental errors. The build should be happening incrementally in the background all the time with only the final link steps happening when I invoke 'build' or 'run'.
- Better help integration. This especially bugs me when I'm developing win32 code. There are often multiple hits for a given keywork, but MSDN picks one and just jumps there. It should give me a choice, and it should remember what I've lookup up recently, so that when I am doing Win32 development, it defaults to the win32 match, and when I start doing C# development it should just start noticing and default to the CLR match. Currently, I can manually do this by selecting the appropriate filter in MSDN, but since I often program in C# during the day and win32 at night (on the same machine), that doesn't really solve my problem.

one apartment and six drummers

I've always been a sucker for rhythm: Music for one apartment and six drummers.

via jwz