Softpanorama Java Bulletin, 2001

[Nov 19. 2001] A Comparative Overview of C#

Overall, I believe C# provides greater expressiveness and is more suited to writing performance-critical code than Java, while sharing Java's elegance and simplicity, which makes both much more appealing than C++.

[Nov 19. 2001] C# From a Java Developer's Perspective  -- Please read this article with the same grain of salt you would read a Linux advocacy article from the CEO of RedHat.

Most developers, especially those with a background in C or C++, would probably agree that features like operator overloading, pointers, preprocessor directives, delegates and deterministic object cleanup make C# more expressive than Java in a number of cases. Similarly, Java developers who learn C# will be pleasantly surprised at features that are missing in Java that will seem glaring in their absence once one uses them in C#, such as boxing, enumerations and pass by reference. On the other hand the lack of checked exceptions, inner classes, cross platform portability or the fact that a class is not the smallest unit of distribution of code makes the choice of C# over Java not a clearcut case of choosing more language features without having to make any compromises.

It is my opinion that both languages are similar enough that they could be made to mirror each other without significant effort if so required by either user base. In this case, C# would have it easier than Java in that C# has less to borrow from Java than Java would have to borrow from C#. However, the true worth of a programming language that is intended for use outside of academia is how quickly the language evolves to adapt to the changing technological landscape and what kind of community surrounds the language. Some programming languages are akin to the French language under the Les Immortels of the Académie Française in France. Les immortels are charged with dictating what constitutes the official French language but they have been slow to adapt to the information age thus their edicts on what constitutes the proper French versions of new words, especially those related to technology, are usually ignored especially since they either conflict with what the general French public would rather call them and show up long after the unsanctioned words have already entered the lexicon. C++ is an example of a language that has undergone a process of balkanization closely resembling the French language under the Les Immortels of the Académie Française while Java under Sun Microsystems can be considered to be a language that has evolved with the times similar to how the English language has done.

Thus the question really becomes, which of these languages looks like it will evolve with the times and be easiest to adapt to new situations as they arise? So far, Sun has done a great job with Java although a lack of versioning support and the non-existence of a framework that enables extensibility of the language built into the platform makes drastic evolution difficult. C# with its support for versioning via the .NET framework and the existence of attributes which can be used to extend the features of the language looks like it would in the long run be the more adaptable language. Only time will tell however if this prediction is accurate.

See also Slashdot comments Slashdot C# From a Java Developer's Perspective

