Smalltalk.org™| main

Static Typing Tunnel Vision Can Be Deadly
written by Peter William Lount
version 1, 20041002 4:10pm PDT
revision 2, 20041002 5:09pm PDT, added response to Shane King.

Microsoft server crash nearly causes 800-plane pile-up
The radio system shutdown, which lasted more than three hours, left 800 planes in the air without contact to air traffic control, and led to at least five cases where planes came too close to one another, according to comments by the Federal Aviation Administration reported in the LA Times and The New York Times. Air traffic controllers were reduced to using personal mobile phones to pass on warnings to controllers at other facilities, and watched close calls without being able to alert pilots, according to the LA Times report.

This article picks up from a discussion on the very real and serious hazards of "static typing" of variables in a life critical computer program and how a "statically typed" variable, of the type "DWORD", overlowed and caused an air traffic control system to fail. Advocates of "static type safety" in computer languages must realize and acknowledge that their "type safety solution" didn't prevent this error from occuring. Sure the "type" of the variable was safe but the people in the planes weren't! Makes you think again about flying. As James Robertson points out "testing" is essential for any system.

In response to a stunned Isaac Gouy: It has everything to do with static typing, Isaac [and Shane].

The fact that numbers in that flawed system are "typed" has everything to do with "static-typing" as their "DWORD" type is a static type that caused a problem when the data overflowed it's constraint bounds. It's also seems likely that the overflow error was not detected and delt with properly at runtime since the majority of popular computer languages simply let data type "overflow" error go by without any warnings, so multiple issues are invovled. In addition it is clear that they choose an incorrect "type" to begin with. The problem thus extends from the language it's tools, the implementation and all the way through to the software designers and implementors.

The fact that Smalltalk's numbers "scale" - in this case small integers scale to larger numbers - dynamically has everything to do with a benefit over statically typed numbers. If a small integer had been used it would have scaled and this problem would not have occured. An example of a dynamically "untyped" variable language being more fault tollerant than a statically typed one!

The fact that the ranges of numbers are so tightly constrained by unnecessary "static types" in the vast majority of computer langauges is a serious issue to reliability and fault tollerance and in some cases life and limb.

Another reason that this has to do with "static typing" technology (as implemented and used in the most popular langauges) is that "static typing" applies blinders to the brains of programmers such that they habitually "type" their variables with excessive constraints in the same of "safety". They simply passed the buck to the end users who then had the burden of remembering to reboot the particular computer every 49.7 days! Give me a break! In this case it seems that it back fired with "static type safety" biting them hard where it hurts.

Isaac you mention that the "problem would not exist in Haskell (static type check)". Please explain exactly how and why the problem would not exist in Haskell? You mention that it would be "statically type checked" (using type inferencing I assume). Could you expand upon this with an example of what would happen when the number exceeds the limits of the "dword" (or other) type that is applied in Haskell, or is it that Haskell has either large numeric ranges or types that dynamically adjust to fit the data?

Remember we are talking about specific implementations of languages and systems that use static typing in imperative programming languages. Practice is often much different than theory. In theory "static typing of variables" sound nice as I'm all for improving the reliability and fault tollerance of programs, especially when lives are potentially at risk. In practice static typing of variables and the size limited numeric data formats available are constraints that programmers - and more devistatingly users - have to live with every day. The constant need to apply a "static type" or "type" to every variable in the vast majority of languages that most programmers use every day tends to produce a habitual "type happiness" or "static type tunnel vision". After a while of using typed variables all the time (unless you know better) it just seems natural to apply a type as if it's required even though languages like Smalltalk prove - by their very existance and major successes - that static type constraints of variables are not needed.

Now it seems that languages like Haskell don't require the programmer to "explicitly" apply a static type of variables since all variables are statically typed in Haskell due to Haskell's type inference system. In reading about Haskell it's clear that while it's possible to not have to manually assign types to variables in Haskell it's a common practice anyway for clarity or to use advanced features of the language.

