Making the case for a slimmed down .NET

March 11, 2005 @ 1:40 am

There was an interesting article a couple of days ago by Richard Grimes, who is a fairly well known author and editor of a .NET column in Dr. Dobbs journal. Apparently Richard stepped down and made some not very flattering comments about .NET that have a lot of people up in arms. I’m always surprised by the outcry and knee jerk reaction that comes over any sort of criticism against .NET – especially from the VB crowd which got a real slap in the face from Richard as basically an irrevelant language.

I find this interesting in a number of ways, because in some ways I’ve made a number of comments along the same lines and have also been attacked as a whiner and naysayer. I say that counter comments like this are an important part to a community and very vital to provide a little controversy instead of all the yes men (and a few wo-men) who think .NET is the end all programming environment for all time. There’s not nearly enough counter commentary here from inside the community although there’s plenty from without.

What really surprises me when things like this happen is the vehemence with which the response comes. Take a look here and here, especially in the comments area.

Getting back to Richard’s post. While I agree that Richard made is point on a purely negative side, he also makes some very valid points about .NET. The most vivid point in mind is this:

In general, I think the library was released too early, and I think it was too large.

This is something that’s been on my mind for a long time, because at first blush it seems so great to have such full featured framework like .NET on your hands. But then you realize that lot of the classes are just not thought all the way through and that you won’t be able to do what the tools advertise to do in the first place.

There are countless places where you still have to rely on interop or alternate mechanisms that require re-inventing the wheel and using - gasp - unsafe code. Not only is this a hack it also compromises the whole security model that .NET is based on as unsafe code will not run even in a lightly locked down application. A few things that come to mind are the Service implementation which is awful, the WinForms TaskTray class, the Eventlog class that Richard mentions as well, and a whole host of WinForms controls (TreeView, Listview and the godawful Toolbar class that seem to have been thrown in at the last minute). Let's not even get into databinding in V1.x in both Win and Web forms <g>.

On the same token it’s important to say that at least we as developers could work around many of these shortcomings with a little effort and this is a sign of an overall well designed framework. It just seems that a lot of features where treated as last minute add-ons or wrappers of existing APIs rather than truly designed interfaces to the functionality they need to serve.

This is certainly not true for the entire framework – there are plenty of well designed classes there where stuff was designed from the ground up rather than just slapping a thin wrapper around a COM interface (WebMail/CDO for example) or Win32 API – but sooner rather than later you run into those half-assed classes that don’t work as they should. The ASP.NET engine comes to mind, which is a fine piece of software architecture (IMHO) and shows that some serious thought went into the design at all levels. The XML classes and the remoting architecture are other examples. Fortunately, the low level aspects of the framework are on the well designed end of the spectrum and this is why most things can be worked around at least.

The problem is that in a lot of cases of shortcomings the damage is done and it may not be fixable in future versions without a side by side replacement that will set up for a monster of a framework in a few versions. We’re already seeing that in Whidbey where most of the WinForm controls get completely replaced by a new set, while the old controls need to still be around so 1.1 apps can run on the 2.0 platform. It will be fun to see what happens 3 versions down the line – 25 megs will seem like a tiny runtime then.

Side note:

Interestingly enough the .NET 2.0 distributable is still only 24 megs. I'm not sure how this can be when the codebase has grown so much in 2.0 AND has to include the old framework functionality.

I think the framework size is a huge issue and the main reason that .NET has not made the inroads it could otherwise have made. Commercial developers – especially smaller vendors and utility producers and tool vendors (like myself) – cannot justify forcing people to download and install a separate piece of software that is 10 times the size of the application itself.

The reality is beyond the developer community and the server .NET has practically no reach at the moment. Commercial applications are far and between. Other than developers tools or server based apps how many .NET applications are you running?

For me the list is short:

NewsGator

Lookout

Fiddler

And even these are stretching it as mostly developer related tools. Beyond that are some internal applications:

My West Wind Web Store front end and Time Tracking module

Web Monitor

That's it on the desktop. Of course add a slew of server application. Am I completely atypical here? I doubt it...

The problem is not the shortcomings I would guess. Heck the VB6 runtime was much less full featured than .NET and there were loads of commercial applications written with it. My guess it comes down to two things:

* Size

* Speed

We've already talked about size. The other one is speed. .NET applications are fast enough, once they're completely loaded up and compiled by the JIT. Up until that point they're a dog. Starting a .NET application for the first time (especially if .NET wasn't loaded anywhere else before) is a 10 second + affair. For commercial software that's unprofessional to say the least. Even VB6 could do better than that and even Visual FoxPro apps will take less than 3 seconds or less from a cold boot. Add to that the massive memory usage (8 megs for a hello world windows form) and you got issues that are not appealing to commercial developers.

