>> I especially like the claims of "every time we added debug code, the 
>> bug went away". Surely it is impossible to work under such conditions...
> 
> Well, I tell you that's pure reality.

> Yeah, it's kind of fun developing software for devices where 
> occasionally the only way to get any helpful debug information out of 
> the thing is by switching an LED on or off, and errors might just as 
> well be hardware-related.

Wouldn't this make it scientifically impossible to deliver a working 
product?

Post a reply to this message

>> It certainly makes me realise that I prefer safe languages over 
>> efficient ones any day of the week. :-P
> 
> You can get such issues with "safe" languages, too: All you need is some 
> race conditions that kick in when performance is particularly good, but 
> don't if performance is bogged down a deal by debug output.

Safe languages don't permit race conditions in the first place.

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> I especially like the claims of "every time we added debug code, the bug 
>> went away". Surely it is impossible to work under such conditions...
> 
>   That was a relatively common problem in C and C++ years ago, but nowadays
> especially C++ compilers have got much better at debugging such things. For
> example Visual C++, when compiling in debug mode, will add bounds checks to
> all STL code and IIRC raw array accesses (although there are limits to the
> latter, as it's quite difficult to check bounds when pointer arithmetic is
> being performed). gcc has a precompiler constant which, when defined, turns
> on similar checks to all STL code. Then you can use valgrind to catch the
> rest.
> 
>   The only situation nowadays where you might end up having such heisenbugs
> in C++ which are not caught by the compiler even in debug mode is if you
> use dirty raw pointer arithmetic hacks, which is something you seldom really
> have to do in clean good-quality code, not even if you aim for maximum
> efficiency.

Maybe you're right, I don't know. I just find it makes me kind of 
nervous working with something which can break just because you changed 
the order of a few statements in a way which, conceptually, shouldn't 
change anything.

(Notice that guy who said he couldn't just add a new integer field to a 
data structure because it would break a few thousand other functions? 
Does that sound like good abstraction you to?)

Still, I guess that's why I'm not a games developer...

I was also puzzled when I looked at Gentoo and discovered just how many 
C programs break horribly just because they were written for IA-32 and 
got recompiled for AMD64.

Post a reply to this message

> (Notice that guy who said he couldn't just add a new integer field to a 
> data structure because it would break a few thousand other functions? Does 
> that sound like good abstraction you to?)
>
> Still, I guess that's why I'm not a games developer...

It's not because it's a game, it's because it's being made for profit. 
Writing any software as a hobby is very different than writing it to try and 
make money.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Safe languages don't permit race conditions in the first place.

  And then you wonder why safe languages are so slow.

-- 
                                                          - Warp

Post a reply to this message

scott wrote:
>> (Notice that guy who said he couldn't just add a new integer field to 
>> a data structure because it would break a few thousand other 
>> functions? Does that sound like good abstraction you to?)
>>
>> Still, I guess that's why I'm not a games developer...
> 
> It's not because it's a game, it's because it's being made for profit. 
> Writing any software as a hobby is very different than writing it to try 
> and make money.

 From what I've seen, only games programmers go to the extremes of using 
obscure and elaborate low-level hackery to squeeze every last 
femtosecond of performance out of the machine. Other programmers usually 
don't have such ardent performance limits to worry about. (Usually.)

Which is not to say that all codebases that aren't games are beautifully 
written... just that games typically have ludicrous performance 
requirements and insane release schedules.

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> Safe languages don't permit race conditions in the first place.
> 
>   And then you wonder why safe languages are so slow.

I wonder why everybody _assumes_ they're going to be slow, yes.

Still, I guess it depends on where your priorities are - how fast the 
program runs vs how many years you have to spend in debug activities.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> (Notice that guy who said he couldn't just add a new integer field to a 
> data structure because it would break a few thousand other functions? 
> Does that sound like good abstraction you to?)

  That kind of code is crap.

  I have been programming for well over a decade on an "unsafe" language,
and I have never wrote a program which would break if you add something
to a class or struct.

  I have to admit, though, that not all programs I have ever written would
fully support 64-bit architectures. By this I don't mean they would not
compile as a 64-bit executable or that they would crash when compiled as
such and run. I mean that they would not necessarily fully utilize the
increased address space.

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Warp wrote:
> > Invisible <voi### [at] devnull> wrote:
> >> Safe languages don't permit race conditions in the first place.
> > 
> >   And then you wonder why safe languages are so slow.

> I wonder why everybody _assumes_ they're going to be slow, yes.

  Well, if every access to a shared variable is thread-safe, it is going
to be slower than non-locked access.

-- 
                                                          - Warp

Post a reply to this message

>> (Notice that guy who said he couldn't just add a new integer field to a 
>> data structure because it would break a few thousand other functions? 
>> Does that sound like good abstraction you to?)
> 
>   That kind of code is crap.
> 
>   I have been programming for well over a decade on an "unsafe" language,
> and I have never wrote a program which would break if you add something
> to a class or struct.

That one did kind of strike me as "this can't be good".

Still, C is a language where, if you so desire, you can make your code 
depend on the exact size of a struct, the endianness of machine words, 
and all kinds of other things to make your code extra fragile. I suppose 
some people would consider this a "feature"...

>   I have to admit, though, that not all programs I have ever written would
> fully support 64-bit architectures. By this I don't mean they would not
> compile as a 64-bit executable or that they would crash when compiled as
> such and run. I mean that they would not necessarily fully utilize the
> increased address space.

Not taking advantage of new features is to be expected; breaking because 
of them even if you aren't using them seems to be like poor design. 
Still, heaps and heaps of C programs seemed to not like being recompiled 
that way...

Post a reply to this message