> Another difference is that .NET was never intended to fully replace > native/non-managed code, but rather to inter-operate easily with it. > You often call into non-managed code and you can have fun with > pointers if you so choose (which probably explains why Mono has > success on Linux where there's a culture of calling out to existing > stuff). This is not all that different from the recent Android stack, > where you often do the "heavy lifting" using the NDK (C) and the rest > of the stuff with the SDK (Java).
That's true but I think they discourage it's use unless you really need it. I'm pretty sure that you can't use the non-managed code when doing C# in Silverlight apps. - Josh > > I think both are learning from each other though, it sounds like it > from people going to the .NET symposium (Charles Nutter etc.) and > that's great news regardless of whichever camp you belong to. I just > happen to like elements from both. :) > > /Casper > > On 14 Sep., 22:03, Joshua Marinacci <[email protected]> wrote: >> I just read through the link you sent. Interesting stuff. >> >> Yes, it's true that the CLR (which is what they are talking about, >> not >> C# the language, when referring to JIT stuff) was designed to be only >> JITed not interpreted; whereas Java was originally designed for more >> constrained devices (and 10 years earlier) and had interpreted VMs as >> a design goal. However, I'm pretty sure JIT support was one of the >> original design goals of Java as well, since JITs pre-date both the >> JVM and the CLR. >> >> In any case, in their article they are still talking about runtime >> dynamic optimizations, not static compilation down to machine code at >> development time. I think the confusion here is about the word >> 'compile'. Both the JVM and the CLR do Just In Time compilation, >> where bytecode (not source code) is transformed into machine code at >> *runtime*. What these iPhone projects are doing is turning source >> code or bytecode into Objective C code *at development time* and >> compiling that into machine code using standard native compilers. >> These are totally different senses of the word 'compile'. Neither the >> JVM nor the CLR had static compilation to machine code at development >> time down a design goal. Both of them *do* still compile their source >> into a virtual machine byte code, which is then interpreted or JITed >> at runtime. >> >> The JVM and the CLR are actually quite similar and have similar >> design >> goals. And they are part of the larger long term trend towards >> managed >> environment programming. The days of statically compiling C code and >> it's equivalents are quickly coming to an end, much as almost no one >> writes assembly anymore. >> >> - J >> >> On Sep 14, 2009, at 11:11 AM, Casper Bang wrote: >> >> >> >>>> something that's there in order to speed up emulation >> >>> That should've said "something that's there in order to speed up >>> interpretation". >> >>> Luckily you don't have take my word for it, I've digged this piece >>> up >>> for you by Bill Venners, Bruce Eckel and Anders Hejlsberg: >>> http://www.artima.com/intv/choices.html >> >>> Joshua is also right of course, Java can be statically compiled too. >>> But I did not claim Java could not be statically compiled, I said >>> that >>> C# was designed to always be compiled, Java was not. >> >>> /Casper > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