array error (Score:1) by feldkamp on Monday November 19, @11:27PM (#2587856) (User #146657 Info)

ok, i'm nitpicking, but... From the article: "In languages like C and C++, each subarray of a multidimensional array must have the same dimensions. In Java and C# arrays do not have to be uniform because jagged arrays can be created as one-dimensional arrays of arrays" In C, C++, or any other language that allows pointers and runtime memory allocation you can set up jagged multidimensional arrays almost as easily. You have to use pointers, but that's no biggie.

[ Reply to This | Parent ]

Laundry list of corrections (Score:1) by coonsta on Tuesday November 20, @12:46AM (#2588026) (User #141485 Info)

I think this is a bit Java biased, in that it uses some very precise wording and fails to mention a lot of relevant features of C# until the appendix-like section D. And it contains some outright mistakes. My corrections: A.2: Java doesn't have an "unsafe" keyword; C# and Java have a "volatile" keyword that is strangely missing. And don't you think it's strange that he doesn't equate C#'s "extern" with Java's "native"? They're approximately the same. A.5: Neglects to mention here that C# has square *and* jagged arrays, it is stuck in section D. A.10: The phrase "both languages have an inheritance hierarchy where all exceptions are derived from a single Exception class" is a tautology, because "all exceptions" *are* exceptions because they extend Exception! Whereas if he meant to say "all objects that can be thrown are instances of types derived from a single Exception class" he would be wrong, because in Java these all derive from java.lang.Throwable. The sentence two sentences after that one, starting "Finally, both languages..." does not make sense. B.8: The last statement in this paragraph is incorrect. Isn't it possibly in Java to simply write ArrayList.class, if java.util.ArrayList has been imported? Likewise in C#, where if System.Collections has not been using'ed it is necessary to write typeof(System.Collections.ArrayList). C.1: This really should mention delegates here. It was inner classes v. delegates that heated up the Sun vs. J++ debate. Thus C# doesn't suffer a "lack" of inner classes, rather it suffers an ideological difference with Java, don't you think? And likewise, Java doesn't suffer a "lack" of delegates. C.3: The criticism that, for example, it is possible to overload "", and this makes overloading bad, and C# has overloading, hence C# is bad-- is nonsense! In C# it is illegal to overload, for example "", or "==" but not "!=". It also says "()" (I assume meaning cast) and "[]" can not be overloaded. This is again very precise and misleading language. They can not be overloaded, because custom conversions and indexers can be used instead! It also fails to mention that "&&", etc. will call "&". The blanket statement that "&&", "||", etc. "can not be overloaded" is very misleading. C.4: You can "fall through" in C#, with goto. Except unlike Java, in C# it is explicit (and more flexible). Fails to mention Java's limited range of "switch" statements, whereas e.g. C# can switch on a ulong. C.5: Seems to miss the distinction between *assemblies* and *modules*. C.6: Some of these criticisms are unfair, e.g. that Java has thread-safe collections. In C#, a reference to a synchronized wrapper can be kept and the un-thread safe reference be let go out of scope! Not mentioning boxing and unboxing here is a failure: one of the chief gripes with Java's collections is that it is necessary to wrap the primitive types in their class equivalents. C.7: Java has a labeled goto of sorts-- break and continue. Thus some of the criticisms of the weakness of languages with goto may also be applied to Java. C.8: Is this section intended to confuse? The fact that marking a method final in Java means that subclasses cannot contain a method with a similar signature is a *coincidence* arising from the fact that (a) final means methods can not be overridden and (b) Java does not have new/reintroduce semantics and relies instead of the name and parameters. Thus C#'s final achieves exactly the same as Java's in terms of dynamic linking and dispatch-- that a particular method can not be overridden. D.3: Should probably mention that .NET has an attribute for marking enumerations as able to be used in bitwise combination, whereas this is always possible (whether correct or not) in a Java pseudo-enumeration with int members. On the other hand, the "workaround" in Java makes this impossible-- you can't "or" objects.

[Sept 8, 2001] Lisp as an Alternative to Java

Introduction

In a recent study [1], Prechelt compared the relative performance of Java and C++ in terms of execution time and memory utilization. Unlike many benchmark studies, Prechelt compared multiple implementations of the same task by multiple programmers in order to control for the effects of differences in programmer skill. Prechelt concluded that, "as of JDK 1.2, Java programs are typically much slower than programs written in C or C++. They also consume much more memory."

We have repeated Precheltнs study using Lisp as the implementation language. Our results show that Lisp's performance is comparable to or better than C++ in terms of execution speed, with significantly lower variability which translates into reduced project risk. Furthermore, development time is significantly lower and less variable than either C++ or Java. Memory consumption is comparable to Java. Lisp thus presents a viable alternative to Java for dynamic applications where performance is important.

Conclusions

Lisp is often considered an esoteric AI language. Our results suggest that it might be worthwhile to revisit this view. Lisp provides nearly all of the advantages that make Java attractive, including automatic memory management, dynamic object-oriented programming, and portability. Our results suggest that Lisp is superior to Java and comparable to C++ in terms of runtime, and superior to both in terms of programming effort, and variability of results. This last item is particularly significant as it translates directly into reduced risk for software development.

Slashdot Lisp as an Alternative to Java

There is more data available for other languages.. (Score:4, Interesting) by crealf on Saturday September 08, @07:53AM (#2266890) (User #414283 Info)

The article about Lisp is a follow-up of an article by Lutz Prechelt in CACM99 (a draft [ira.uka.de] is available on his page along with other articles). However there is more data now, as, Prechelt itself widdened the study, and published in 2000 An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl [ira.uka.de] (a detailed technical report is here [ira.uka.de]). If you look, from the developer point of view, Python and Perl work times are similar to those of Lisp, along with program sizes. Of course, from the speed point of view, in the test, none of the scripting language could compete with Lisp. Anyway some articles by Prechelt [ira.uka.de] are interesting too (as many other research papers ; found via citeseer [nec.com] for instance)

Smalltalk a better alternative to Java (Score:1, Interesting) by Anonymous Coward on Saturday September 08, @08:33AM (#2266985)

In my opinion Smalltalk makes a much better alternative to Java. Smalltalk has all the trappings--a very rich set of base classes, byte-coded, garbage collected, etc. There are many Smalltalks out there...Smalltalk/X is quite good, and even has a Smalltalk-to-C compiler to boot. It's not totally free, but pretty cheap (and I believe for non-commercial use everything works but the S-to-C compiler). Squeak is an even better place to start...it is highly portable (moreso than Java), very extensible (thanks to VM plugins) and has as very active community that includes Alan Kay, the man who INVENTED the term "object-oriented programming". Squeak has a just-in-time compiler (JITTER), support for multiple front-ends, and can be tied to any kind of external libraries and DLL's. It's not GPL'd, but it is free under an old Apple license (I believe the only issue is with the fonts..they are still Apple fonts). It's already been ported to every platform I've ever seen, including the iPaq (both WinCE and Linux). It runs even on STOCK iPaqs (ie 32m) without any expansion...Java, from what I understand, still has big problems just running on the iPaq, not to mention unexpanded iPaqs. And of course, we can't forget about old GNU Smalltalk, which is still seeing development. Smalltalk is quite easy to learn--you can just pick up the old "Smalltalk-80: The Language" (Goldberg) and work right from there. Squeak already has two really good books that have just come into print (go to Amazon and search for Mark Guzdial). (this is not meant as a language flame...I'm just throwing this out on the table, since we're discussing alternatives to Java. Scheme/LISP is a cool idea as well, but I think Smalltalk deserves some mention.)

I've written 2 Lisp and 4 Java books (Score:3, Informative) by MarkWatson on Saturday September 08, @09:56AM (#2267225) (User #189759 Info)

First, great topic! I have written 2 Lisp books for Springer-Verlag and 4 Java books, so you bet that I have an opinion on my two favorite languages. First, given free choice, I would use Common LISP for most of my devlopment work. Common LISP has a huge library and is a very stable language. Although I prefer Xanalys LispWorks, there are also good free Common LISP systems. Java is also a great language, mainly because of the awesome class libraries and the J2EE framework (I am biased here because I am just finishing up writing a J2EE book). Peter Norvig once made a great comment on Java and Lisp (roughly quoting him): Java is only half as good as Lisp for AI but that is good enough. Anyway, I find that both Java and Common LISP are very efficient environments to code in. I only use Java for my work because that is what my customers want. BTW, I have a new free web book on Java and AI on my web site - help yourself! Best regards, Mark -- www.markwatson.com -- Open Source and Content

Why Java succeeded, LISP can't make headway now (Score:5, Informative) by joneshenry on Saturday September 08, @10:44AM (#2267438) (User #9497 Info)

Java was never marketted as the ultimate fast language to do searching or to manipulate large data structures. What Java was marketted as was a language that was good enough for programming paradigms popular at the time such as object orientation and automatic garbage collection while providing the most comprehensive APIs under the control of one entity who would continue to push the extension of those APIs.   In this LinuxWorld interview [linuxworld.com] look what Stroustrup is hoping to someday have in the C++ standard for libraries. It's a joke, almost all of those features are already in Java. As Stroustrup says, a standard GUI framework is not "politically feasible".   Now go listen to what Linux Torvalds is saying [ddj.com] about what he finds to be the most exciting thing to happen to Linux the past year. Hint, it's not the completion of the kernel 2.4.x, it's KDE. The foundation of KDE's success is the triumph of Qt as the de facto standard that a large community has embraced to build an entire reimplementation of end user applications.   To fill the void of a standard GUI framework for C++, Microsoft has dictated a set of de facto standards for Windows, and Trolltech has successfully pushed Qt as the de facto standard for Linux.   I claim that as a whole the programming community doesn't care whether a standard is de jure or de facto, but they do care that SOME standard exists. When it comes to talking people into making the investment of time and money to learn a platform on which to base their careers, a multitude of incompatible choices is NOT the way to market.   I find talking about LISP as one language compared to Java to be a complete joke. Whose LISP? Scheme? Whose version of Scheme, GNU's Guile? Is the Elisp in Emacs the most widely distributed implementation of LISP? Can Emacs be rewritten using Guile? What is the GUI framework for all of LISP? Anyone come up with a set of LISP APIs that are the equivalent of J2EE or Jini?   I find it extremely disheartening that the same people who can grasp the argument that the value of networks lies in the communication people can do are incapable of applying the same reasoning to programming languages. Is it that hard to read Odlyzko [umn.edu] and not see that people just want to do the same thing with programming languages--talk among themselves. The modern paradigm for software where the money is being made is getting things to work with each other. Dinosaur languages that wait around for decades while slow bureaucratic committees create nonsolutions are going to get stomped by faster moving mammals such as Java pushed by single-decision vendors. And so are fragmented languages with a multitude of incompatible and incomplete implementations such as LISP.

Some hopefully useful points (Score:2, Informative) by dlakelan ([email protected]) on Saturday September 08, @02:20PM (#2268461) (User #43245 Info | http://www.endpointcomputing.com)

First off, one of the best spokespersons for Lisp is Paul Graham, author of "On Lisp" and "ANSI Common Lisp". His web site is Here [paulgraham.com]. Reading through his articles [paulgraham.com] will give you a better sense of what lisp is about. One that I'd like to see people comment on is: java's cover [paulgraham.com] ... It resonates with my experience as well. Also This response [paulgraham.com] to his java's cover article succinctly makes a good point that covers most of the bickering found here... I personally think that the argument that Lisp is not widely known, and therefore not enough programmers exist to support corporate projects is bogus. The fact that you can hire someone who claims to know C++ does NOT in any way shape or form mean that you can hire someone who will solve your C++ programming problem! See my own web site [endpointcomputing.com] for more on that. I personally believe that if you have a large C++ program you're working on and need to hire a new person or a replacement who already claims to know C++, the start up cost for that person is the same as if you have a Lisp program doing the same thing, and need to hire someone AND train them to use Lisp. Why? the training more than pays for itself because it gives the new person a formal introduction to your project, and Lisp is a more productive system than C++ for most tasks. Furthermore, it's quite likely that the person who claims to know C++ doesn't know it as well as you would like, and therefore the fact that you haven't formally trained them on your project is a cost you aren't considering. One of the points that the original article by the fellow at NASA makes is that Lisp turned out to have a very low standard deviation of run-time and development time. What this basically says is that the lisp programs were more consistent. This is a very good thing as anyone who has ever had deadlines knows. Yes, the JVM version used in this study is old, but lets face it that would affect the average, but wouldn't affect the standard deviation much. Java programs are more likely to be slow, as are C++ programs! The point about lisp being a memory hog that a few people have made here is invalid as well. The NASA article states: Memory consumption for Lisp was significantly higher than for C/C++ and roughly comparable to Java. However, this result is somewhat misleading for two reasons. First, Lisp and Java both do internal memory management using garbage collection, so it is often the case that the Lisp and Java runtimes will allocate memory from the operating system this is not actually being used by the application program. People here have interpreted this to mean that the system is a memory hog anyway. In fact many lisp systems reserve a large chunk of their address space, which makes it look like a large amount of memory is in use. However the operating system has really just reserved it, not allocated it. When you touch one of the pages it does get allocated. So it LOOKS like you're using a LOT of memory, but in fact because of the VM system, you are NOT using very much memory at all. The biggest reasons people don't use Lisp are they either don't understand Lisp, or have been forced by clients or supervisors to use something else.

Interesting, but flawed? (Score:5, Insightful) by tkrotchko on Saturday September 08, @07:41AM (#2266864) (User #124118 Info | http://www.toad.net/~tomk)

Its interesting to see the results of a short study, even though the author admits to the flaw in his methodolody (primarily the subjects were self-chosen). Still, I don't think that's a fatal flaw, and I think his results do have some validity. However, I think the author misses a more important issue: development involving a single programmer for a relatively small task isn't the point for most organizations. Maintainability and a large pool of potential developers (for example) are a significant factor in deciding what language to use. LISP is a fabulous language, but try to find 10 programmers at a reasonable price in the next 2 weeks. Good luck. Also, while initial development time is important, typically testing/debug cycles are the costly part of implementation, so that's what should weigh on your mind as the area that the most gains can be made. Further, large projects are collaborative efforts, so the objects and libraries available for a particular language plays a role in how quickly you can produce quality code. As an aside, it would've been interesting to see the same development done with experienced Visual Basic programmer. My guess is he/she would have the lowest development cycle, and yet it wouldn't be my first choice for a large scale development project (although at the risk of being flamed, its not a bad language for just banging out a quick set of tools for my own use). Some of thing things I believe are more important when thinking about a programming language: 1) Amenable to use by team of programmers 2) Viability over a period of time (5-10 years). 3) Large developer base 4) Cross platform - not because I think cross-platform is a good thing by itself; rather, I think its important to avoid being locked-in to a single hardware or Operating System vendor. 5) Mature IDE, debugging tools, and compilers. 6) Wide applicability Computer languages tend to develop in response to specific needs, and most programmers will probably end up learning 5-10 languages over the course of their career. It would be helpful to have a discussion of the appropriate roles for certain computer languages, since I'm not sure any computer languages is better than any other.