It must be noted that Haskell is not an "imperitive" programming language but a functional programming langauge and as such Haskell is very different from Smalltalk. For example, the Haskell 98 system is not an Object Oriented Programming Language although it's possble to add in packages that entend it with some object capabilities, and it seems that such features are being considered for the language (i.e. 0'Haskell. As such how relevant would a comparison really with Smalltalk be?

Functional programming langauges are very different from imperative general purpose programming languages and object oriented programming languages.

In this comparison, "object oriented programming [OOP] vs function oriented" languages, the conclusion is rather stark in favor of OOP:

Differences between functional and objected oriented programming can be summed up as follows:

In object oriented programming everything [pure object languages like Smalltalk] (or almost everything [impure object langauges such as Java, Objective-C, & C++]) is treated as an object that can be modified and that can perform tasks, or in OOP speak one might say objects have state and behavior. What it buys you (among other more advanced things) is: modularity, and data hiding.
...
In functional programming what you have basically are a set of functions each of which performs a task. Selectively executing these function results in the solution to the problem at hand.
...
simply put OOP makes it easier to conceive very large complex systems. Because it gives the developers the ability to break the system down to small tangible.. uhh.. objects... :) which can be designed, developed, and tested independently.
...
In a functional paradigm what invariably happens as a large system grows: it becomes a huge pile of functions. All of which are interconnected, and dependent on each other. Which means if you change one function you break 10 others, it becomes impossible to manage. A *good* large program written in a functional language is usually designed with OOP principles in mind. (i.e. it is designed as a set of modules that are not inter-dependent on other modules)

What is the dynamic untyped advantage and how can it work?

All variables in Smalltalk are typed with a single "universal type" (since it's universal there is no constraint upon it and thus it's not a "static type") of object. All objects in Smalltalk carry their type information with them. The original purpose of "types" is to prevent "illegal" operations from proceeding and corrupting data in memory. It's not possible in Smalltalk to apply an "illegal" operation to the wrong "object type" as a "does not understand" error is generated in the case of an object receiving a message it doesn't have a method for. In this regard Smalltalk is considered a "strongly typed dynamic language without variable type constrants or restrictions".

A reason that Smalltalk applications hold together is that the objects carry their "type information" with them as they travel through the program. This means that variables are free to hold ANY object at any time which provides the basis for "dynamic freedom". Any "constraints" that need to be applied to restrict the "class" of objects that can be assigned to a variable are done at runtime using the full semantic power of the Smalltalk language rather than a limited "static type syntax".

When you apply limited - single or even multiple - "static" type speicifications (either manually entering them or via type inference) to variables the possible pathways for information and objects to travel within the program is severly restricted. This reduction is a loss of degrees of freedom of movement for the program and the designer. Maybe that's what you want, but more often than not it simply limits what you can write. This is why applying constraints to variables is less than desireable and should be applied with caution and the awareness of future limitations in the program.

What's really shocking is that the vast majority of programmers have never been exposed to dynamic programming without statically typed variables and aren't even aware that they are limited by it's inherently restrictive type tunnel vision.

The scary part of this near air disaster is that those who think that static typing IS the answer are fooling themselves. Testing of software is essential and dynamic systems that can adapt to the situation are crucial.

In response to Shane King please see the response to Isaac above regarding the "typed" issue; in reference to the "testing" issue, yes Shane, they passed the buck to the end user and this was unacceptable. They also choose the wrong data type, which is unacceptable. The fact that they had to choose a limited range numeric type at all is essentially unacceptable in today's modern era of information technology considering that systems, such as Smalltalk, can deal with a wide range of numeric types easily. Actually they likely had a larger numeric range, [speculation on] but the programmer likely didn't even think about it and simply choose a limited "DWORD" type out of habbit. Totally unacceptable and a result of Type Tunnel Vision if that's what happened. Hopefully we probably find out more details about this major mishap as time goes on since it was so serious. . Fortunately no one was killed this time. It was inexcuable that the users were forced to reboot the machine. It also seems that a proper solution had been deployed in Seattle but not in L.A.. I wonder what the event timeline was?

May all your journeys be free of "type safety faults" and poor designs.

Articles in the Dynamic Language Freedom series: