Originally posted by MichaeltheGreat
"Web services" are just a small aspect of .NET - there's really no reason not to use it for standard desktop applications, n-tier, or web apps. J2EE also addresses web services, which really are (IMO) still at the stage of being a solution looking for a problem. .NET is much more about being a cross-platform capable operating environment, without being dependent on "The mother of all languages" nonsense.
"Web services" are just a small aspect of .NET - there's really no reason not to use it for standard desktop applications, n-tier, or web apps. J2EE also addresses web services, which really are (IMO) still at the stage of being a solution looking for a problem. .NET is much more about being a cross-platform capable operating environment, without being dependent on "The mother of all languages" nonsense.
Originally posted by MichaeltheGreat
Java is hardly a panacea - it's lots of fun to want to make use of features in 1.3 or 1.4, while knowing some of the devices you want to support only have 1.1 or 1.2 compatible JVMs. Java still has it's place - I wouldn't try writing game apps for my Nextel phone in .NET for another year or two.
Not to mention that Java does it's "one size (almost, usually, well, more often than not) fits (almost, some of the time) all" by compromising both on speed and on implementation. GUI elements in Java on Windows suck compared to native Windows elements, regardless of whether you use the M$ or Sun JVMs. Java interoperability with languages like C++ is problematic, and sometimes just painful.
Java is hardly a panacea - it's lots of fun to want to make use of features in 1.3 or 1.4, while knowing some of the devices you want to support only have 1.1 or 1.2 compatible JVMs. Java still has it's place - I wouldn't try writing game apps for my Nextel phone in .NET for another year or two.
Not to mention that Java does it's "one size (almost, usually, well, more often than not) fits (almost, some of the time) all" by compromising both on speed and on implementation. GUI elements in Java on Windows suck compared to native Windows elements, regardless of whether you use the M$ or Sun JVMs. Java interoperability with languages like C++ is problematic, and sometimes just painful.
Originally posted by MichaeltheGreat
It frees you from DLL-hell by providing excellent versioning tools. Each app can specify versioning behavior of its components by default global behavior, at the app level, or at the level of each component. Automatic updating via remote server is easy, and won't break anything else, even if the components being updates reside in the global assembly cache.
It frees you from DLL-hell by providing excellent versioning tools. Each app can specify versioning behavior of its components by default global behavior, at the app level, or at the level of each component. Automatic updating via remote server is easy, and won't break anything else, even if the components being updates reside in the global assembly cache.
Originally posted by MichaeltheGreat
Inheritance and other OOP features and memory management is fully supported in all .NET compliant languages, including stuff like COBOL.
Inheritance and other OOP features and memory management is fully supported in all .NET compliant languages, including stuff like COBOL.
Originally posted by MichaeltheGreat
Objects written in one .NET compliant language are seamlessly compatible in all respects with objects written in any other .NET compliant language, so you can program in your preferred language or use the language tool best adapted to what you're doing. You also no longer have to care what language 3rd-party components or assemblies are written in, there are no compatibility issues.
Objects written in one .NET compliant language are seamlessly compatible in all respects with objects written in any other .NET compliant language, so you can program in your preferred language or use the language tool best adapted to what you're doing. You also no longer have to care what language 3rd-party components or assemblies are written in, there are no compatibility issues.
Originally posted by MichaeltheGreat
Dependence on the Windows registry and Win32 API calls is completely eliminated, so all .NET apps are fully compatible with all Win versions, if they're running the .NET framework.
Dependence on the Windows registry and Win32 API calls is completely eliminated, so all .NET apps are fully compatible with all Win versions, if they're running the .NET framework.
Originally posted by MichaeltheGreat
Memory leaks are eliminated by garbage collection, which can be invoked manually.
Memory leaks are eliminated by garbage collection, which can be invoked manually.
Comment