Unfortunately for your argument, C Sharp plus the CLS and the CLR do not equate to Dotnet. In fact, together they constitute are about 1/10th of the Dotnet APIs (120 out of 1250 classes and counting).
Rotor is only available for academic use and is highly restrictedm unlike, say Kaffe. And, of course, Rotor isn't not Dotnet - it's the CLR again.
Don't worry, this is a common mistake. I should know - this is approximately the 50th posting I've made correcting this on/. Obviously somebody's marketing is very effective...
Aha, you're right about Kazaa - the GNUtella client Limewire is in Java, not Kazaa.
But of course there are countless other client-side apps, notably the free ones. I'm sure you can do the comparisons with the numbers of Mono / C Sharp applications on Sourceforge for yourself.
I'm afraid I've no idea what point you are trying to make regarding SWT. Is there something wrong with being a wrapper per se? If so, does the same criticism apply to GTK# for C Sharp?
100% - we're talking about Dotnet-the-platform, remember?
I suggest you and your buddies finally throw in the towel with the the Dotnet-is-a-standard-because-C-Sharp-is bait-and-switch routine because for it's starting to confuse you more than your potential dupes.
Why go to a Debian site to ask about Kaffe when you can go to the Kaffe site?
You'll see from the email archives that they are busy implementing the latest JDK specifications, which are publically available. These are for J2SE 1.4.2 - there is no J2SE 2.x, perhaps this is the source of your confusion?
I have actually been quite impressed with what you can do with Visual Studio and.NET
And what can you do with this that you can't do with JBuilder or WebLogic Workshop? You do realize that these tools can create portals, workflow and web service systems using drag-and-drop? I'd be interested to see if all this was really in VS.NET.
Friedman is a well-known Mono propagandist, as has been covered in/. before (based on this article).
The rest of the comments above appear to follow the "let's play dumb" ploy that's been a distinctive feature of the Mono program from the outset. Three years after starting, there are still no concrete objectives listed on the project site. Can I really port my Dotnet application to Linux? Gee, that's a tough one - we'll get back to you...
The Mono vs. Java comparisons in particular are almost desperate in their attempt to mislead. All these statements have been refuted numerous times before on/., but it's clear that we're not dealing with people that can respond intelligently to objections, instead we're in the "Mono groundhog day" zone. Here, proponents are obliged to constantly restate discredited arguments in the hope that there are at least some new readers out there who are naive enough to be drawn in to their cloner "community".
FACT: Java has 3 million developers now, and is continuing to grow rapidly, both on the server side and now on the client side. (Millons of phones now support a JVM compared to... well, are there any Dotnet phones?)
FACT: Most of Dotnet is patented and not standardized. Anyone still resorting to the assertion that Dotnet is open because the C Sharp language is standardized is either hopelessly out of touch or being deliberately deceptive.
FACT: All of the Java platform is available on a free license for open-source developments, including the test suites. This is what the Kaffe people use. Nothing comparable exists for Dotnet whatsoever.
FACT: Java development happens under the JCP, an open process with a number of big players involved, not just one company.
The bottom line is that Java is, and has been for some time, a far better platform for Linux development than Mono. There are three very high quality commercial VMs freely available (from BEA, Sun and IBM) and dozens more for specialist platforms, plus of course an open-source implementation.
For some of us, hearing the latest Mono annoucement about how it's bringing some great new feature to Linux just a cause for amusement, since typically that feature has been available with Java for years. (One example comes from Friedman again, who mentioned the exciting possibility of Javascript on Mono "soon". Needless to say, Rhino, Javascript on the JVM project, has been around for some time (5 years to be precise)..
Others, apparently, are taken in by this nonsense and genuinely believe that they are adding features and helping open source by extending the reach of the Microsoft environment. It's time people woke up and realized that they are doing OS no favors, in fact, are likely to do it positive harm, to say nothing of the risk to their employers and associates.
Mono is an implementation of the.NET development platform.
Hopefully this will be updated to reflect the fact that Mono will only ever be a partial implementation of Dotnet, and that porting Dotnet applications to Mono will not be possible?
After all, we wouldn't want to mislead people, would we?
Conscious as I am of the incomparable force of bald assertion in/. debates, I venture to direct the attention of all those interested to the API linked in my earlier post.
Take a look at methods such as getChannel() on stream implementation classes such as FileInputStream.
Now recall that channels are part of NIO and did not exist prior to 1.4. A reasonable deduction is that the implementation of IO has changed to use NIO.
Though reasonable, I cannot claim to have made it since it appears in the book "JDK 1.4 Tutorial". Those possessing sufficient literary stamina and dedication to reach page 2 will be rewarded with the following:
"The New I/O API model coexists peacefully with the original I/O libraries from the java.io package. In fact, to a substantial degree, the original I/O libraries have been rewritten to take advantage of the New I/O API."
For what it's worth (and I appreciate that this may be very little) my experience is that since 1.4, java.io socket calls are throwing additional run-time exceptions, including more descriptive variants of IOException. This, to me, indicates that revised mechanisms are in operation beneath the covers.
I trust that this conclusion will not be too shocking to those of delicate disposition.
Given that the old IO APIs were rewritten to sit on top of NIO, I'd expect NIO to be breaking all those existing applications that use java.io. But that's not happening.
I follow the moth in the helicopter to lure it away from the flowers, and then Roy comes along in the Lockheed Starfighter and attacks it with air-to-air missiles.
I had a feeling that such an effort - making XML a complete general purpose language - must be out there (as opposed to the myriad of things like SAML which are actually complete but specialized).
I would have started with Scheme - not obvious why Self was chosen but it looks alright. Does it have macros though?!
How does this architectural approach lead you to conclude that Dotnet (an example of a statically optimizing system) must be superior to the JVM (a dynamically optimizing system)? Most academics have concluded the opposite.
I'm afraid I'm unable to 'keep in mind' your observation on what you imagine the execution-time dependencies of applications to be since
a) those writing Dotnet or Java applications are not primarily motivated by portability, and will not accept a big performance tradeoff from native code
b) in Java the supporting libraries are mostly written in Java
c) applications bound by I/O affect only response time, not throughput - performance of the code is still important for those threads that are not waiting
Lastly, I think you'll find that numerical libraries for Java are, like the general libraries, still written in Java - there is no native-code Linpack for Java, nor is that the direction of projects like Java Grande. The VM and its language are therefore the dominant factors in all aspects of performance.
True. And only a "troll" for those who refuse to acknowledge the need for a VM on Linux.
Of course, there are some excellent VMs for Linux. Observing Linux development discussions as their significance is slowly realized promises to be an interesting sport for/. spectators.
ROFL. I can just imagine putting the business case for migrating an existing Java application to Mono.
Yes I'd like to pay to reimplement this already functional, secure and stable application on Mono. Mono will give me fewer features, worse stability, dismal performance and limited support.
On completing this migration, my company will get to hold hands with a select band of deluded neophytes who daily give thanks that they haven't been sued by Microsoft.
I'd be interested in some benchmarks. My experience in fiddling with some numerically-intensive code is that Sun JVM 1.4.1 is about 4 times faster than a Dotnet release of 18 months ago. I haven't tried a more recent version.
Slashdot Mirror
Yes indeed.
/. Obviously somebody's marketing is very effective...
Unfortunately for your argument, C Sharp plus the CLS and the CLR do not equate to Dotnet. In fact, together they constitute are about 1/10th of the Dotnet APIs (120 out of 1250 classes and counting).
Rotor is only available for academic use and is highly restrictedm unlike, say Kaffe. And, of course, Rotor isn't not Dotnet - it's the CLR again.
Don't worry, this is a common mistake. I should know - this is approximately the 50th posting I've made correcting this on
Aha, you're right about Kazaa - the GNUtella client Limewire is in Java, not Kazaa.
But of course there are countless other client-side apps, notably the free ones. I'm sure you can do the comparisons with the numbers of Mono / C Sharp applications on Sourceforge for yourself.
I'm afraid I've no idea what point you are trying to make regarding SWT. Is there something wrong with being a wrapper per se? If so, does the same criticism apply to GTK# for C Sharp?
100% - we're talking about Dotnet-the-platform, remember?
I suggest you and your buddies finally throw in the towel with the the Dotnet-is-a-standard-because-C-Sharp-is bait-and-switch routine because for it's starting to confuse you more than your potential dupes.
Why go to a Debian site to ask about Kaffe when you can go to the Kaffe site?
You'll see from the email archives that they are busy implementing the latest JDK specifications, which are publically available. These are for J2SE 1.4.2 - there is no J2SE 2.x, perhaps this is the source of your confusion?
I have actually been quite impressed with what you can do with Visual Studio and .NET
And what can you do with this that you can't do with JBuilder or WebLogic Workshop? You do realize that these tools can create portals, workflow and web service systems using drag-and-drop? I'd be interested to see if all this was really in VS.NET.
Well, I'm a programmer so I use JBuilder, WebLogic Workshop and WebSphere Studio.
Possibly you have heard of Kazaa?
FWIW, Java/GTK already has a developer or two in the form of IBM. I'd be very interested to see examples of equivalent levels of investment in Mono.
Number of classes standardized with C Sharp and the CLR: ~120
Number of classes in the rest of Dotnet and hence unstandardized: ~1250
As you say, not complex.
Friedman is a well-known Mono propagandist, as has been covered in /. before (based on this article).
/., but it's clear that we're not dealing with people that can respond intelligently to objections, instead we're in the "Mono groundhog day" zone. Here, proponents are obliged to constantly restate discredited arguments in the hope that there are at least some new readers out there who are naive enough to be drawn in to their cloner "community".
The rest of the comments above appear to follow the "let's play dumb" ploy that's been a distinctive feature of the Mono program from the outset. Three years after starting, there are still no concrete objectives listed on the project site. Can I really port my Dotnet application to Linux? Gee, that's a tough one - we'll get back to you...
The Mono vs. Java comparisons in particular are almost desperate in their attempt to mislead. All these statements have been refuted numerous times before on
FACT: Java has 3 million developers now, and is continuing to grow rapidly, both on the server side and now on the client side. (Millons of phones now support a JVM compared to... well, are there any Dotnet phones?)
FACT: Most of Dotnet is patented and not standardized. Anyone still resorting to the assertion that Dotnet is open because the C Sharp language is standardized is either hopelessly out of touch or being deliberately deceptive.
FACT: All of the Java platform is available on a free license for open-source developments, including the test suites. This is what the Kaffe people use. Nothing comparable exists for Dotnet whatsoever.
FACT: Java development happens under the JCP, an open process with a number of big players involved, not just one company.
The bottom line is that Java is, and has been for some time, a far better platform for Linux development than Mono. There are three very high quality commercial VMs freely available (from BEA, Sun and IBM) and dozens more for specialist platforms, plus of course an open-source implementation.
For some of us, hearing the latest Mono annoucement about how it's bringing some great new feature to Linux just a cause for amusement, since typically that feature has been available with Java for years. (One example comes from Friedman again, who mentioned the exciting possibility of Javascript on Mono "soon". Needless to say, Rhino, Javascript on the JVM project, has been around for some time (5 years to be precise)..
Others, apparently, are taken in by this nonsense and genuinely believe that they are adding features and helping open source by extending the reach of the Microsoft environment. It's time people woke up and realized that they are doing OS no favors, in fact, are likely to do it positive harm, to say nothing of the risk to their employers and associates.
That's funny, the Mono site says:
.NET development platform.
Mono is an implementation of the
Hopefully this will be updated to reflect the fact that Mono will only ever be a partial implementation of Dotnet, and that porting Dotnet applications to Mono will not be possible?
After all, we wouldn't want to mislead people, would we?
Would it not be easier
In that case for the government
To dissolve the people
And elect another?
(c) 1953 Berthold Brecht
Funny... big content providers like this one, you mean?
Oh, I see, you mean stuff like this.
That's easy then, I choose to "lump it", no question.
And thanks for asking!
Conscious as I am of the incomparable force of bald assertion in /. debates, I venture to direct the attention of all those interested to the API linked in my earlier post.
Take a look at methods such as getChannel() on stream implementation classes such as FileInputStream.
Now recall that channels are part of NIO and did not exist prior to 1.4. A reasonable deduction is that the implementation of IO has changed to use NIO.
Though reasonable, I cannot claim to have made it since it appears in the book "JDK 1.4 Tutorial". Those possessing sufficient literary stamina and dedication to reach page 2 will be rewarded with the following:
"The New I/O API model coexists peacefully with the original I/O libraries from the java.io package. In fact, to a substantial degree, the original I/O libraries have been rewritten to take advantage of the New I/O API."
For what it's worth (and I appreciate that this may be very little) my experience is that since 1.4, java.io socket calls are throwing additional run-time exceptions, including more descriptive variants of IOException. This, to me, indicates that revised mechanisms are in operation beneath the covers.
I trust that this conclusion will not be too shocking to those of delicate disposition.
Hmmm... really?
Given that the old IO APIs were rewritten to sit on top of NIO, I'd expect NIO to be breaking all those existing applications that use java.io. But that's not happening.
Do you have links to the relevant bug reports?
These include:
There's also a transparently obvious move to appeal to the
Ob. Python link: Mosquito Hunting
I follow the moth in the helicopter to lure it away from the flowers, and then Roy comes along in the Lockheed Starfighter and attacks it with air-to-air missiles.
Uh, unfortunately I'm obliged to retract my endorsement - it's not XML at all!
In fact, Water is pretty eccentric all over.
I'm afraid it's back to Scheme and SXML for me...
Very interesting, thanks!
I had a feeling that such an effort - making XML a complete general purpose language - must be out there (as opposed to the myriad of things like SAML which are actually complete but specialized).
I would have started with Scheme - not obvious why Self was chosen but it looks alright. Does it have macros though?!
Er, no.
J2EE servers use the same VMs as regular Java apps. JVMs use JITs.
All JITs are capable of more optimizations than the static compiler used in Dotnet.
How does this architectural approach lead you to conclude that Dotnet (an example of a statically optimizing system) must be superior to the JVM (a dynamically optimizing system)? Most academics have concluded the opposite.
I'm afraid I'm unable to 'keep in mind' your observation on what you imagine the execution-time dependencies of applications to be since
a) those writing Dotnet or Java applications are not primarily motivated by portability, and will not accept a big performance tradeoff from native code
b) in Java the supporting libraries are mostly written in Java
c) applications bound by I/O affect only response time, not throughput - performance of the code is still important for those threads that are not waiting
Lastly, I think you'll find that numerical libraries for Java are, like the general libraries, still written in Java - there is no native-code Linpack for Java, nor is that the direction of projects like Java Grande. The VM and its language are therefore the dominant factors in all aspects of performance.
True. And only a "troll" for those who refuse to acknowledge the need for a VM on Linux.
/. spectators.
Of course, there are some excellent VMs for Linux.
Observing Linux development discussions as their significance is slowly realized promises to be an interesting sport for
"Tide over" in the sense of "implementing 1/4 of the APIs", I presume.
Anybody with any sense who wants the features of Dotnet for Unix will be using Java.
ROFL. I can just imagine putting the business case for migrating an existing Java application to Mono.
Yes I'd like to pay to reimplement this already functional, secure and stable application on Mono. Mono will give me fewer features, worse stability, dismal performance and limited support.
On completing this migration, my company will get to hold hands with a select band of deluded neophytes who daily give thanks that they haven't been sued by Microsoft.
Gosh, sounds like XML-RPC.
Guess which came first?
.Net has is superior native execution
I'd be interested in some benchmarks. My experience in fiddling with some numerically-intensive code is that Sun JVM 1.4.1 is about 4 times faster than a Dotnet release of 18 months ago. I haven't tried a more recent version.
How about a less loaded term?
Something neutral like Enabling Act would be far more acceptable
(Ermächtigungsgesetz in the original).