RE: [GD-General] Eiffel

[Brian S. <bs...@mi...>]

> You just spent an e-mail discussing how "everyone gets bit by some
> aspect of STL" then go on to say that the STL needs much debugging is =
a
> fallacy?

Near the end of your email, I think you made the right distinction =
between debugging STL (which I'm arguing is a distraction at best) and =
debuggable STL programs (which no one in their right mind is against).

So - given that I was talking about debugging STL in that bit you =
excerpted - what's the contradiction?  Anyone can get bit by a thing =
they didn't expect in a library or language they're unfamiliar with.  I =
can certainly remember vividly the first time I learned about C struct =
packing, and when I discovered that I couldn't free() something twice.  =
It's just that competent people - what I assume we all are - don't KEEP =
getting bit by these things, repeatedly, daily. Once you spend a few =
hours debugging your early programs, those lessons are deeply ingrained. =
 So since I never free things twice any longer, does that mean free() is =
badly designed?  I would argue my expectations were badly formed.

Does that mean I'm saying we should just count on studly programmers to =
fix all their bugs alone?  Hell no, no way, never.  We all have enough =
sense to run things like debug heaps to catch memory leaks, even though =
we know what causes memory leaks and theoretically should never let one =
come into a program.  After all, none of us are programming =
theoretically - we're out in the real world where people do make =
mistakes.  For STL, the STLPort implementation (http://www.stlport.org) =
has a debugging mode that catches lots of misuses, and if you're looking =
for a version with iterators that will slap you cross the face and say =
in a Mr. T voice, "I pity the fool who uses this invalid iterator", =
that's your baby.  But you can't argue that STL is badly designed =
because Plauger's implementation does no input validation or debug =
checking.  You might be able to argue it from other standpoints, but not =
from that one.

The good thing is that awareness that most of your problems are =
self-inflicted means you're beyond the denial stage...next stop anger :)

--brian

p.s. sorry if I got anyone's hopes up too high, the STLPort iterators do =
NOT actually use Mr. T voices.

-----Original Message-----
From:	Brian Hook [mailto:bri...@py...]
Sent:	Mon 12/24/2001 11:14 AM
To:	gam...@li...
Cc:=09
Subject:	RE: [GD-General] Eiffel

> Behalf Of Brian Sharon
=20
> Additionally, I think it's funny how most people who dislike=20
> STL say that it's "too hard to debug". =20

A well designed class library and API provides assertion mechanisms to
help users detect their own errors.  By that logic, DX or Win32
shouldn't return error codes, because hey, it's the user's bugs that are
causing the problems.

To which I say, "Duh" =3D)  But a key part of ANY reusable code is =
making
sure that it provides competent debugging assistance.  ESPECIALLY when
that API is difficult to grasp initially.

> The earliest is denial - the idea that the problem=20
> lies within STL rather than your own code. =20

No, I would just like it if I knew what I did wrong when everything
explodes, instead of being stuck looking at some variable like "___p".
=20
> In the early stages, everyone gets bit by some aspect of STL.=20

Which is a pretty strong indicator that STL could use some tightening up
in its design or, alternatively, that implementation should provide
basic pre and post-condition checking.  DirectX provides this, one of
the areas I think it does a better job than OpenGL.

> But the notion that the STL needs much debugging, or any=20
> really, is a fallacy in my opinion.

You just spent an e-mail discussing how "everyone gets bit by some
aspect of STL" then go on to say that the STL needs much debugging is a
fallacy?

> It can be hard to look=20
> at the code and figure out what you're doing wrong, but I've=20
> never seen anyone in the denial stage actually find a bug in it.

My mistake.  I said "STL was difficult to debug" when, in fact, I meant
"debugging STL programs is difficult".  Subtle but important
distinction.  As a professional software developer for many years now,
I'm well aware most problems I encounter are self-inflicted =3D)  But =
part
of software engineering is finding tools that help the programmer find
and fix what is now trendily called "software defects".  Just dumping
that onus on the programmer rather flies in the face of what many in the
software engineering world are trying to push -- better software through
better tools and development methodologies, instead of relying entirely
on programmer studliness.

Brian


_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general