Topic: data types are not needed
Topic: declarative vs. procedural representation
Topic: design for change
Topic: dynamic type checking
Topic: early vs. late binding
Topic: generic operations and polymorphism
Topic: language flexibility
Topic: non-exclusive data type
Topic: object-oriented data types
Topic: scripting language
Topic: type reflection and introspection
Topic: weak vs. strong type checking
Summary
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
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
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
Subtopic: static type checking
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
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
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
Quote: implicitly typed local declaration from copy assignment; var keyword [»bierGM10_2007]
Subtopic: run-time validation
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
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
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
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 [»tratL9_2007]
Related Topics
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)
