Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
What are Types Good For Anyway?
Hypothesis: Types do not help in creating software with fewer errors.
- They don't help to find deep errors – just simple errors that are easy to find and fix anyways.
- They cause an awful lot of time and work to get the Compiler to stop complaining about your types.
- If they didn't exist, you'd find the same kinds of bugs by testing in less time than it would take to get the types right for the Compiler.
Comments? Opinions? Evidence one way or the other?
True. If types didn't exist in the first place, one wouldn't have to cast in one type from the other...
Ever coded in SML? Its a pain to compile anything, but once you do, you're done. About the only real errors you'll find after something compiles are either not initializing something, or possibly doing the wrong thing in some case. But your case analysis will be complete by force, because it complains about incomplete pattern matches.
Back in compilers, whenever something compiled, it usually meant being done in 30-60 minutes. There were two exceptions. The first was when our YACC grammar was wrong, and the second was when the final assembly program was output, and I had to make it acceptable by the assembler.
I would spend more time than this testing. I had a whole directory full of wierd test cases. But I never spent more than 30-60 fixing anything.
Mark Guzdial has listed three rationalizations regarding the value of
types in a programming environment. Each of these are erroneous on a
fundamental level, which will be presented on a case-by-case basis.
1) They don't help to find deep errors – just simple errors that are
easy to find and fix anyways.
We must now attempt to distinguish between 'deep' errors and 'simple'
errors. Deep errors would best be defined as flaws in the design of
the program versus 'simple' errors which are errors in the
implementation of that design. The more strongly typed a language,
the more difficult it is to invoke undefined behavior. What this
really means is that the compiler/interpreter for a strongly typed
language will perform a large portion of the mundane, and easily
overlooked, debugging. As a side-effect of the compiler/interpreter
forcing the programmer to rigorously perform case analysis, flaws in
the fundamental logic of the program are often uncovered and
corrected; for example: performing the wrong operation with
inappropriate input due to a typeless system whereas a typed system
would throw an error. It is therefor plain to see, that strongly
typed languages are capable of finding not only the easy to find
'simple' errors, but also difficult to find 'simple' errors, as well
as some classes of 'deep' errors.
2) They cause an awful lot of time and work to get the Compiler to
stop complaining about your types.
Computers operate much more quickly than the human brain, they are
simply limited in scope of what they are capable of processing.
Whatever errors the compiler does detect, it detects in much less time
than the programmer. This process saves the programmer both time and
energy which can be spent contemplating the core logic of the program.
The only type errors that cannot be caught by the compiler are casts,
however, any given statement in a typeless language introduces the
same propensity for error that a cast does. Also, casting is not
generally allowed in very rigidly typed languages, eliminating even
that point of failure.
3) If they didn't exist, you'd find the same kinds of bugs by testing
in less time than it would take to get the types right for the
This is a repeat of point number two.
Typeless languages, when properly implemented, make excellent
candidates for rapid prototyping at the expense of cleanliness,
robustness, and speed. Types give the programmer a clear concept of
the domain (set of valid input values) and range (set of valid
outputs) of any given code segment, making typeless code more
difficult to read. While robust systems can be, in principle, built
from typeless languages, the resultant product is frequently
intelligible only to the original programming team. Massive
optimizations are performed on compiled code that are only possible
with prior knowledge of exact sizes in memory of the various datatypes
involved, as well as restrictions on the input and output of those
Aside from succeeding where typeless languages fail, strongly typed
languages are advantageous for such things as allowing for special
programming constructs (such as pattern matching), mathematically
provable systems, and other things.
Link to this Page
- Etc. last edited on 10 October 2005 at 8:37 pm by r43h14.res.gatech.edu