|
|
Re: Are Dynamic Languages Going to Replace Static Languages?
|
Posted: May 22, 2003 5:17 PM
|
|
Some remarks on this topic in general:
1. Statically type checking a function gives you the guarantee that it uses the proper operations for all input values. Notice the for-all part, but also note that this is only true for safe type systems. Contrary to rumors, C++ is not safe.
2. Dynamically type checking (in say Scheme) means that you guarantee that you only check for those values that the function is actually applied to. So in future runs, it may actually fail.
3. Having said that, I strongly believe that building a test suite before you write your program finds far more errors quickly than a static type system, including powerful systems like those in Cayenne, Haskell, or ML. This is also what I teach in my introductory courses and what I wish to instill as a culture in those courses. Take a look at http://www.htdp.org/ and look for all the design recipes to see what I mean. (The book is on-line but also in paper.)
4. A static type system, especially an inference system, comes with a huge problem. Nobody has found a way to provide good feedback when the system discovers type errors. (First research efforts on this: POPL 1986!). So yes programs run when they type check but until they type check, you can't use the debugger or any other tool to find the problem.
5. We (the PLT crew) have developed an alternative to address exactly this dichotomy. The idea is to develop auxiliary value flow analysis tools for dynamically typed languages. If you write a script to add a header line to each file, you don't even think about it. If you have a prototype that you want to turn into a product, you carefully get each portion "type right".
6. We also addressed the error reporting issue. We explain the error that our inference tool finds via flow diagrams that we draw atop the program. It shows how a bad value might end up in a position where it violates a primitive function. The programmer can then figure out whether this is a weakness in the analysis tool or the program (usually).
7. We accomplished this by giving up on equational reasoning a la ML and use subset reasoning instead. We find it more natural. The cost is that the complexity of the algorithm is high.
8. We're in the process of re-engineering MrSpidey now. We are
also exploring an ML-like alternative again, simply to find out whether we can tame it, too.
9. If you're interested, go to my home page and peruse some of our publications on Soft Scheme, MrSpidey, and MrFlow:
http://www.ccs.neu.edu/home/matthias/
-- Matthias Felleisen
|
|
Previous Topic
