| |||||||||||||
Will Mono Become the Preferred Platform for Linux Development? (O'ReillyNet)Will Mono Become the Preferred Platform for Linux Development? (O'ReillyNet)Posted Mar 12, 2004 17:19 UTC (Fri) by ncm (subscriber, #165)Parent article: Will Mono Become the Preferred Platform for Linux Development? (O'ReillyNet) No, thank you. If C# were the Right Thing for C++, Java would have been the Right Thing, earlier. As it happened, Java never caught on outside of those areas where its use was enforced by corporate directive, and there are very few Java programs meant for use by anyone not already using the language. There are good reasons for this. The problems that both languages try to solve are not problems that Free Software has. Free Software has much better solutions for its own problems, and has no need to trade off speed, power, and simplicity to solve them. Even portability to non-Unixy environments, the raison d'etre for a CLR, is not compelling: both Python programs and the Python interpreter have always been more portable than Java, to a much more varied range of target platforms.
(Log in to post comments)
typo Posted Mar 12, 2004 17:22 UTC (Fri) by ncm (subscriber, #165) [Link] Sorry, that should say "the Right Thing for Free Software".
Java != JVM Posted Mar 12, 2004 19:22 UTC (Fri) by ibukanov (subscriber, #3942) [Link] I presume by Java and C# in this context you actually mean JVM and CLI, right? Free Software does not need a portable bytecode indeed but as languages Java and C# are very reasonable and much more suitable for GUI and server applications then C/C++ due to supported garbage collection and impossibility to have buffer overflows. IMHO C# even contains enough syntax sugar to make programming in it as productive as in Python while providing benefits of static type system to catch many errors during compilation.GCJ makes it possible to write Java applications that easily integrates with the rest of Free Software and I only wish Mono guys would take the same approach to C#. And even if Microsoft holds patents to parts of the language itself (which I doubt as C# does not contains anything new, it just put known constructs in a reasonable basket), then dropping those features should not cripple the language.
Java != JVM Posted Mar 12, 2004 20:21 UTC (Fri) by ncm (subscriber, #165) [Link] The JVM/CLR and its follies constitute just part of the languages' problems.Other problems include the poor range of choices for libraries that comes with an immature language. Another (although this has less effect on adoption than it should) is faulty language design, insufficient, for example, to encapsulate resource management, or to localize exception handling. Another is the execution model (independent of VM games) that requires garbage collection, thus big footprint, thus poor cache locality, thus unavoidable sluggishness, and memory leaks (despite the GC) that never get fixed. Another is the unfortunate 16-bit character type, too narrow to represent all the scripts it should, but too wide to represent atomically in a file system. C++ works better than Java or C# for hard problems, and Python works better for easy problems, and for many hard problems too. There's plenty of overlap between them. Free Software just doesn't need a high-overhead language dropped into the middle of that overlap, unsuitable for either end of the spectrum.
Java != JVM Posted Mar 12, 2004 21:28 UTC (Fri) by raytd (guest, #4823) [Link] "...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.
Java != JVM Posted Mar 12, 2004 23:04 UTC (Fri) by ibukanov (subscriber, #3942) [Link] > 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.
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.
|
|||||||||||||