Java > Scala

[Timon Gehr]

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.