be careful what you wish for...
on
Dell CEO Tells All
·
· Score: 4, Insightful
Conversely, you cannot say "I want all of the tax breaks and government s ubsidies of a company that is giving Americans jobs" while at the same time cherry-picking your labor pool from the cheapest of third-world labor. If you want to be a "global company"? Fine. Then relinquish your cushy benefits you get for supporting American interests.
Why don't you put some meat on your argument, demonstrating with actual figures that the tax breaks and "subsidies" (what subsidies?) Dell gets in the US are better than what they can achieve elsewhere.
I suspect the primary reason companies like Dell stay in the US is that they want to be on a US stock exchange. For various historical reasons, the US stock market has been the most attractive for companies since WWII. However, that may be changing now, and companies like Dell may take you at your word.
OSS advocates often decry Microsoft for stealing ideas from everyone left and right,
No, they don't. OSS developers, in fact, advocate the sharing and reuse of good ideas, and it isn't stealing if the ideas aren't patented. What technical people (whether OSS users or not) generally "decry" Microsoft for is that Microsoft is giving the false impression of having innovated in areas where they just copied.
yet Mozilla has to steal their advertising ideas from Apple?
Even if Apple had come up with the idea, it would be in the public domain. "Look how much better my life got after switching to product X" ads are older than radio. This is really just another instance of people wrongly attributing a common idea or someone else's invention to Apple. Apple may be using the idea right now, but that doesn't make it "theirs".
Have you considered that in fact Java might be a factor of 100x or more faster according to your own argument, because chances are there are already high performance or completed frameworks availaible for Java whereas you have none for C#?
Hard as that may be to believe, some people have to write that software. People like me, for example.
It's always fatser to use something existing, and with Java you have a huge variety of stuff, some of it even built in,
And most of it useless, duplicated junk. Besides, if Java doesn't let me add matrices using infix operators and if Java doesn't have value classes, libraries aren't going to fix that.
the new NIO packages are really fast and the reason Java spanks C# in IO performance (incidentially also of use in HPC).
Oh, stop confusing languages and platforms: Java is a platform, C# is a language.
Besides, with Mono on Linux, I get memory mapping and direct access to mapped files, in addition to full access to the POSIX APIs.
Furthermore JNI is not THAT hard.
JNI is comparatively high overhead, and Java lacks primitives for accessing native data structures efficiently. Furthermore, JNI requires the use of an entirely separate compiler and language.
All the arguments you make could be made for Fortran 77: "it's not that hard", "there are lots of libraries", "lots of people know it", etc. And, unlike Java, Fortran 77 is at least free, patent unencumbered, and mature. But, the fact is, better languages matter. C# is an open standard and it improves on Java in just those ways that experts on HPC themselves recommended Java be changed 6 years ago. Java failed to adopt those recommendations, Microsoft did and called the result "C#". It really is a no-brainer.
If seeing Portugese or English bothers people, there is a simple technical solution: apply language identification and just don't show content that's in the wrong language. Orkut can and should do this at the message and forum level. It could even offer automated translations "the wrong language" as a third option.
I said C# was slower than Java, but thought people might like a few numbers to back that up. Take a look Here. [tommti-systems.de]
You're barking up the wrong tree. I know that the C# implementation I'm using (Mono) is generally slower than Sun Java for comparable operations right now since I benchmarked it myself. But whether a language is better for HPC doesn't depend on whether a particular implementation is faster at this moment in time.
Furthermore, C# also seems to be very slow using lists. And to top it off Java was again about rwice as fast doing matrix operations!!! How does THAT make C# superior for high performance computing? What good is operator overloading for you if all your code runs twice as slow?
Well, if the factor is just 2, then the case is settled: C# already wins. Why? Because it's cheaper to write correct code that works but runs a little more slowly than to spend several times as much time trying to write code to fit into the Java straightjacket and then still having to spend extra time chasing down bugs resulting from the unintuitive way of expressing stuff.
Note also that C# makes it trivial to use truly high performance native libraries or even to write inner loops in C/C++ or Fortran myself, something that is hard in Java. Once you leave the Java straightjacket of poor language design, WORA, and JNI, things become a lot easier.
And these tests were all on the Microsoft VM, who is famous for writing REALLY good compilers.
You should go less by what you hear and think a bit more for yourself.
That might mean something to me if.Net were not currently slower than Java. But I guess no matter how slow a platform is, as long as it has "high-performance" support it must be better? I see... To claim that C# is so superior for High Performance computing, when it does not yet run on computers that are meant for same, just goes to show how far out of whack your vision of reality really is.
Let me spell it out for you:
The C# language is better than the Java language for high performance computing
Current CLR implementations are not as good as current JVM implementations for their common subset of functionality.
One is about the language, the other is about the implementation. The Java language has problems for HPC.
Now, let's look at a few more issues:
Sun has had the JavaGrande proposals on their table since 1998 and they haven't implemented most of them; in fact, they have stated that they will never implement most of them.
Mono is a couple of years old and already has a decent JIT, far ahead of where Sun's Java implementation was after two years.
So, every indication is that (1) the Java language won't get any better in these areas and (2) C# implementations are improving rapidly.
Here's a free clue for the day - most of your performance losses are going to come from algorithmic issues, not platform ones.
Here is your free clue for the day: when I need to fit almost 2 billion instances of a SinglePrecisionComplex number class into a 16G memory, I can do it with C#, whereas I need between 32G and 64G with Java. Try fixing that with algorithms.
You were posting about how Mono allows platform specific coding when Java allows exactly the same thing.
Java allows some platform specific coding, using add-on libraries. Unfortunately, there are many important platform-specific things I can't do with Java out of the box, or even with existing third party packages. Furthermore, writing native bindings to C/C++ libraries in Java is a lot of work compared to C#.
You say that Mono ships with native linux desktop bindings. Well, there are GTK bindings for Java,
Java doesn't ship with Gtk bindings, even on Linux, and most Java users on Linux aren't going to have them installed. All Mono users on Linux are going to have Gtk# installed, and, in fact, almost all Mono applications for Linux are written with Gtk#.
there is SWT for java which uses native widgets and there's Swing and AWT as well.
Neither SWT nor AWT are native bindings; they happen to use native widgets, but they don't give you anything like the native APIs, and they don't give you full access to native functionalities. And neither of them are desktop bindings, meaning they don't let you integrate fully with the desktop (although SWT seems to be better than Swing in that regard). AWT is so poorly designed and limited that it is useless anyway. And SWT doesn't ship with any certified Java implementation.
Furthermore, you can write native interfaces in Mono without ever having to write a line of C or C++ code--you just declare the C library interface in your C# code and call it. Try doing that in Java.
But this is exactly what Java does offer you through the GTK bindings or via SWT.
You misunderstood; I wasn't talking about "GUI interfaces", I was talking about "library interfaces", as I clearly stated. Java-GTK and SWT have nothing to do with calling arbitrary native C libraries.
In C# I can call any C function in any dynamic library without writing a line of C/C++ code. I can write C# code to efficiently access native data structures, to allocate and free memory with malloc, etc. You can't do that in Java, not the way it is, and not with any add-ons.
I'm sorry, but your problem is that you really just don't know what you are talking about and have not the slightest clue about what C# is. As a result, you attribute any criticism of Java to some kind of unfair persecution. But Java simply happens to be not very good technology; it never has been, Sun has had nearly a decade to fix it, people have given Sun extraordinary support and leeway, and they still have failed.
At this point, Sun Java is more of a marketing construct, a religious and blind pursuit of WORA that is of no use to most people. C# has taken Java and turned it into a fairly reasonable general purpose language that integrates well with existing systems, but can also be used to write WORA software, if you really want to. It's embarrassing, but in this case, Microsoft really does have the better technology. It's particularly embarrassing not because Microsoft had any great insights (they have just done something reasonable), but because Sun has been so incredibly stupid.
Second, diamonds (especially large, high quality diamonds) ARE still rare.
There are many rare minerals that cost hardly anything, so rarity doesn't make the difference.
Furthermore, many of those gemstones can be created artificially or have substitutes that are indistinguishable to the casual observer. The reason these are expensive is because they have become symbols of luxury and wealth, and that is a product of marketing.
that it requires more smarts to figure out how to use a Macintosh. In different, the Mac UI really has become more difficult than Windows or Linux. Mac is apparently not the computer for "the rest of us" anymore, but the computer for nerds.
I'm using Java to work with OpenGL and DirectX - is that platform specfic enough for you?
Did you write the OpenGL bindings yourself? Did you write the DirectX bindings yourself? Interfacing Java with native facilities is hard. And what Java ships with in terms of integration with Linux is poor. You can't even do signal handling or interact with the desktop out of the box.
Mono, in contrast, ships with native Linux desktop bindings: Gnome, Gtk+, XML libraries, etc. Furthermore, you can write native interfaces in Mono without ever having to write a line of C or C++ code--you just declare the C library interface in your C# code and call it. Try doing that in Java.
Your post is pure FUD - you've been able to write dirty Java from the outset.
Even if my statement were factually wrong (which it isn't), how would it be "FUD"? Do you even know what "FUD" is?
Face it, Sun isn't some small startup anymore that big companies try to keep down with FUD. Quite to the contrary: Sun is like IBM used to be in IBM's big-FUD-days: a threatened and dying behemoth with bad technology but lots of gullible customers. Sun at one point had it all: good technology and a huge market, but they lost it through stupidity and business mistakes to both Microsoft and open source. Now, Sun is trying to FUD their way out of their failure and incompetence by misrepresenting open source and Microsoft technologies and generally trying to create fear about everything other than their own products.
So, if you want to do something about FUD, make Sun shut up, because Sun is the biggest source of FUD on this planet.
The ironic thing about this is that Java actually offers a more fully featured API for writing code on Windows than.NET does.
I agree, but so what? I would go further and say that the.NET APIs suck and that you shouldn't use them. But we aren't talking about.NET on Windows. We are talking about Mono. The examples in Ars Technica don't use.NET, they use Gtk#.
Mono provides a huge set of APIs, much bigger than Microsoft.NET. In particular, Mono provides excellent bindings to native Linux APIs, including Gnome and Gtk. Those are APIs that OSS developers already know, that are mature, and that are proven, in contrast to Sun, which has produced a completely new and unfamiliar set of APIs.
The reality is that Java has a very well developed, secure and fully featured API..NET's API is extremely thin and of patchy quality.
The reality is that you are missing the point. The reality is that Java is a proprietary platform whose Linux desktop integration is charitably described as "mediocre at best". Mono, on the other hand, is an open source platform which integrates completely natively with the Linux desktop and Linux APIs because it uses the Linux native APIs.
That Mono also happens to give you cross-platform capabilities on top of that (through Gtk+ ports to Windows and.NET compatibility libraries on Linux) is an added bonus. But, in particular with Mono's Gtk# APIs, Linux comes first and everything else comes second, and that's the way I like it as a Linux developer.
It's a university--a place of learning and cooperation. You shouldn't lock it down any more than a campus should be run like a high security prison.
If the university actually did run the network securely, shutting down most ports, controlling what kind of software people get to install, enforcing password and security policies, then people would bitch about how much the network is run like a police state.
That doesn't mean individual services shouldn't be more careful--access to CCTV cameras should, perhaps, be locked down (or they should be completely open).
I think the best way is to do what C++ does: it also gives you both declared and undeclared exceptions, but it makes the "can throw everything" case the default for every function.
Value classes, unsafe modules, pointer arithmetic, call-by-reference, templates (implemented differently from Java), multidimensional arrays, operator overloading, to name some.
Yes, those are some differences. But even taken altogether, they are not so great.
Those differences are roughly what the JavaGrande forum recommended in 1998 for making Java suitable for high performance computing. Java still doesn't implement most of them, despite Sun's assurances that they would do this to the contrary.
So, maybe those differences don't matter to you, but they matter to people trying to write high-performance code: Java just doesn't cut it, while C# does.
what about profilers (like OptmizeIt) or memory tools? [...] But if you are writing anything real I would be hesitant to throw away the advantage of a wide range of analysis tools. And it only gets better in JDK 1.5 with a LOT of really nice monitoring features built into the VM.
What good do profilers do me if Java doesn't support high performance computing in the first place? What good is a memory profiler if Java doesn't give me the tools to control the layout of data structures?
In any case, code optimization doesn't require complicated tools or GUIs; a simple profiler that prints a textual report is sufficient. Anything really tricky requires careful manual instrumentation anyway.
If we want to have the option of a low-cost port to another environment we'll damn well ask for it.
Quite right. And the reason why "we" often don't want that option is because cross-platform capabilities come at a steep price. But, of course, you'll joyously accept a poor user experience, poor desktop integration, and longer development times just so that you can brag about how "portable" your software is.
As the parent no doubt accurately predicts, the biggest use of Mono will be the development of Gnome applications, Gnome being practically universal on corporate desktops these days.
Well, you just go ahead in your foolish belief that the corporate desktop is the only thing that matters in this world. You can compound your foolishness by going on to believe that Java has any relevance to the corporate desktop.
so Adobe and Borland will be quite happy to wait a little bit longer for Mono to accurately support all those tricky little Windows APIs
Given what a poorly designed piece of shit Adobe Acrobat Reader is, I think anything that keeps Adobe from porting more of their junk to Linux is to be welcomed. And Borland--are they even still in business?
Value classes, unsafe modules, pointer arithmetic, call-by-reference, templates (implemented differently from Java), multidimensional arrays, operator overloading, to name some.
There are (even in 1.4) many more similarities than differences.
And Madeleine Albright also has many more similarities with Claudia Schiffer than differences; which one would you rather have as your date? Differences can matter, even between things that are, over all, pretty similar.
And as I said the tool and platform support (like Ant) is much better with Java.
I think that's making lemonade from lemons. Java needed Ant because Java's compilation model was so odd that traditional UNIX tools didn't work. C# actually works very well with traditional UNIX tools because its compilation model is much closer to C/C++.
A year ago, some important tools were missing for Mono, but today, everything I need is there; Java may have more quantity, but how many tools do you need?
Any way you look at it, it makes little sense to go with MONO if you are considering tools to build a project.
It may make little sense to you. To me, Mono is already more useful than Java (and I have developed in Java for half a dozen years). Java never managed to replace C++ for my work because it just had too many limitations. C#, on the other hand, looks like it is going to eliminate C++ from my work once and for all.
I tried it and now I have 150 if/then statements around this one database call - is that OK?
No, it's not OK. In fact, it's just an indication that you don't know how to handle exceptional conditions in your code correctly. Correct exception handling is actually far easier than what Java tries to force you to do, which is why Java's exception declarations are such a misfeature.
Correct exception handling means that you identify a complete collection of locations in the code where you can safely reset your program to a known state and you place exception handlers in those locations (such a complete collection is usually quite small--often, only a single exception handler suffices). Furthermore, you identify those places where you need to protect resources with "try... finally", and you use "try... finally" religiously in every single such place, whether you believe that an exception can be thrown there or not. All other exception handlers are optional as far as correctness is concerned; you only add them if the functionality of your program calls for it, and that will be obvious from its requirements.
Strangely that assumption is quite widespread. I think I've tracked down the source [mono-project.com] though.
Yes, you have correctly tracked down the source of that misconception. It's an easy misconception to have, given what the Mono project writes about itself.
Now, dig down a little deeper and go to the downloads. What do you see? A "Mono Stack" on the left, consisting of OSS libraries and APIs, and a.NET stack on the right, consisting of.NET libraries and APIs. You can pick one or the other, or both. Neat, huh? Now, also note the relative sizes of the Mono and.NET stacks.
Now, turn to the FAQ:
Question 132: Is Mono only an implementation of the.NET Framework?
Mono implements both the.NET Framework, as well as plenty of class libraries that are either UNIX specific, Gnome specific, or that are not part of the.NET Framework but people find useful.
Question 50: Can mono run the WebMatrix?
No. That requires System.Windows.Forms support which is not currently implemented.
Question 40: Do you fear that Microsoft will change the spec and render Mono useless?
No. Microsoft proved with the CLI and the C# language that it was possible to create a powerful foundation for many languages to inter-operate. We will always have that.
Even if changes happened in the platform which were undocumented, the existing platform would a value on its own.
What does that tell you?
A lot of Mono software (most, in fact) already is completely incompatible with Microsoft.NET, since Mono doesn't even implement important parts of.NET, but does provide extensive non-.NET libraries that are being used by Mono applications. So,.NET compatibilty just doesn't matter to most Mono developers.
People know that Microsoft could change.NET, and it generally doesn't matter to them.
Why is the Mono project seemingly saying one thing and delivering another? Well, in part, it's because the term ".NET" is really ambiguous. In part, it's because where their money comes from and where their commercial interests are (they aren't doing this out of religion, they are in it for commercial purposes).
So, your confusion is understandable. I wish the Mono project were clearer on their front page, too, but I suspect they have reasons for what they are doing. Either way, you should really dig a little deeper.
The big problem with.NET is that Framework itself does tell you what exceptions might be thrown
Neither do the Java libraries. They tell you about some exceptions that might be thrown, but that makes it all the more dangerous because people incorrectly assume that they know all the exceptions that might be thrown and leave out essential exception handling code.
You should always write exception handling code as if anything could happen at any time.
Why does this article not go into the reasons why you would want to consider a platform years behind an exisitng one with similar capabilities, better cross-platform support, and way more tools.
Well, you may consider those self-evident truths, but there are many people who don't. For example, there are subtle but very important differences between the C# and Java languages (even with JDK 1.5). There are also many people who don't want cross-platform support.
Instead it just pretends that corss-platform wasn't even possible before MONO.
The article's mention of cross-platform features is bogus; what makes Mono so attractive to OSS developers is that it uses the same APIs OSS developers already know. The resulting programs are actually no more cross-platform than any other Gtk+/Gnome program, meaning, they will run on Windows and OS X, but they will work best on Linux.
There are legitimate concerns over how MS exerts it monopoly power, and many of the resultant concerns with Mono and its support of MS'.Net are not satisfactorily answered. What about MS total control of the standard?
It doesn't matter because that's not what Mono is about. Mono has two sets of APIs: OSS APIs and.NET APIs. You use the.NET APIs only if you either are trying to port Windows software to Linux or if you are a masochist. Most OSS developers are going to stick to the OSS APIs and never even install the.NET stuff.
Why not point out that C# is pretty close to a clone of the Java language, and that.Net is essentially the Java runtime environment, with MS additions. Why is.Net any better than Java for application development. Is its speed any better? Is Mono's speed any better than Java's?
C# and Java are quite similar, and C# is based closely on Java. But there are differences: C# allows you to declare unsafe modules, C# makes it easy to write platform-specific code, and C# has some other significant language differences. Whether that makes C# "better" or "worse" is a matter of perspective. Personally, I think it makes C# a better language, but there are obviously Java developers who vehemently disagree. Ultimately, you'll have to make up your own mind and vote with your feet.
Even though C# is a standardized language the.Net framework is not.
Mono is an implementation of ECMA C#, bindings of C# to OSS libraries like Gnome, Gtk, etc., and a reimplementation of the.NET framework.
I suspect most Mono developers never touch Mono's.NET framework (it's a separate download that you don't need unless you specifically want to develop.NET applications), so what Microsoft does or does not do with.NET doesn't matter to them.
I'm not sure we can be confident that Microsoft can't legally stop open source implementations of the the framework. Does anyone know what protection mono (and.gnu) have against legal threats?
Well, the most straightforward protection you can have is that you can use Mono without using the.NET framework; most people do that for technical reasons alone.
Beyond that, you can never be confident that someone with deep pockets isn't going to sue you if you sufficiently annoy them. However, the legal situation surrounding Mono's.NET implementation (which, again, you probably wouldn't be using anyway) has been scrutinized very carefully now, and all the facts are well known: all the patents that could apply are on the table, all the statements from the major players are out, etc. I haven't seen any smoking guns; if you find any, let us know.
Mono isn't all about cross-platform development, it's about giving you a more modern general purpose programming language than C/C++ and providing lots of useful bindings for it. Some of those bindings happen to be cross-platform, others don't. You really just get a choice.
As languages, C# and Python are simply different. Both have their uses, and neither is better. C#, for example, lets you do pointer manipulation and its implementations are efficient enough even for writing low-level loops. Also, people find C#'s static type checking useful for long-lived, multi-programmer projects. If all your needs are met by Python, consider yourself lucky; other people's needs are not that simple.
In terms of libraries, you can have Python/Gtk+, Python/wxWindows, C#/Gtk+, and C#/wxWindows, and all four exist (C#/wxWindows isn't all that far along yet, but people are working on it). So, your choice of toolkit and your choice of language are orthogonal.
What was the reasoning behind making the first letter of the method names upper case?
It's Microsoft's coding conventions. They apparently go back to some people the hired from other well-known research labs in the distant past. I think it's mostly an indication of the kind of insulation Microsoft has grown up in.
I'm sorry but the thought of microsoft's mangled conventions polluting the linux/unix world is making me ill.:-(
It's not pretty, but, frankly, from a traditional UNIX point of view, neither are the mixed case names so popular in other Java and C++ libraries either.
Personally, I think the C# folks make too much of a big deal about the mandatory exception handling in Java. Heard a fellow from Microsoft say "Frequently, Java folks just put an empty catch() block to catch the exception they know won't happen, so why make it mandatory?"
I've got bad news for you. I find situations like that about once a week when auditing my programmers' code, and it's almost always a situation that -can- happen, but the programmer couldn't see it.
I agree. And that's exactly what makes mandatory exception handling in Java such a problem: as you observe, programmers do, in fact, assume that certain exceptions can't happen. So, what do Java programmers do? They don't write a proper exception handler, they do write an empty catch block to make the type checker shut up. And, depending on the context, the result is a serious bug that wouldn't have been there without mandatory exception handling.
Secondly, because Java programmers believe that exception declarations tell them where exceptions happen, they fail to take into account that every single line of code can throw exceptions that don't need to be declared. Therefore, they tend to leave out essential clean-up and error recovery code.
Slashdot Mirror
Conversely, you cannot say "I want all of the tax breaks and government s ubsidies of a company that is giving Americans jobs" while at the same time cherry-picking your labor pool from the cheapest of third-world labor. If you want to be a "global company"? Fine. Then relinquish your cushy benefits you get for supporting American interests.
Why don't you put some meat on your argument, demonstrating with actual figures that the tax breaks and "subsidies" (what subsidies?) Dell gets in the US are better than what they can achieve elsewhere.
I suspect the primary reason companies like Dell stay in the US is that they want to be on a US stock exchange. For various historical reasons, the US stock market has been the most attractive for companies since WWII. However, that may be changing now, and companies like Dell may take you at your word.
OSS advocates often decry Microsoft for stealing ideas from everyone left and right,
No, they don't. OSS developers, in fact, advocate the sharing and reuse of good ideas, and it isn't stealing if the ideas aren't patented. What technical people (whether OSS users or not) generally "decry" Microsoft for is that Microsoft is giving the false impression of having innovated in areas where they just copied.
yet Mozilla has to steal their advertising ideas from Apple?
Even if Apple had come up with the idea, it would be in the public domain. "Look how much better my life got after switching to product X" ads are older than radio. This is really just another instance of people wrongly attributing a common idea or someone else's invention to Apple. Apple may be using the idea right now, but that doesn't make it "theirs".
Have you considered that in fact Java might be a factor of 100x or more faster according to your own argument, because chances are there are already high performance or completed frameworks availaible for Java whereas you have none for C#?
Hard as that may be to believe, some people have to write that software. People like me, for example.
It's always fatser to use something existing, and with Java you have a huge variety of stuff, some of it even built in,
And most of it useless, duplicated junk. Besides, if Java doesn't let me add matrices using infix operators and if Java doesn't have value classes, libraries aren't going to fix that.
the new NIO packages are really fast and the reason Java spanks C# in IO performance (incidentially also of use in HPC).
Oh, stop confusing languages and platforms: Java is a platform, C# is a language.
Besides, with Mono on Linux, I get memory mapping and direct access to mapped files, in addition to full access to the POSIX APIs.
Furthermore JNI is not THAT hard.
JNI is comparatively high overhead, and Java lacks primitives for accessing native data structures efficiently. Furthermore, JNI requires the use of an entirely separate compiler and language.
All the arguments you make could be made for Fortran 77: "it's not that hard", "there are lots of libraries", "lots of people know it", etc. And, unlike Java, Fortran 77 is at least free, patent unencumbered, and mature. But, the fact is, better languages matter. C# is an open standard and it improves on Java in just those ways that experts on HPC themselves recommended Java be changed 6 years ago. Java failed to adopt those recommendations, Microsoft did and called the result "C#". It really is a no-brainer.
If seeing Portugese or English bothers people, there is a simple technical solution: apply language identification and just don't show content that's in the wrong language. Orkut can and should do this at the message and forum level. It could even offer automated translations "the wrong language" as a third option.
I said C# was slower than Java, but thought people might like a few numbers to back that up. Take a look Here. [tommti-systems.de]
You're barking up the wrong tree. I know that the C# implementation I'm using (Mono) is generally slower than Sun Java for comparable operations right now since I benchmarked it myself. But whether a language is better for HPC doesn't depend on whether a particular implementation is faster at this moment in time.
Furthermore, C# also seems to be very slow using lists. And to top it off Java was again about rwice as fast doing matrix operations!!! How does THAT make C# superior for high performance computing? What good is operator overloading for you if all your code runs twice as slow?
Well, if the factor is just 2, then the case is settled: C# already wins. Why? Because it's cheaper to write correct code that works but runs a little more slowly than to spend several times as much time trying to write code to fit into the Java straightjacket and then still having to spend extra time chasing down bugs resulting from the unintuitive way of expressing stuff.
Note also that C# makes it trivial to use truly high performance native libraries or even to write inner loops in C/C++ or Fortran myself, something that is hard in Java. Once you leave the Java straightjacket of poor language design, WORA, and JNI, things become a lot easier.
And these tests were all on the Microsoft VM, who is famous for writing REALLY good compilers.
You should go less by what you hear and think a bit more for yourself.
Let me spell it out for you:
One is about the language, the other is about the implementation. The Java language has problems for HPC.
Now, let's look at a few more issues:
So, every indication is that (1) the Java language won't get any better in these areas and (2) C# implementations are improving rapidly.
Here's a free clue for the day - most of your performance losses are going to come from algorithmic issues, not platform ones.
Here is your free clue for the day: when I need to fit almost 2 billion instances of a SinglePrecisionComplex number class into a 16G memory, I can do it with C#, whereas I need between 32G and 64G with Java. Try fixing that with algorithms.
Java allows some platform specific coding, using add-on libraries. Unfortunately, there are many important platform-specific things I can't do with Java out of the box, or even with existing third party packages. Furthermore, writing native bindings to C/C++ libraries in Java is a lot of work compared to C#.
You say that Mono ships with native linux desktop bindings. Well, there are GTK bindings for Java,
Java doesn't ship with Gtk bindings, even on Linux, and most Java users on Linux aren't going to have them installed. All Mono users on Linux are going to have Gtk# installed, and, in fact, almost all Mono applications for Linux are written with Gtk#.
there is SWT for java which uses native widgets and there's Swing and AWT as well.
Neither SWT nor AWT are native bindings; they happen to use native widgets, but they don't give you anything like the native APIs, and they don't give you full access to native functionalities. And neither of them are desktop bindings, meaning they don't let you integrate fully with the desktop (although SWT seems to be better than Swing in that regard). AWT is so poorly designed and limited that it is useless anyway. And SWT doesn't ship with any certified Java implementation.
But this is exactly what Java does offer you through the GTK bindings or via SWT.
You misunderstood; I wasn't talking about "GUI interfaces", I was talking about "library interfaces", as I clearly stated. Java-GTK and SWT have nothing to do with calling arbitrary native C libraries.
In C# I can call any C function in any dynamic library without writing a line of C/C++ code. I can write C# code to efficiently access native data structures, to allocate and free memory with malloc, etc. You can't do that in Java, not the way it is, and not with any add-ons.
I'm sorry, but your problem is that you really just don't know what you are talking about and have not the slightest clue about what C# is. As a result, you attribute any criticism of Java to some kind of unfair persecution. But Java simply happens to be not very good technology; it never has been, Sun has had nearly a decade to fix it, people have given Sun extraordinary support and leeway, and they still have failed.
At this point, Sun Java is more of a marketing construct, a religious and blind pursuit of WORA that is of no use to most people. C# has taken Java and turned it into a fairly reasonable general purpose language that integrates well with existing systems, but can also be used to write WORA software, if you really want to. It's embarrassing, but in this case, Microsoft really does have the better technology. It's particularly embarrassing not because Microsoft had any great insights (they have just done something reasonable), but because Sun has been so incredibly stupid.
Second, diamonds (especially large, high quality diamonds) ARE still rare.
There are many rare minerals that cost hardly anything, so rarity doesn't make the difference.
Furthermore, many of those gemstones can be created artificially or have substitutes that are indistinguishable to the casual observer. The reason these are expensive is because they have become symbols of luxury and wealth, and that is a product of marketing.
that it requires more smarts to figure out how to use a Macintosh. In different, the Mac UI really has become more difficult than Windows or Linux. Mac is apparently not the computer for "the rest of us" anymore, but the computer for nerds.
I'm using Java to work with OpenGL and DirectX - is that platform specfic enough for you?
Did you write the OpenGL bindings yourself? Did you write the DirectX bindings yourself? Interfacing Java with native facilities is hard. And what Java ships with in terms of integration with Linux is poor. You can't even do signal handling or interact with the desktop out of the box.
Mono, in contrast, ships with native Linux desktop bindings: Gnome, Gtk+, XML libraries, etc. Furthermore, you can write native interfaces in Mono without ever having to write a line of C or C++ code--you just declare the C library interface in your C# code and call it. Try doing that in Java.
Your post is pure FUD - you've been able to write dirty Java from the outset.
Even if my statement were factually wrong (which it isn't), how would it be "FUD"? Do you even know what "FUD" is?
Face it, Sun isn't some small startup anymore that big companies try to keep down with FUD. Quite to the contrary: Sun is like IBM used to be in IBM's big-FUD-days: a threatened and dying behemoth with bad technology but lots of gullible customers. Sun at one point had it all: good technology and a huge market, but they lost it through stupidity and business mistakes to both Microsoft and open source. Now, Sun is trying to FUD their way out of their failure and incompetence by misrepresenting open source and Microsoft technologies and generally trying to create fear about everything other than their own products.
So, if you want to do something about FUD, make Sun shut up, because Sun is the biggest source of FUD on this planet.
The ironic thing about this is that Java actually offers a more fully featured API for writing code on Windows than .NET does.
.NET APIs suck and that you shouldn't use them. But we aren't talking about .NET on Windows. We are talking about Mono. The examples in Ars Technica don't use .NET, they use Gtk#.
.NET. In particular, Mono provides excellent bindings to native Linux APIs, including Gnome and Gtk. Those are APIs that OSS developers already know, that are mature, and that are proven, in contrast to Sun, which has produced a completely new and unfamiliar set of APIs.
.NET's API is extremely thin and of patchy quality.
.NET compatibility libraries on Linux) is an added bonus. But, in particular with Mono's Gtk# APIs, Linux comes first and everything else comes second, and that's the way I like it as a Linux developer.
I agree, but so what? I would go further and say that the
Mono provides a huge set of APIs, much bigger than Microsoft
The reality is that Java has a very well developed, secure and fully featured API.
The reality is that you are missing the point. The reality is that Java is a proprietary platform whose Linux desktop integration is charitably described as "mediocre at best". Mono, on the other hand, is an open source platform which integrates completely natively with the Linux desktop and Linux APIs because it uses the Linux native APIs.
That Mono also happens to give you cross-platform capabilities on top of that (through Gtk+ ports to Windows and
It's a university--a place of learning and cooperation. You shouldn't lock it down any more than a campus should be run like a high security prison.
If the university actually did run the network securely, shutting down most ports, controlling what kind of software people get to install, enforcing password and security policies, then people would bitch about how much the network is run like a police state.
That doesn't mean individual services shouldn't be more careful--access to CCTV cameras should, perhaps, be locked down (or they should be completely open).
That I think is the best way
I think the best way is to do what C++ does: it also gives you both declared and undeclared exceptions, but it makes the "can throw everything" case the default for every function.
Yes, those are some differences. But even taken altogether, they are not so great.
Those differences are roughly what the JavaGrande forum recommended in 1998 for making Java suitable for high performance computing. Java still doesn't implement most of them, despite Sun's assurances that they would do this to the contrary.
So, maybe those differences don't matter to you, but they matter to people trying to write high-performance code: Java just doesn't cut it, while C# does.
what about profilers (like OptmizeIt) or memory tools? [...] But if you are writing anything real I would be hesitant to throw away the advantage of a wide range of analysis tools. And it only gets better in JDK 1.5 with a LOT of really nice monitoring features built into the VM.
What good do profilers do me if Java doesn't support high performance computing in the first place? What good is a memory profiler if Java doesn't give me the tools to control the layout of data structures?
In any case, code optimization doesn't require complicated tools or GUIs; a simple profiler that prints a textual report is sufficient. Anything really tricky requires careful manual instrumentation anyway.
If we want to have the option of a low-cost port to another environment we'll damn well ask for it.
Quite right. And the reason why "we" often don't want that option is because cross-platform capabilities come at a steep price. But, of course, you'll joyously accept a poor user experience, poor desktop integration, and longer development times just so that you can brag about how "portable" your software is.
As the parent no doubt accurately predicts, the biggest use of Mono will be the development of Gnome applications, Gnome being practically universal on corporate desktops these days.
Well, you just go ahead in your foolish belief that the corporate desktop is the only thing that matters in this world. You can compound your foolishness by going on to believe that Java has any relevance to the corporate desktop.
so Adobe and Borland will be quite happy to wait a little bit longer for Mono to accurately support all those tricky little Windows APIs
Given what a poorly designed piece of shit Adobe Acrobat Reader is, I think anything that keeps Adobe from porting more of their junk to Linux is to be welcomed. And Borland--are they even still in business?
So what would you say these differences are?
Value classes, unsafe modules, pointer arithmetic, call-by-reference, templates (implemented differently from Java), multidimensional arrays, operator overloading, to name some.
There are (even in 1.4) many more similarities than differences.
And Madeleine Albright also has many more similarities with Claudia Schiffer than differences; which one would you rather have as your date? Differences can matter, even between things that are, over all, pretty similar.
And as I said the tool and platform support (like Ant) is much better with Java.
I think that's making lemonade from lemons. Java needed Ant because Java's compilation model was so odd that traditional UNIX tools didn't work. C# actually works very well with traditional UNIX tools because its compilation model is much closer to C/C++.
A year ago, some important tools were missing for Mono, but today, everything I need is there; Java may have more quantity, but how many tools do you need?
Any way you look at it, it makes little sense to go with MONO if you are considering tools to build a project.
It may make little sense to you. To me, Mono is already more useful than Java (and I have developed in Java for half a dozen years). Java never managed to replace C++ for my work because it just had too many limitations. C#, on the other hand, looks like it is going to eliminate C++ from my work once and for all.
I tried it and now I have 150 if/then statements around this one database call - is that OK?
... finally", and you use "try ... finally" religiously in every single such place, whether you believe that an exception can be thrown there or not. All other exception handlers are optional as far as correctness is concerned; you only add them if the functionality of your program calls for it, and that will be obvious from its requirements.
No, it's not OK. In fact, it's just an indication that you don't know how to handle exceptional conditions in your code correctly. Correct exception handling is actually far easier than what Java tries to force you to do, which is why Java's exception declarations are such a misfeature.
Correct exception handling means that you identify a complete collection of locations in the code where you can safely reset your program to a known state and you place exception handlers in those locations (such a complete collection is usually quite small--often, only a single exception handler suffices). Furthermore, you identify those places where you need to protect resources with "try
Yes, you have correctly tracked down the source of that misconception. It's an easy misconception to have, given what the Mono project writes about itself.
Now, dig down a little deeper and go to the downloads. What do you see? A "Mono Stack" on the left, consisting of OSS libraries and APIs, and a
Now, turn to the FAQ:
What does that tell you?
Why is the Mono project seemingly saying one thing and delivering another? Well, in part, it's because the term ".NET" is really ambiguous. In part, it's because where their money comes from and where their commercial interests are (they aren't doing this out of religion, they are in it for commercial purposes).
So, your confusion is understandable. I wish the Mono project were clearer on their front page, too, but I suspect they have reasons for what they are doing. Either way, you should really dig a little deeper.
The big problem with .NET is that Framework itself does tell you what exceptions might be thrown
Neither do the Java libraries. They tell you about some exceptions that might be thrown, but that makes it all the more dangerous because people incorrectly assume that they know all the exceptions that might be thrown and leave out essential exception handling code.
You should always write exception handling code as if anything could happen at any time.
Why does this article not go into the reasons why you would want to consider a platform years behind an exisitng one with similar capabilities, better cross-platform support, and way more tools.
Well, you may consider those self-evident truths, but there are many people who don't. For example, there are subtle but very important differences between the C# and Java languages (even with JDK 1.5). There are also many people who don't want cross-platform support.
Instead it just pretends that corss-platform wasn't even possible before MONO.
The article's mention of cross-platform features is bogus; what makes Mono so attractive to OSS developers is that it uses the same APIs OSS developers already know. The resulting programs are actually no more cross-platform than any other Gtk+/Gnome program, meaning, they will run on Windows and OS X, but they will work best on Linux.
There are legitimate concerns over how MS exerts it monopoly power, and many of the resultant concerns with Mono and its support of MS' .Net are not satisfactorily answered. What about MS total control of the standard?
.NET APIs. You use the .NET APIs only if you either are trying to port Windows software to Linux or if you are a masochist. Most OSS developers are going to stick to the OSS APIs and never even install the .NET stuff.
.Net is essentially the Java runtime environment, with MS additions. Why is .Net any better than Java for application development. Is its speed any better? Is Mono's speed any better than Java's?
It doesn't matter because that's not what Mono is about. Mono has two sets of APIs: OSS APIs and
Why not point out that C# is pretty close to a clone of the Java language, and that
C# and Java are quite similar, and C# is based closely on Java. But there are differences: C# allows you to declare unsafe modules, C# makes it easy to write platform-specific code, and C# has some other significant language differences. Whether that makes C# "better" or "worse" is a matter of perspective. Personally, I think it makes C# a better language, but there are obviously Java developers who vehemently disagree. Ultimately, you'll have to make up your own mind and vote with your feet.
Even though C# is a standardized language the .Net framework is not.
.NET framework.
.NET framework (it's a separate download that you don't need unless you specifically want to develop .NET applications), so what Microsoft does or does not do with .NET doesn't matter to them.
.gnu) have against legal threats?
.NET framework; most people do that for technical reasons alone.
.NET implementation (which, again, you probably wouldn't be using anyway) has been scrutinized very carefully now, and all the facts are well known: all the patents that could apply are on the table, all the statements from the major players are out, etc. I haven't seen any smoking guns; if you find any, let us know.
Mono is an implementation of ECMA C#, bindings of C# to OSS libraries like Gnome, Gtk, etc., and a reimplementation of the
I suspect most Mono developers never touch Mono's
I'm not sure we can be confident that Microsoft can't legally stop open source implementations of the the framework. Does anyone know what protection mono (and
Well, the most straightforward protection you can have is that you can use Mono without using the
Beyond that, you can never be confident that someone with deep pockets isn't going to sue you if you sufficiently annoy them. However, the legal situation surrounding Mono's
Mono isn't all about cross-platform development, it's about giving you a more modern general purpose programming language than C/C++ and providing lots of useful bindings for it. Some of those bindings happen to be cross-platform, others don't. You really just get a choice.
As languages, C# and Python are simply different. Both have their uses, and neither is better. C#, for example, lets you do pointer manipulation and its implementations are efficient enough even for writing low-level loops. Also, people find C#'s static type checking useful for long-lived, multi-programmer projects. If all your needs are met by Python, consider yourself lucky; other people's needs are not that simple.
In terms of libraries, you can have Python/Gtk+, Python/wxWindows, C#/Gtk+, and C#/wxWindows, and all four exist (C#/wxWindows isn't all that far along yet, but people are working on it). So, your choice of toolkit and your choice of language are orthogonal.
What was the reasoning behind making the first letter of the method names upper case?
:-(
It's Microsoft's coding conventions. They apparently go back to some people the hired from other well-known research labs in the distant past. I think it's mostly an indication of the kind of insulation Microsoft has grown up in.
I'm sorry but the thought of microsoft's mangled conventions polluting the linux/unix world is making me ill.
It's not pretty, but, frankly, from a traditional UNIX point of view, neither are the mixed case names so popular in other Java and C++ libraries either.
Personally, I think the C# folks make too much of a big deal about the mandatory exception handling in Java. Heard a fellow from Microsoft say "Frequently, Java folks just put an empty catch() block to catch the exception they know won't happen, so why make it mandatory?"
I've got bad news for you. I find situations like that about once a week when auditing my programmers' code, and it's almost always a situation that -can- happen, but the programmer couldn't see it.
I agree. And that's exactly what makes mandatory exception handling in Java such a problem: as you observe, programmers do, in fact, assume that certain exceptions can't happen. So, what do Java programmers do? They don't write a proper exception handler, they do write an empty catch block to make the type checker shut up. And, depending on the context, the result is a serious bug that wouldn't have been there without mandatory exception handling.
Secondly, because Java programmers believe that exception declarations tell them where exceptions happen, they fail to take into account that every single line of code can throw exceptions that don't need to be declared. Therefore, they tend to leave out essential clean-up and error recovery code.