Maybe this will change in the future as hardware catches up with the requirements of this environment. But even a gig of memory gets eaten up real quick if you have a dozen .NET utility applications running. It’s a sad state of affairs when people make the argument, that ‘getting faster hardware’ will solve the performance problem. Remember that whenever you upgrade your hardware just to get something new to run, you’re also making whatever else you were running before running that much faster. It’s very instructive to take a step back some time and run applications you built 5 or 10 years or longer ago and run them on today’s hardware. It really makes you realize how much of a pig today’s software is.

And are we really that much better of in building applications today than 5 years ago? In some places like the Web I would say no doubt it - ASP.NET makes life a lot easier. Web Services and remoting make it drastically more easy to communicate among machines. But for desktop development in the current state of .NET? I’m not sure…

I agree with Richard that it would be REALLY nice to a have a stripped down version of the framework that doesn’t include all the server related components – the whole Web space, Enterprise Services, Messaging etc.
Microsoft has been able to create a tiny framework for portable devices, so it should be possible to create something similar with for the desktop. Of course this is day dreaming – this will never happen.

And so Microsoft is shooting itself in the foot. Don’t wanna ship the framework with the OS, but yet they’re making it rather unpalatable to bundle it with smaller applications.

I don’t quite understand the logic here. Why was .NET 1.1 not shipped with XP SP2 for example? The .NET framework is fairly unobtrusive – it doesn’t require a reboot and it doesn’t affect the machine if not used. With all the other worthless shit that gets installed without asking the footprint of .NET is not exactly a big problem.

The problem of distribution of the framework will always be a problem though. LongHorn isn’t going to fix that. By the time Whidbey ships there maybe quite a large number of machines that do have .NET 1.x installed. Of course by then that version will be obsolete because now you don’t want 1.1 to be there but you need 2.x. And the cycle repeats. Once LongHorn ships it will be tied to a specific version of .NET. And then things may become really fun as the .NET framework gets tied to the OS. And we thought it was a pain in the ass to have VS, SQL Server and .NET all tied together in an intricate dependency shuffle.

Interesting times ahead for sure. I’m quietly laughing of the complaints I’ve had in the past with runtimes – the Visual FoxPro runtime and VB runtimes not being part of the OS. That seems paltry now in comparison with a 4 meg footprint for VFP and less than that for pure VB (much more with data components). I still fret at Help Builder being a 10 meg download now (4 megs for the VFP runtime, 2.5 for the documentation the rest for the app and templates). 10 megs is a small download these days... Still, if I had to add 24 megs to that for people who don't have .NET how many people would balk? This is a problem that has immediate $$$ concerns and shouldn't be taken lightly as some of the .NET Yes-Men will do.

Feedback for this Weblog Entry

re: Making the case for a slimmed down .NET
by Gabe March 11, 2005 @ 5:59 am

Last I checked, MS still included VC++ in Visual Studio. In fact, the Whidbey version should be very nice. If you want small size and the best possible speed, use the right tool.

VB was never really about the consumer space (not much boxed software is written in VB), it was always targetted for internal company developers and solutions providers (just like VFP). .NET is a little bit inbetween. It is targets both markets (although, as you said, not equaly well). I do have one major boxed application which I love and is written in .NET, Sony's Vegas Video editing suite. It's pretty cool, I can even script in .NET (instead of COM).

Being an "enterprise" developer, I love what .NET (especially ASP.NET) gives me in terms of flexability and productivity.

I hear what your saying about backward compatability, though. It may be best to simply require different versions of the framework for different apps (as long as they stick to major versions).

re: Making the case for a slimmed down .NET
by Jay Schumacher March 11, 2005 @ 6:47 am

Thanks for posting this Rick, a very interesting read. I find this comment from Richards article particularly ironic:

They do not want the expense of rewriting their existing code for .NET

And yet that is what MS consistently pushes other developers/corporations to do. Do what I say, not what I do...

Although it is not a boxed application, the WSU Paint.NET program is also a good .NET product. For those who haven't seen it:

http://www.eecs.wsu.edu/paint.net/

re: Making the case for a slimmed down .NET
by Colin Nicholls March 11, 2005 @ 2:35 pm

Gabe -

FWIW there is no way Vegas is a pure .NET app. RealTime audio/video editing? I don't believe it. Besides, Vegas has been around a while, since before .NET I'm sure. They'll be some good, stable, legacy code in there somewhere.

re: Making the case for a slimmed down .NET
by Rick Strahl March 11, 2005 @ 4:06 pm

