Le 02/12/2011 21:44, Timon Gehr a écrit : >> >> In what way is Eclipse sluggish ? The Java language is slower than C++, >> but Eclipse happily compiles hundreds of thousands of lines or millions >> of lines of Java code in a few seconds or at most tens of seconds. Try >> to do that even with C, not talking about C++. > > Except that _Eclipse_ does not do anything to achieve this. It just > invokes ant, which invokes javac, which is presumably written in C and > C++. I can do that in a console without waiting 5 minutes until the IDE > has finished starting. >
Wow. Sorry, but that's wrong on all accounts. eclipse integrates its own compiler which isn't javac, it's an incremental compiler that was written by IBM, part of JDT Core http://www.eclipse.org/jdt/core/index.php And I would believe it doesn't invoke ant at all, as eclipse manages the project itself. There is no ant file anywhere in your project AFAIK. And finally, the javac compiler is written in Java, not in C nor C++. And I believe that's true since the first release. Only the JVM is written in C. > Furthermore, if you add up all those startup times of every java > application and add that to the total time used for compilation I am not > convinced the compilation time/LOC ratio is still that impressive (yes, > JIT compilation is compilation too!) > Having programmed as a contractor for years on projects of hundreds of KLOC both in C++ and in Java, what I can recall is, in C++ turnaround is a PITA because of heavy recompilation, even when using idioms like PIMPL. It's one of the main issues of this language. While in Java, the compilation time is near zero. The launch time of applications entirely depends on what you do with them: if it has to open several DB connections to initialize itself, yes it's sluggish, but that doesn't have anything to do with the language, rather with the application. In the end, you may want to use a local or an embedded database for testing. I've seen C++ applications with starting times just as awful, for the same reasons. And JIT compilation, you don't feel it, so it doesn't matter. >> >> The fact is, you are more productive in Java than in C++ by nearly an >> order of magnitude. >> Because: >> 0) the language is easier, has far less idiosyncrasies > > Simpler language implies higher complexity to adapt it to your problem > domain. It is a matter of trade-offs (but I am not the one to argue that > C++ got all of those right.) > >> 1) the IDEs are extremely helpful, > > I don't usually program in Java, but when I do, I use a simple text editor. > If you are doing serious work with this language, you're simply wasting your time with a simple text editor. >> 2) the API is extremely complete and reliable > > Yes it is, and that is certainly a good thing, but: > > result = x.add(y.multiply(BigInteger.valueOf(7))).pow(3).abs().setBit(27); > > ExtremelyDetailedClassName extremelyDetailedClassName = new > ExtremelyDetailedClassName(). > I agree it's annoying and ugly, I hate it as much as you. But in the end, in terms of productivity, that doesn't matter much. The coding time is a small part of the coder's activity time. However, I agree a badly designed API can make you lose a lot of time. > I guess you get used to it, and that those things are the reason why the > IDE is extremely helpful. > Yes, the IDE takes care of a lot of boilerplate code. It's ugly, but it's hardly a productivity issue. One other thing that's cool is refactoring is no longer an issue, like it is in C or C++. With powerful IDEs, you can refactor without fearing too much regression, and that's a very important advantage, especially in a heavily OO language. >> 3) there are libraries for nearly everything > > More than for C? It's hard to compare as C and Java are definitely not targetted at the same kind of applications, but certainly much more than for C++. And the good thing is, many of them are of high quality. If what you do is serverside application, the Java ecosystem is second to none. On complex command line tools, it's also adequate and can show some very good performance. On other uses, it depends on the requirements. > >> 4) debugging is usually easier than in C++ > > Yes, and that is a big win for productivity. > >> 5) you have less bugs (especially, hard to find bugs like unitialized >> variables for instance, or race conditions) > > You can have race conditions perfectly fine in Java code. The Java > memory model is very complicated. There has long been a common practice > of using double checked locking, eg. for singleton initialization while > avoiding inefficient volatile variables. Until somebody figured out that > the java memory model does not actually support the idiom and that all > that code that did the supposedly right and clever thing was buggy. ;) Yes, I agree you can. But you most often want to avoid using low level API and only resort to high level synchronization that the JDK offers, which greatly reduces risks. D has the same policy, to an even better extent. >> 6) porting is easier >> 7) it is safer in the sense that you have less security holes >> >> These qualities largely compensate the defects and shortcomings of the >> language, and I can attest from experience that because of its massive >> toolset and libraries > > I agree. If productivity is important and efficiency is not an issue > then writing the project in Java is maybe a better option than writing > it in C++. (especially if you can't get hold of a decent number of C++ > good C++ programmers to carry out the project, which is hard.) But > writing Java code is not very pleasant imho. (But there are other fine > languages, like the one we like to discuss here ;)) > >> as well as static typing, > > Java is halfway dynamically checked. Did you know that every field > update of an array of class references performs a downcast check? > Yes. That's because of type erasure. Java containers only contain Object objects. For backward compatibility with Java 1.4 and earlier, that didn't have generics. Type erasure is a pain, even the language designers agree on this, but they didn't have the choice if they wanted to avoid hundreds of millions of lines of customer code to be rewritten. >> Java is comparable in productivity with Python. >> Besides, with a little attention to what you do, you can extract very >> decent performance out of it. > > How many Java programmers know what to pay attention to? > I don't know, but don't assume Java programmers are all stupid. It is as wrong an idea as saying all Indian programmers are lousy. There is far more Java/Indian programmers than D programmers, so even though a majority are the average Joe (and I count myself in them), many of them are good. Given the state of the industry, sufficient to say there are jobs and a good pay to attract all sorts of programmers, good and bad alike. It's just the curve bell applied to a larger community. What I can say though, is a bad C++ programmer can cause much worse problems than a bad Java programmer. >> For instance embedded Java databases like >> H2 and HSQLDB are demonstrably faster than MySQL and PostgreSQL or >> Oracle on small to average sized disk-based databases, and they were >> written by a single guy. >> In many environments where it is massively used, Java is *not* the >> bottleneck, the JVM is fast enough. Rather the network or the database >> are. This is enough to convince most companies to invest massively into >> Java. So saying that Java is a toy language is ridiculous. > > Java means a lot different things: > > - Language > - Libraries > - Security Model > - Virtual Machine > - ... > > The issue is that in discussions about java, this often leads to > misunderstandings. Yes.