Perhaps not quite as illuminating as it appears (Score:1) by ascholl (ascholl-at-max(dot)cs(dot)kzoo(dot)edu) on Saturday September 08, @07:53AM (#2266888) (User #225398 Info)

The study does show an advantage of lisp over java/c/c++ -- but only for small problems which depend heavily on the types of tasks lisp was designed for. The author recognizes the second problem ("It might be because the benchmark task involved search and managing a complex linked data structure, two jobs for which Lisp happens to be specifically designed and particularly well suited.") but doesn't even mention the first. While I haven't seen the example programs, I suspect that the reason the java versions performed poorly time-wise was probably directly related to object instantiation. Instantiating an object is a pretty expensive task in java; typical 'by the book' methods would involve instantiating new numbers for every collection of digits, word, digit/character set representation, etc. The performance cut due to instantiation can be minimized dramatically by re-using program wide collections of commonly used objects, but the effect would only be seen on large inputs. Since the example input was much smaller than the actual test case, it seems likely that the programmers may have neglected to include this functianality. Hypothising about implementation aside, the larger question is one of problem scope. If you're going to claim that language A is better than language B, you probably aren't concerned about tiny (albeit non-trivial) problems like the example. Now, I don't know whether this is true, but it seems possible that a large project implemented in java or c/c++ might be built quicker, be easier to maintain, and be less fragile than its equivilent in lisp. It may even perform better. It's not fair to assume blindly that the advantages of lisp seen in this study will scale up. I'm not claiming that they don't ... but still. If we're choosing a language for a task, this should be a primary consideration.

 

[Aug 30, 2001] Sun plans release of Forte 3

Sun plans a Sept 10 release of version 3 of Forte for Java, an IDE for Java development. Will support C, C++ and Java.

Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

Disclaimer: