Active Topics
-
The N900 is now 15 years old! (9)
to Nokia N900 by Arno_11 - 17 hrs, 47 mins ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 6 days, 6 hrs ago - more...
| The Following User Says Thank You to attila77 For This Useful Post: | ||
 |
|
2011-01-29
, 13:45
|
|
Posts: 3,524 |
Thanked: 2,958 times |
Joined on Oct 2007
@ Delta Quadrant
|
#82
|
Originally Posted by attila77
That is simply not true. The write-once app has very much to do with the language. I know it *has* been done before, and you *can* compile C to Java VM but it is generally not used this way in the majority of cases for a number of reasons -- in fact it's somewhat rare.
For tl;dr people: the holy grail of run-anywhere binaries have (nearly) nothing to do with the language, it's about platform/OS abstraction.
*snip*
I'm not arguing capability, but reality.
The rest is conversation drift. I stand by my assertions about developers being particular to their environments and that write-once applications have a tendency to be tied to a particular language.
|
|
2011-01-29
, 13:49
|
|
Posts: 726 |
Thanked: 345 times |
Joined on Apr 2010
@ Sweden
|
#83
|
Originally Posted by attila77
A program that is not run will perform equally well no matter what language is used (speed == 0). If any comment is to be made about how "fast" or "slow" it is, the environment it is run in must be included. In the case of Java, this includes the JVM (which differs between devices, I know). If the JVM is simplistic, Java will not do very well compared to applications running on "bare metal". But I didn't interpret the comment as that kind of comparison.
This is where all these discussions get derailed. You start comparing the Java platform with the C++ language.
The comment I was commenting on contained a very broad statement about speed that, as far as I could see, said nothing about the actual language other than that the person didn't like Java and preferred C.
|
|
2011-01-29
, 14:16
|
|
Posts: 3,319 |
Thanked: 5,610 times |
Joined on Aug 2008
@ Finland
|
#84
|
Originally Posted by Capt'n Corrupt
The point is that it isn't a causal relation (what people tend to think based on Java-JVM symbiosis), it's simply correlation, see .NET
I'm not arguing capability, but reality.
The rest is conversation drift. I stand by my assertions about developers being particular to their environments and that write-once applications have a tendency to be tied to a particular language.
Originally Posted by Joorin
Ah, but that's language hypocrisy then
A program that is not run will perform equally well no matter what language is used (speed == 0). If any comment is to be made about how "fast" or "slow" it is, the environment it is run in must be included
In order to compare apples to apple, either you compare PLATFORMS or you compare LANGUAGES. It's a common misconception that C++ does not have level platform level solutions - admittedly, it's nowhere as dominant/unified as Oracle's (nee Sun's) Java platform, but definitely not unheard-of. I already mentioned .NET above, so, let's see, what does Java give you over a C++/CLI .NET application (I know most people associate C# with .NET in their heads, but C++ *is* part of the CLI language list).http://en.wikipedia.org/wiki/List_of_CLI_languages
EDIT: And of course, from a compiler geek perspective a weird twist is that nowadays X86 itself is an abstraction (as it covers CPUs that have vastly different innards, the most extreme example of this was the Transmeta approach).
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
Last edited by attila77; 2011-01-29 at 15:42.
| The Following User Says Thank You to attila77 For This Useful Post: | ||
|
|
2011-01-30
, 02:26
|
|
Posts: 303 |
Thanked: 146 times |
Joined on Aug 2009
|
#86
|
Originally Posted by Joorin
LOL. I am not even going to comment on your trolling attempt.
Ok, so you're ignorant about Java. Fair enough.
But if you're ignorant about it, what do you know that you dislike?
You can use compiled C libraries from Java. Just Google it and lessen that ignorance.
The endless speed debate. Java, on the other hand, offers great ways to optimize your running binary by inspecting it which isn't possible in C++. There are nice Java3D bindings using available 3D hardware so you're left with (real) speed differences when it comes to number crunching. How does that apply to you as a "desktop developer"?
How does the CPU type affect this? How is that relevant?
|
|
2011-01-30
, 10:02
|
|
Posts: 726 |
Thanked: 345 times |
Joined on Apr 2010
@ Sweden
|
#87
|
Originally Posted by Radu
No trolling. Really. You say that you don't know Java but that you don't like it. This really makes me wonder what you actually do know to make you dislike it.
LOL. I am not even going to comment on your trolling attempt.
No, you have no idea about programming.
The fact that you can use SOME C libraries in Java doesn't help you that much when the goal of Java is "write once, run everywhere", now does it?
And, being able to use native code for the heavy number crunching and Java for the rest actually lets you write pretty portable Java code for everything but the most CPU intensive parts.
If you can use your C code on other platforms, why use Java for portability in the first place?
On top of that, having as much of the code as possible written in Java makes it easier to move the code to another Java platform. You will still need to port the C parts, but by keeping that bit as small as possible it becomes manageable.
Yes, in theory Java is as fast or faster than C++, which is in theory faster than ASM (because hey, the compiler can do stuff better than humans do).
In reality, this is a silly argument, Java and .NET is noticeably slower than C/C++.
ARM CPUs are optimized for low power, not for speed. If you use a VM rather than native code your application is going to be even slower. You don't have the horsepower of a X86 CPU.
| The Following User Says Thank You to Joorin For This Useful Post: | ||
|
|
2011-01-30
, 15:56
|
|
Posts: 3,319 |
Thanked: 5,610 times |
Joined on Aug 2008
@ Finland
|
#88
|
Originally Posted by Joorin
Fixed it for 'ya
On top of that, having as much of the code as possible written in <favorite application framework/platfom> makes it easier to move the code to another <favorite application framework/platfom> platform. You will still need to port the <legacy> parts, but by keeping that bit as small as possible it becomes manageable.
The fact that, say, the Qt SDK spans ~half a dozen target operating systems on almost as many hardware platforms is quite telling that software development has moved on and many of the lessons of platform-building have been incorporated into today's solutions, regardless of language.
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
|
|
2011-01-30
, 18:16
|
|
Posts: 726 |
Thanked: 345 times |
Joined on Apr 2010
@ Sweden
|
#89
|
@attila77
I do get your point but to call everything that's not part of the target platform "legacy" is a bit on the too simple side.
As an example from reality: I will need to handle some 17000 UDP packets per second in an application I'll soon be working on. The desired language to use is C# but it's hard, if not impossible, to make this work using only C#. So, by writing a buffering packet handler in C++ to avoid garbage collection and stalled reception I can still write the rest in C#.
I do get your point but to call everything that's not part of the target platform "legacy" is a bit on the too simple side.
As an example from reality: I will need to handle some 17000 UDP packets per second in an application I'll soon be working on. The desired language to use is C# but it's hard, if not impossible, to make this work using only C#. So, by writing a buffering packet handler in C++ to avoid garbage collection and stalled reception I can still write the rest in C#.
| The Following User Says Thank You to Joorin For This Useful Post: | ||
|
|
2011-01-31
, 01:26
|
|
Posts: 303 |
Thanked: 146 times |
Joined on Aug 2009
|
#90
|
Originally Posted by Joorin
I used the ad hominem "nonsense" as a reply to you implying that I am ignorant. Yes, I don't know Java, but that doesn't mean I have no idea what Java is, how it works, what is the performance compared to other languages, etc.
No trolling. Really. You say that you don't know Java but that you don't like it. This really makes me wonder what you actually do know to make you dislike it.
I assure you, I do have "an idea" about programming. And more than that. No need for ad hominem nonsense.
How did the "goal of Java" become relevant? How it actually works is more important. To be able to use snippets of C code actually increases the chances that the rest can be "pure Java".
And, being able to use native code for the heavy number crunching and Java for the rest actually lets you write pretty portable Java code for everything but the most CPU intensive parts.
If you take a look at Android, to name one, the APIs available out of the box differs between native binaries and Java applications.
On top of that, having as much of the code as possible written in Java makes it easier to move the code to another Java platform. You will still need to port the C parts, but by keeping that bit as small as possible it becomes manageable.
I don't know of any compiler that can beat the speed of hand coded assembler unless you're talking of larger frame optimizations. But for "ordinary use", I do agree on the compiler being very good at generating fast code.
With you being a "desktop developer", how did you come to this realization? A widget taking 74ms to update instead of 61ms?
1Ghz ARM CPUs offer some kick, though. And the benefits of Java/.NET might very well be worth the potential loss of milliseconds in update time.
 |
| Tags |
| bada rox, dalvik, future, java haters, meego, meego?fail, nokia, sandbox sucks |
«
Previous Thread
|
Next Thread
»
| Thread Tools | |
|
All times are GMT. The time now is 11:29.
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc