I know Java is practical within certain contexts and for certain class of people, but our judgement of what's good or bad in general shouldn't really be a matter of taste and preference. Are we an engineering discipline or what?
What we call a matter of preference is actually things that go beyond engineering. We may have emotional ties to programming languages ("I love Java", "I hate C++") because of job security, because of often subconscious fear of inability to learn new stuff, and so on. We should clean up the table from the psychological aspects of the matter and look at what's left: that's how powerful and how clever a language can be in the hands of a good developer.
Java is a terribly verbose and an embarrassingly simplistic language. C is simplistic and can be considered dead the day C++ compilers catch up with speed and memory allocation, which will make it suitable for embedded programming too.
(And BTW, I don't mind JVM, it probably is a fantastic piece of engineering, except... for reasons I don't understand very well, a simple "Hello world" application written for JVM can take seconds to load and execute. I've heard a thousands reasons none of which made much sense. As well as promises JVM will be improved in the future. First time I heard this was 15 years ago, still no progress.)
"C is simplistic and can be considered dead the day C++ compilers catch up with speed and memory allocation"
Those really are not the problems that are most pressing with C++ in the embedded field. Comparable speed is rarely noticeably different provided you avoid certain key things, and you can always just swap in a new allocator if you want.
By memory allocation I meant memory usage by the compiler itself. Plus libstdc++ which is not easy to get rid of, and if you do dump it, you at least cut off C++ exceptions.
I once switched from C++ to C because g++ just couldn't handle the module even having all optimizations turned off. That was a huge automatically generated C module with thousands of functions. A rather rare situation but showed very clearly that C++ is not almighty.
Compiler speed/memory use are generally entirely irrelevant with embedded stuff. If you're natively building on your tiny target instead of cross compiling from your beefy workstation, you're doing it wrong.
No, for the very real issues with C++ in small installations, you will have to look at the language itself.
Believe it or not, it was on a beefy workstation (I think the number of functions was tens of thousands actually). Of course I could have split the module or find some other solution, but the thing was, switching to C solved the problem. More importantly, I was able to switch on compiler optimizations.
"our judgement of what's good or bad in general shouldn't really be a matter of taste and preference. Are we an engineering discipline or what?"
You know what. It's a funny thing, but as I was typing my response to your original post, I actually said this exact same thing to myself, and I started to think. It would be incredible if there was some non-emotional, non-touchy-feely way to get at the value of one language vs another. But then programming language choice just seems to be an inherently "feel" based decision...
"We should clean up the table from the psychological aspects of the matter and look at what's left: that's how powerful and how clever a language can be in the hands of a good developer."
This is one of the things that I thought of, but then there are so many demonstrations of people using all kinds of programming languages to do things that are incredibly clever and powerful.
Sometimes I like to just go through open source projects written in programming languages I am not extremely familiar with. I just want to get a taste of some of the myriad of programming styles and techniques that are out there. The different ways of looking at the same problem.
Even if I disagree with the method used, it is always eye-opening to see other ways of doing things - even some that may be vastly different from anything that I have ever seen before (my first time looking at Haskell comes to mind). I like to understand how and why different developers choose the routes that they choose.
I don't know, but to me it seems that, in a way, it is good that there is no emotionless method for rating languages. To declare one language as being definitively better than all others seems to me that it would be a tremendous loss. There is some value, I think, in having a diversity of "good" languages just for its own sake.
As to the simplicity of a language, well, to some people simplicity in a programming language is a beautiful thing, but then, the problem is that what constitutes simple is also a thing that varies from developer to developer. Perhaps the diversity of languages is a natural development from the diversity of programmers?
I think about Ruby. You know, when Matz describes why he created the language, he says that he wanted to create something that felt fun to develop in - fun for him. The fact that other people just happened to like Ruby was an unintended side effect.
I think that most people create a programming language with a similar type of outlook. They, either purposefully or subconsciously, try to build it to achieve a certain "feel". Perhaps it is this "feel" that makes a good developer powerful and clever with a language.
"for reasons I don't understand very well, a simple \"Hello world\" application written for JVM can take seconds to load and execute."
Generally agreed, except: let's be careful with the notion of simplicity. I used the word "simplistic" which bears some negative flavor (pointlessly simple?). Lisp is relatively simple and yet powerful, i.e. it is not simplistic. C++ is incredibly complex (dare to write a full blown modern C++ compiler?) and powerful. Not surprisingly though, the simplicity of Lisp doesn't make it easier to grasp.
From this point of view, languages that are neither complex nor allow for complexity can be called "simplistic". They are easy to learn, easy to write code in, and as easy to grow to unmaintainable sizes because of their verbosity. Since we have very few readers here at the bottom of the thread, I will admit that every time I see all kinds of dancing around class instantiation, endless method calls etc in Java, where in some other language it would take a single function call, it reminds me of how kids count the steps out loud when they go up or down the stairs. When you grow older, you don't count any more, it's kind of implied :)
And I haven't found a better measure of quality of programming languages than that proposed by Paul Graham here: http://www.paulgraham.com/power.html
Edit: just noticed downvotes for my previous comment, so no, we are not alone :)
mojuba, I have to thank you for that link. I confess that I had never read that document prior to today. The thing that I like most about it is that he leaves it open ended.
He doesn't pretend to have all of the answers but rather invites the reader to embark on a thought exercise. Ignoring the question of comparing languages, that is an excellent example of how to write concerning this type of topic.
On comparing languages, I have to say that comparing languages based on power does make sense - with power defined as programmer productivity. From this perspective, I can understand your view on Java.
But is it the language itself that is to blame or the spaghetti code that all too often results from inexperienced users? I recall that the JRuby team has done some interesting things within the limitations of the Java language.
Note: To those who down-voted the original comment, I did not think that the down-voting is the most optimum solution for when you have a different perspective on an issue. Wouldn't it be better for everyone to chime into the discussion and increase everyone's knowledge with your perspective on the issue? This type of thing is why I have to ignore votes and just try to learn.
What we call a matter of preference is actually things that go beyond engineering. We may have emotional ties to programming languages ("I love Java", "I hate C++") because of job security, because of often subconscious fear of inability to learn new stuff, and so on. We should clean up the table from the psychological aspects of the matter and look at what's left: that's how powerful and how clever a language can be in the hands of a good developer.
Java is a terribly verbose and an embarrassingly simplistic language. C is simplistic and can be considered dead the day C++ compilers catch up with speed and memory allocation, which will make it suitable for embedded programming too.
(And BTW, I don't mind JVM, it probably is a fantastic piece of engineering, except... for reasons I don't understand very well, a simple "Hello world" application written for JVM can take seconds to load and execute. I've heard a thousands reasons none of which made much sense. As well as promises JVM will be improved in the future. First time I heard this was 15 years ago, still no progress.)