RE: [GD-General] Eiffel

[Brian H. <bri...@py...>]

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

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" =)  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 
> lies within STL rather than your own code.  

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".
 
> In the early stages, everyone gets bit by some aspect of STL. 

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 
> 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 
> at the code and figure out what you're doing wrong, but I've 
> 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 =)  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