Java > Scala

Timon Gehr timon.gehr at gmx.ch
Fri Dec 2 12:44:33 PST 2011


On 12/02/2011 09:01 PM, Somedude wrote:
> Le 02/12/2011 18:08, Nick Sabalausky a écrit :
>> "Russel Winder"<russel at russel.org.uk>  wrote in message
>> news:mailman.1242.1322814007.24802.digitalmars-d at puremagic.com...
>>>
>>> Java is the main language of development just now. D is a tiny little
>>> backwater in the nether regions of obscurity. If any language is a joke
>>> here, it is D since it is currently unable to claim any serious market
>>> share in the world of development.
>>
>> I see, so popularity is the primary determining factor of quality and
>> validity. Right? What's right is inherently popular and what's popular is
>> inherently right.
>>
>>> If you don't know why, how can you make claims that you cannot
>>> substantiate in any way shape or form.
>>
>> That's just BS. Even the scientific method starts with *observations*, not
>> the "how" or "why". Those come later. Observations without knowing the
>> underlying cause are perfectly valid. Hell, if JVM is slow, then it doesn't
>> really even matter why (unless you're optimizing it or trying to avoid the
>> same pitfalls), now does it?
>>
>>> I am entirely comfortable with my perceptions
>>> of languages, so have no need for such behaviours.
>>
>> That's BS posturing and chest-thumping. What is this, some damn new agers
>> group where nobody's allowed to dislike anything and feel strongly about it?
>>
>> The reason you feel no need for such things is because you don't appear to
>> find significant fault with Java/JVM. Other people do. And unlike you, those
>> people have to put up with a world heavily infected by it. *Of course*, you
>> don't feel a need to complain, you're comfortable equating popularity with
>> validity.
>>
>> I'm not trying to say you're not entitled to be happy with Java/JVM, but
>> when someone who likes the status quo sees someone who dislikes it and then
>> says, "Hey, how dare you be unhappy about it! After all, I'm happy! It's the
>> popular thing, therefore it must be ok and you should like it!", and starts
>> preaching, that's just asinine.
>>
>>
>
> 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.

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!)

>
> 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.

> 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 guess you get used to it, and that those things are the reason why the 
IDE is extremely helpful.


> 3) there are libraries for nearly everything

More than for C?

> 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. ;)

> 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?

> 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?

> 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.


More information about the Digitalmars-d mailing list