Then, we intro'd types.
To enrich the discussion of types as a way to find errors sooner and document code, I mentioned ESC/Java. ESC/Java statically checks much more than types; it allows us to express a variety of constraints on the program in a form that carries many of the same advantages as types (enforced/guaranteed, as discussed below). Here's the example we saw in class.
To enrich the discussion of types as a way to improve efficiency, I poked around in some Java bytecode produced by the short program at the end of this post. I used the jclasslib bytecode viewer to check out the bytecode. If we can determine the type of an object statically, we can (though my Java compiler didn't in this case) avoid checking the type of the object dynamically to figure out which foo method to run.
By the way, here's a fascinating and readable thesis on Starkiller, a system that tries to infer types for Python programs to improve their efficiency (and hopefully safety and security).
A couple of great contributions that came up in class:
What do we lose with static type checking?
(1) Expressiveness. One compelling example is heterogeneous lists. It can be really handy to have a list of different types of things like '(1 2 "three" four). I won't go into details as to why, because studies of dynamically type-checked languages show that programmers don't use this flexibility very often. (Sadly, I can't find a reference to such a study right now. Please post one in comments if you find one!)
(2) Quick prototyping/early runtime testing. Generally speaking, static type systems front-load a great deal of annotation work. Dynamic type-checking lets us skip by this. Oleg pointed out after class that this point is critical in the real world of business. You don't make money until you have a product, and you may never make money if your product comes out too late. So, high maintenance cost after initial development may not be a reasonable argument for adopting a language with static type-checking. (You'll never reap those lower maintenance costs benefits if you run out of money before you finish developing!)
Why are types better than comments (or Hungarian notation variable names)?
(1) They're enforced: Lazy/overworked programmers can't skip them. (Good or bad?)
(2) They're guaranteed: The type-checker ensures that they stay consistent with the current state of the program, whereas comments tend to drift.
Appendix: Sample Java Program We Played With
public class TypePlay {
public static void printOne(int i) {
Base b;
if (i <= 0)
b = new Base();
else if (i == 1)
b = new Sub1();
else
b = new Sub2();
System.out.println(b.foo());
}
public static void printThisOne() {
Base b;
b = new Sub2();
System.out.println(b.foo());
}
}
class Base {
public int foo() { return 1; }
}
class Sub1 extends Base {
public int foo() { return 2; }
}
class Sub2 extends Base {
public int foo() { return 3; }
}
No comments:
Post a Comment