Gabe, the C++ point is a VERY bad one. This was one of the main sticking points for all these years in that Microsoft only had one high end tool that didn't have a decent UI front end (MFC? Please). other tool vendors (Borland especially with Delphi and C++ Builder) at least made an effort to provide a GUI front end form designer type interface to these powerful languages. Even now MS doesn't have this for pure C++ (although C++ now can do WinForms with managed code and the same limtitations I mentinoed before).

I get your point about C++ being efficient, but this is not an ideal environment for building application level code (although I'm sure some of the He men C++ guys will say it is - which I admire - but as we know life is too short to code in C++ <g>).

There's a huge gap left open in the consumer space in the Microsoft product line and this would be an excellent opportunity for MS to get Microsoft out onto the desktop more rapidly and more widely accepted.

+++ Rick ---

re: Making the case for a slimmed down .NET
by Rick Strahl March 11, 2005 @ 4:08 pm

Jay,

I've played with Paint.NET and while it is a nice application it's a dog compared to any commercial paint program. It's dead slow and demonstrates exactly the problems I mention in the post - big memory usage, super slow startup and lackluster performance in this case. Granted it's a newer program but for something like a Paint program it will be very tough to compete in the space that native code owns (Photoshop, PaintShop Pro etc.) - and those apps aren't speed demons either.

re: Making the case for a slimmed down .NET
by Gabe March 11, 2005 @ 5:24 pm

Rick, I agree, Delphi is a great tool / language. What's stopping you for using that tool? (I'm not being a "wiseguy", I really would like to know).

Colin, I'm not sure if Vegas is 100% .NET, I know version 5 requires the framework and that it's scripting engine is all .NET. I also know that when I applied SP1 for .NET 1.1, it wouldn't work any more. (A good example of versioning issues with .NET).

re: Making the case for a slimmed down .NET
by Rick Strahl March 22, 2005 @ 4:22 pm

Gabe, I've never been fond of Delphi or the Borland IDE. I used to use Delphi, but that language always felt too verbose and clunky to me - reminded me of my College CS classes too much maybe. Yes, it's a good tool, but being a Microsoft developer it's hard to get up to speed on a non-MS tool for only a handful of of small projects. Somewhere I have to draw the line of how many tools I can work with. Right now that'd be VC#, VFP and sometimes VC++.

In fact, the original version of Web Monitor was written in Borland C++ Builder. It was doable, but a chore for me both for the C++ angle and the Dev Environment at the time at least.

