On Jan 18, 5:09 am, Casper Bang <[email protected]> wrote: > If you want a modern, static language catering to high performance, then C# > really is hard to beat. It has the best parts from Java but improves on it > across the board. When it comes to game development, being able to work on > unsigned types, use pointers, call native code, use stack based value types > (structs), use out parameters (i.e. implement swap), compile AOT (fast > launch), use SIMD instructions etc. is a big advantage. Those are some of > the things I remember the Unity (Mono) developers talking about > [http://unity3d.com/unity/].
I just posted links to benchmarks showing Java consistently outperforming C#/Mono by a wide margin across a whole suite of different benchmark tests. Instead of responding to these, you just repeat the standard C# talking points which we *just* talked about at length. Ideally, the JVM would be better and faster at scooping up some of the features from the CLR runtime. It would probably break too much legacy code to introduce unsigned integer types to Java, the language, but there is no reason it can't be added at the VM level where it can be optionally adopted by the alt language community. "That's why you can currently develop for iOS and Android devices, even if Microsoft makes no SDK available for these platforms (Xamarin does however)." The Mono team did an awesome job providing tool chains that included embedded CLR runtimes for devices like iOS/Android that don't have system level CLR runtimes. The same style of tool chains allow them to make apps for Google Chrome Native Client (NaCL) and now PlayStation Vita. I'd like to see the JVM community build something like this. I'd like to be able to use my favorite JVM languages/libraries/IDEs and make executables with an embedded JVM that can run by itself on Windows, or run in Google Chrome NaCL or potentially run on the Vita. You are saying that the licensing differences between CLR and the JVM prevent this from happening. Can you show me evidence of this? The Mono team could have done exactly the same thing with the JVM. Unfortunately, they didn't and no one else has, but I don't see any legal or technical barriers to this. "It [C#] has the best parts from Java but improves on it across the board" Generally, yes, C# the language is an incremental improvement upon Java the language. And the reason people choose Java is when the flexibility and community benefits outweigh the minor language level incremental improvements of C#. However, even Java the language has some better points. For example, Java has a richer set of enums with more type safety and more functionality. That's a small feature, but I use enums heavily in code that I write. A second point, is more features isn't always better. They give you more rope to hang yourself with. You can really see this with Scala; sometimes I look at some Scala code written by some Scala enthusiasts and it uses so many syntax features in such obscure ways, that it is impossible for mere mortals to understand. Secondly, the F#/Scala/Clojure languages aim to provide more than an incremental improvement on Java, they are aiming for a full paradigm shift. But, even if you don't want that full paradigm shift, and want a safer, incrementally improved OO language, the forthcoming language Kotlin looks to one up both C# and Java. Actually, if I were to name one of the bigger technical advantages of JVM over .NET: build tools. The .NET world is in the dark ages. They still use IDE auto-generated auto-maintained .csproj/msbuild files. In the Java world, even the old Ant was better than this. Then Maven came a long as a much better system and became the standard in the Java community. Now, we see Gradle or SBT emerging as the new bleeding edge. Rather than have a kludgy build script that requires tools to auto-edit to be usable, the Java world has build languages that are elegant enough to be maintined by hand, and developers can optionally add an IDE type tool on top of that. And while JVM's build tools put .NET in the dark ages, C/C++ and Haskell are even worse. They are still using makefiles where you have to encode logic to check the file date on your .o files and compile the .c (or .hs) files and name all your .o files to link them together... "In fact, Oracle has openly admitted that JNI was intentionally designed to be hard to use in order to push people to write pure Java." C/C++ allowed programmers to write unsafe code. And despite endless style guides and code reviews this frequently led to problems. Java completely stopped programmers from doing crazy pointer manipulation and gives you an absolute compiler level guarantee of protection from a whole class of problems that were rampant in the C/C++ world. At the same time, there are some cases, were you have to sacrifice runtime performance. C# made a different compromise and took a different trade off. Also, I've never used JNI directly, but I've used JOGL and JavaCL which use JNI internally and shield you from the details. -- 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.
