It is libertarian hogwash. It is advocating for a very dangerous form of laissez faire capitalism.
What about what I said was hogwash? What is the flaw in my reasoning? I'm not advocating 100% hands off here, I'm advocating choice. I'm advocating letting sick people who might have no other options try whatever they want to try to stay alive.
How is my comment flamebait? It was a serious suggestion. How about whomever modded down my comment post a rebuttal instead of just trying to hide something you don't agree with.
I fully understand the importance of the FDA. It is extremely important to the safety of the American public and its doctors to have a reliable and unbiased source of information regarding drugs.
One could argue that the market could regulate these drugs. If a drug company release a drug that did serious damage to 20% of the people taking it, this information would spread quickly and soon most people would stop taking that drug. But I would argue it is far better to have to undergo the rigorous testing the FDA puts most of the drugs through before they're made public so the dangers are known before it's available to most people.
On the other hand, I think there is a lot to be said for making the FDA an "informational" body only. In other words, it would do the same testing it does now, and all drugs would have to be submitted before release just as they are now, but regardless of the outcome of that testing the drug companies could make that drug publicly available. Before taking a drug, or before a doctor prescribes a drug, this database would be consulted to see the dangers and see how effective it is. The patients and doctors could then make their own decision as to whether or not this drug is good or bad.
If I'm dying of cancer I should be able to try anything I damn well please... in fact, if I've got a bad cold I should be able to try anything I damn well please. If I'm stupid and try the pharmacological equivalent of rat poison, then so be it... but the government shouldn't be able to limit my options.
I honestly don't understand much of your previous post.
You've provided reasons without evidence
No, I've both provided evidence of intentional misinformation in wikipedia that was not caught by the editing system, as well as pointing out logical flaws in the conclusions made by people referencing the Nature study.
you have no right to criticize those who have worked from evidence, even if they haven't performed a scientific study.
I have every right. You don't get to make sweeping generalizations based on person experience. This is illogical and unscientific and I have every right to criticize it. Who the hell are you to tell me what I can and cannot criticize?
I could have just been reading the wrong articles, but aren't graphics drivers in Linux kernel modules? The Linux kernel is a monolithic one, as most Unix kernels are. (Not including the Mach-based kernels, such as OS X.)
NT is far more like the Mach kernel than it is like a monolithic kernel. The graphics subsystem was moved into the kernel back in the NT 4 days because software rendering was the norm and performance was horrible. Now that hardware rendering and dedicated GPUs are the norm, this isn't really necessary and only serves to hurt reliability.
In addition, Microsoft's push to move most drivers out of the kernel is not one I see replicated elsewhere. Why have a printer driver as part of the kernel? It doesn't need that performance boost... at least not anymore.
Again, I'm not super-well versed on Linux driver implementation. Please, somebody provide some insight.
A formal randomly-sampled experiment is complex; people make judgements based on examination of a few items all the time.
A these people would be wrong it concluding that all the items on the menu are as high quality as the one they had. Just because most people make invalid conclusions doesn't all of a sudden make them valid!
I've backed up my claims with facts, as has Nature
You've backed up absolutely nothing, and the whole point of my post was to show that Nature's methods only allow us to conclude something about science articles on Wikipedia, not the accuracy of Wikipedia in general.
A sampling of science articles tells us about the science articles. That is a proper subject to judge an encyclopedia on. Not every study covers the entire world, nor should it.
I disagree, and I've provided reasons for my disagreement as well as links supporting my conclusions. People are concluding things about the quality of Wikipedia in general from a study that can only tell us about science articles. Studies obviously have built in limits to their scope. This is built in by how large of a sampling size they choose, what they chose to sample, etc.
Reading a handful of articles and saying "ya that looks good" is not a valid way of judging Wikipedia as a whole.
Your restaraunt analogy is flawed. A better analogy would be that one can conclude that the majority of restaraunts in Boston are good because I've been to two of them and they were good.
Nobody seems to want to bother to back up their claims with facts. Is it not possible that Wikipedia, while being a very interesting experiment, just doesn't work very well as far as ensuring accuracy?
I'm not claiming to know that Wikipedia is less accurate than any other encyclopedia. I'm simply saying that only sampling science articles isn't telling us what we need to know to judge it properly.
Considering me personally checking articles for accuracy is not a valid way of concluding anything about the accuracy of Wikipedia as a whole, no I have not.
As far as your conclusions, they are flawed. What about the process encourages neutral points of view? Simply because anybody can contribute? This assumes quite a bit about the demographics of the people using Wikipedia. It also assumes that intentional lies are caught more often than they are missed.
Many of the same unsupported assertions used to trumpted certain aspects of open source are made when defending Wikipedia. Just because more eyes can catch and correct mistakes does not mean that they actually do. Add to that the fact that there is basically nobody responsible for the content (unlike Britannica, which could be sued for knowingly publishing lies in one of its articles), I think people using Wikipedia as a resource need to be that much more careful.
Seems to me that science articles might not be the place category of articles to use to judge the accuracy of Wikipedia. I suspect that most people contributing to the science articles have a pretty good knowledge of the subjects in question... they're not things that most people know a lot about. Acheulean industry? Kinetic isotope effect? Meliaceae? Huh?
Where I suspect more errors abound in wikipedia is in the articles about things that a lot of people think they know a lot about, but in fact don't have any idea what they're talking about. Or topics in which people have a vested interest in misinforming people. (Political topics, for example.)
Honestly, a better comparison would have been a sampling of 100 or so randomly selected entries. Confining it to just science articles seems like an attempt to misrepresent the accuracy of wikipedia.
It absolutely is not the same. The CLR has native support for generics. The JVM does not. Period. It's a compiler trick in Java.
The differences aren't just with primitive types. They happen with all types. The impact is just typically the greatest with primitives.
The approaches could not be more different. Java's approach is to only address code generality. It allows developers to THINK they have a strongly typed collection class (or whatever), but in fact it's just going to get turned into a glorified array list of type Object.
The CLR/.NET's approach is to actually have the type evaluated runtime and turned into a fully strongly typed structure with all the benefits that has, both generality wise and speed wise.
Either you don't have a grasp of the concepts involved, or you're being extremely intellectually dishonest.
The CLR aka Common Language Runtime is what is the VM for Java. CLI is what is bytecode for Java.
Java is the term used to describe both the VM and the language. That's why I didn't make the distinction.
Regardignm generics, I can't get why everyone is repeating that old myth? Java WAS FIRST with GENERICS. C# 2.0 was just releast last month!! and C# 1.0 HAS NO GENERICS.
Yes, Java implemented Generics before C#, but Java's Generics are not true generics. The reason for this is a limitation imposed by the VM... a limitation that does not exist in the CLR.
There are two major benefits for using generics, code generality (you can create a collection class that can accept any kind of object yet still be strongly typed as apposed to just accepting "objects"), and speed.
With Java's generics you get the generality, but not the speed. Here is a comparitive overview to look at, although it's by the creator of C# so there is obviously some spin... but it's factually correct.
After all.NET applications are written with an IDE that hides most of the technologie, you don't learn how stuff really works and if somethign fails you hardly can figure whats wrong.
VS.NET hides nothing. All the code it generates is there for you to see. In addition, you don't have to use VS.NET. You can write it in notepad (or Emacs, or VI, or whatever) and compile from the command line, just like Java.
A good developer will know how the platform they use works regardless of the platform in question. I used to code a lot of VB 6 and I was quite familiar with the inner workings. ThunderMain anybody?
So it looks like you're right, JBoss is indeed used the most often, but expensive app servers still make up the vast majority of the market place for J2EE.
So while it wasn't the slam dunk I was hoping for to shut you up, it still supports my argument.
It was Gartner and Giga... and why do you have so much hate?
Are you not getting laid or something?
As far as more recent reports, I wasn't really able to find much data. Where are you getting YOUR data from? What evidence do you have that the market for J2EE app servers has changed dramatically over the past 4 or 5 years?
All the windows programmers who were using visual C++ and visual basic are now forced to use.NET.
Forced by who? VS.NET fully supports writing 100% unmanaged C++, and Microsoft is dedicated to supporting their unmanaged C++ libraries for a long, long time. In fact, one of the best parts of.NET/CLR is that you can use managed extensions for C++ and integrate with the.NET framework a little bit at a time.
As far as VB, official support ended in March I think, but VB 6 isn't going anywhere for a while. There will be legacy apps for many years, and via COM interop between those legacy apps and.NET is fully possible.
In a couple of years they will all be forced to use avalon and what ever else MS comes up with. MS programmer use whatever MS gives them.
Microsoft has been great, at the very least over the past 5 or 6 years, at listen to developer feedback and changing products accordingly. Microsoft gives developers what developers want (for the most part), and developers gladly use it because it allows us to make lots of money.
Visual studio lets you slap controls on a screen and call it an app.
Sure. It also gives you pretty much the best IDE for software development on the planet. It's great for developing everything from simply utility apps which are 75% drag/drop, as well as developing large scale enterprise applications. It all depends on the developer using it.
Never mind the fact that you have just built an application which will bog down in maintenance headaches for the rest of it's life, you built in a day!.
Huh? What does this have to do with VS? If the developer sucks it doesn't matter what tool they use to write the software... the software will suck.
This "ease of programming" is like crack to a MS programmer. They get a rush out of delivering their unmaintanable application in a week. To hell with a proper layering, logging, configuration, relational layers, and whatnot.
What the hell are you talking about? Come out of your cave man... or, better yet, stay in there and keep your foolish mouth shut.
Java portability is important to a minority of server application developers. Java portability is also somewhat of a myth for anything but fairly simple applications.
Regardless, portability can be important... or at least the options that Java gives you for choosing a server platform from scratch. With.NET, you're basically running on Windows no matter what at this point.
Projects like Mono are making progress, and their adoption is definitly increasing, but I'm not sure it will ever by significant.
By "in pretty much every case" I meant in pretty much every case where Java is used, not every application server.
The vast majority of Java app server usage is comprised of exactly two productions: WebSphere and WebLogic.
WebSphere and WebLogic both large companies ready to support you if you run into issues. (Although I think HP is starting to offer support for JBoss, which could help it increase its market share.)
For most mission critical deployments, WebSphere and WebLogic are the only choice for many companies just for that reason. The market share shows it.
Can someone explain to me how.NET is so fundamentally different from Java that it could escape Java's fate?
Well, I'm not sure what Java's fate is, but while.NET isn't fundamentally different than Java, it has several big differences.
As far as the CLR vs the Java runtime goes, Java byte code is fairly specific to java. It's possible to create non-Java languages that target the byte code, but it's not particularly practical. The CLR, on the other hand, was designed from the start with the idea of multiple language support.
It may not seem like a big deal to some, but being able to write more or less equally capable code in VB.NET, C#, J#, C++, Python, or a long list of other languages really does increase adoption.
The CLR affords far better platform specific integration than Java. JNI is complicated and horrible. COM Interop and API invocation in.NET is fairly easy and straight forward. This is important for adoption considering the huge amount of legacy code that often needs to be interop'd with.
The security framework built into.NET (Code Access Security) is arguably more refined and capable than the model built into Java. This doesn't really affect the current generation of applications, but for the v2.0 generation it will be very important due to ClickOnce deployment.
The CLR has support better support for a variety of programming constucts, such as generics, than Java does... or, in some cases did but the latest and greatest java releases have done a pretty good job and matching.NET's language feature set.
While both.NET and Java are free, the application servers they run on are not. For ASP.NET, IIS is the application server. For Java/J2EE, it could be Web Sphere or a variety of others. In pretty much every case a Windows license will be a lot cheaper than the license for the J2EE app server... especially Web Sphere.
As far as language comparison goes, it's not really all that useful since the CLR supports pretty much everything you could think of, including a nearly 1 to 1 copy of Java. (J#). But if we must, here is a great, although some what dated, comparison of Java and C#.
Isn't.NET (C# really) just a Java rip-off?
Not really. It's an evolutionary step. They certainly looked at Java, but they looked at everything. Managed runtimes were not invented by Sun. They've been around for 30 years. Microsoft creating.NET is a step toward Windows having a 100% managed API... something that's good for everybody. 10 years from now it will be rare to see an unmanaged application on Windows, aside from some niche areas. Java could never have done that because Sun wasn't in the position Microsoft is in.
Except that you can still use print statements (or System.Diagnostics.Debug.WriteLine, or whatever) in conjunction with a good IDE.
In fact, the best IDEs allow you to have the value of a variable or expression printed every time a particular part of your code is hit, without modifying that code at all. (VS.NET, for instance.)
In the end, you really shouldn't have to modify source code to figure out the value of variables at various points in the execution of that code.
Slashdot Mirror
It is libertarian hogwash. It is advocating for a very dangerous form of laissez faire capitalism.
What about what I said was hogwash? What is the flaw in my reasoning? I'm not advocating 100% hands off here, I'm advocating choice. I'm advocating letting sick people who might have no other options try whatever they want to try to stay alive.
How is my comment flamebait? It was a serious suggestion. How about whomever modded down my comment post a rebuttal instead of just trying to hide something you don't agree with.
I fully understand the importance of the FDA. It is extremely important to the safety of the American public and its doctors to have a reliable and unbiased source of information regarding drugs.
One could argue that the market could regulate these drugs. If a drug company release a drug that did serious damage to 20% of the people taking it, this information would spread quickly and soon most people would stop taking that drug. But I would argue it is far better to have to undergo the rigorous testing the FDA puts most of the drugs through before they're made public so the dangers are known before it's available to most people.
On the other hand, I think there is a lot to be said for making the FDA an "informational" body only. In other words, it would do the same testing it does now, and all drugs would have to be submitted before release just as they are now, but regardless of the outcome of that testing the drug companies could make that drug publicly available. Before taking a drug, or before a doctor prescribes a drug, this database would be consulted to see the dangers and see how effective it is. The patients and doctors could then make their own decision as to whether or not this drug is good or bad.
If I'm dying of cancer I should be able to try anything I damn well please... in fact, if I've got a bad cold I should be able to try anything I damn well please. If I'm stupid and try the pharmacological equivalent of rat poison, then so be it... but the government shouldn't be able to limit my options.
Windows Update does not refuse security related updates for non-authentic copies of Windows.
It is only optional updates, as well as other tools and support utilities.
Right from Wikipedia: "Security updates that address software vulnerabilities are available to all Windows users, with or without WGA validation".
I honestly don't understand much of your previous post.
You've provided reasons without evidence
No, I've both provided evidence of intentional misinformation in wikipedia that was not caught by the editing system, as well as pointing out logical flaws in the conclusions made by people referencing the Nature study.
you have no right to criticize those who have worked from evidence, even if they haven't performed a scientific study.
I have every right. You don't get to make sweeping generalizations based on person experience. This is illogical and unscientific and I have every right to criticize it. Who the hell are you to tell me what I can and cannot criticize?
Interix is a free download.
In addition, Windows Vista Server will have them pre-installed.
The fact of the matter is, very few people actually use Interix. There just isn't much of a demand.
I could have just been reading the wrong articles, but aren't graphics drivers in Linux kernel modules? The Linux kernel is a monolithic one, as most Unix kernels are. (Not including the Mach-based kernels, such as OS X.)
NT is far more like the Mach kernel than it is like a monolithic kernel. The graphics subsystem was moved into the kernel back in the NT 4 days because software rendering was the norm and performance was horrible. Now that hardware rendering and dedicated GPUs are the norm, this isn't really necessary and only serves to hurt reliability.
In addition, Microsoft's push to move most drivers out of the kernel is not one I see replicated elsewhere. Why have a printer driver as part of the kernel? It doesn't need that performance boost... at least not anymore.
Again, I'm not super-well versed on Linux driver implementation. Please, somebody provide some insight.
A formal randomly-sampled experiment is complex; people make judgements based on examination of a few items all the time.
A these people would be wrong it concluding that all the items on the menu are as high quality as the one they had. Just because most people make invalid conclusions doesn't all of a sudden make them valid!
I've backed up my claims with facts, as has Nature
You've backed up absolutely nothing, and the whole point of my post was to show that Nature's methods only allow us to conclude something about science articles on Wikipedia, not the accuracy of Wikipedia in general.
A sampling of science articles tells us about the science articles. That is a proper subject to judge an encyclopedia on. Not every study covers the entire world, nor should it.
I disagree, and I've provided reasons for my disagreement as well as links supporting my conclusions. People are concluding things about the quality of Wikipedia in general from a study that can only tell us about science articles. Studies obviously have built in limits to their scope. This is built in by how large of a sampling size they choose, what they chose to sample, etc.
Reading a handful of articles and saying "ya that looks good" is not a valid way of judging Wikipedia as a whole.
Your restaraunt analogy is flawed. A better analogy would be that one can conclude that the majority of restaraunts in Boston are good because I've been to two of them and they were good.
Nobody seems to want to bother to back up their claims with facts. Is it not possible that Wikipedia, while being a very interesting experiment, just doesn't work very well as far as ensuring accuracy?
I'm not claiming to know that Wikipedia is less accurate than any other encyclopedia. I'm simply saying that only sampling science articles isn't telling us what we need to know to judge it properly.
The POSIX subsytem in Windows is now called Interix. Some people disagree with your conclusion that the subsytem is a sham.
Maybe you just made the method call incorrectly.
Considering me personally checking articles for accuracy is not a valid way of concluding anything about the accuracy of Wikipedia as a whole, no I have not.
As far as your conclusions, they are flawed. What about the process encourages neutral points of view? Simply because anybody can contribute? This assumes quite a bit about the demographics of the people using Wikipedia. It also assumes that intentional lies are caught more often than they are missed.
Many of the same unsupported assertions used to trumpted certain aspects of open source are made when defending Wikipedia. Just because more eyes can catch and correct mistakes does not mean that they actually do. Add to that the fact that there is basically nobody responsible for the content (unlike Britannica, which could be sued for knowingly publishing lies in one of its articles), I think people using Wikipedia as a resource need to be that much more careful.
Seems to me that science articles might not be the place category of articles to use to judge the accuracy of Wikipedia. I suspect that most people contributing to the science articles have a pretty good knowledge of the subjects in question... they're not things that most people know a lot about. Acheulean industry? Kinetic isotope effect? Meliaceae? Huh?
Where I suspect more errors abound in wikipedia is in the articles about things that a lot of people think they know a lot about, but in fact don't have any idea what they're talking about. Or topics in which people have a vested interest in misinforming people. (Political topics, for example.)
Honestly, a better comparison would have been a sampling of 100 or so randomly selected entries. Confining it to just science articles seems like an attempt to misrepresent the accuracy of wikipedia.
It absolutely is not the same. The CLR has native support for generics. The JVM does not. Period. It's a compiler trick in Java.
The differences aren't just with primitive types. They happen with all types. The impact is just typically the greatest with primitives.
The approaches could not be more different. Java's approach is to only address code generality. It allows developers to THINK they have a strongly typed collection class (or whatever), but in fact it's just going to get turned into a glorified array list of type Object.
The CLR/.NET's approach is to actually have the type evaluated runtime and turned into a fully strongly typed structure with all the benefits that has, both generality wise and speed wise.
Either you don't have a grasp of the concepts involved, or you're being extremely intellectually dishonest.
The CLR aka Common Language Runtime is what is the VM for Java. CLI is what is bytecode for Java.
.NET applications are written with an IDE that hides most of the technologie, you don't learn how stuff really works and if somethign fails you hardly can figure whats wrong.
Java is the term used to describe both the VM and the language. That's why I didn't make the distinction.
Regardignm generics, I can't get why everyone is repeating that old myth? Java WAS FIRST with GENERICS. C# 2.0 was just releast last month!! and C# 1.0 HAS NO GENERICS.
Yes, Java implemented Generics before C#, but Java's Generics are not true generics. The reason for this is a limitation imposed by the VM... a limitation that does not exist in the CLR.
There are two major benefits for using generics, code generality (you can create a collection class that can accept any kind of object yet still be strongly typed as apposed to just accepting "objects"), and speed.
With Java's generics you get the generality, but not the speed. Here is a comparitive overview to look at, although it's by the creator of C# so there is obviously some spin... but it's factually correct.
After all
VS.NET hides nothing. All the code it generates is there for you to see. In addition, you don't have to use VS.NET. You can write it in notepad (or Emacs, or VI, or whatever) and compile from the command line, just like Java.
A good developer will know how the platform they use works regardless of the platform in question. I used to code a lot of VB 6 and I was quite familiar with the inner workings. ThunderMain anybody?
Damn, jumped the gun. I misread the article. The actual breakouts are:
JBoss: 34.8
WebSphere: 33.9%
WebLogic: 28.7%
Oracle: 22%
So it looks like you're right, JBoss is indeed used the most often, but expensive app servers still make up the vast majority of the market place for J2EE.
So while it wasn't the slam dunk I was hoping for to shut you up, it still supports my argument.
I found a report from 2005 that, ironically, is talking about open source app servers being underestimated market share wise.
The report concluded that the data points to the following breakout:
JBoss: 4.8%
WebSphere: 33.9%
WebLogic: 28.7%
Oracle: 22%
So it looks like while the industry might be only saying JBoss has 2% market share, it actually has more than twice that at close to 5%!
Guess what... I'm even MORE right than I thought I was. 90% of all J2EE app servers are VERY EXPENSIVE.
There ya go, "fuckwad".
It was Gartner and Giga... and why do you have so much hate?
Are you not getting laid or something?
As far as more recent reports, I wasn't really able to find much data. Where are you getting YOUR data from? What evidence do you have that the market for J2EE app servers has changed dramatically over the past 4 or 5 years?
All the windows programmers who were using visual C++ and visual basic are now forced to use .NET.
.NET/CLR is that you can use managed extensions for C++ and integrate with the .NET framework a little bit at a time.
.NET is fully possible.
Forced by who? VS.NET fully supports writing 100% unmanaged C++, and Microsoft is dedicated to supporting their unmanaged C++ libraries for a long, long time. In fact, one of the best parts of
As far as VB, official support ended in March I think, but VB 6 isn't going anywhere for a while. There will be legacy apps for many years, and via COM interop between those legacy apps and
In a couple of years they will all be forced to use avalon and what ever else MS comes up with. MS programmer use whatever MS gives them.
Microsoft has been great, at the very least over the past 5 or 6 years, at listen to developer feedback and changing products accordingly. Microsoft gives developers what developers want (for the most part), and developers gladly use it because it allows us to make lots of money.
Visual studio lets you slap controls on a screen and call it an app.
Sure. It also gives you pretty much the best IDE for software development on the planet. It's great for developing everything from simply utility apps which are 75% drag/drop, as well as developing large scale enterprise applications. It all depends on the developer using it.
Never mind the fact that you have just built an application which will bog down in maintenance headaches for the rest of it's life, you built in a day!.
Huh? What does this have to do with VS? If the developer sucks it doesn't matter what tool they use to write the software... the software will suck.
This "ease of programming" is like crack to a MS programmer. They get a rush out of delivering their unmaintanable application in a week. To hell with a proper layering, logging, configuration, relational layers, and whatnot.
What the hell are you talking about? Come out of your cave man... or, better yet, stay in there and keep your foolish mouth shut.
As usual, personal experience is not quite a large enough sample size to make the judgements you're making.
See my other post for sources.
If by my ass you mean Giga or Gartner, then yes... my ass.
Java portability is important to a minority of server application developers. Java portability is also somewhat of a myth for anything but fairly simple applications.
.NET, you're basically running on Windows no matter what at this point.
Regardless, portability can be important... or at least the options that Java gives you for choosing a server platform from scratch. With
Projects like Mono are making progress, and their adoption is definitly increasing, but I'm not sure it will ever by significant.
By "in pretty much every case" I meant in pretty much every case where Java is used, not every application server.
The vast majority of Java app server usage is comprised of exactly two productions: WebSphere and WebLogic.
WebSphere and WebLogic both large companies ready to support you if you run into issues. (Although I think HP is starting to offer support for JBoss, which could help it increase its market share.)
For most mission critical deployments, WebSphere and WebLogic are the only choice for many companies just for that reason. The market share shows it.
I forgot to post the language comparison between C# and Java. Sorry.
Can someone explain to me how .NET is so fundamentally different from Java that it could escape Java's fate?
.NET isn't fundamentally different than Java, it has several big differences.
.NET is fairly easy and straight forward. This is important for adoption considering the huge amount of legacy code that often needs to be interop'd with.
.NET (Code Access Security) is arguably more refined and capable than the model built into Java. This doesn't really affect the current generation of applications, but for the v2.0 generation it will be very important due to ClickOnce deployment.
.NET's language feature set.
.NET and Java are free, the application servers they run on are not. For ASP.NET, IIS is the application server. For Java/J2EE, it could be Web Sphere or a variety of others. In pretty much every case a Windows license will be a lot cheaper than the license for the J2EE app server... especially Web Sphere.
.NET (C# really) just a Java rip-off?
.NET is a step toward Windows having a 100% managed API... something that's good for everybody. 10 years from now it will be rare to see an unmanaged application on Windows, aside from some niche areas. Java could never have done that because Sun wasn't in the position Microsoft is in.
Well, I'm not sure what Java's fate is, but while
As far as the CLR vs the Java runtime goes, Java byte code is fairly specific to java. It's possible to create non-Java languages that target the byte code, but it's not particularly practical. The CLR, on the other hand, was designed from the start with the idea of multiple language support.
It may not seem like a big deal to some, but being able to write more or less equally capable code in VB.NET, C#, J#, C++, Python, or a long list of other languages really does increase adoption.
The CLR affords far better platform specific integration than Java. JNI is complicated and horrible. COM Interop and API invocation in
The security framework built into
The CLR has support better support for a variety of programming constucts, such as generics, than Java does... or, in some cases did but the latest and greatest java releases have done a pretty good job and matching
While both
As far as language comparison goes, it's not really all that useful since the CLR supports pretty much everything you could think of, including a nearly 1 to 1 copy of Java. (J#). But if we must, here is a great, although some what dated, comparison of Java and C#.
Isn't
Not really. It's an evolutionary step. They certainly looked at Java, but they looked at everything. Managed runtimes were not invented by Sun. They've been around for 30 years. Microsoft creating
Except that you can still use print statements (or System.Diagnostics.Debug.WriteLine, or whatever) in conjunction with a good IDE.
In fact, the best IDEs allow you to have the value of a variable or expression printed every time a particular part of your code is hit, without modifying that code at all. (VS.NET, for instance.)
In the end, you really shouldn't have to modify source code to figure out the value of variables at various points in the execution of that code.