Athos
Friday, March 25, 2005
 
Responding to Richard Grimes article on .NET by Dan Fernandez'


Responding to Richard Grimes article on .NET


Edit #1 - Based on feedback, fixed grammatical errors...

I recently ran across an article written by Richard Grimes in Dr. Dobbs Journal titled Mr. Grimes farewell. I wanted to respond to some of Richard's assertions and points in the article. You should take Richard's article with a grain of salt as he does clearly state that the article is "his opinion". That being said, Richard's article is supposed to be his view of the current state of .NET, but rather than discuss how far we've come and where we're going, he instead argues three points - the .NET Framework is too large blocking adoption, issues with the design of the .NET Framework, and over half the article bashing Visual Basic, and finally that Microsoft is "losing confidence" in the .NET Framework. His quotes, italicized in gray, and my responses are below.

On the size of the .NET Framework blocking adoption

My Response: Maybe I'm being too picky, but the size is 23,698K or 23.7MB. While Java's runtime is smaller, it still weighs in at 15MB. Throughout the article, Richard refers to .NET applications when he's really referring to client or public client (meaning not in the firewall) For example, installing the .NET Framework on a server or within an intranet where you can control the environment certainly isn't an issue. Even for public client machines, there's plenty of commercial shareware from games to RSS readers that require the .NET Framework. I've also talked to plenty of shareware developers and they certainly aren't using Java. Many use C/C++, Visual Basic, or Delphi. As far as adoption "and the state of .NET",  which the article is supposed to be about is best summarized by Soma, the Developer Division Vice President in his post on .NET Momentum.

Soma: We have seen over 70 million downloads of the .NET framework from Windows Update and the Microsoft Download center to date.  For a simple guy like me, that translates to about 5.5 million downloads a month.  Another interesting datapoint is that in 2004, we expect to have about 54 million new PCs shipping with the .NET framework installed/preloaded.  We also have over 2.5M developers targeting managed code. 

On the Design of the .NET Framework

My Response: These two points contradict each other. In the first he implies that the .NET Framework is a replica of Java, but in the next statement he claims that the .NET Framework is simply ported Win32 classes, Windows Foundation Classes (WFC), and VB runtime classes. Which one is it? If his point is that you can write a simple application and that it will look the same in C# and Java or C++, I don't think that really proves much. Below is an example of a for loop. 

for (int i = 0; i < x; i++) {...}

Guess what language it's written in? If you said either C, C++, C#, and Java, then you are correct. I don't see what he's trying to prove here. If he tries to build a more robust application then "Hello World" you're going to run into framework or library specific features (ATL is not, MFC is not EJB, etc).

On Interface-based Programming and Remoting

Point #1 - Interfaces are dead

Point #2 - Lack of documentation on using interfaces with .NET Remoting

My Response: We don't "prefer" any mechanism, per se. While we may offer guidance, developers can choose to develop their applications as they see fit. Our Patterns and Practices group does provide guidance and best practices on these and other points and even includes guidelines on how to design a remote interface. I don't see a class-based favoritism over interfaces, in fact, there has been an increasing movement to use messages and service orientation rather than object orientation. I concede his point on deploying server assemblies to the client, but poor design is poor design. People deploying a server assembly to a client just so that the metadata of the service objects is available could have easily used an interface or schema instead. That being said, there are some situations where you do in fact want to have server code in each client, the example being a peer-to-peer chat where each client acts as both a client and a server.

 

On Microsoft using the .NET Framework for their applications

My Response: We should dissect exactly what Richard says here. He says that Microsoft is using .NET to extend existing products and that Microsoft doesn't want the expense of rewriting applications from scratch in .NET. This makes perfect sense to me, why would we re-write perfectly good code? .NET code can interoperate with existing code, and you bet we're going to take advantage of the interoperability layer to add new features that exploit the best managed code has to offer.  As I pointed out previously, Microsoft is using .NET in all sorts of software from operating systems, to developer tools, to Office.

My Response: This is a half-truth at best. While Windows XP Professional does not use the .NET Framework, that's because the .NET Framework was released after Windows XP Professional shipped. Let's look at the operating systems that shipped after the .NET Framework was released:

