C# and other OOP languages

[tggzzz]

... Given that many Java programs work very crappy ...

Which is equally true for all languages, of course. Maybe the key factor isn't the language

No. Sometimes the problem is in the framework. Lot's of errors I've seen in Java programs originate from parallel threading errors.

I appreciate English (probably) isn't your first language. In the context of programming, the word "framework" has so many different definitions, meanings and usages that it has become almost meaningless.  From a famous book written by a logician 150 years ago: "When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to mean—neither more nor less.", see http://en.wikipedia.org/wiki/Humpty_Dumpty#In_Through_the_Looking-Glass

So, in order to understand what you are trying to say, could you please indicate which meaning of "framework" you are using?

(For some meanings I would not disagree with you, but for others you are plain wrong.)

[miguelvp]

Hmmm, where to start.

There is a fundamental problem with Java vs C#. Java uses CORBA for marshalling and it's quite expensive, C# and all other M$ languages and technologies use COM and that's more than obvious in Windows8 where everything is an interface.

C++ without COM interfaces is fast and with lambdas and the new additions of C++11 it makes it a more robust language, of course you have to know what you are doing because it's still as powerful as ASM, C and C++.

Object orientation is really not hard to grasp, the premise is simple, you define an object and provide methods to work on that object.

But concurrency and fault tolerance are not free. It's up to the programmer to make it scalable on any language.

The new trend, well not really yet a trend, is to use functional languages like Erlang and Haskell for cloud computing that is scalable, fault tolerant and concurrent. It's going to help a lot too when we have a thousand cores.

C# and Java are cute. I rather program in python since I can import C++ libraries, in any event C++ is still king until the Functional languages take over so we can use more than 10% of our processors without a lot of programmers sleepless hours to use all of those cores at full capacity.

