[SC-L] Could I use Java or c#? [was: Re: re-writing college books]

[robin at kallisti.net.nz (Robin Sheat)]

On Tuesday 14 November 2006 13:28, Crispin Cowan wrote:
> It means that compromising performance 
It's not necessarily a given that runtime performance is compromised. There 
are situations where Java is faster than C (I've tested this on trivial 
things). I'm sure there are situations where the reverse is true, too. But as 
new releases of the JVM come out, all Java programs get faster.

Personally, I find the programmer time to be much better used in Java too. 
That is less of a factor of the VM side of things (although you can do some 
really quite nice debugging things by communicating with the JVM which 
helps), but it does tend to be a feature of things that predominantly run 
inside some non-native environment. I don't know if there's a causation 
effect going on there or not however.

> to obtain runtime portability 
> that does not actually exist is a poor bargain.
The runtime portability is not perfect. The problems mostly exist where it 
interfaces to the underlying system, and where that's done imperfectly. Not 
so long ago, I ported a commercial desktop Java-based application from 
Windows to Linux. It took me a day or two to go through all the references to 
File, and make sure they were constructed properly (i.e. replace instances 
of '\\' with a properly constructed File) and do some testing, and that was 
all. It then looked and behaved just the same as it did on Windows, and 
objects could happily be de/reserialised across the different platforms (and 
on different architectures if necessary).

However, you never have to deal with different word sizes, different endians, 
and so on. It removes as many of the gotchas as is feasible. Back on the 
security topic for a moment, you also gain things like sandboxing that works 
in a way that isn't reliant on the capabilities of the hardware.

Robin.