Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code

I'm sorry for not being clear.


I said:
jlg> Then your programs are considerably different from what I'm familiar
jlg> with. Most errors are not syntactic or static semantic errors (like type
jlg> errors). The vast majority of debugging time is spent isolating and
jlg> correcting problems which are not - and cannot be - found by the
jlg> typechecks no matter how strict your type system is.


To which Jonathan Eifrig replied replied giving a list of types of errors
and their nature. What he said was true. However, it does not address
the point I was making. The article I was responding to made claim that
programs which pass the typechecker of a strictly typed language never
have bugs (the exact statement was " An SML program which successfully
typechecks will not bomb at runtime").


This latter is clearly wrong. Not only *CAN* programs which are free of
type errors still contain bugs, those remaining bugs are the hardest to
find and correct: they account for the vast majority of debugging time.
I've seen this claim made several times before - that functional languages
eliminate all bugs. The first time was when the old VAL language was
being discussed in a seminar. Someone asked whether there was any
provision for an interactive debugging tool in a VAL environment and the
answer was (and the guy was serious - or the best actor in the world) that
debugging wasn't necessary since the code would be written in VAL.


In fact, I would be surprised if SML were so restrictive as to guarantee
bomb-free code once you pass the typechecker. To be a useful, a
programming language must allow sufficient flexibility to the user for a
wide variety of algorithms and applications to be legally encoded. This
means that the language will also *inherently* be sufficiently flexible
for the user to inadvertantly code unintended, but still legal programs.
That is in the very nature of programming language design.


--
J. Giles
--

Return to the comp.compilers page.
Search the comp.compilers archives again.