Say no to marshalling it just too expensive (even if COM is lighter because it wasn't developed by committee like CORBA was).
COM btw started as OLE then ActiveX adopted by .NET etc.. the new inception is Windows Run Time (WRT) it's powerful but not the quickest (but better than CORBA) Distributed COM or D-COM is powerful too, better than RPC.

To me marshalling is like a copy construct in C++, you just don't want to do that, or at least avoid it when possible.

So for OOP languages, if they need to be on the cloud and be scaleable and concurrent. I will say Erlang.

[nctnico]

... Given that many Java programs work very crappy ...

Which is equally true for all languages, of course. Maybe the key factor isn't the language

No. Sometimes the problem is in the framework. Lot's of errors I've seen in Java programs originate from parallel threading errors.

I appreciate English (probably) isn't your first language. In the context of programming, the word "framework" has so many different definitions,

In programming context a framework is a set of libraries that complete a language or offer a programming environment. See: http://en.wikipedia.org/wiki/Software_framework

[tggzzz]

... Given that many Java programs work very crappy ...

Which is equally true for all languages, of course. Maybe the key factor isn't the language

No. Sometimes the problem is in the framework. Lot's of errors I've seen in Java programs originate from parallel threading errors.

I appreciate English (probably) isn't your first language. In the context of programming, the word "framework" has so many different definitions,

In programming context a framework is a set of libraries that complete a language or offer a programming environment. See: http://en.wikipedia.org/wiki/Software_framework

OK. So then the validity or otherwise of your argument depends on which libraries you mean.

If you mean the standard Java runtime libraries that that are part of the JDK/J2SE, then you will have to work very hard and be very specific in order to justify your assertion. Why? Because there are many high-reliability high-availability soft real-time applications that would be  visible and very expensive if they failed. I know. I've seen them and built some myself.

If, on the other hand, you mean some other library that uses the standard Java runtime libraries, then you will also have to be specific, but it will be less difficult to justify your assertion. Why? Because anybody can "write a Java framework", publish it and then try to debug it when someone complains - and many have with predictably ghastly results.

If, on the third hand, the frameworks you are referring to involve communicating with other computers across the internet, then you may well be right, because far too programmers don't understand the fundamental limitations of distributed systems. Far too few have even heard of L Peter Deutsch's  "eight fallacies of distributed computing", let alone realised how thry must shape frameworks and applications. Far to many presume that the network and all the other computers (that they don't even know exist) will always function conrrectly.

Hells teeth, I've even come across people that think it is possible to have reliable distributed transactions. (Hint: it isn't, unless you've made fundamental breakthroughs in solving the Byzantine General's problem, and the "split brain" problems arising from network partitioning). Such people are very likely to create a subtly faulty mess even on a single computer, in any language.

But neither the "other hand" nor the "third hand" issues are related to Java: they are common to all languages and environments.

Blaming Java almost always the equivalent of saying that, say, Analog Devices integrated circuits are faulty because a Chinese (or other) backstreet shop read an application note, copied a circuit in it without understanding, turned it into a bad PCB, and sold it.

[nctnico]

Then explain why Java applications are more prone to erratic behaviour than others (based on my own observations). I've seen quite a few Java application where following the same procedure results in an error every now and then. Even Eclipse isn't entirely free of this kind of behaviour. If it is a bug then it would fail every time; not once in a while.

[HackedFridgeMagnet]

Then explain why Java applications are more prone to erratic behaviour than others

Cause the JVM's written in C++. 

Java on the Windows Desktop was dead and is ever since

The funny thing is Microsoft just paid $2.5 billion for a Java game. Java on windows is not quite dead yet.

My kids love it. They're just worried about Microsoft wrecking it.

[tggzzz]

Then explain why Java applications are more prone to erratic behaviour than others (based on my own observations).

Anecdotes are not data.

The simple, and almost certainly correct, explanation is that the applications are written badly. "Badly" = not taking into account all possible sequences of inputs, or not taking into account that the sub-systems they communicate might fail, or merely in a way that should feature on  "The Daily WTF!".

Whenever an engineer comes to me and says "my circuit doesn't work, so the IC must be faulty", I tell them to "prove it". In trying to do so, they almost always end up finding the fault in their understanding of the IC or their circuit.

The same is true of computer programs (with the notable exception of C++, where even language lawyers can't agree on what is right)

I've seen quite a few Java application where following the same procedure results in an error every now and then.

I've seen even more C#, C++, C, Ruby, .... applications that give an "error now and again". Should we then suppose that C#, C++, C, Ruby etc is to blame? I think not.

If it is a bug then it would fail every time; not once in a while.

Nonsense.

To summarise your position: "I've seen a few failures, so Java is at fault". Unconvincing.

[nctnico]

You seem to misunderstand. A real bug is easy to reproduce. A program always fails in the same way. What is different with Java programs (note the plural) is that programs don't always fail in the same way but behave erratic. You may call that an anecdote and dismiss it but that still doesn't mean there is no underlying problem.

[tggzzz]

You seem to misunderstand. A real bug is easy to reproduce.

Nonsense, both in practice and in theory, both for hardware and for software.

You've clearly never had to locate faults in large systems with various components written by various companies, changing asynchronously with each other.

Suppose one programmer sets the transaction properties of a database transaction in a different way to other programmers. There's no chance whatsoever of detecting that in unit tests, and it is improbable (though conceivable) that you would detect it in integration tests. Even if you were to try and stimulate that specific problem, it would be very difficult to do it reliably. The way you are likely to see it is in very infrequent "random" failures in the installed system - and those failures would look to you just like a multithreading problem. Well in a way it is a multithreading problem, but not one that can be blamed on the database or language.

Or another example: consider the idiots that believe there are 24 hours in a day or 60 seconds in a minute. Even if you get it right inside your code, how will your program work with a separate system (or library) that gets it wrong? Unless you explicitly test for all those possibilities, you will have to wait an indeterminate number of years for the right conditions to stimulate the problem.

A program always fails in the same way.

Nonsense.

You clearly haven't dealt with large scale distributed programs and networking hardware.

What is different with Java programs (note the plural) is that programs don't always fail in the same way but behave erratic. You may call that an anecdote and dismiss it but that still doesn't mean there is no underlying problem.

Erratic behaviour is nothing new, and there are endless ways in which it might occur.

Your assertion is that the Java multithreading is the root cause of all these bugs. You have no evidence whatsoever to substantiate that presumption. A much simpler and more likely reason is that the developers didn't understand the behaviour inherent in the system they were "designing", and hence wrote bad code. They would have done the same in any language you care to choose.

[nctnico]

A much simpler and more likely reason is that the developers didn't understand the behaviour inherent in the system they were "designing", and hence wrote bad code.

Then let's say that my observation is that Java programmers appear to have above average problems understanding their programming environment (framework) and leave it at that. You may choose to use that information to your advantage or not.

[SirNick]

I hate Java, and I shudder to defend it.  But...

Code: [Select]

#include <stdio.h>

int main () {
    int x;
   
    if (x == 3) {
        printf("Error -- aborting.\n");
        return 1;
    }
   
    printf("All clear!\n");
    return 0;
}

Code: [Select]

gcc -o test test.c

Code: [Select]

./test
All clear!

Code: [Select]

./test
All clear!

Code: [Select]

./test
All clear!

Code: [Select]

./test
Error -- aborting.
Now, did I just witness an inconsistency in the language?  Or a bug?

[c4757p]

The language is quite consistent and the compiler's not buggy. It's a bug in your code. What do you think the value of x is at the moment you test it?

The operating system is just giving you whatever block of memory happens to be available, with whatever data already happens to be in it. It won't load an initial value unless you tell it to.

By the way, you can and should make the compiler smarter:

Code: [Select]

% gcc -Wall -Wextra -Werror -o test test.c
test.c: In function ‘main’:
test.c:6:8: error: ‘x’ is used uninitialized in this function [-Werror=uninitialized]
     if (x == 3) {
        ^
cc1: all warnings being treated as errors


[miguelvp]

Uninitialized data is a common rookie mistake.
It doesn't help that when you make a debug build some compilers initializes the data for you.

[tggzzz]

A much simpler and more likely reason is that the developers didn't understand the behaviour inherent in the system they were "designing", and hence wrote bad code.

Then let's say that my observation is that Java programmers appear to have above average problems understanding their programming environment (framework) and leave it at that. You may choose to use that information to your advantage or not.

There is no practical use that I, or anyone else, could make of that (very arguable) observation.

Java is now the ab initio language of choice, so one would expect more ab initio class errors.
 
Java is sufficiently powerful that it enables ordinary programmers to tackle far more complex problems than are possible in many earlier languages.

If you look at http://thedailywtf.com/ you will see many languages represented, including Java and C#.

I note that you are not attempting to defend your assertions, unsurprisingly.

[tggzzz]

I hate Java, and I shudder to defend it.  But...

It is always good to see someone recognising that all tools have their advantages and disadvantages. Knowing them is the essential starting point for choosing the most appropriate tool for the task at hand.

But you knew that!

[SirNick]

The language is quite consistent and the compiler's not buggy. It's a bug in your code. What do you think the value of x is at the moment you test it?

BTW, in case it wasn't obvious, I fully understand the implications of the code as written.  The variable was intentionally not initialized to illustrate that sometimes "languages" do "random" things because the humans that write code in those languages make mistakes that aren't always immediately visible.  Code like that example could work perfectly for years, until it suddenly doesn't.

Are Java's problems similar?  Who knows.  Without a specific case study, including source and test results, it's hard to substantiate claims that it tends to fail in inconsistent ways.

However, in my own, scientifically unproven opinion, the Java environment tends to be fragile and prone to having code that worked yesterday stop working today.  It's almost always the result of users updating the JRE every time it pops up a notification, leaving a trail of dozens of prior versions, and ensuring that no one has any clue which JRE is actually running a given app or applet at any given time.  Not that C is free of its own dependency issues, of course...

[nctnico]

Then let's say that my observation is that Java programmers appear to have above average problems understanding their programming environment (framework) and leave it at that. You may choose to use that information to your advantage or not.

I note that you are not attempting to defend your assertions, unsurprisingly.

I don't have to. I know what I have seen. If you Google 'Java erratic behaviour' there seem to be many ways to shoot yourself in the foot because of less obvious issues to be aware off. Java (the one from Sun) is often touted to be an easy language to use but if that where the case then why did Google go through all the trouble and create their own version of Java. They wheren't going to avoid having to pay for Java anyway. I don't see you trying to answer that question.

[jancumps]

Uninitialized data is a common rookie mistake.
It doesn't help that when you make a debug build some compilers initializes the data for you.

Oh dear, have I been bitten by that one in the late 1990s©
In visual C++, a Date variable was initialized in debug mode and not in non-debug mode. That got me completely on the wrong path for the best part of a (well paid ) day.

It's not a language issue though, just an implementation library issue. But I recognized miguelvp's situation.

[SirNick]

why did Google go through all the trouble and create their own version of Java

It has always been unclear to me why they chose Java, out of all the available languages.  To insulate themselves from future architectural changes?  Some folks have presented very impressive numbers in terms of JIT execution overhead.  But on a space and speed constrained platform, why volunteer for any overhead at all?

[c4757p]

The language is quite consistent and the compiler's not buggy. It's a bug in your code. What do you think the value of x is at the moment you test it?

BTW, in case it wasn't obvious, I fully understand the implications of the code as written.  The variable was intentionally not initialized to illustrate that sometimes "languages" do "random" things because the humans that write code in those languages make mistakes that aren't always immediately visible.  Code like that example could work perfectly for years, until it suddenly doesn't.

Doesn't matter. Languages which initialize to a default value can mask the uninitialized variable just as well as they can point it out. All depends on whether the default value is valid in a given case or not. The only way around this is to detect it intentionally: enable warnings for uninitialized access, and run a memory checker like Valgrind. And unless you're developing for a platform where you can't use Valgrind, there is no excuse for not doing either one.

[Bored@Work]

then why did Google go through all the trouble and create their own version of Java.

Google didn't create their own version of Java. In fact, you need to use the Sun, now Oracle, toolchain, including the Oracle Java compiler, to develop for Android. Google added a way to later on transpile the bytecode, as generated by the Oracle Java compiler, into their own version of bytecode, for their own virtual machine.

But the language, and compiler implementation is 100% Oracle Java. Every alleged, imaginary or real limitation or idiosyncrasy of the language is 100% there, because of the use of the originally compiler from Sun/Oracle.

Google also developed copies of many, but not all standard Java libraries, or used open source. That code is written in the original Sun/Oracle Java language and is compiled with the Oracle Java compiler, too.

They wheren't going to avoid having to pay for Java anyway.

Actually, paying is exactly what Google were and is still trying to avoid. They didn't like the licensing terms offered by Sun. So the went ahead, using the freely available Sun/Oracle Java compiler, adding a bit of stuff at the end, and their own  libraries.

Oracle doesn't like that a bit and is dragging Google through the courts because of this http://en.wikipedia.org/wiki/Oracle_v._Google

Then let's say that my observation is that Java programmers appear to have above average problems understanding their programming environment (framework) and leave it at that.

Well, you didn't exactly show any above average knowledge of Java with your rather strange claims of Googles own version of Java.

[tggzzz]

why did Google go through all the trouble and create their own version of Java. They wheren't going to avoid having to pay for Java anyway. I don't see you trying to answer that question.

Complete ignorance. Google didn't create their own version of Java, so the whole premise of your question and conclusions evaporate into thin air.

Oracle tried to sue Google for that reason (for >$1bn), and their case was comprehensively demolished in court.

Android/Dahlvik has different libraries, a different compilation philosophy (much more like .NET), a different runtime, leaving merely some similar syntax and semantics.

[tggzzz]

why did Google go through all the trouble and create their own version of Java

It has always been unclear to me why they chose Java, out of all the available languages.  To insulate themselves from future architectural changes?  Some folks have presented very impressive numbers in terms of JIT execution overhead.  But on a space and speed constrained platform, why volunteer for any overhead at all?

The didn't choose Java, as has been proven in court.

They did choose a language with similar semantics and syntax so as to enable a rapid uptake by the hoardes of Java programmers. Dahlvik is principally an ahead-of-time compilation system, similar to .NET. Caveat: I haven't looked at Google's reported replacement for Dahlvik.

[tggzzz]

Then let's say that my observation is that Java programmers appear to have above average problems understanding their programming environment (framework) and leave it at that.

Well, you didn't exactly show any above average knowledge of Java with your rather strange claims of Googles own version of Java.

Precisely.

As far as I can determine, all his assertions on this subject have been more-or-less a rant. I make no assertions about his statements on other topics.

[nctnico]

Then let's say that my observation is that Java programmers appear to have above average problems understanding their programming environment (framework) and leave it at that.

Well, you didn't exactly show any above average knowledge of Java with your rather strange claims of Googles own version of Java.

The interesting thing about observations is that you don't need in depth knowledge to make them. And if Google only wrote their own JVM then they probably had a good reason to do so instead of buying it off the shelve from (at that time) Sun.