Topic: dynamic vs. static data type

topics > computer science > data > Group: data type

type checking
type inheritance

data types are not needed
declarative vs. procedural representation
design for change
dynamic type checking
early vs. late binding
generic operations and polymorphism
language flexibility
non-exclusive data type
object-oriented data types
scripting language
type reflection and introspection
weak vs. strong type checking


A data type is statically defined if it is known at compile-time. The compiler can check static data types for type compatibility and pre-select polymorphic functions. If a type is not known at compile-time, it is dynamically defined. At run-time, the system selects the appropriate functions and tests the type as needed. As an analogy, static types are like electric plugs while dynamic types are like multi-voltage appliances.

Static types are strong types that prevent many programming errors. They force the programmer to design a type hierarchy. Static types avoid the cost of run-time type checks and allow efficient implementation.

With dynamic types, the programmer uses data without concern for its type. There is less code to write and data types can change as needed. If the program misuses a type, it throws an error.

Subtopic: static vs. dynamic up

Quote: the dynamic languages Self, Smalltalk, and Lisp give you the sense of building--not writing--sofware; you watch your program emerge from objects, methods, and attributes; you try out objects as you go [»ungaD9_2007]
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: dynamic binding allows a class to manipulate polymorphic entities without testing the type; e.g., t.postorder traverses many kinds of trees [»meyeB9_1990]

Subtopic: strong types up

Quote: strong typing simplifies syntactic analysis and identifies many programming errors
Quote: parametric polymorphism is better than dynamic approaches; errors caught at compile time; invariants expressed in types; fewer conversions, avoids run-time type checks [»kennA6_2001]
Quote: all CLR objects include exact, runtime type information; e.g., distinguishes List from List [»kennA6_2001]
Quote: use static type rules and lazy dictionary creation for parametric polymorphism; checked once instead of every instantiation [»kennA6_2001]

Subtopic: static type checking up

Quote: allow static type checking by specifying the types, assigning a set of values for each type, and restricting 'seal', 'testseal', and 'unseal' to module boundaries [»morrJH10_1973]
Quote: data types increase reliability and reduce development costs; compile-time checking and redundancy
Quote: static type checking avoids dynamic type errors and encourages a well-thought-out design [»stroB_1994]
Quote: in Algol, every expression is syntactically type checked; run-time checks only needed on procedure entry [»wirtN6_1966]

Subtopic: static more efficient up

Quote: designed Java's semantics so that 'a=b+c' and 'p.m' could be implemented quickly; e.g., lead to static typing [»goslJ6_1997]
Quote: code generation is inefficient for languages whose semantics are not close to the bytes-and-pointers model; often 3 to 10 times slower, especially with dynamic typing [»koenA12_1995]

Subtopic: dynamic type up

Quote: Ruby is a pure, untyped, object-oriented language with metaclasses, iterators, closures, reflection, run-time extension, dynamic loading, marshalling, threads, exceptions, garbage collection [»thomD1_2001]
Quote: CLR reflection allows runtime type creation, queries, and method invocation [»hamiJ2_2003]

Subtopic: implicit type up

Quote: implicitly typed local declaration from copy assignment; var keyword [»bierGM10_2007]

Subtopic: run-time 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: attribute-dependent type, sub-class up

Quote: static type-checking may not catch type errors due to subclassing a function argument [»alexRT1_2000]
Quote: in database design, the instance hierarchy may depend on an attribute; e.g., inexpensive products may be treated as bulk items [»buneP5_1986]

Subtopic: type tests error-prone up

Quote: a switch statement that uses run-time type inquires destroys the modularity of a program; it is error-prone and not object-oriented [»stroB_1991]
Quote: a type field leads to two kinds of errors in large programs: failure to test the type field and missed cases in a switch [»stroB_1991]

Subtopic: problems with static data type up

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: static type systems constrain the programmer; they ossify programs, making them less amenable to change; a change may require numerous rewrites [»tratL9_2007]
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

Related Topics up

Group: type checking   (12 topics, 392 quotes)
Group: type inheritance   (13 topics, 394 quotes)

Topic: data types are not needed (8 items)
Topic: declarative vs. procedural representation (54 items)
Topic: design for change (76 items)
Topic: dynamic type checking (43 items)
Topic: early vs. late binding (15 items)
Topic: generic operations and polymorphism (67 items)
Topic: language flexibility (34 items)
Topic: non-exclusive data type (16 items)
Topic: object-oriented data types (29 items)
Topic: scripting language (27 items)
Topic: type reflection and introspection (28 items)
Topic: weak vs. strong type checking
(42 items)

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