So I hate to feed the trolls, but... On Wed, Jun 29, 2005 at 02:35:50PM -0700, Yan Hu wrote: } Look at the job market for the server side now. 3 years ago, .Net took } only 20% of the server side market. Now it is creeping up to 40%. .Net is } better or faster than Java? Nah.. Some .Net zealots otained some } benchmarks on Tiger and .Net1.1 using linPack. Tiger outperformed .Net. } But why is .NET creeping up so fast? VS.net contributes to a great } portion of its success. One of my friends is a NET develepor. I envy his } speed of rolling out (small to medium sized) web applications like they } were egg rolls. Only the market tells what is good nor not..... You have } one thousand sound reasons to back up what you claim. If the market says } "no", then it is garbage........
I have never liked IDEs. I have never used an IDE that didn't get in my way more than it helped. VS.NET is no exception. Below I'll give you some reasons why .NET is popular that have nothing to do with the quality, or lack thereof, of VS.NET as an IDE. I recently developed an ASP.NET web app. This involved writing in the following languages: ASP.NET (JSP-ish), C#, CSS, and JavaScript. It was only because I could convince VS.NET to let me edit these files with Vim that I did not tear out all my hair. That said, ASP.NET beats the pants off JSP. I can tell you definitively that ASP.NET's custom web control stuff (both ascx files and just plain class instances) beats hell out of JSP's tag libraries. The EL is not a big enough plus to make up for the difficulty of wrapping functionality in a custom tag. I haven't done anything significant with Struts, but I didn't have any trouble separating model, view, and controller in ASP.NET. In addition, C# is what Java always should have been. Here are a few Java mistakes that are done right in C#: 1. The language and virtual machine are internationally standardized. 2. JavaBeans use a naming convention (get/set methods), rather than first-class, syntactically clear, reflectable properties. (Yes, you find the methods by reflection, but they are "properties" because of the naming convention, not because the reflection API knows anything about properties.) 3. Namespaces (packages) are hierarchical in name, but not in scope. 4. The source filename must match the (public) class defined in it. 5. The source file must be located in a directory hierarchy that matches the package hierarchy to which it belongs. 6. C/C++ precompiler directives were simply dropped, rather than fixed to be less prone to misuse. 7. Receiving an event requires implementing an interface, with its associated method(s), and calling a method on the event producer to register the handler; producing an event requires writing add and remove handler methods, as well as writing a loop to invoke the appropriate method on each registered handler. What makes this wrong can be seen by comparing it to the C# event handling mechanism: a delegate type (essentially an OO function pointer, which includes the object reference almost exactly like Obj-C's selectors) is declared to handle a particular event, an event is declared in the producer class of the delegate type, a method with the appropriate signature can be registered with the event using += and unregistered using -=, and the handlers are invoked by the producer class by calling the event like a method. Oh, yeah, and a class's events are available through the reflection API. 8. Special casing value types (e.g. int, char, etc.), rather than either making everything a proper object (like SmallTalk) or making it possible for developers to define value types. I'll admit that Java has gotten better with the release of 1.5, and about damn time. It has generics, which are not yet available in C# (currently in beta). It also has anonymous classes, which are primarily valuable for event handling. Java now has the enhanced for loop (C#'s foreach), automatic un-/boxing (C# has it), and typesafe enums (C# has it). There is also the metadata facility, which is similar to C#'s attributes. In some ways, Java has caught up with C# (though I'm not likely to forgive Sun for the unpleasantness that is the JavaBean convention). Of course, C# is moving forward as well. (See http://www.ondotnet.com/pub/a/dotnet/2004/04/05/csharpwhidbeypt1.html and http://www.ondotnet.com/pub/a/dotnet/2004/04/12/csharpwhidbeypt2.html for a rundown of its coming features.) It's getting generics. It's also getting anonymous methods (a lot like anonymous classes, and intended for the same sort of use, i.e. event handling, but see mistake #7 above). It's also getting an absolutely brilliant way of expressing iteration, using the "yield return" construct. Basically, all the bookkeeping you have to do in an iterator is done for you, and you just write a loop (or whatever other traversal) around your data, executing yield return on each element. Also coming is partial classes; not only are you not required to define one and only one (public) class in a source file, you are no longer required to define an entire class in a source file. (At first blush, this sounds terrible; it makes more sense when you take into account its purpose, which is to allow developer code and generated code to reside in separate files without being forced to subclass.) And one more thing: nullable value types. That means that you can have an int variable that acts just like an int, unless you need it to be null. There are other things I haven't mentioned. C# and .NET and ASP.NET have their warts, like anything else (the largest being Microsoft itself). As a developer, however, I have to say that it was a pleasure developing in ASP.NET/C# as it never was in Java. --Greg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
