Java...
Is it just me or do c++ programmers in general hate java as well. |
Let me guess, are they those late 90's programmers that lost their jobs after most enterprise and large-scale computing switched from C++ to Java?
Anyways, while more often than not java code is compiled to bytecode fed through the VM thus abstracting it further from hardware than c/c++, that doesn't mean you can't compile java code directly to machine code like you would c/c++. Honestly, its the virtual machine that keeps java from having direct (or near direct) access to hardware. |
All modern Java VMs compile Java to optimised native code. The only difference is that the set of optimisations done for Java is different than the set of optimisations done for C++ (generally JVMs have to be much smarter than C++ compilers to get the same pefromance, because Java is a higher level language).
Last edited on
I like to think of Java as C++'s idiot cousin, because that means that C# is that much more of an abomination (I'm only half joking here). Since this is a website dedicated to C++ I'll play devil's advocate and point out some of the more obviouos pro's for Java:
- There is only one company putting out the framework so all of the documentation should come from them. No third parties getting involved thinking that they have a better way of notating functions which gets in the way as you spend a week adjusting to their "documentation style".
- "jqs.exe" starts as a service, this means for those of us writting in Java we rarely need to remember to actually initialize, link to, or check for dependancies because the framework is already there for any user who is logged into the system either locally at the desktop or remotley in a Terminal Services Session (Sorry for the Win32 terminology).
- It's syntactically simular enough to C++ that the learning curve isn't really noticable. Although one could argue that this works against you since someone who is not practiced in both would get them confused easily.
- It's cross platform by it's very nature of being a third party framwork. There is no "If you're writting in this version of Linux you should use C++ otherwise you should use C in anything else" or "If you're writing in Win32 it's really C but it can be forced to look like C++ if you know what you're doing, just don't get it mixed up with C++\CLI because that's not the same thing...etc" or "If you want to write for a Mac you need to learn a whole new language called 'Objective-C'". Trust me this gets damn annoying really fast.
- There is only one company putting out the framework so all of the documentation should come from them. No third parties getting involved thinking that they have a better way of notating functions which gets in the way as you spend a week adjusting to their "documentation style".
- "jqs.exe" starts as a service, this means for those of us writting in Java we rarely need to remember to actually initialize, link to, or check for dependancies because the framework is already there for any user who is logged into the system either locally at the desktop or remotley in a Terminal Services Session (Sorry for the Win32 terminology).
- It's syntactically simular enough to C++ that the learning curve isn't really noticable. Although one could argue that this works against you since someone who is not practiced in both would get them confused easily.
- It's cross platform by it's very nature of being a third party framwork. There is no "If you're writting in this version of Linux you should use C++ otherwise you should use C in anything else" or "If you're writing in Win32 it's really C but it can be forced to look like C++ if you know what you're doing, just don't get it mixed up with C++\CLI because that's not the same thing...etc" or "If you want to write for a Mac you need to learn a whole new language called 'Objective-C'". Trust me this gets damn annoying really fast.
I personally dislike the Java language, but not the Java platform. If there was an officially supported Java bytecode backend for LLVM, I'd include it in my compiler immediately (along with the front-end).
The language sacrifices a lot of "dangerous" features to make it more beginner-friendly, features which in the hands of an expert can be very powerful tools. While I understand the reasoning, I do not necessarily agree with it. Not everything should be catered to the lowest common population segment.
-Albatross
The language sacrifices a lot of "dangerous" features to make it more beginner-friendly, features which in the hands of an expert can be very powerful tools. While I understand the reasoning, I do not necessarily agree with it. Not everything should be catered to the lowest common population segment.
-Albatross
Last edited on
closed account (3hM2Nwbp)
My Java Views:
+1 : Standardized documentation tool
+1 : "There's a class for that!"
+1 : Template parameters can extend existing classes
+1 : JNLP (Network Launch Protocol)
+1 : One class per file
+1 : Standardized reflection (and all of the goodies therein)
+1 : Effortlessly cross-platform code
-1 : Lack of low-level control (Think of a black box that's more like a black hole.)
-1 : Installing and configuring an (updated) JVM is border-line impossible for average end-users. (Think setting up paths...)
*-1 : IMO Profilers have quite a steep learning curve.
Total: +5 4 by my count.
If it wasn't for a few aspects of the language, I'd be a java-noid.
+1 : Standardized documentation tool
+1 : "There's a class for that!"
+1 : Template parameters can extend existing classes
|
|
+1 : JNLP (Network Launch Protocol)
+1 : One class per file
+1 : Standardized reflection (and all of the goodies therein)
+1 : Effortlessly cross-platform code
-1 : Lack of low-level control (Think of a black box that's more like a black hole.)
-1 : Installing and configuring an (updated) JVM is border-line impossible for average end-users. (Think setting up paths...)
*-1 : IMO Profilers have quite a steep learning curve.
Total: +
If it wasn't for a few aspects of the language, I'd be a java-noid.
Last edited on
| rapidcoder wrote: |
|---|
| Let me guess, are they those late 90's programmers that lost their jobs after most enterprise and large-scale computing switched from C++ to Java? |
closed account (1vRz3TCk)
| It's cross platform |
| "If you want to write for a Mac you need to learn a whole new language called 'Objective-C'" |
I have no feelings on Java one way or the other. I have not enjoyed using it but I have not hated it. I am possibly less interested in it now because of its current 'owners' than I was before.
-1 : Installing and configuring an (updated) JVM is border-line impossible for average end-users. (Think setting up paths...) |
Huh? Click a link "download Java", click "Next" one or two times, done. Anyway, most of them don't need to do that, because JRE is already installed on ~60-90% of computers (depends on who is benchmarking).
I dislike Java/C# because of the garbage collection. Smart pointer are doing the same job without a thread in the background that does who knows what...
Smart pointer are doing the same job without a thread in the background that does who knows what... |
The same job? Good joke. They don't reclaim cycles. You pay additional cost at every pointer assignment. Your pointers get bigger (higher memory usage). You pay a huge synchronisation cost if you happen to use them in multiple thread enabled application - you get interlocked inc/dec at every pointer assignment. They don't defragment memory. They don't provide fast allocation and they don't provide zero-cost deallocation (why pay for objects you no longer use?).
Most of the "I don't like Java's GC" comes from not knowing how it really works.
Last edited on
Then why don't you inform the apparently ignorant populace how it works, then? I'm sure they'll be interested to know.
-Albatross
-Albatross
| Most of the "I don't like Java's GC" comes from not knowing how it really works. |
closed account (1yR4jE8b)
While I like C++ for many things (speed, flexibility, etc...), I also like getting my work done. It takes a fraction of the time to write a program in Java then it does in C++, and Python/Ruby even less time still.
The amount of Java hate here is pretty staggering, and from the looks of it, mostly due to ignorance...
The amount of Java hate here is pretty staggering, and from the looks of it, mostly due to ignorance...
@darkestfright
If I had to guess the amount of Java hate we have here is due to a combination of ignorance and those who show up every once in a while on their high horse waving a flag for Java. if you get what I mean...
If I had to guess the amount of Java hate we have here is due to a combination of ignorance and those who show up every once in a while on their high horse waving a flag for Java. if you get what I mean...
@rapidcoder
<-agree
<-umm... are you sure?
<- Does usual pointer use fragments memory more? I am not very sure how hardware works, but once a friend in uni told me that, at least on x86 processors, memory is managed by the hardware using some weird system ("paging" I think). In other words, pointers are *always* fragmented *on the hardware level*; laying pointers "flat" is only to please "those stupid users", the programmers.
| pointers get bigger |
| (higher memory usage) |
| They don't defragment memory. |
Last edited on
rapidcoder is talking about virtual memory.
While paging is partly aided by the hardware (for example, by triggering an interrupt when a program tries to access a page that's been swapped out), it's mostly a function of the kernel.
While paging is partly aided by the hardware (for example, by triggering an interrupt when a program tries to access a page that's been swapped out), it's mostly a function of the kernel.
What I meant to say is that fragmenting your pointers (in the "laying out flat" sense of the word) does not (at least immediately) imply either slower performance, nor greater memory use. Actually, I think "compactifying" your pointers would be a mistake from an optimization standpoint, since the hardware already does that for you in the bottom-most layer. Compactifying your pointers appears to be a redundant abstraction for what is already handled for you.
[P.S.] When I was at the start of learning how to program (from this forum hehe :) I did some C++ new-delete experiments trying to get my RAM use to rise through memory fragmentation. I couldn't come up with a scheme that did it. Anyone have a suggestion?
[P.S.] When I was at the start of learning how to program (from this forum hehe :) I did some C++ new-delete experiments trying to get my RAM use to rise through memory fragmentation. I couldn't come up with a scheme that did it. Anyone have a suggestion?
Last edited on
It's a problem of memory usage, not performance. In a 32-bit space, if you have 4096 evenly-spaced 1 KiB buffers, then the size of the biggest single buffer you can allocate is 1023 KiB, even though only 4 MiB total are actually being used.
It's an exaggeration, of course, but you get the idea. It could be a problem for a program running for a very long time and performing certain patterns of allocation and deallocation.
EDIT: There are system calls that let you request memory at specific addresses. You can play with that, although system monitors will not report more than you actually requested, for obvious reasons.
It's an exaggeration, of course, but you get the idea. It could be a problem for a program running for a very long time and performing certain patterns of allocation and deallocation.
EDIT: There are system calls that let you request memory at specific addresses. You can play with that, although system monitors will not report more than you actually requested, for obvious reasons.
Last edited on