Java != JVM [LWN.net]

Java != JVM

Posted Mar 12, 2004 21:28 UTC (Fri) by raytd (guest, #4823)
In reply to: Java != JVM by ibukanov
Parent article: Will Mono Become the Preferred Platform for Linux Development? (O'ReillyNet)

"...impossibility to have buffer overflows."

I used to know a guy that claimed he could code fortran in *any* language.

My first inclination is to think that for any language to be sufficiently powerful it should never *prevent* one from hanging {him,her}self; However, I don't necessarily think that it should be *easy* either.

"...programming in it [C#] as productive as in Python..."

I've come to love python more and more each time I use it, but I'm still a die-hard c coder. Nothing, and I mean *nothing* gives you the power and flexibily of c when you're coding close to bare-metal. I may be wrong, but I seriously doubt C# or Java (or anything else for that matter) will ever come close to providing the portability, ease of programming *and* performance one gets when coding the high-level in python and the low-level in c.

(Log in to post comments)

Java != JVM

Posted Mar 14, 2004 9:51 UTC (Sun) by joib (guest, #8541) [Link]

On the other hand Python is often too dynamic and many errors that would be caught in a staically typed language are happen at run time.

Personally, I think that static typing has its place, and that is in low level high performance languages like C/C++. For writing applications in a high level language like Java or python the argument is much weaker.

Write any non-trivial program in Java and it's almost certain that you'll make extensive use of the collections classes. Well gee, say goodbye to your type safety. The only thing that static typing gives you here is lots of type casts all over the place (Ugh!).

But I don't worry that much about the loss of static type safety. Unit tests (you do practice test driven development, now don't you?) will catch type errors, among many other things.

Java even with its language design problems and even with only features available currently in GCJ fits network-bounded-server role resonably well.

Personally, I would like to use python for this task too. But what saves Java, is that there is *a lot* of very high quality open source stuff for almost anything you can imagine. For starters, the spring framework and hibernate will take you a long way towards server-programming nirvana, despite the "over-verbosity" of Java. The only thing in the python world that even comes close is zope, and that is IMHO a bit too weird and un-pythonic. However, zope 3 does look promising, and I'm planning to take another look at zope once it's released.

High-level vs. low-level useless

Posted Mar 14, 2004 20:56 UTC (Sun) by ncm (subscriber, #165) [Link]

For modern languages, the distinction between "high-level" and "low-level" doesn't mean very much. A much more useful distinction is dynamic range -- how hard are the problems it's good for?

For easy problems almost any language will do -- speed doesn't matter, programs are small, and maintenance is easy, so coding convenience is the most important thing.

For hard problems, you need efficiency, apparatus to help organize lots of code, compile-time evaluation to abstract code generation, control of execution details to enable tuning, and effective compile-time error checking to make sweeping changes safe.

Python covers the easy-problem space easily, and reaches far up into hard-problem space. C++ has everything needed for the hardest problems, but is not so convenient to use for banging out trivia. Java and C# fall somewhere in the middle -- way too inconvenient to displace Python, but lacking most of the features needed to take on hard problems confidently.

Java != JVM

Posted Mar 18, 2004 12:05 UTC (Thu) by hjernemadsen (subscriber, #5676) [Link]

But that is not a problem with type safety, but rather a problem with the Java language. I you do the same thing in C++ you can use the STL-library, which amongst other things provides lists and sets of any type, with guaranteed type safety. So no type casts are needed, and you are guaranteed that you can only add the elements to the list, if they have the correct type.

In my experience having type safety catches many programming errors.

Java != JVM

Posted Mar 14, 2004 17:11 UTC (Sun) by oak (subscriber, #2786) [Link]

> On the other hand Python is often too dynamic and many errors that would be caught in a staically typed language are happen at run time.

If you have proper development process in place, these errors have been catched by your test cases and fixed. Test coverage testing tells whether you have enough test cases.

Or are you claiming that with statically typed langauges testing is not needed? :-)

Java != JVM

Posted Mar 15, 2004 7:39 UTC (Mon) by ibukanov (subscriber, #3942) [Link]

> Or are you claiming that with statically typed langauges testing is not needed? :-)

In a statically typed language you need less test suits since the compiler can do type checking.

Here is an example when test suite is a hard to achive option.

At work I have to maintain a driver of html pages so business data can be submitted autonatically against a web site that useses extremely complex JavaScript and ActiveX mixture in place of vanilla HTML forms. The driver uses a browser library to maintain the state of dynamic DOM and previosly used JavaScript to stuff the DOM with business data.

When the site changes it is critical to update the driver ASAP. Fortunately it is not that hard since the browser library continue to work and it is a matter of finding proper places in the new DOM for the data. Unfortunately any delay in that means that someone has to spend time enetering data manually into MSIE. So you simply can not afford time to create test suits which may not be even feasible since effectively you need a copy of the web site to test properly.

I stopped using JavaScript in the driver when after a couple of trivial mistypes that caused submittion of wrong data. The bug would be caught trivially by the compiler in a static language and now the driver is all in Java.