On 9/27/05, Peter Miller <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-09-27 at 12:00 +1000, Bruce Badger wrote:
> As a developer intent on doing the best job possible, I want to
> discover whole classes of bugs long before the corresponding unit test
> is executed. (E.g. my keyboard can't spel.)
I certainly share the desire to do a good job! Wrt bugs, I'm quite
happy if I can find the problems before I check code into my version
control system. I tend to be running SUnit tests while I am writing
code and debugging. BTW, the Smalltalk IDE I use does have a spell
checker that picks up many typos (I know - I have clumsy fingers :-/).
> What is essential in a production environment is a way to validate the
> code for trivially stupid mistakes, like a = b.c where b is an int, and
> c is a struct member; or prentf("%g\m", 4)
Right, before we get to the production system. This is the kind of
thing I had in mind when I said I don't experience the problems one
might imagine static typing would save you from.
> The worst are some interpretive languages where whole code blocks are
> parsed at run time, creating the wonderful situation where customers (!)
> ring up and say "what does syntax error mean?"
[Aside: Languages can be implemented in many ways - e.g. there are
statically compiling Smalltalk IDEs & C can be interpreted. Yes,
Smalltalk tends to be dynamically compiled and C tends to be
statically compiled, but that's not the fault of the language.]
Production environments can throw up all kinds of surprises, mostly
because users do unexpected things or present unexpected data.
Neither static typing nor unit tests will give you a 100% guarantee
against a system doing something embarrassing. I reckon no code
coverage tool can cover 100% of situations either, even if it does
help you cover 100% of the code. Surprises are inevitable.
Clearly it is possible to build excellent system using all kinds of
tool sets. It's possible to build crap systems too. IMO, the best
tool for the job is the one that developer finds to be the best one
for the job. Of course, a good developer will keep an open mind and
look out for different and perhaps better ways of doing things, but
having a current preferred tool set is important (BTW flitting from
one tool to the next in hope of a silver bullet is as bad as sticking
with what you know and not keeping an open mind, IMO).
For myself, I think the best trade-off is to be found using Smalltalk
as the primary language. :-)
All the best,
Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.org/
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
