On 12/02/2011 10:40 PM, Somedude wrote:
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.
Yes, I figured that out about one hour ago and corrected my statement ;).
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.
Yes. You can write sluggy code in any language.
And JIT compilation, you don't feel it, so it doesn't matter.
It is a waste of resources/energy imho. The fact that those are cheaper
than programmers does not make it right.
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.
That is why I don't think it is pleasant to program in Java.
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++.
C++ libraries are a superset of C libraries.
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.
I think it is unrelated to type erasure in this case, because Arrays are
not generic. The issue is that they are treated as covariant, which is
_not_ statically type safe. Generics solve the same problem in a much
nicer way (wildcards ftw!), but there your get the type check because of
type erasure. So you get the worst possible solution: Dynamic checks on
arrays because they were no proper generics some time ago, and dynamic
checks on generics, for the same reason.
A similar typecheck happens when you assign an object to an interface
reference iirc, because the bytecode verifier cannot check multiple
subtyping relationships.
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.
I would rather have forked the language, but I understand why they did not.
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.
I certainly don't.
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.
A good programmer can develop efficiently in any halfway decent language.
What I can say though, is a bad C++ programmer can cause much worse
problems than a bad Java programmer.
That is true, and I don't particularly like C++ either. It is kinda nice
to exploit some special case to confuse programmers who like C++ and
thought they knew C++ though ;)
For example:
#define NAME someValidIdentifier
struct B{int foo;};
template<class T> int NAME(T x){
bool y = x.foo<1>(0);
return y;
}
int main(){
int c = NAME(B());
}
For what definitions of NAME does the program compile?
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.
