C++ has no inherent support for multiple threads. Pretty much everything is done through an OS api.
My contention is and always will be that it is easier simply to avoid threading entirely than to even bother with the details of where and when to use it. The pain of doing it right through native threads will be worth it when those few problems that demand threading arise. This statement is obviously opinion and highly subjective.
>>To this my response is that yes, straight C makes stack smashes a reality. C++, when used with the standard libraries, can correct this issue.
C++ corrects this? How?
By using the STL to create your datastructures. This safety is included.
One of Java's best assets is its notion of dynamic class loading, which could just as easily be done in a native-binary model, although the use of
bytecode makes Java's approach more flexible, more adaptive, and of course logistically simpler for porting purposes.
Sorry Earlybird, but if you don't know by now that C++ has late binding and RTTI (which is directly implied by the ext preceeding that part I quoted), there really isn't much point continuing this thread.
Plenty of people have successfully implemented forms/servlets in
C++ and RDBMS or similar things in Java.
No, no one has implemented a Java RDBMS, at least in the sense that they ever expected anyone else to use it.
Now for medium to large scale, cross platform, multithreaded, easily extensible, middleware applications that will need little or no maintainance but are
easily maintenable, Java[tm] cannot be beat.
The only one I'll give you is XML support. Java probably has the best support for XML right now - too bad its general text-handling sucks.
For "safety" without the performance cost of threading, I suggest any of Perl, Python, Ruby, etc. Its my opinion that there are still very few applications that really demand threading, and the chance of misusing it is greater than the supposed benefits.
..Unless, that is, all the "object churn" has been inlined by the VM - at runtime.
I don't think any VM - or JIT - has ever claimed to eliminate object churn completely. I'm getting the impression that you think you can throw whatever you want at the VM and JIT and it will magically divine what you were really trying to do and somehow create the optimal solution for you. Unfortunately, this appears to be a pervasive myth among Java programmers.
No wonder new stuff is sprouting up like mushrooms -- a phenomenon
that I suppose Bjarne Stroustrup is mildly annoyed about and doesn't quite understand. Once you've written a C++ app, it's a dead end. It not reusable.
I can assure you that there is nothing about programming languages that you (or I) understand that Bjarne doesn't. C++ is a system/platform language. Java is an application langauge. Bjarne and Gosling have pointed this out repeatedly. This is why you'd be silly to write a forms/servelet app in C++ (unless its being served on a site like yahoo or AOL), and you'd be equally silly to write an RDBMs, web browser, or document processor in java.
The notion that C++ code is a "dead end" is also ludicrous. C++ has standard libs. Java has standard libs. You either use them or your own object hierarchy. If your C++ hierarchy is unuseable, why would its java version be any better? As it stands, reuse through generic programming is far more powerful than OO in any case.
I agree with the rest of your post, so I won't quote it. As it stands, if you like Python, check out Ruby - its probably closer to the OO nirvana you are looking for, although it is mostly popular in Japan where it orginated.
What you seem to be saying is that you're angry with Java from abstracting the low-level too much.
No, I'm sick of a language making me buy and pay for synchronization when I may neither want nor need it. If a programmer doesn't know the difference, you have to wonder what their paycheck is for. I repeat - there is no such thing as threading for dummies. You cannot get around using your head on threads, and when you do, C++ will be a much more satisfactory choice.
How wouldn't you know what you're incurring? You're writing the app, aren't you? There are such things as profiling tools.
Find me ten average Java programmers who can point out the synchronized objects and the non-synchronized objects they are instantiating. Threading will get you poor performance when poorly applied. I would rather have the default be that it not be applied, as I don't want to pay for what I don't use.
Memory allocation is definitely costly, on the other hand, but is much less prone to errors than stack-allocation of objects in C++. (Pointer smashes from
passing around stack-objects that went out of scope a long time ago is a nasty, but common, occurence when you have free reign with memory addresses in
the language.)
To this my response is that yes, straight C makes stack smashes a reality. C++, when used with the standard libraries, can correct this issue. Added to which, generic programming is entirely more useful than OO, and C++ is the only language the implements it usefully.
"Verbose syntax" doesn't cause performance problems,
Bullshit!!!
The compiler has to do something with all of those language elements. When you enter
Foo.bar.crap(crud), there isn't a genie in a bottle that comes out and figures out what you were trying to say - your statements get parsed with the presumption that you want all this object churn to happen.
Syntax matters. Yes, you can find "hotspots" in the code, but a JIT is not a magic wand. Try writing a compiler sometime and you'll appreciate the impact of syntax on compiled code.
A fairly rigorous set of benchmarks was performed by Michael Hirsch in the August 2000 issue of Linux Journal.
It isn't pretty. All of the Windows solutions beat all of the linux solutions, inlcuding gcj.
Java may be adequate on linux, but I really don't know how you could conclude that it "rocks".
Javalobby stats should not be trusted - my experience is that Javalobby has the lowest collective IQ of any community tech site on the web, and their articles are typically mindless advocacy with no useful data.
- JDK 1.3 is a massive improvement in client side performance,
Java is dead on the client - deal with it - Sun has. Compare Java client code to even the crap that runs in Macromedia plug-ins, and there is no comparison.
Plus, server side Java code has been shown to be, at times, faster than optimized C code:
Oh be real - these benchmarks are all using in-memory operations on scaled data sets. Show me some real-world tests - graphics, user input, networking - and watch Java come to a crawl. These are the same types of useless benchmarks that HotSport advocates have been tossing around. They're cute, but no one is going to bet their job on matrix transformation benchmarks (if they want to keep their job).
Java is a very pleasant language to work in.
Uggh! I strongly disagree. How verbose can one language be? I can crank out useable solutions in perl in a quarter of the code, and they'll likely cream the Java performance as well (Hotspot included), and I'm not talking about matrix transforms or Fibonacci sequences.
My major problem with Java is it tries to make threading useable by people who have no idea what threads are or why or when they should be used. Like attaching a thread to each Socket, or synchronization of strings.There is no such thing as "threading for dummies" - try going this route and you actually get a massive performance degradation.
As for Java performance - look at the language! All that threading, OO support, etc. that is built-in, and all that object churn you don't even know you're incurring - they're part of Java and result from the ridiculously verbose syntax. You're never going to get rid of this degradation.
I still heartily endorse the use of C++ for large scale code. Its open, it performs, and it doesn't make you pay for features you don't use. Its intelligently designed, and designed for intelligent people. Admittedly it has a learning curve, but anything worthwhile does.
As an owner of a vast chunk of Sun stock, I am obviously happy that it has appreciated, but I'm not naive enough to think that Java has anything to do with it.
Its sales of Sparc boxes that are paying the bills over there folks.
I can't wait to hear the response from Sun advocates - but let me tell you as a preemptive counter-response, that Jini adoption is going nowhere. Industry is still aching from draconian dealings with MS - they aren't about to enter into the same types of relationship with Sun.
Jini is dead folks. If you think otherwise, point me at one real world device that uses it.
The latest issue of linux journal has a great piece about Java on linux - currently even compiled solutions like gcj perform worse than the windows runtimes, and this is coming from a linux publication.
Firstly, I woiuld like to let you know that IBM and Oracle have succesfully jumped on and off every programming bandwagon of the last ten years.
Trust me - Java can vanish from Oracle as fast as it came...and this coming from someone who has the audacity to call others clueless - give me a break - you obviously have little experience with Oracle "support" of these passing-fancy technologies.
As for Servelets and JSP - Java has got to be the clunkiest page pushing platform I have ever seen. Compare the simplicity and power of PHP to the ridiculously verbose embedded Java solutions, and you really have to wonder who is making these decisions.
And what is with the ridiculous "tm" following each mention of Java??
Java continues to be what it always has been - a "for-idiots-by-idiots" language that will never perform and will always be ridiculously verbose to the point of pain.
Digital's mistakes are legendary (mostly the continuous
waffling other whether to support Vax or UNIX and not enough resources to do both), but it appears that Sun may be headed down that same road
(Free Solaris for $99, use Linux at the low end, migrate to Solaris at the high end).
When do this strategy emerge? Every indication is that Sun is backing Solaris on Sparc as their single unified strategy.
As for Compaq, their only hope now is large corporate contracts. Dell has largely pushed them out of the direct/consumer market, and their recent stumbles have given consumers the impression that they are no longer a leader despite their size. As you know, the company has also had some extremely questionable financials in the last two years.
The fact that Sun is destroying IBM in the unix market has little to do with technical issues - the Sparc architecture itself is far behind. Its marketing pure and simple. Sun has a coherent end-to-end marketing story - Solaris on Sun Sparc hardware, IBM doesn't - they're beholden to too many platforms.
Take a look at Sun's market share and their stock price. They aren't too worried about linux just yet. In fact, its IBM who should be worried about Sun virtually locking up the midrange like Microsoft has the low end.
The not-Sun and not-MS crowd (HP, IBM, SGI) have woken up and finally smelled the coffee - those who present a unified single solution, win.
Expect each vendor in this group crowd to dump its proprietary unix. HP certainly will if it wants to revice its flagging unix-systems division - which in this quarter was only a fraction of HP's reported earnings. SGI pretty much already has adopted linux full-fledged (not sure if this, or SGI, even really matters), and IBM looks like they are on their way.
They really don't have a choice - Sun is as much of a threat to these vendors now as MS, and McNealy is going to be as much as a cut-throat as Gates about killing off the competition (who I garner he never really cared for anyway).
Fragmentation-for-features was only ever worthwhile when unix was being marketed strictly to brainy IT folks buying high-end equipment only. Now its entering the mainstream and marketing matters. The fragmented approach simply doesn't jive when you are trying to tell a coherent marketing story.
IBM can't kill Itanium because it was never going to really breathe any life into it - the potential market for Moneterey was small and getting smaller.
Like it or not, a lot of people are lining up behind Itanium and Intel is still the unquestioned emperor of the microprocessor market. They'll do fine without Monterey.
Monterey was really one of IBM's worst ideas in recent memory, and harkened back to an earlier time (early 90s) when IBM seemed unable to gauge public demands.
I amazed that they even ever saw SCO as a viable partner - the corpse of SCO has been floating from door to door looking for some poor sucker to take it in and break it down for spare parts. Caldera finally was suckered. Ransom Love looked quite clueless telling the audience in San Jose that Linux alone couldn't do it - that somehow SCO's dead product line was needed to complete its promise to customers. What hooey. SCO will be like WordPerfect, a forgotten power that drifts from buyer to buyer. Caldera needs to realize that customers want to hear a coherent marketing story - having a linux company come out and tell people that linux is inadequate is not what I would call a compelling marketing story. This doesn't surprise me one bit - Caldera has never known one thing about marketing their own product (the "Business Linux"???? what the hell is that????).
Anyway, back to IBM. Its nice to see finally that the potential market for AIX on IA64 is likely too small to address as a strategic issue. Customers are tired of parallel product lines that somehow address high-end, midrange, low-end, in some bizarre drivel that never makes any sense. Look at Compaq's worthless unix marketing plan regarding Tru64 and Linux.
IBMs major problem has always been that it considers itself too big to commit to any one platform. This is why still to this day IBM has marketing issues. Look at Sun - they have one product line and one OS - a Sun customer always knows what end is up with that company and the Sun commitment is always coherent. This is why Sun is going to continue being the number one unix vendor, for better or for worse, even though IBM's product lineup is likely superior (just impossible to see in continuity).
Slashdot Mirror
If I had to nail down your perspective neatly, I'd simply have to conclude that you're simply a habitual complainer.
My contention is and always will be that it is easier simply to avoid threading entirely than to even bother with the details of where and when to use it. The pain of doing it right through native threads will be worth it when those few problems that demand threading arise. This statement is obviously opinion and highly subjective.
>>To this my response is that yes, straight C makes stack smashes a reality. C++, when used with the standard libraries, can correct this issue.
C++ corrects this? How?
By using the STL to create your datastructures. This safety is included.
Sorry Earlybird, but if you don't know by now that C++ has late binding and RTTI (which is directly implied by the ext preceeding that part I quoted), there really isn't much point continuing this thread.
Plenty of people have successfully implemented forms/servlets in C++ and RDBMS or similar things in Java.
No, no one has implemented a Java RDBMS, at least in the sense that they ever expected anyone else to use it.
The only one I'll give you is XML support. Java probably has the best support for XML right now - too bad its general text-handling sucks.
For "safety" without the performance cost of threading, I suggest any of Perl, Python, Ruby, etc. Its my opinion that there are still very few applications that really demand threading, and the chance of misusing it is greater than the supposed benefits.
I don't think any VM - or JIT - has ever claimed to eliminate object churn completely. I'm getting the impression that you think you can throw whatever you want at the VM and JIT and it will magically divine what you were really trying to do and somehow create the optimal solution for you. Unfortunately, this appears to be a pervasive myth among Java programmers.
I can assure you that there is nothing about programming languages that you (or I) understand that Bjarne doesn't. C++ is a system/platform language. Java is an application langauge. Bjarne and Gosling have pointed this out repeatedly. This is why you'd be silly to write a forms/servelet app in C++ (unless its being served on a site like yahoo or AOL), and you'd be equally silly to write an RDBMs, web browser, or document processor in java.
The notion that C++ code is a "dead end" is also ludicrous. C++ has standard libs. Java has standard libs. You either use them or your own object hierarchy. If your C++ hierarchy is unuseable, why would its java version be any better? As it stands, reuse through generic programming is far more powerful than OO in any case.
I agree with the rest of your post, so I won't quote it. As it stands, if you like Python, check out Ruby - its probably closer to the OO nirvana you are looking for, although it is mostly popular in Japan where it orginated.
Heavy use since 0.9.
Most of the time very frustrating - trying to use the various incarantions of AWT/Swing/whatever.
On the server side, some serious data mangling and networking (perl/C++ destroys it in this repsect).
Its a solution looking for a problem.
No, I'm sick of a language making me buy and pay for synchronization when I may neither want nor need it. If a programmer doesn't know the difference, you have to wonder what their paycheck is for. I repeat - there is no such thing as threading for dummies. You cannot get around using your head on threads, and when you do, C++ will be a much more satisfactory choice.
How wouldn't you know what you're incurring? You're writing the app, aren't you? There are such things as profiling tools.
Find me ten average Java programmers who can point out the synchronized objects and the non-synchronized objects they are instantiating. Threading will get you poor performance when poorly applied. I would rather have the default be that it not be applied, as I don't want to pay for what I don't use.
Memory allocation is definitely costly, on the other hand, but is much less prone to errors than stack-allocation of objects in C++. (Pointer smashes from passing around stack-objects that went out of scope a long time ago is a nasty, but common, occurence when you have free reign with memory addresses in the language.)
To this my response is that yes, straight C makes stack smashes a reality. C++, when used with the standard libraries, can correct this issue. Added to which, generic programming is entirely more useful than OO, and C++ is the only language the implements it usefully.
Bullshit!!!
The compiler has to do something with all of those language elements. When you enter
Foo.bar.crap(crud), there isn't a genie in a bottle that comes out and figures out what you were trying to say - your statements get parsed with the presumption that you want all this object churn to happen.
Syntax matters. Yes, you can find "hotspots" in the code, but a JIT is not a magic wand. Try writing a compiler sometime and you'll appreciate the impact of syntax on compiled code.
It really goes to show how few coders really know that much about their tools and why they use them.
It isn't pretty. All of the Windows solutions beat all of the linux solutions, inlcuding gcj.
Java may be adequate on linux, but I really don't know how you could conclude that it "rocks".
Javalobby stats should not be trusted - my experience is that Javalobby has the lowest collective IQ of any community tech site on the web, and their articles are typically mindless advocacy with no useful data.
Java is dead on the client - deal with it - Sun has. Compare Java client code to even the crap that runs in Macromedia plug-ins, and there is no comparison.
Plus, server side Java code has been shown to be, at times, faster than optimized C code:
Oh be real - these benchmarks are all using in-memory operations on scaled data sets. Show me some real-world tests - graphics, user input, networking - and watch Java come to a crawl. These are the same types of useless benchmarks that HotSport advocates have been tossing around. They're cute, but no one is going to bet their job on matrix transformation benchmarks (if they want to keep their job).
Java is a very pleasant language to work in.
Uggh! I strongly disagree. How verbose can one language be? I can crank out useable solutions in perl in a quarter of the code, and they'll likely cream the Java performance as well (Hotspot included), and I'm not talking about matrix transforms or Fibonacci sequences.
My major problem with Java is it tries to make threading useable by people who have no idea what threads are or why or when they should be used. Like attaching a thread to each Socket, or synchronization of strings.There is no such thing as "threading for dummies" - try going this route and you actually get a massive performance degradation.
As for Java performance - look at the language! All that threading, OO support, etc. that is built-in, and all that object churn you don't even know you're incurring - they're part of Java and result from the ridiculously verbose syntax. You're never going to get rid of this degradation.
I still heartily endorse the use of C++ for large scale code. Its open, it performs, and it doesn't make you pay for features you don't use. Its intelligently designed, and designed for intelligent people. Admittedly it has a learning curve, but anything worthwhile does.
Its sales of Sparc boxes that are paying the bills over there folks.
Jini is dead folks. If you think otherwise, point me at one real world device that uses it.
Trust me - Java can vanish from Oracle as fast as it came...and this coming from someone who has the audacity to call others clueless - give me a break - you obviously have little experience with Oracle "support" of these passing-fancy technologies.
As for Servelets and JSP - Java has got to be the clunkiest page pushing platform I have ever seen. Compare the simplicity and power of PHP to the ridiculously verbose embedded Java solutions, and you really have to wonder who is making these decisions.
And what is with the ridiculous "tm" following each mention of Java??
Java continues to be what it always has been - a "for-idiots-by-idiots" language that will never perform and will always be ridiculously verbose to the point of pain.
When do this strategy emerge? Every indication is that Sun is backing Solaris on Sparc as their single unified strategy.
As for Compaq, their only hope now is large corporate contracts. Dell has largely pushed them out of the direct/consumer market, and their recent stumbles have given consumers the impression that they are no longer a leader despite their size. As you know, the company has also had some extremely questionable financials in the last two years.
The fact that Sun is destroying IBM in the unix market has little to do with technical issues - the Sparc architecture itself is far behind. Its marketing pure and simple. Sun has a coherent end-to-end marketing story - Solaris on Sun Sparc hardware, IBM doesn't - they're beholden to too many platforms.
No, before linux you had very few ISVs willing to even bother trying to get their products on any unix platform.
This is a good thing.
It won't help Caldera
Take a look at Sun's market share and their stock price. They aren't too worried about linux just yet. In fact, its IBM who should be worried about Sun virtually locking up the midrange like Microsoft has the low end.
Expect each vendor in this group crowd to dump its proprietary unix. HP certainly will if it wants to revice its flagging unix-systems division - which in this quarter was only a fraction of HP's reported earnings. SGI pretty much already has adopted linux full-fledged (not sure if this, or SGI, even really matters), and IBM looks like they are on their way.
They really don't have a choice - Sun is as much of a threat to these vendors now as MS, and McNealy is going to be as much as a cut-throat as Gates about killing off the competition (who I garner he never really cared for anyway).
Fragmentation-for-features was only ever worthwhile when unix was being marketed strictly to brainy IT folks buying high-end equipment only. Now its entering the mainstream and marketing matters. The fragmented approach simply doesn't jive when you are trying to tell a coherent marketing story.
Like it or not, a lot of people are lining up behind Itanium and Intel is still the unquestioned emperor of the microprocessor market. They'll do fine without Monterey.
I amazed that they even ever saw SCO as a viable partner - the corpse of SCO has been floating from door to door looking for some poor sucker to take it in and break it down for spare parts. Caldera finally was suckered. Ransom Love looked quite clueless telling the audience in San Jose that Linux alone couldn't do it - that somehow SCO's dead product line was needed to complete its promise to customers. What hooey. SCO will be like WordPerfect, a forgotten power that drifts from buyer to buyer. Caldera needs to realize that customers want to hear a coherent marketing story - having a linux company come out and tell people that linux is inadequate is not what I would call a compelling marketing story. This doesn't surprise me one bit - Caldera has never known one thing about marketing their own product (the "Business Linux"???? what the hell is that????).
Anyway, back to IBM. Its nice to see finally that the potential market for AIX on IA64 is likely too small to address as a strategic issue. Customers are tired of parallel product lines that somehow address high-end, midrange, low-end, in some bizarre drivel that never makes any sense. Look at Compaq's worthless unix marketing plan regarding Tru64 and Linux.
IBMs major problem has always been that it considers itself too big to commit to any one platform. This is why still to this day IBM has marketing issues. Look at Sun - they have one product line and one OS - a Sun customer always knows what end is up with that company and the Sun commitment is always coherent. This is why Sun is going to continue being the number one unix vendor, for better or for worse, even though IBM's product lineup is likely superior (just impossible to see in continuity).