| |||||||||||||
Java != JVMJava != JVMPosted Mar 12, 2004 23:04 UTC (Fri) by ibukanov (subscriber, #3942)In reply to: Java != JVM by raytd Parent article: Will Mono Become the Preferred Platform for Linux Development? (O'ReillyNet) > I may be wrong, but I seriously doubt C# or Java ... 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. For server software as long as there is C or C++ code there is a risk of buffer overflow. 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. Java even with its language design problems and even with only features available currently in GCJ fits network-bounded-server role resonably well. C# could fit even better due to more flexible features. One can argue that functional languages or 100% safe versions of C would fit that role even better but searching Google for "open source Java" gives 5_490_000 results and for "open source OCaml" gives 20_100. Which tells something about amount of open source libraries available in Java and OCaml.
(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] 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 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.
|
|||||||||||||