Java > Scala

Somedude lovelydear at mailmetrash.com
Fri Dec 2 13:40:15 PST 2011


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.


More information about the Digitalmars-d mailing list