C++ vs Java - a motoring analogy
Discussion
Had an interesting discussion with one of our Java developers yesterday afternoon that I thought I'd share.
He'd overheard some of us C++ guys having a chat about dynamic memory allocation and confessed that as a Java guy he didn't even know what it was let alone used it.
The conversation moved on and he asked me why I stuck with C++ and I replied that it's like the difference between an automatic car and a manual; the automatic is more convenient, for sure, but some people relish the joy of a well-executed manual downshift with a heel-and-toe blip of the throttle and the greater degree of control and involvement. Plus a torque converter automatic takes some of the power of the engine away (although I acknowledge that it is less so these days).
He conceded my point and then admitted that he did actually drive an automatic as he "couldn't be arsed with the hassle of changing gear", which kind of reinforced my point.
I'm not expecting our Java PHer's (esp. dern) to agree with me, but what do you think of the analogy? Fair or flawed?
He'd overheard some of us C++ guys having a chat about dynamic memory allocation and confessed that as a Java guy he didn't even know what it was let alone used it.
The conversation moved on and he asked me why I stuck with C++ and I replied that it's like the difference between an automatic car and a manual; the automatic is more convenient, for sure, but some people relish the joy of a well-executed manual downshift with a heel-and-toe blip of the throttle and the greater degree of control and involvement. Plus a torque converter automatic takes some of the power of the engine away (although I acknowledge that it is less so these days).
He conceded my point and then admitted that he did actually drive an automatic as he "couldn't be arsed with the hassle of changing gear", which kind of reinforced my point.
I'm not expecting our Java PHer's (esp. dern) to agree with me, but what do you think of the analogy? Fair or flawed?
I reckon it's pretty reasonable.
There are times when you just can't avoid using a manual. I've just been writing some code, and everything worked fine when working on small files. The trouble was that it just seemed to hang up and do nothing for ages if you loaded up bigger files maybe 60 or 80 megabytes. (Prescott)
You start digging around and realise that the problem is actually coming from the way that you are allocating memory or more specifically the lifetime of objects. Once the realisation is made, a couple of quick tweaks, and the software handles an 80 meg file just as easily as a small one. If your compiler or runtime environment is controlling cleanup of objects, I just cant see how one would make such optimisations.
Another issue that I can't see java handling so well is that of heap corruption. So for example, I make a mistake somewhere, and corrupt a bit of the heap. I actually coded the heap that I normally use myself, so putting in checks to find the source of the problem is a doddle. The thing is that the boundary checks to find the problem can need to be so heavy that you can't get to the point where the problem occurs.
If you cant own your heap, I just cant see how you could perform such debugging. I suppose being a virtual machine, access by reference can be protected by a software mechanism that C++ people would call an access violation or exception fault. Nevertheless I can't imagine the performance penalty of having to generate access violations in software rather than in hardware.
There are times when you just can't avoid using a manual. I've just been writing some code, and everything worked fine when working on small files. The trouble was that it just seemed to hang up and do nothing for ages if you loaded up bigger files maybe 60 or 80 megabytes. (Prescott)
You start digging around and realise that the problem is actually coming from the way that you are allocating memory or more specifically the lifetime of objects. Once the realisation is made, a couple of quick tweaks, and the software handles an 80 meg file just as easily as a small one. If your compiler or runtime environment is controlling cleanup of objects, I just cant see how one would make such optimisations.
Another issue that I can't see java handling so well is that of heap corruption. So for example, I make a mistake somewhere, and corrupt a bit of the heap. I actually coded the heap that I normally use myself, so putting in checks to find the source of the problem is a doddle. The thing is that the boundary checks to find the problem can need to be so heavy that you can't get to the point where the problem occurs.
If you cant own your heap, I just cant see how you could perform such debugging. I suppose being a virtual machine, access by reference can be protected by a software mechanism that C++ people would call an access violation or exception fault. Nevertheless I can't imagine the performance penalty of having to generate access violations in software rather than in hardware.
I think that's a fair analagy.
It is a personal preference. I cut my teeth writing C, loved the speed and beauty of well crafted code using pointers, and function poniters.
I even wrote my own 'safe' macro wrappers to go around malloc and free to keep a track on where the memory was going.
These days however I predominantly code in Java and to be honest I don't miss the old ways at all.
What is crucial and worrying though is this Java guy didn't even know what you were talking about. Having been there, seen it, done it & spent a weekend tracking down memory leaks, I always have an appreciation for what is going on under the hood.
In these days of faster CPUs bucket loads of memory that as I youth you'd never even imagined let alone deamt about, the 'art' of coding is getting sloppy, but I appreaciate the extra time I have to focus on the Application and am more than happy to leave all the memory management to Sun.
best
Ex
It is a personal preference. I cut my teeth writing C, loved the speed and beauty of well crafted code using pointers, and function poniters.
I even wrote my own 'safe' macro wrappers to go around malloc and free to keep a track on where the memory was going.
These days however I predominantly code in Java and to be honest I don't miss the old ways at all.
What is crucial and worrying though is this Java guy didn't even know what you were talking about. Having been there, seen it, done it & spent a weekend tracking down memory leaks, I always have an appreciation for what is going on under the hood.
In these days of faster CPUs bucket loads of memory that as I youth you'd never even imagined let alone deamt about, the 'art' of coding is getting sloppy, but I appreaciate the extra time I have to focus on the Application and am more than happy to leave all the memory management to Sun.
best
Ex
Isn't it just a case of looking up a level (C++ to Java) and asking about all the stuff the next level hides.
Then looking down (C++ to C) and saying how primitave it is.
You just choose an appropiate level for what you know, and what the task requires.
It's a good analogy though
(C programmer)
Then looking down (C++ to C) and saying how primitave it is.
You just choose an appropiate level for what you know, and what the task requires.
It's a good analogy though
(C programmer)
dilbert said:
If you cant own your heap, I just cant see how you could perform such debugging. I suppose being a virtual machine, access by reference can be protected by a software mechanism that C++ people would call an access violation or exception fault. Nevertheless I can't imagine the performance penalty of having to generate access violations in software rather than in hardware.
There are plenty of development tools that allow you to look into the heap, they all will show you the number of objects that have been created.I't normally pretty straight forward to ascertain what's causing the problems. Also with the latest generation of profilers you can rapidly see where improvments need to be made.
Years ago I wrote a Java prgoram that included a parser for a scripting language I'd designed. The parsing was woefully slow, after a bit of investigation it turned out to be an IO call that was reading the next character fro mthe script file. Never figured out why it would be so poor, but it was trivial to load the entire file into memory and then pass characters one ata time from there.
TheExcession said:
dilbert said:
If you cant own your heap, I just cant see how you could perform such debugging. I suppose being a virtual machine, access by reference can be protected by a software mechanism that C++ people would call an access violation or exception fault. Nevertheless I can't imagine the performance penalty of having to generate access violations in software rather than in hardware.
There are plenty of development tools that allow you to look into the heap, they all will show you the number of objects that have been created.I't normally pretty straight forward to ascertain what's causing the problems. Also with the latest generation of profilers you can rapidly see where improvments need to be made.
Years ago I wrote a Java prgoram that included a parser for a scripting language I'd designed. The parsing was woefully slow, after a bit of investigation it turned out to be an IO call that was reading the next character fro mthe script file. Never figured out why it would be so poor, but it was trivial to load the entire file into memory and then pass characters one ata time from there.
Actually I figured out how to invoke the one I have on my compiler a few months back with a different problem. By the time I'd figured out what it was telling me, I realised it was only telling me what I already thought!!!!Best thing about my heap, I'd say anyhow, is that when you forget to cleanup (like you can in C++), it'll automatically tell you what what the object you forgot to free was. Simple but effective. Now I know that with java, you get the benefit of not being able to do that, but I'd say my heap is pretty helpful in that respect.
plasticpig said:
If you are driving a manual car with C++ what is the guy who is using an assembly language driving?
Well, for a start, you're stretching the analogy because I defined it only for C++ and Java, so I'm throwing you an out-of-bounds error message. 
But, if you insist, I'd say he was driving a car eligable for the London-Brighton run where you have to prime the fuel pump by hand, start it with a hand crank, advance or retard the ignition with a manual control, and double de-clutch when changing gear due to a lack of syncromesh.
plasticpig said:
I dont think the anology works myself. You have not factored in Assembly language. If you are driving a manual car with C++ what is the guy who is using an assembly language driving? For that matter what is the programmer using a 5GL driving?
Mr assembly man, is not only changing gears himself, he gets to choose the ratios!!!Mr 5GL man tells his car to go to the shops, and get some turnips. The trouble is, smart as the car may be, it doesn't fit down the supermarket aisle.
plasticpig said:
For that matter what is the programmer using a 5GL driving?
I used advanced CASE tools throughout my development career, the main one of which was a pattern based C++ generator (in fact it used patterns long before they became en vogue for Java).In the terms of this analogy, I had a chauffer and I told him where to go.
dilbert said:
plasticpig said:
I dont think the anology works myself. You have not factored in Assembly language. If you are driving a manual car with C++ what is the guy who is using an assembly language driving? For that matter what is the programmer using a 5GL driving?
Mr assembly man, is not only changing gears himself, he gets to choose the ratios!!!Mr 5GL man tells his car to go to the shops, and get some turnips. The trouble is, smart as the car may be, it doesn't fit down the supermarket aisle.
Oh and Jon: fair analogy I'd say. But what was your Java guy saying when he didn't know what dynamic memory allocation was? Did the chap not go through the usual training? Surely they still teach this stuff on Computer Science courses?
Not that I did one, either, mind. I did Systems Analysis and we weren't actually required to do much programming...unless you deliberately chose all the technical options...which I did.
JonRB said:
Had an interesting discussion with one of our Java developers yesterday afternoon that I thought I'd share.
He'd overheard some of us C++ guys having a chat about dynamic memory allocation and confessed that as a Java guy he didn't even know what it was let alone used it.
The conversation moved on and he asked me why I stuck with C++ and I replied that it's like the difference between an automatic car and a manual; the automatic is more convenient, for sure, but some people relish the joy of a well-executed manual downshift with a heel-and-toe blip of the throttle and the greater degree of control and involvement. Plus a torque converter automatic takes some of the power of the engine away (although I acknowledge that it is less so these days).
He conceded my point and then admitted that he did actually drive an automatic as he "couldn't be arsed with the hassle of changing gear", which kind of reinforced my point.
I'm not expecting our Java PHer's (esp. dern) to agree with me, but what do you think of the analogy? Fair or flawed?
Pointless He'd overheard some of us C++ guys having a chat about dynamic memory allocation and confessed that as a Java guy he didn't even know what it was let alone used it.
The conversation moved on and he asked me why I stuck with C++ and I replied that it's like the difference between an automatic car and a manual; the automatic is more convenient, for sure, but some people relish the joy of a well-executed manual downshift with a heel-and-toe blip of the throttle and the greater degree of control and involvement. Plus a torque converter automatic takes some of the power of the engine away (although I acknowledge that it is less so these days).
He conceded my point and then admitted that he did actually drive an automatic as he "couldn't be arsed with the hassle of changing gear", which kind of reinforced my point.
I'm not expecting our Java PHer's (esp. dern) to agree with me, but what do you think of the analogy? Fair or flawed?
. Half the point of driving a car is getting from A to B. The other half is having fun. You can change the ratios to suit yourself.
The entire point of a development language is to create a reliable, maintainable and profitable piece of software. The developer having fun or showing his technical prowess with the nuts and bolts isn't even a consideration. The reason the business has tended to move away from C/C++ towards C# and Java is that memory management is one less thing for the developer to worry about (and screw up on) so they can achieve their business goals. A technical developer should not be, in this day and age, fiddling with the low level stuff like memory management... they should be getting stuck in with the OO business process modelling.
Regards,
Mark
dern said:
The entire point of a development language is to create a reliable, maintainable and profitable piece of software. The developer having fun or showing his technical prowess with the nuts and bolts isn't even a consideration. The reason the business has tended to move away from C/C++ towards C# and Java is that memory management is one less thing for the developer to worry about (and screw up on) so they can achieve their business goals. A technical developer should not be, in this day and age, fiddling with the low level stuff like memory management... they should be getting stuck in with the OO business process modelling.
I knew I could rely on you to make sure that "JonRB's First Law of Posting on PistonHeads" wasn't violated, Mark. (Said law being "Never start a thread on PH whose sole purpose is for people to agree with you. Because they won't")
Edited by JonRB on Friday 8th June 12:04
JonRB said:
I knew I could rely on you to make sure that "JonRB's First Law of Posting on PistonHeads" wasn't violated, Mark.
(Said law being "Never start a thread on PH whose sole purpose is for people to agree with you. Because they won't"
(Said law being "Never start a thread on PH whose sole purpose is for people to agree with you. Because they won't"
I used to do all this in C and it was kind of fun so I know where you're coming from. However I also remember the sheer unpredictable nature of the fix effort required to sort out memory issues. I'm more than happy with java (and c# from the last year) handling it for me and I get my kicks elsewhere.
More seriously, Mark (dern), the question wasn't why businesses continue to use C++, it was why I as a developer choose to continue to use it and market myself as using it, rather than "moving on" (sic) to "better" (sic) languages.
I continue to develop in C++ because a) I'm extremely experienced and, dare I say it, good at C++ and b) I enjoy it as a language. Whilst clients are happy to continue to pay me good rates for providing C++ development services I'm happy to accept them.
I continue to develop in C++ because a) I'm extremely experienced and, dare I say it, good at C++ and b) I enjoy it as a language. Whilst clients are happy to continue to pay me good rates for providing C++ development services I'm happy to accept them.
JonRB said:
More seriously, Mark (dern), the question wasn't why businesses continue to use C++, it was why I as a developer choose to continue to use it and market myself as using it, rather than "moving on" (sic) to "better" (sic) languages.
I continue to develop in C++ because a) I'm extremely experienced and, dare I say it, good at C++ and b) I enjoy it as a language. Whilst clients are happy to continue to pay me good rates for providing C++ development services I'm happy to accept them.
I personally believe that the question why we use something and why the business use something are interlinked. I use java for the same reasons as you use c++ however I'd drop it like a stone if I felt I was becoming marginalised in terms of the jobs I could get or if I felt the language was now being applied to purely legacy systems. I know that that isn't currently the case for c++ but I certainly dropped c and picked up java because I could see it happening and I'm glad I did. This last year I spent a year doing c# for the same reason although admittedly I'm going back to java because I don't see much difference in them or the demand for them and I can bag more money with java. I make an effort not to fall for the lure of supporting legacy systems for big money because I know that one day I'll be dropped along with the system and then have a hell of a hill to climb.I continue to develop in C++ because a) I'm extremely experienced and, dare I say it, good at C++ and b) I enjoy it as a language. Whilst clients are happy to continue to pay me good rates for providing C++ development services I'm happy to accept them.
For me a valid motoring analogy would be sticking wit c/c++ instead of picking up java/c# would be sticking with carbs rather than going with FI
Edited by dern on Friday 8th June 12:15
dern said:
The entire point of a development language is to create a reliable, maintainable and profitable piece of software. The developer having fun or showing his technical prowess with the nuts and bolts isn't even a consideration. The reason the business has tended to move away from C/C++ towards C# and Java is that memory management is one less thing for the developer to worry about (and screw up on) so they can achieve their business goals. A technical developer should not be, in this day and age, fiddling with the low level stuff like memory management... they should be getting stuck in with the OO business process modelling.
My companys uses multiple development language's for its applications. We mix and match as required. The main system is developed in a 4GL. We use C++ where we need to do low level stuff or we need to optimise the speed of processing. We also use Visual Basic for stuff which the 4GL is not capable of but does not require C++.dern said:
I make an effort not to fall for the lure of supporting legacy systems for big money because I know that one day I'll be dropped along with the system and then have a hell of a hill to climb.
Yes, that's always a concern in the back of my mind too but at the moment I'm not resisting the lure, I'm embracing it. But there's still new development going on as well, which is good.From having dabbled with C# I know that the hill isn't as steep as it could be as Microsoft seemed to have had C++ developers in mind when they specced C# (probably due to their huge investment in the language - Windows itself is written in C++, or was up until at least NT), but you're right, it is a concern.
Edited by JonRB on Friday 8th June 12:34
Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff