> I've used well over a hundred of C#/.NET desktop apps on Windows. Not > a single one runs under Mono (although they run under Wine). I've used > a handful of C#/Mono applications on Linux. Not a single one runs on > Windows under .NET. If I write Hello World in C#/.NET with Visual > Studio I can't run that HelloWorld.exe through C#/Mono. This is the > exact opposite of the JVM world, where I've never even heard of a JVM > desktop app that didn't have Windows/Linux/Mac compatability. And if I > build a HelloWorld.jar in any Windows/Linux/Mac platform, it runs fine > on all the others. Citing the C# ISO/ECMA specs doesn't make a big > difference from a reality-perspective of using actual existing > software.
Sure it does, you are doing an apple to pear comparison. The fact is that no widget toolkit is mandated by C#, so you can not expect to be handed a UI that runs on all platforms. Think of it as a headless JRE, where you have to bundle your UI bindings accordingly (GTK/QT/Cocoa/ WPF). > Are you saying that there are no major successful Java GUI apps > outside of IDEs? Obviously, there are thousands of highly used, very > successful cross platform GUI apps written in a JVM-language, so I'm > not sure what you are trying to say. The cross platform GUI technology > works, has it's flaws of course, but it's great. Ok, well you still fail to mention some of these - it's rather easy to throw out a number like that. Cross platform UI can work yes, but what I am saying is that they don't work well enough to be worth the trouble. Which other programming language or platform mandates a UI? Can you honestly claim Swing has not been an underachiever on the desktop? Even newer JVM languages like Fantom have abandoned Swing. > Mono is simpler? That's basically developer preference. Lots of > developers claim their favorite tool is simpler, more elegant, more > powerful, etc. When I say it's simpler, it's because it doesn't have to cater to 20.000 classes in the runtime lib as the JRE has [http://bit.ly/ d4lB7x] and it generally favors simpler design decisions (you'll find no ClassLoader, no PermGenSpace to trip you over, no interpretation to slow startup). Mono is not my favorite tool, but if you follow both the JVM and the Mono space you'd know these differentiators. > Mono can statically compile? I assume you mean compile to CPU code vs > compile to VM code and have the VM convert to CPU code at run time or > load time. I don't quite follow your logic here. What is the advantage > of that? As I already mentioned, it's the reason why you find Mono on the iPhone and iPad. Why do you think Google didn't go with the JVM on Android? > I would presume that a product like MonoTouch compiles to an > intermediate representation of some kind and uses some pre existing > toolset or library from GNU or Apple or whomever to generate the > actual ARM v7 ISA CPU code, although I have no idea how that product > is actually implemented. I can see that the product requires an Apple > SDK. Do you actually know otherwise? AFAIK it only requires the SDK in order to be able to test and similar things tied to the toolchain. It's possible it's even Mono that's behind Apple's sudden U-tern in regards to section 3.3.1. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