On Longhorn and the death of browser applications

My Response: I respectfully disagree. XAML will allow for rich interfaces, but ASP.NET and HTML are not going away. Our value is that we can take the best of both worlds, and provide an optimized experience to XAML browsers while still maintaining compatibility with old computers. It should also be noted that there is a difference between client applications and server applications. The server market itself is *totally different* then the client/consumer market. While people talk about Microsoft's dominance in client operating systems at around 90%, we are nowhere near that number in the server market. We're competing against products and companies like IBM WebSphere, hundreds of middleware products, Oracle in the database market, etc. If we want to win the server market, we need to have the fastest, most reliable, most secure, most productive and affordable solution for creating Web applications. To say that browser applications are a threat to Microsoft is so....1996. The threat is not the Web. If it was, wouldn't Microsoft have "lost" already given that the Web is already incredibly successful and popular. How much more popular does the Web have to be before this is proven untrue? Richard then goes on to say that Microsoft needs to do this because of client revenue. The client operating system market, as stated above ~90% is pretty saturated. The server market is where the opportunity for revenue growth truly lies (PS the server and tool business grew 18% last quarter! - see slide 9). On the question of revenue, a typical server deal is in the thousands of dollars as you're paying for several parts including:

Depending on the complexity of the solution, this can range from thousands of dollars to several million dollars. Server products are expensive. If you look at the market for Web content-management solutions, the average price can be around $50,000 for a one-proc enterprise license. My point being that there are plenty of revenue opportunities and competitive threats from the likes of IBM and others in the server market. Do you know how large the market for database software is in terms of revenue? Would you agree that it's billions of dollars? Do you know that Oracle is the #2 software company and their primary revenue is from databases? That's just *one* of the market opportunities for server software. Back to my point - We are totally committed to our server products and to making Windows Server and ASP.NET the best platform for creating Web applications. Period.

On Longhorn

My Response: The decision to make Avalon available to other versions of Windows was driven by one thing, customer demand. Any rudimentary Web search turns up results of customers complaining about not being able to have this functionality on down-level operating systems.

On using the .NET Framework for shipping products

My Response: Richard, the key parts of Longhorn you've mentioned in your article, Avalon and Indigo, are written in managed code. How does that indicate we are losing confidence in .NET when we've decided to bet the success of our next operating system on the .NET Framework? You might then make the follow up argument that because the entire operating system isn't managed, that we have "lost confidence". While that's your opinion, I don't think managed code is right for every scenario and Microsoft has never claimed that it is. Microsoft still fully supports C/C++ and we have a very large existing C/C++ code base and C++ customer constiuency. We'll use managed code where it makes sense.

My Response: I'll avoid responding to the VB bashing as someone is already working on that. There are two points here, one is using the .NET Framework for creating operating systems, the other on Microsoft revenue. On creating operating systems using the .NET Framework, I don't think we've *ever* said that you should be creating an operating system from scratch based solely on managed code. The truth is, gasp, the vast majority of our customers are not creating operating systems.  For those customers who are or who need that level of control and performance, we have C/C++ and we absolutely have not abandoned that. On revenue generating profits, I've already listed several revenue generating applications using the .NET Framework. Microsoft is divided into the seven business groups listed below and let's see which ones are using managed code. 

I hope this clears up and FUD, half-truths and any misconceptions on managed code. If something is incorrect here, please let me know!

 

 



posted on Tuesday, February 22, 2005 2:06 PM


- posted by JaneAthos @ 3/25/2005 09:43:00 PM 0 comments
 
