And for a Java enthusiast to make a general statement about performance as a primary reason to avoid a language/platform is selective amnesia at its finest.
Not at all. Firstly, I was not a Java enthusiast in 1995 because it was slow, so no hypocrisy here. Secondly, many of the comments here about Ruby aren't saying 'well it might get faster' - they are saying 'it is fast enough now'. Thirdly, it is difficult to predict which languages end up fast. A decade ago it looked like Smalltalk was on that route, but it failed and Java succeeded.
Well, it is not very helpful to have a discussion with someone who is insisting nothing can be ever measured. I do not feel it was an argument in reply to my arguments.
Helpful or not, it is almost certainly the truth - it is not me who is insisting this, it is virtually all of modern physics. There may be a few who disagree (Wolfram, for example), but almost no-one takes this seriously.
My point in reply to your argument what that a point of view 'outside of the universe' would not make sense (in my opinion), as there would be neither time nor space in which to have the point of view....
Well, there can be different points of view, can't they?
Outside of time and space, it hard to know what 'point of view' means.
You are right that the Bell equations seem to contradict me; but Wolfram states they are unconfirmed
Well, he would say that, and he is hardly an authority on the matter. Almost all others disagree with him.
I don't quite see why if a quantum state represents an overlay of several states it cannot even represent an exact single state when requested to do so.
Because there is no such thing as an exact single state, at least of more than one variable. You can't have an exact state of position and momentum at the same time, for example.
Particles without quantum physics would basically react like billard, basically relying on the pauli principle and exchange of values that maintain the sums. I can see what your reply will be: That billard physics has been disproved in favor of quantum physics.
Actually no - I would say that the 'billiard' model sounds no more or less like a simulation than the quantum model.
I am not disputing that, I am stating that there might exist a point of view outside our universe from which our universe can be considered a simulation.
I don't see that - as it is hard enough to define a point of view within the universe, let another without - I'm not even the idea of a 'point of view' is sensible for this.
I believe the existance of a working quantum theory means that the universe can be considered as a simulation insofar as there might exist a universe without quantum physics and just particle physics.
This is extremely doubtful, as it is hard to see how there could even be particles without quantum physics. What would these particles be? Infinitesimal points? If so, how could they react?
"Java starts up as a high-performance interpreter (like Ruby, PERL etc.),"
thanks for the acknowledgement
But even within a few seconds, it gets much faster.
"in the background" still means "in time": it's compiled just before it can run, and then the "hotspot" analyzer goes on looking for spots that can be optimized. It's a runtime, occupying memory and cpu cycles and no matter how many optimizations it does, the generated code still doesn't run at C/C++/OCaml levels...
It occupies some memory and CPU cycles, but not much. Hotspot optimisers run fine even in restricted memory and CPU situations like J2ME.
And, no matter how many times you repeat it, saying that 'the generated code still doesn't run at C/C++.. levels' is simply factually wrong.
Once the Hotspot optimiser has done it's work you are left with very highly tuned machine code that is as good as anything that is churned out by a pre-compiler. Loop unrolling is performed where necessary, variable and constant re-organistion, aggressive in-lining of function, and removal of bounds checking is just the start. There is also native machine code re-ordering to optimise pipeline use, and also the use of additional features on specific processors (such as MMX).
This is exactly what pre-compilers do. You get the same performance. In fact, you can get better as the code is regularly (but in a low-priority background thread that does not impair performance) re-profiled so that optimisations can be changed and refined.
If you wish to insist that Java is slower, you are going to have to explain how all these optimisations actually make code slower, when they have for decades been used to give high performance. The only difference with Java is that this aggressive optimisation takes place mostly during a short period after the application starts.
Actually, I have simplified things. There are options on modern JVMs to control the balance between startup performance and optimising. The '-client' switch (on by default) says 'start up fast and concentrate on optimising later'. This means that, although the program is pretty fast, heavy optimisation may not happen for a while. The '-server' switch is designed for non-GUI apps. It says 'take a bit longer starting up and turn on full optimisation in the background immediately'.
It is the use of the '-server' switch that allows Java to easily match the output of most C or C++ compilers in most benchmarks providing code runs for more than a few seconds.
yes, there's a delay while it's being JITted. that's what JIT means: just-in-time compilation. in other words: just in time for a run.
No, because Java isn't Jitted anymore, and hasn't been for years. Java starts up as a high-performance interpreter (like Ruby, PERL etc.), then is compiled to native code in the background. There is no 'just in time', because there is no 'in time' - it is later.
"java games" are using specific chips for graphics and sound and perhaps a thin java wrapper lib for some low-level device API.
No they aren't. It doesn't work like this at all. Java games can certainly use hardware acceleration where it is present, but they don't have to - all of the 3D stuff can be done in pure Java.
Like I said, java wrappers for low-level native stuff...
And you were wrong.
"There are resource hogs in all languages. Java is in no way special."
so there we have it.
No. All this means is that resource-hogging programs can be written in Java, as in any language. There is nothing specifically resource hogging about Java itself.
I am, and what you have posted is very interesting. Personally, I don't much like SWT - it has real performance problems on some platforms I use - especially Linux. So, Java/GTK+ interests me if it can be neatly packaged for many platforms.
Meta-meta widget toolkits? It doesn't sound right to me somehow. Surely SWT should be hitting the metal (that is, X11) directly? What's gained by having it go via an intermediary whose API almost certainly isn't a one-to-one match?
Portability. You can have exactly the same SWT code on a large number of platforms. Don't think of SWT as 'meta' - think of it as mapping between a Java API and the 'native' API.
Re:Time For Apple To Release The Cocoa Runtime
on
Why Use GTK+?
·
· Score: 1
To able to build one fat binary on either Linux or Windows that runs on both Windows and Linux would turn the computing world on its head.
You mean like this?
javac MyApplication.java jar cvf MyJar.jar MyApplication.class
"This is the same excuse I have heard for decades when fans of a language try and 'justify' it's lack of performance."
Java:Ruby:: Pot:Kettle
It has got to the stage where Slashdotters making flippant comments about Java's apparent lack of performance are making themselves look ignorant, not cool - as part being cool is understanding technology and being up-to-date, not keeping hold of ancient language prejudices.
Just to give one example - last year someone wanted to do XML processing in Ruby. They could not believe how slow it was. Java's XML processing was about the speed of good C-based libraries. Ruby was about 50 times(!) slower.
"Even open source Java has reached the stage where it will run cross-platform GUIs."
Indeed, GTK+ for instance.:)
Yes - but my point is - why do you even need to know that you are using GTK+? Isn't this as irrelevant as knowing which filesystem type you are saving to? With something like SWT on Java you can use GTK+, Win32, Motif, MacOS/X etc. without knowing or caring which GUI is implementing your widgets. Surely this is the way forward, rather than trying to code for a particular GUI library?
For most applications, that might be the case, but it still injects bizarre loading behaviors in Real-Time apps, massively parallel apps, and high frequency data processing (i.e. the Stock Markets...) apps. I know, I develop code for the last category, and any Java apps we write (and we do write code IN Java as well as C++) avoid doing any code that does any dynamic allocations- otherwise we get little spikes (And, this is with modern JVMs...) that cause us to drop packet traffic like mad. JVMs don't do GC in a nice manner when you deal with data streams that swallow an OC-3 whole.
This is interesting, as I know that there are Java VMs that really do handle real-time apps with no problems whatsoever - I guess they must be specially tailored ones.
Re:With the bazillion GUI toolkits out there..
on
Why Use GTK+?
·
· Score: 1
Are there any cross platform (linux, mac, windows) GUI RAD tools ala Builder, yet?
Yes - and there has been for years. Java + IntelliJ or NetBeans. Even open source Java has reached the stage where it will run cross-platform GUIs.
Actually it is fun - it involved a lot of detective work!
BTW, (I'm thinking of your ports) isn't it amazing what programmers will go through because people can't come up with a new set of specs for they want the thing to do? I suppose it pays the bills.:-)
Actually, it is not that. It is because they develop in one language with no concerns for future portability, then don't bother to upgrade for 10 years and their code and language becomes unsupported.....
I don't think you understand: the approach used by scripting languages, like ruby, is to act as glue for already compiled software components. For this mean they have a high-level interface, a mere thin wrapper for native libs. Java libs (bytecodes), by contrast, are loaded into the JVM, then compiled (JIT), and finally run.
I don't think you understand. We are talking about language performance here, not what languages are used for. Whether or not a language is used as a wrapper is irrelevant. You show little understanding of how modern Java works - it is not JITed in the way you indicate - there is no 'finally' run (I assume by 'finally' you are implying some sort of delay).
Sure, there's a layer: what do you think will be translating ruby's syntax and operational semantics into the JVM's?
But the code that does that is hotspot optimised to native code, so there is no difference from C.
Can run is not the same as runs.
Tell that to the millions who use Java games on mobile devices each day.
What are you talking about anyway? A stripped-down JVM for embedded devices or a stripped-down HelloWorld.java running in a similar constrained VM with no libs loaded?
No. Reasonably full-featured VMs that have things like Gaming 3D libraries.
How untrue. Your swing app won't run in such environment, neither will you J2EE spaceopera...
So what? Your Ruby TK app won't run in that either, and neither will your PHP Zope application.
Here in the real world, java apps are some real resource hogs.
There are resource hogs in all languages. Java is in no way special. Even Swing Apps can run in a few MB.
Also, Java is semi-compiled while Ruby is purely interpreted, making it even slower.
Java is fully compiled. The Hotspot optimiser translates the Java byte code to highly optimised machine code.
However, if computers keep getting faster as they have been I doubt that Ruby's performance will be much of an issue in the future.
I have heard this kind of excuse for slow languages for decades. The fact is that the demands made by users is continually increasing - speed always has been and always will be important. More interestingly, what will be important is multi-threaded performance when the new multicore CPUs become common on the desktop. Java was designed to be easily multi-threaded from the start.
Actually, if Ruby can be effectively multi-threaded it may end up more efficient even interpreted than some single-threaded C/++ apps.
Now, I really don't like Ruby (Python is the king of the hill), but this is a gross understatement. More appropriate would be every fucking thing.
Apart from things like high-performance numerics, portable multi-threading, secure networking, secure class loading.. just to name a few.
So not 'every fucking thing' then......
I never understood why Java is considered a language and not a stripped-down C with a bloated vendor-API.
Because C doesn't have classes, unicode, built-in portable threading, a standard GUI library, exception handling, automatic stack tracing on error, a security manager, binary portability across different processors and word lengths, generics, standard APIs for portable relational database persistence and distributed code, internationalization, standard APIs for web page generation, standard APIs for high-performance image processing, standard APIs for high-performance 2D and 3D graphics, built-in datatypes for unlimited precision numerics....
Oh - and most of the common APIs (Hibernate, Spring etc) used with Java don't come from a commercial vendor.
Oh - and those APIs mentioned above aren't Vendor APIs - they are provided by all organisations that provide Java, not just Sun.
Apart from that you are correct.
Re:Loving complexity for complexity's sake
on
Ruby Off the Rails
·
· Score: 1
Swing applications still usually look they were created by children with crayons. If not that bad, then they still don't look as good on average as an SWT application.
I could not disagree more. SWT looks terrible on Windows - I have rarely seen one that picks up the XP look and feel right. on MacOS/X and Windows Vista Swing will be guaranteed to be indistiguishable from the native GUI.
Also, if you don't like the Swing look - download one you do like - there are hundreds of alternatives.
Ruby, IMHO, have the simplest model to do extensions on C/C++. So, is very easy to make a prototype on Ruby, profile, and speedup the bottlenecks with C
I have been down this route with other languages. There can come a point where a significant part of your code ends up in C or C++ (at least the key parts that do most of the work). You therefore lose many of the benefits of the language you start of with.
With a language like Java (or some of the faster Smalltalks or LISPs) this sort of messy compromise is unecessary.
By constrast, ruby has many good specialised data types and operators builtin, which do away with many uses for libs, and its libraries are thin wrappers to C compiled stuff running natively...
Unlike Ruby, Java does not require any C underneath, as it is compiled directly to native code.
Then why are you developing in java and its huge memory and cpu costs? To do anything in such limited language, you have to load tons of class libraries, running in the same runtime.
What huge memory and runtime costs? Java can run in just a few hundred KB.
You don't, of course, have to load tons of class libraries. Unlike many other languages, Java only loads the classes it needs, not the entire library file, as with.SO files and DLLs.
Next time you start to post about high memory and CPU costs you might want to consider that the fastest growth of Java today is in mobile devices, with their restricted memory and CPU power.
"There are alternatives - you can use both Ruby and Java together (JRuby works on the JVM)."
It sounds stupid to me to build a runtime on top of another runtime, if the goal is performance.
Who said there was a runtime on top of another runtime? It might be an idea to research before you post. Ruby on the JVM uses the JVM as it's runtime - there are no additional layers.
If your users demand performance above anything else, i suggest you deliver your software without a slow, bulky runtime
Which is why I don't use a language with a slow bulky runtime. I use modern Java, and (of course) I get very good performance.
Documentation is difficult, and good documentation is a lot harder than good code, and trying to fix this by adding a special type of comment to your code solves very little.
Javadoc is not trying to solve the problem of documentation - it is only trying to provide a way that method- and class-level documentation in code can be indexed, cross-indexed and collated as web pages. Nothing more.
I agree that there could be better ways to do things and keep things up-to-date, but to say that JavaDoc solves little is, in my view, way too harsh.
Autogenerating such comments OTOH is plain offensive, because real documentation cannot be generated
Autogeneration is simply there to create a skeleton comment with boiler-plate stuff filled in (parameter names, return types etc.). It is not intended as a replacement for real documentation - just as a time-saver for producing such documentation.
Slashdot Mirror
And for a Java enthusiast to make a general statement about performance as a primary reason to avoid a language/platform is selective amnesia at its finest.
Not at all. Firstly, I was not a Java enthusiast in 1995 because it was slow, so no hypocrisy here. Secondly, many of the comments here about Ruby aren't saying 'well it might get faster' - they are saying 'it is fast enough now'. Thirdly, it is difficult to predict which languages end up fast. A decade ago it looked like Smalltalk was on that route, but it failed and Java succeeded.
Mathematics and logic are universal - I can still have views about a Mandelbrot fractal, although I have never lived in one.
I agree.
I thank you for the discussion
And you.
Well, it is not very helpful to have a discussion with someone who is insisting nothing can be ever measured. I do not feel it was an argument in reply to my arguments.
Helpful or not, it is almost certainly the truth - it is not me who is insisting this, it is virtually all of modern physics. There may be a few who disagree (Wolfram, for example), but almost no-one takes this seriously.
My point in reply to your argument what that a point of view 'outside of the universe' would not make sense (in my opinion), as there would be neither time nor space in which to have the point of view....
Yea, fuck you too. If you have measured the spin of a particle, you know exactly what the spin state is or at least was.
The spin state, if measured around one axis, is a single variable.
I said....
"there is no such thing as an exact single state, at least of more than one variable."
Well, there can be different points of view, can't they?
Outside of time and space, it hard to know what 'point of view' means.
You are right that the Bell equations seem to contradict me; but Wolfram states they are unconfirmed
Well, he would say that, and he is hardly an authority on the matter. Almost all others disagree with him.
I don't quite see why if a quantum state represents an overlay of several states it cannot even represent an exact single state when requested to do so.
Because there is no such thing as an exact single state, at least of more than one variable. You can't have an exact state of position and momentum at the same time, for example.
Particles without quantum physics would basically react like billard, basically relying on the pauli principle and exchange of values that maintain the sums. I can see what your reply will be: That billard physics has been disproved in favor of quantum physics.
Actually no - I would say that the 'billiard' model sounds no more or less like a simulation than the quantum model.
I am not disputing that, I am stating that there might exist a point of view outside our universe from which our universe can be considered a simulation.
I don't see that - as it is hard enough to define a point of view within the universe, let another without - I'm not even the idea of a 'point of view' is sensible for this.
I believe the existance of a working quantum theory means that the universe can be considered as a simulation insofar as there might exist a universe without quantum physics and just particle physics.
This is extremely doubtful, as it is hard to see how there could even be particles without quantum physics. What would these particles be? Infinitesimal points? If so, how could they react?
"Java starts up as a high-performance interpreter (like Ruby, PERL etc.),"
thanks for the acknowledgement
But even within a few seconds, it gets much faster.
"in the background" still means "in time": it's compiled just before it can run, and then the "hotspot" analyzer goes on looking for spots that can be optimized. It's a runtime, occupying memory and cpu cycles and no matter how many optimizations it does, the generated code still doesn't run at C/C++/OCaml levels...
It occupies some memory and CPU cycles, but not much. Hotspot optimisers run fine even in restricted memory and CPU situations like J2ME.
And, no matter how many times you repeat it, saying that 'the generated code still doesn't run at C/C++.. levels' is simply factually wrong.
Once the Hotspot optimiser has done it's work you are left with very highly tuned machine code that is as good as anything that is churned out by a pre-compiler. Loop unrolling is performed where necessary, variable and constant re-organistion, aggressive in-lining of function, and removal of bounds checking is just the start. There is also native machine code re-ordering to optimise pipeline use, and also the use of additional features on specific processors (such as MMX).
This is exactly what pre-compilers do. You get the same performance. In fact, you can get better as the code is regularly (but in a low-priority background thread that does not impair performance) re-profiled so that optimisations can be changed and refined.
If you wish to insist that Java is slower, you are going to have to explain how all these optimisations actually make code slower, when they have for decades been used to give high performance. The only difference with Java is that this aggressive optimisation takes place mostly during a short period after the application starts.
Actually, I have simplified things. There are options on modern JVMs to control the balance between startup performance and optimising. The '-client' switch (on by default) says 'start up fast and concentrate on optimising later'. This means that, although the program is pretty fast, heavy optimisation may not happen for a while. The '-server' switch is designed for non-GUI apps. It says 'take a bit longer starting up and turn on full optimisation in the background immediately'.
It is the use of the '-server' switch that allows Java to easily match the output of most C or C++ compilers in most benchmarks providing code runs for more than a few seconds.
hey, i'm kinda tired. are you?
Not at all! I'm just getting started....
yes, there's a delay while it's being JITted. that's what JIT means: just-in-time compilation. in other words: just in time for a run.
No, because Java isn't Jitted anymore, and hasn't been for years. Java starts up as a high-performance interpreter (like Ruby, PERL etc.), then is compiled to native code in the background. There is no 'just in time', because there is no 'in time' - it is later.
"java games" are using specific chips for graphics and sound and perhaps a thin java wrapper lib for some low-level device API.
No they aren't. It doesn't work like this at all. Java games can certainly use hardware acceleration where it is present, but they don't have to - all of the 3D stuff can be done in pure Java.
Like I said, java wrappers for low-level native stuff...
And you were wrong.
"There are resource hogs in all languages. Java is in no way special."
so there we have it.
No. All this means is that resource-hogging programs can be written in Java, as in any language. There is nothing specifically resource hogging about Java itself.
Try to keep an open mind, yeah? :) :)
I am, and what you have posted is very interesting. Personally, I don't much like SWT - it has real performance problems on some platforms I use - especially Linux. So, Java/GTK+ interests me if it can be neatly packaged for many platforms.
Meta-meta widget toolkits? It doesn't sound right to me somehow. Surely SWT should be hitting the metal (that is, X11) directly? What's gained by having it go via an intermediary whose API almost certainly isn't a one-to-one match?
Portability. You can have exactly the same SWT code on a large number of platforms. Don't think of SWT as 'meta' - think of it as mapping between a Java API and the 'native' API.
To able to build one fat binary on either Linux or Windows that runs on both Windows and Linux would turn the computing world on its head.
You mean like this?
javac MyApplication.java
jar cvf MyJar.jar MyApplication.class
"This is the same excuse I have heard for decades when fans of a language try and 'justify' it's lack of performance."
:: Pot:Kettle
:: Pot:Kettle
Java:Ruby
It has got to the stage where Slashdotters making flippant comments about Java's apparent lack of performance are making themselves look ignorant, not cool - as part being cool is understanding technology and being up-to-date, not keeping hold of ancient language prejudices.
Just to give one example - last year someone wanted to do XML processing in Ruby. They could not believe how slow it was. Java's XML processing was about the speed of good C-based libraries. Ruby was about 50 times(!) slower.
So, comments like
Java:Ruby
Are an old, out-of-date joke told badly.
"Even open source Java has reached the stage where it will run cross-platform GUIs."
:)
Indeed, GTK+ for instance.
Yes - but my point is - why do you even need to know that you are using GTK+? Isn't this as irrelevant as knowing which filesystem type you are saving to? With something like SWT on Java you can use GTK+, Win32, Motif, MacOS/X etc. without knowing or caring which GUI is implementing your widgets. Surely this is the way forward, rather than trying to code for a particular GUI library?
Scanned it. Page one had conventional false hood. The polar ice caps are not at a record low. Only 50-100 million years ago they were completely gone.
'record low' means 'lowest on record'. Unless I am mistaken we have no human records from 50-200 million years ago.
For most applications, that might be the case, but it still injects bizarre loading behaviors in Real-Time apps, massively parallel apps, and high frequency data processing (i.e. the Stock Markets...) apps. I know, I develop code for the last category, and any Java apps we write (and we do write code IN Java as well as C++) avoid doing any code that does any dynamic allocations- otherwise we get little spikes (And, this is with modern JVMs...) that cause us to drop packet traffic like mad. JVMs don't do GC in a nice manner when you deal with data streams that swallow an OC-3 whole.
This is interesting, as I know that there are Java VMs that really do handle real-time apps with no problems whatsoever - I guess they must be specially tailored ones.
Are there any cross platform (linux, mac, windows) GUI RAD tools ala Builder, yet?
Yes - and there has been for years. Java + IntelliJ or NetBeans. Even open source Java has reached the stage where it will run cross-platform GUIs.
I don't envy you that work. :-)
:-)
Actually it is fun - it involved a lot of detective work!
BTW, (I'm thinking of your ports) isn't it amazing what programmers will go through because people can't come up with a new set of specs for they want the thing to do? I suppose it pays the bills.
Actually, it is not that. It is because they develop in one language with no concerns for future portability, then don't bother to upgrade for 10 years and their code and language becomes unsupported.....
I don't think you understand: the approach used by scripting languages, like ruby, is to act as glue for already compiled software components. For this mean they have a high-level interface, a mere thin wrapper for native libs. Java libs (bytecodes), by contrast, are loaded into the JVM, then compiled (JIT), and finally run.
I don't think you understand. We are talking about language performance here, not what languages are used for. Whether or not a language is used as a wrapper is irrelevant. You show little understanding of how modern Java works - it is not JITed in the way you indicate - there is no 'finally' run (I assume by 'finally' you are implying some sort of delay).
Sure, there's a layer: what do you think will be translating ruby's syntax and operational semantics into the JVM's?
But the code that does that is hotspot optimised to native code, so there is no difference from C.
Can run is not the same as runs.
Tell that to the millions who use Java games on mobile devices each day.
What are you talking about anyway? A stripped-down JVM for embedded devices or a stripped-down HelloWorld.java running in a similar constrained VM with no libs loaded?
No. Reasonably full-featured VMs that have things like Gaming 3D libraries.
How untrue. Your swing app won't run in such environment, neither will you J2EE spaceopera...
So what? Your Ruby TK app won't run in that either, and neither will your PHP Zope application.
Here in the real world, java apps are some real resource hogs.
There are resource hogs in all languages. Java is in no way special. Even Swing Apps can run in a few MB.
Also, Java is semi-compiled while Ruby is purely interpreted, making it even slower.
Java is fully compiled. The Hotspot optimiser translates the Java byte code to highly optimised machine code.
However, if computers keep getting faster as they have been I doubt that Ruby's performance will be much of an issue in the future.
I have heard this kind of excuse for slow languages for decades. The fact is that the demands made by users is continually increasing - speed always has been and always will be important. More interestingly, what will be important is multi-threaded performance when the new multicore CPUs become common on the desktop. Java was designed to be easily multi-threaded from the start.
Actually, if Ruby can be effectively multi-threaded it may end up more efficient even interpreted than some single-threaded C/++ apps.
Now, I really don't like Ruby (Python is the king of the hill), but this is a gross understatement. More appropriate would be every fucking thing .
.. just to name a few.
Apart from things like high-performance numerics, portable multi-threading, secure networking, secure class loading
So not 'every fucking thing' then......
I never understood why Java is considered a language and not a stripped-down C with a bloated vendor-API.
Because C doesn't have classes, unicode, built-in portable threading, a standard GUI library, exception handling, automatic stack tracing on error, a security manager, binary portability across different processors and word lengths, generics, standard APIs for portable relational database persistence and distributed code, internationalization, standard APIs for web page generation, standard APIs for high-performance image processing, standard APIs for high-performance 2D and 3D graphics, built-in datatypes for unlimited precision numerics....
Oh - and most of the common APIs (Hibernate, Spring etc) used with Java don't come from a commercial
vendor.
Oh - and those APIs mentioned above aren't Vendor APIs - they are provided by all organisations that provide Java, not just Sun.
Apart from that you are correct.
Swing applications still usually look they were created by children with crayons. If not that bad, then they still don't look as good on average as an SWT application.
I could not disagree more. SWT looks terrible on Windows - I have rarely seen one that picks up the XP look and feel right. on MacOS/X and Windows Vista Swing will be guaranteed to be indistiguishable from the native GUI.
Also, if you don't like the Swing look - download one you do like - there are hundreds of alternatives.
Ruby, IMHO, have the simplest model to do extensions on C/C++.
So, is very easy to make a prototype on Ruby, profile, and speedup the bottlenecks with C
I have been down this route with other languages. There can come a point where a significant part of your code ends up in C or C++ (at least the key parts that do most of the work). You therefore lose many of the benefits of the language you start of with.
With a language like Java (or some of the faster Smalltalks or LISPs) this sort of messy compromise is unecessary.
By constrast, ruby has many good specialised data types and operators builtin, which do away with many uses for libs, and its libraries are thin wrappers to C compiled stuff running natively...
.SO files and DLLs.
Unlike Ruby, Java does not require any C underneath, as it is compiled directly to native code.
Then why are you developing in java and its huge memory and cpu costs? To do anything in such limited language, you have to load tons of class libraries, running in the same runtime.
What huge memory and runtime costs? Java can run in just a few hundred KB.
You don't, of course, have to load tons of class libraries. Unlike many other languages, Java only loads the classes it needs, not the entire library file, as with
Next time you start to post about high memory and CPU costs you might want to consider that the fastest growth of Java today is in mobile devices, with their restricted memory and CPU power.
"There are alternatives - you can use both Ruby and Java together (JRuby works on the JVM)."
It sounds stupid to me to build a runtime on top of another runtime, if the goal is performance.
Who said there was a runtime on top of another runtime? It might be an idea to research before you post. Ruby on the JVM uses the JVM as it's runtime - there are no additional layers.
If your users demand performance above anything else, i suggest you deliver your software without a slow, bulky runtime
Which is why I don't use a language with a slow bulky runtime. I use modern Java, and (of course) I get very good performance.
You really need to get up to date.
Documentation is difficult, and good documentation is a lot harder than good code, and trying to fix this by adding a special type of comment to your code solves very little.
Javadoc is not trying to solve the problem of documentation - it is only trying to provide a way that method- and class-level documentation in code can be indexed, cross-indexed and collated as web pages. Nothing more.
I agree that there could be better ways to do things and keep things up-to-date, but to say that JavaDoc solves little is, in my view, way too harsh.
Autogenerating such comments OTOH is plain offensive, because real documentation cannot be generated
Autogeneration is simply there to create a skeleton comment with boiler-plate stuff filled in (parameter names, return types etc.). It is not intended as a replacement for real documentation - just as a time-saver for producing such documentation.