Static vs dynamic typing describes at what point type analysis (determining whether a programmer's request to perform a particular operation is permissible) happens: at compile time for a statically typed language, or at run time for a dynamically typed one. Manifest typing in this view is close in the meaning, if not necessarily an exact synonym, of static typing. Statically typed languages often require type declarations in programs, however some statically typed languages such as ML can in some cases infer types from the operations performed, making manifest type declarations unnecessary. It is important to note that dynamic typing does not imply absence of type checking, in spite of the absence of variable and function type declarations--so calling dynamically typed languages such as Smalltalk "untyped" would be grossly incorrect.
Strong vs weak typing characterizes whether type checking, static or dynamic, can be meaningfully circumvented. "Meaningfully" is important here, implying that the type overrides should be predictable in their effect and at least reasonably portable between implementations. In a weakly typed language such overrides are possible. For example, in C , one can take a pointer to an Employee, cast it to char* and pass to a function that expects an argument of that type. In contrast to that, in Smalltalk it is not possible to take an instance of Employee and use with it an operation not defined for instances of Employee.
Actually, Testing is more important to guarantee program correctness than selecting among XXX-typed languages:
See Bruce Eckel's note: (In which he advocate python)
5-2-03 Strong Typing vs. Strong Testing
http://mindview.net/WebLog/log-0025
That is to say, if a program compiles in a strong, statically typed language, it just means that it has passed some tests. It means that the syntax is guaranteed to be correct (Python checks syntax at compile time, as well. It just doesn't have as many syntax contraints). But there's no guarantee of correctness just because the compiler passes your code. If your code seems to run, that's also no guarantee of correctness. The only guarantee of correctness, regardless of whether your language is strongly or weakly typed, is whether it passes all the tests that define the correctness of your program. And you have to write some of those tests yourself. These, of course, are unit tests. In Thinking in Java, 3rd Edition, we filled the book with unit tests, and they paid off over and over again. Once you become "test infected," you can't go back. It's very much like going from old C to C++. Suddenly, the compiler was performing many more tests for you and your code was getting right, faster. But those syntax tests can only go so far. The compiler cannot know how you expect the program to behave, so you must "extend" the compiler by adding unit tests (regardless of the language you're using). If you do this, you can make sweeping changes (refactoring code or modifying design) in a rapid manner because you know that your suite of tests will back you up, and immediately fail if there's a problem — just like a compilation fails when there's a syntax problem. But without a full set of unit tests (at the very least), you can't guarantee the correctness of a program. To claim that the strong, static type checking constraints in C++, Java, or C# will prevent you from writing broken programs is clearly an illusion (you know this from personal experience). In fact, what we need is Strong testing, not strong typing.
0 comments:
Post a Comment