fwd>>Mr. Grimes’ Farewell
Mr. Grimes’ Farewell (from http://www.ddj.com/documents/s=9211/ddj050201dnn/)


Richard is stepping down from his post of commenting on all things .NET. In his farewell address, he looks back at some missteps in the development of .NET and offers words of warning about the future of the platform
It is now almost three years since I started writing this newsletter and now I've decided to finish. I thought I would provide a concluding article to give my view on the current state of .NET.

I started using .NET when it was in technical preview at the beginning of 2000; at that time it was called COM+2 and the main language was something called Cool. The framework briefly became Next Generation Windows Services (NGWS) before some marketing wonk came up with a term that really would confuse Internet search engines: .NET. How many times have you been asked what .NET means and what relationship it has to .COM and .ORG? Of course, Cool faired no better. Some bright spark decided to call it C#, which initially confused search engines and users alike. The search engines did not like the # character and the users did not know how to pronounce it (C-pound? Or for those of us on the eastern side of the Atlantic, C-hash?). Almost the first thing I posted on the technical preview newsgroups was a simple console application in Cool, and its equivalent in Java with the rhetoric question to spot the difference. That solicited a robust response from the Visual Studio Product Manager who didn't really see the point that I was making.

Unlike other versions of Visual Studio, the first beta of Visual Studio.NET was open. Anyone could download the beta and post bugs or questions in the beta newsgroups. To be honest, I wasn't comfortable with that. I will only post a repeatable bug in a public group, and as a reserved Englishman, I am unlikely to post bugs that are not repeatable or post suggestions on improvements. I have not seen any published results as to whether such a wide and open beta was beneficial in terms of the number of bugs that were identified; however, I suspect that finding bugs was not the intention—it was more likely that the beta was open to get as wide acceptance as possible.

Like everyone, I was initially overwhelmed with the size of the framework. There was so much there! In the last few years I have come to the conclusion that its size is a hindrance. There are too many classes and although I think that there are many classes that are well designed, I think that there are some that haven't been given more than a cursory thought. There are classes that are mere wrappers around Win32, but there are other classes that appear to be ported from other frameworks. Before it released .NET, Microsoft had its own Java framework library called WFC, and it also had a managed library as part of the Visual Basic (classic) runtime. It would be nice to know how many classes from WFC and VB were ported to .NET. I can identify one such class, because it works just as badly in .NET as it did in VB, and that class is EventLog. This class behaves just like the VB equivalent, and no one even bothered to think through the design before rubber stamping it for the 1.0 version of the framework. For the record, I did complain about this class during the beta, but the developer responsible just gave me some lame excuse. Finally, this class has been "fixed" in 2.0, but the errant methods have not been deprecated, so I don't regard it as a fix at all.

In general, I think the library was released too early, and I think it was too large. The framework redistributable is 25 MB, which is many times larger than the Java redistributable. One of the lessons of the early versions of Visual Basic was that the shareware and freeware market created the popularity of the language. While there are some shareware apps written in .NET, I often hear people complain about the huge redistributable. In this column, I have written about the size issue, and I still think that it would benefit the framework if Microsoft provided a cut down version of the framework with perhaps just mscorlib and system assemblies.

While I am on the subject of Visual Basic, I may as well give my opinion about that language. It has to be said that Visual Basic (classic) was getting rather tired. The language was inherently single threaded and had serious problems with COM (certainly as far as creating COM servers). In fact, when I had finished writing my book on MTS (published in 1999), I came to the conclusion that MTS had been designed to allow Visual Basic developers to write objects that could benefit from threading and security, and COM+ took this a step further. Visual Basic could call Win32 functions, but it often had to use dirty hacks to use them effectively. But with COM, and COM security, it had gone as far as it could and could not provide what C++ could do in a few lines of code. Any situation where C++ can provide a facility in a few lines and VB cannot is embarrassing to VB. However, most of the problems are so inherent in the language and the runtime that the solution had to be radical. And that lead to VB.NET.

Well, a search of the Internet will give you most of the details of the furor that the release of VB.NET caused. The best site is Karl E. Peterson's (http://www.mvps.org/vb/rants/vfred.htm). VB.NET simply isn't VB: As Karl's site shows, there are multiple incompatibilities between the language of VB and VB.NET. Further, VB is single threaded, does not have exceptions, and was typically used to write non-OOP code. VB.NET was provided with a “porting” tool, but most people I know who have used it (including me) have found that the tool simply comments out large amounts of the incompatible code. My advice early on was that VB developers should not port their code, and instead they should convert it to VB classes that could be called by .NET code through COM interop. That way, the VB code remained in the environment where it was designed to work. Microsoft, of course, perpetuated the myth that VB.NET was VB and promoted the porting tool.

Some people regard VB.NET as wonderful. I really don't see the reason for the language. There are a few features that other languages do not have (exception filters and renaming interface methods are two), but these are not good enough reasons for a new language. There is the argument that VB developers would be more comfortable with VB.NET, but as I've said, VB.NET is not VB, and since a developer would have to learn principles of OOP and .NET principles like threading, exceptions, and delegates, the developer may as well learn a new language. C# is the natural language to use for .NET and there was no need for VB.NET. Semicolons and braces are not so difficult to get used to! Instead, we have a language that's .NET, but not quite all there. In my opinion, the Common Language Specification (CLS) was created simply to make sure that other languages could create code that would work specifically with VB.NET code, rather than making all languages work with each other. I understand that signed integers are useful, but so are unsigned integers! I do not understand why VB.NET cannot have unsigned integers as part of the language. I think that case insensitivity is juvenile, there is no excuse for using Option Strict Off (“late binding” is a synonym for “hard to find run time bugs”), and it’s easy to lose track of your variables if you don't explicitly declare them. VB.NET has serious flaws that are not counteracted by the few benefits it gives.

I have written a column on VB.NET and I have spoken at VB.NET conferences, so I know the language well. However, it's not a language I am comfortable with: I find that whenever I use the language, I tend to swear a lot. It just doesn't work the way I expect it to, and I am not the only one. This is the most common complaint I have heard from people who moved from VB (classic) to VB.NET and this backs up Karl E. Peterson's statement that VB.NET is just not VB. So why did Microsoft create VB.NET? The answer is that in 2000, the number of VB developers exceeded the number of users of Microsoft's other principle language, C++, by at least a factor of 10 (these were figures I saw at an internal Microsoft meeting). Microsoft made a big point in announcing that C# was another language "from the C++ family" and the marketers judged that they could not get all of those VB programmers to use a C++-like language. Instead, they judged that they would be more likely to get a fair proportion of those VB programmers to move over to .NET if Microsoft generated a VB-like language. In other words, the reason for VB.NET was marketing and not technological.

It is worth pointing out that .NET in general has many similarities with VB (classic). Like VB, .NET can use interfaces but the preferred way is to use classes. Interfaces are elegant but .NET's preference for class-based solutions has marked the death of interfaces. Look at .NET remoting: This has been provided to allow an object to run in the context where it was created, and be accessed from another context. This means that the object state is kept local, and it is the behavior that is remoted. Thus, remoting is an interface-based facility. You can use .NET remoting with interfaces, but reading through the documentation and all of the “how-tos” on the Web, you wouldn't realize this. Instead, Microsoft prefers people to use a class-based approach, which often results in the bizarre situation of people deploying their server assembly to the client so that the client has the metadata of the service objects available, or a soapsuds assembly, which basically was a hack to get around the problems of having class-based remoting.

Another area where .NET is very VB-like is Microsoft's attitude to the framework. Microsoft treats .NET as a useful library to extend its products, and to date, it has not shown any more conviction to the framework. There have been a few .NET products written entirely in .NET; one such product is Microsoft CRM. However, these are not the main revenue generators. Instead, .NET has been retrofitted to the existing products and used to extend them. Even Visual Studio .NET is not a .NET product. devenv.exe is an unmanaged process written in C++ (and presumably MFC). VS.NET hosts the .NET runtime so that it can use .NET objects like the property grid and so that it can be extended through code written as .NET assemblies. It's my opinion that this is the model that Microsoft will use in the future. They do not want the expense of rewriting their existing code for .NET, and there is no compulsion to provide all new code in .NET; instead, .NET will be hosted as and when it's needed, particularly to allow extensibility through user-supplied code.

Microsoft's current operating systems, XP and Windows 2003, do not depend on .NET; and with XP, .NET is an optional component. The next version of Windows, codenamed Longhorn, was released as a technical preview at the 2003 PDC, and it looked as if the operating system would have .NET's tendrils throughout. However, a lot has changed since then. Over the last year, Microsoft has released a series of announcements that have shown that it is more concerned with an artificial deadline of a release date of 2006 rather than a passion towards new technology. The first casualty was WinFS. It's true that this technology made Longhorn slow, and in particular, WinFS made Outlook Express totally unusable. But rather than making this technology work, Microsoft chose to remove it. Reading between the lines, I doubt if this technology will ever return. Next, Microsoft announced that the two other .NET technologies in Longhorn, Indigo and Avalon, would be available for other versions of Windows. Indigo is a messaging technology, so it makes sense that other versions of Windows can use it. However, I take the decision to make Avalon available to other versions of Windows as a lack of confidence in the sales of Longhorn.

My opinion is that Avalon, or more specifically, XAML, will mark the death of ASP. The reason is that Avalon is a client-side technology, but the browser is an important part of the distribution model. XAML is so rich that a browser-contained XAML application will look no different to a process-based Avalon application, and coupled with Web Services or Indigo (as the mechanism to access remote code), an XAML application will make an ASP.NET application look paltry and antiquated. Why would Microsoft want to kill ASP? Well, with installation of ASP.NET Microsoft sells a single copy of Windows 2003 and perhaps a handful of copies of Visual Studio.NET. The clients don't have to be Windows, so there is no extra sale to Microsoft (whether as a product or licence). This is hardly a great revenue generator, and worse, ASP.NET actually makes it easy to write the application so that it can be used by browsers other than IE. However, with a technology like XAML Microsoft gets to control the client. So in addition to the server and the development tools, the client must have Avalon. That could be a huge revenue generator for Microsoft, assuming that customers could be persuaded to upgrade to Longhorn. However, Microsoft's announcement that Avalon will be available for other versions of Windows indicates to me that they are not so confident on the uptake of Longhorn, and developers will not write applications for Avalon if they are not convinced that there will be the clients that will run it.

So, with the announcements they have made last year, Microsoft has indicated that Longhorn will not be the great .NET innovation that we were lead to believe it was from PDC 2003. This indicates to me that Microsoft is losing confidence in .NET. When I see the beta of Longhorn (due later this year), I will examine it carefully to see how much of it is implemented with .NET. I suspect very little will be. Here are some clues to look for: If Longhorn does not implement the shell, or will not allow you to extend the shell with .NET, then Microsoft has clearly lost their confidence. If Longhorn does not implement any services in .NET, then they will indicate (as I do) that .NET is not the right technology for running under the privileges of the LOCALSYSTEM account.

So if you've reached this far, you will get the impression that I have a very cynical opinion of .NET. The framework has a lot of promise, but I think Microsoft was far too ambitious releasing far too many assemblies much too quickly. As a result design suffered, but to provide backward compatibility, Microsoft could not simply redesign the whole library and deprecate the old one. So we are stuck with the library we have. Microsoft has allowed marketing to take precedence over technology: They created and promoted VB.NET simply as an attempt to get the bulk of Windows developers to use .NET, and not because there was any need for the language. The framework has become Visual Basic—it's intended for users to develop applications, but not for Microsoft to create operating systems or the revenue generating products that they base their profits on.




--------------------------------------------------------------------------------

Richard Grimes speaks at conferences and writes extensively on .NET, COM, and COM+. He is the author of Developing Applications with Visual Studio .NET (Addison-Wesley, 2002). If you have comments about this topic, Richard can be reached at richard@richardgrimes.com.




--------------------------------------------------------------------------------
- posted by JaneAthos @ 3/25/2005 09:30:00 PM 0 comments
Wednesday, March 23, 2005
 
江城子　无题

十丈红尘两茫茫
不思量　入膏肓
孤城破帽　消磨旧模样
莫使相逢莫使离
最相思　如参商
　
画眉深浅君莫忘
心惶惑　梦不长
泪下惊魂　唯有月如往
别后怕醒恨夜残
鹧鸪叫　人断肠
- posted by JaneAthos @ 3/23/2005 09:19:00 PM 0 comments

Powered by Blogger