12 May
2005
12 May
'05
4:16 p.m.
From: "Antonio Carlini" <a.carlini at ntlworld.com>
Sent: Thursday, May 12, 2005 5:50 PM
John Hogerhuis wrote:
One big problem with goto comes from Fortran, with FORTRAN and early Basic's
the goto uses line numbers. Newer languages allow better labels:
go to 4000
Doesn't tell you much.
C
C Cleanup files and exit
C
go to 4000
This at least tells you something.
Another problem is that many programmers don't understand the compilers they
are using. If you don't understand how the compiler handles stacks etc then
we know where the problem is: It is the Programmers fault for using a tool
that they don't understand.
It is a problem with the Programmers not the tools. It reminds me of
stopping to help someone with a flat tire:
It was a young guy with a new car with his girlfriend. He had a scissor
jack that he had just shoved under the car and jacked it up. He had it
under the passenger side floor board and it punched through. Someone else
had stopped and lent him an old-fashioned bumper-jack. It had ripped
through the plastic bumper.
When I stopped he was angry and unwilling to accept any help, it was sad,
thousands of dollars worth of damage over a flat tire.
It was not either of the jacks fault that they had done all the damage to
the car, both jacks were able to do the job that they were designed for but
the guy was not trained in how to use them but felt he was smart enough to
know what he was doing.
Randy
www.s100-manuals.com
Agreed, but nor should anyone really care about
provable
correctness, right? Engineering is about making things that
are practically useful, i.e. "good enough"-- we're not
designing stained glass windows for the Church of Reason,
we're simply making and maintaining tools to solve todays
problems more efficiently than if those tools were not
available.
Certainly we should not immediately drop our coding sticks
and not touch them again until we _know_ we have attained
perfection. But I disagree strongly that we should not strive
to reach that goal.
If we had a mechanism now to create provably correct
programs (that met specifications that we could be
sure meant what we intended them to mean) - and
further assuming that use of such a mechanism did
not impose excessive cost or efficiency burdens etc, -
then I think we would have to use them for all
serious programs.
Given the choice, I'd prefer the programs I use to
work perfectly rather than imperfectly - and I'd prefer
to spend the time I program at work creating correct
code rather than being dragged back to fix yesterday's
mistake.
I'm more than willing to trade an occasional goto for that!
Antonio