Map
Index
Random
Help
Topics
th

Topic: weak vs. strong type checking

topics > computer science > data > Group: type checking



Topic:
casting a variable to a different type
Topic:
data types are not needed
Topic:
dynamic type checking
Topic:
dynamic vs. static data type
Topic:
extensible systems
Topic:
flavor analysis and typestates for supplementary type checking
Topic:
non-hierarchical classification and multiple classification
Topic:
referential transparency
Topic:
scripting language
Topic:
type conversion
Topic:
type-safe and secure languages

Summary

Strong type checking takes more development time, tends to distort a design, and may over-constrain a program. But both experience and experiments have shown it better in the long run with weak or typeless languages. Any method that reduces errors at run-time is worth a fairly high cost at design time. (cbb 1/90)
Subtopic: structural type vs. named type up

Quote: use named types for fine-grained types implemented by a program type; e.g., different kinds of strings

Subtopic: dynamic vs. static up

Quote: static type checking is akin to physical plug compatibility which works well despite many standards; dynamic checking is like protection/adaptation circuitry [»stroB_1991]
Quote: the difference between dynamic and static type checking is the difference between "x must be a car" and "x is a car" [»stroB_1991]

Subtopic: container type up

Quote: APL's arrays impose a uniform type; e.g., the type of A and B in A+B is array of real or array of integer; not true in LISP [»atkiMP6_1987]

Subtopic: weak typing and intuitive classes up

Quote: in Smalltalk, any object can be assigned to any name without type restrictions
Quote: dynamic type checking underspecifies an interface; it makes an assumption that is checked at runtime
Quote: a weakly-typed language such as Flavors allows an intuitive class structure [»wolfW9_1989]

Subtopic: incomplete type checking up

Quote: C does not check argument types against parameter types; can cause type errors; caught by 'lint' [»ritcDM7_1978c]
Quote: C's lint program caches most type errors; misses union types and use of explicit escapes [»ritcDM7_1978c]

Subtopic: problems with weak typing up

Quote: type errors are a problem for machine programming; e.g., using an integer as an address [»hoarCA_1974]
Quote: a meaningless or erroneous argument should be illegal, otherwise you hide bugs rather than find them [»maguS_1993]
Quote: with a weakly-typed language, inconsistencies are not caught until run-time
Quote: programs written in weakly-typed, object-oriented languages must be redesigned for strongly-type languages
QuoteRef: coheS4_1974 ;;120 lose syntax depends on type checking to catch logical errors

Subtopic: strong typing up

Quote: a robust library expresses constraints as types, reports errors relative to user, and does not cause application errors [»fricA4_2000]
Quote: strong typing requires more work but catches more bugs early; makes programs more useful [»wolfW9_1989]
Quote: in Modula-3 every expression has a unique type with a simple subtype relation [»nelsG_1991]
Quote: Modula-3 does not use ambiguous types, target-typing, or automatic conversions (except for packed fields, etc.)
Quote: programs are more reliable with a statically typed language than with a typeless one [»gannJD8_1977]
Quote: novice users are helped more than expert users by a statically typed language [»gannJD8_1977]
Quote: a data type provides information about the intended use of data, restricting its meaningful operations [»parnDL3_1976]
Quote: data types increase reliability and reduce development costs; compile-time checking and redundancy

Subtopic: strong typing for security up

Quote: guarantee sandbox security by well-typed applets and verified parameter references [»leroX1_1998]
Quote: simple types are too coarse for a security policy; e.g., a string can be a message, a file name, or a cryptographic key [»leroX1_1998]
Quote: strong typing protects the sandbox model by preventing arbitrary access to the computer running the execution environment [»leroX1_1998]
Quote: type inheritance describes common features while strong typing erects fire walls between types [»wolfW9_1989]
Quote: a strongly typed interface helps ensure that only compatible pieces of software are linked together; allows strong assumptions, minimizes run-time tests, assists system integration [»stroB_1991]

Subtopic: type soundness, safety up

Quote: proof of type soundness for a large, sequential sublanguage of Java; via the interactive theorem prover Isabelle/HOL [»nipkT1_1998]
Quote: Java guarantees memory and type safety at runtime and compile time; programs cannot forge pointers, overrun arrays, or apply an operator to the wrong type [»hartPH12_2001]
Quote: extensible systems run core system services and dynamically composed extensions in the same address space using low-latency, type-safe interfaces [»grimR2_2001]
Quote: SPIN depends only on Modula-3's interfaces, type safety, and automatic memory management; no dangling pointers or array overflow [»bersBN12_1995]

Subtopic: conversion up

Quote: Russell allows var to val coercion, e.g. in an arithmetic expression [»demeA3_1979]

Subtopic: validation up

Quote: enforce type system with run-time validation checks on each argument; e.g., all file names belong to the /tmp directory

Subtopic: exception types up

Quote: Java provides both type checked exceptions and unchecked exceptions; which is better? [»goldO11_2001]

Subtopic: problems with strong typing up

Quote: static type systems have little expressive power; they do not prevent users from accessing the first element of an empty list, creating off-by-one errors, or using null pointers [»tratL9_2007]
Quote: with statically typed languages, you edit a program, fix type errors, debug with breakpoints, find the problem, stop the world, edit, and repeat [»ungaD9_2007]
Quote: a simple testing strategy captures virtually all errors that a static type system would capture
Quote: a strongly-typed language such as C++ distorts the original, intuitive class structure [»wolfW9_1989]
Quote: strong typing is difficult to define simply; e.g., inconsistent subtyping, operator overloading, ambiguous types for literals, target typing, automatic conversions that lose information [»nelsG_1991]
Quote: strong typing discourages reuse through incompatible interfaces; it does not raise the level of programming [»oustJK3_1998]
Quote: strong typing in C++ leads to extra code; e.g., SetFont requires an initialized CFont object
Quote: the strong typing of most object-oriented languages encourages narrowly defined packages that are hard to reuse
[»oustJK3_1998]

Related Topics up

Topic: casting a variable to a different type (7 items)
Topic: data types are not needed (8 items)
Topic: dynamic type checking (43 items)
Topic: dynamic vs. static data type (24 items)
Topic: extensible systems (22 items)
Topic: flavor analysis and typestates for supplementary type checking (68 items)
Topic: non-hierarchical classification and multiple classification (16 items)
Topic: referential transparency (26 items)
Topic: scripting language (27 items)
Topic: type conversion (33 items)
Topic: type-safe and secure languages
(43 items)

Updated barberCB 3/06
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.