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
Quote: use named types for fine-grained types implemented by a program type; e.g., different kinds of strings
| Subtopic: dynamic vs. static
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
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
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
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
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
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
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
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
Quote: Russell allows var to val coercion, e.g. in an arithmetic expression [»demeA3_1979]
| Subtopic: validation
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
Quote: Java provides both type checked exceptions and unchecked exceptions; which is better? [»goldO11_2001]
| Subtopic: problems with strong typing
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
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)
|