Rewriting that with .NET was a pleasure. It was easy to build complex functionality including the multi-threading support and easy to design a maintainable architecture. But the resource usage for Web Monitor is enormous and for a tool like this it really sucks to have a small app that does very little (basically run a few threads and fire off HTTP requests) take up well over 10 megs of memory (and that's running as a service without forms)! It's a marketing problem really, not a functional problem, but a very real one for vendors of tools and utilities.

BTW, Delphi now also does .NET so Delphi may also go the way of the dodo for native code.

re: Making the case for a slimmed down .NET
by Jeff Atwood March 27, 2005 @ 7:53 pm

Er.. does 10mb of memory really matter in today's world of 3.8ghz processors and 1gb memory? I'm pretty sure AOL instant messenger takes up that much, and you'll get rid of that when you pry it out of users' cold, dead hands.

re: Making the case for a slimmed down .NET
by Jeff Atwood March 27, 2005 @ 8:00 pm

> It’s a sad state of affairs when people make the argument, that ‘getting faster hardware’ will solve the performance problem.

And yet that's exactly what happened with VB5/6. Tons of people said exactly what you're saying-- too slow, too big, this crazy plan will never work. And yet here you're putting VB6 on a pedestal as an EXAMPLE of speed. Ironic. I don't see anything in your argument that outweighs what the history you cited has already proven.

> It’s a sad state of affairs when people make the argument, that ‘getting faster hardware’ will solve the performance problem. Remember that whenever you upgrade your hardware just to get something new to run, you’re also making whatever else you were running before running that much faster. It’s very instructive to take a step back some time and run applications you built 5 or 10 years or longer ago and run them on today’s hardware. It really makes you realize how much of a pig today’s software is.

Most apps don't have serious performance requirements, so why not sacrifice 10 percent of this exorbitant Athlon 64 4000+ to make things easier on us? Computers get faster every day-- our brains don't. This is a perfectly logical tradeoff to make. Hell, you even said it yourself:

> Rewriting that with .NET was a pleasure. It was easy to build complex functionality including the multi-threading support and easy to design a maintainable architecture.

And really, who gives a damn if it takes 20mb or runs 30 percent slower than the Delphi version. If you think it's worth it rewrite it in Delphi-- arguably the lightest, fastest env that's still RAD-- be my guest!

re: Making the case for a slimmed down .NET
by Jeff Atwood March 27, 2005 @ 8:26 pm

> Other than developers tools or server based apps how many .NET applications are you running?

Windows Media Center Edition was written entirely in .NET 1.0. I think the current 2005 version is 1.1 though. And I am using the heck out of MCE on my HTPC.

re: Making the case for a slimmed down .NET
by Rick Strahl March 27, 2005 @ 10:42 pm

Jeff, as far as history goes .NET on the desktop has a long way to go before it is widely accepted - Microsoft will likely shove it down our throats with LongHorn (which is probably a good thing)

Unlike VB (which I've never used extensively) .NET is not an instant hit in terms of distribution and installation. Just think how sad that comparison is: VB wasn't considered a speed demon at the time, but compared to .NET it is. Now you tell me, why is it that NEW technology gets slower and less efficient over time providing essentially the same services (in this case the windows/event loop interfaces)? Yes, .NET provides so much more than VB, but in the core services we're still dealing with basic Win32 interfaces wrappered ontop of the Windows API - this shit doesn't need to get slower - it should get faster!

When VB came out the the runtime was an issue but not merely as much as it is for .NET. The numbers bear that out - look at the software you download and use - the percentage of .NET apps is absolutely tiny.

I love developing in .NET and the power it provides. But on the desktop this version and WinForms is pretty crappy and more importantly often unproductive. Unlike the server side it looks like the MS Teams weren't ready to ship with none of the same design elegance that the ASP.NET side demonstrates and none of the efficiencies either!

Jeff, I'm not sure what you're saying but Media Center Edition is still WinXP plus some tools. There maybe a few .NET components in there, but the product is still basically WinXP - it's hardly 'entirely' in .NET.

I've been sold on .NET but at the same time I can also admit and see that there are issues in desktop scenarios. Part of being a good developer is knowing the strong and WEAK points of the platform you are using and being able to discern when another tool might be a better choice for the job. With .NET desktop apps there are apparently for many people other much more attractive choices.

re: Making the case for a slimmed down .NET
by Jeff Atwood March 28, 2005 @ 6:37 pm

> Jeff, I'm not sure what you're saying but Media Center Edition is still WinXP plus some tools

Obviously XP is still XP; the MCE app itself is .NET code.

> But on the desktop this version and WinForms is pretty crappy

Have you worked with VB6 recently? .NET winforms is certainly FAR less crappy than VB6. For one thing, you actually have access to the WM queue using standard code. It's really like night and day. I'm not sure what your definition of "crappy" is, or what environments you're programming in that are so much better. Delphi is the only one I can think of that would be superior, and that's because it integrates so tightly with the native win32 API, whereas .NET is a wrapper.

> the percentage of .NET apps is absolutely tiny.

And the same thing could be said about VB5 circa 1998.

> same design elegance that the ASP.NET side demonstrates

Personally I think ASP.NET is one of the most disappointing areas of the framework; the abstraction breaks down all over the place. I guess what you're saying here is that HTTP apps are easier to wrap with an API than win32 apps are. I agree. At any rate, there are massive changes in ASP.NET 2.0, so however elegant it was, clearly it needed to be changed.

re: Making the case for a slimmed down .NET
by Rick Strahl March 28, 2005 @ 7:34 pm

Jeff,

For productivity in a desktop environment, I've used FoxPro for years. In terms of productivity it runs circles around what .NET 1.x (out of the box) does today. It's not nearly as powerful if i want to go low level, but then again when you're building a business applications you're using the same handful of controls over and over. My point isn't that it that .NET is no good, but that it could have and should have been lot better. In fact V1.1 could have fixed some of these obvious shortcomings a year after V 1.0, but there was ZIP done to add features or enhance designers.

There are so many obvious flaws that it seems odd to me that no one looked at the stuff and went - hmmmm... this interface really doesn't make sense (my favority here is the WinForm designer and the FAT borders around objects that keep you from seeing object alignment).

In V1, the overall architecture is good, but implementation of the native controls and Windowing interfaces and most of all the lousy designer just shows that much of this wasn't thought through all the way through, IMHO. The power is there though as evidenced by well designed third party controls/control frameworks, but unless you get low level, the existing controls have many shortcomings that need to be worked around in day to day development - most of them obvious things that even the limited ACtivex controls of the day (MSCOMCTL etc.) used to do. Again, in some ways it's a step back not forward.

As to ASP.NET - you were looking for a WinForms implementation? In that case I can see your disappointment, but it's also mighty unrealistic. Web Forms have their problems and inconsistencies, but the overall model and for the most part the implementation is vastly superior in design and pure architecture to the Winform stuff. FWIW, the majority of the changes in ASP.NET 2.0 are built ontop of the existing framework rather than replacing the existing architecture.