On 7/25/2011 4:33, Warp wrote:
> Darren New<dne### [at] sanrrcom>  wrote:
>> On 7/24/2011 3:38, Orchid XP v8 wrote:
>>> On 23/07/2011 06:37 PM, Darren New wrote:
>>>
>>>> Interesting.
>>>
>>> I'm ticked by "C++ crashes a lot if it's immature".
>>>
>>> What, if C++ is immature? Or the C++ codebase is immature? Or perhaps you
>>> mean if the C++ developers are immature? ;-)
>
>> I think they meant your code crashes a lot if it's written in C++ and hasn't
>> had lots of debugging.
>
>    I think it depends a lot on the competence of the C++ programmer(s).
> Granted, becoming a very competent C++ programmer (whose code seldom crashes,
> or if it does, the crashes get caught very early on the development cycle)
> may require more work than with some other languages, but it's not impossible.

Well, I'd say it takes more time and more development. So if you count a 
single program, or if you count all the programs over your career, the 
comment is probably true. I.e., it also takes longer for a competent 
programmer to get expert at C++ than it does for a competent programmer to 
get expert at a simpler language.

>    I wonder if something similar ever happens with the "safer" programming
> languages (eg. you get a "null pointer exception" or some other similar
> error and have absolutely no idea why, and no debugging tool is helping).

Occasionally. Usually it's something like running out of file handles, if 
it's a low-level problem. I had that in Tcl once, and of course the thing 
would have to run for hours before it ran out of handles, and I just 
couldn't find where the problem was. The code was too complex in the error 
handling, and I for whatever reason bashed my head on it for a couple of 
days rather than refactor it, and I couldn't figure out which of the files 
it was running out of (i.e., which of the several "open" calls wasn't 
matching a "close").

The other kind of problem that's difficult is the large-scale logic problem. 
I had something that could rebuild the cache from the data store (to 
simplify the description). Then I added code to record changes to the data 
store and apply them incrementally to the cache.  And once every few days, 
that would crash and fall back to rebuilding from scratch. And it took me a 
while to figure out if someone added X and then deleted X all in one cycle, 
when it tried to propagate "add X" to the cache, it was already gone from 
the data store, so it gave up and fell back to the full rebuild. Fundamental 
mistakes in architecture or algorithm don't get any easier with safer or 
simpler languages.

The difference between the two is, you can reason from the program text. I 
knew I was running out of file handles because somewhere in the code that 
did open/read/write/close, one of the paths out of that code wasn't doing 
the close. I had very high confidence that it wasn't some other third party 
library stomping on my stack and changing the file handle variable to some 
other value.

But, in all honesty, the number of "I can't find this nightmare bug" I've 
encountered in safe languages is about the same as the number of "I found 
the bug, and it's in the compiler/interpreter" kinds of nightmare bugs.

I can't tell you the number of times in unsafe languages where I spent three 
days trying to figure out what was actually broken. To be fair, usually when 
I'm using unsafe languages, it's often because the machine isn't powerful 
enough or standard enough to support something like valgrind or even gdb, or 
you're missing so much source that such tools aren't useful, so it's purely 
reasoning from the code you actually have.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message