|
Re: Have Generics Killed Java?
|
Posted: Aug 8, 2010 3:43 PM
|
|
Morgan wrote: > Seeing all the casts makes me really appreciate the > new generics. > Yeah. Can't say I loved those, goodness knows.
Niklas gave this C# example: > > dictionary.ForEach((k, v) => Console.WriteLine(...) > Gotta love that.
Still. I continue to be amazed that there is any kind of argument over specification-first development, where the specification is both readable and runnable. (Every production shop I see, people don't seem to think they have time for it.)
<generalization> People who work in statically-typed languages spend so much time satisfying the compiler that they often seem appalled by the "extra time" required to write tests. By the time they have finished satisfying the compiler, they have a program that runs in a "plausible" manner. But they leave behind a program that isn't truly spec'd, and that has unknown bugs. Worse, when a bug does surface, the cause will be hard to find. (A major advantage of tests is that they keep bugs shallow.) </generalization>
On the other hand, I take the point made by several folks that static typing in general, and generics in particular, help immensely when trying to figure out what some other programmer's code expects, and what it gives back. In large projects especially, fixed classes and static types all seem like a major win.
But here, I think that "specification" (as in readable, runnable tests) provides an interesting answer: a) They say what a routine accepts and what it gives back. b) If an "open" class needs to be extended to work, the tests tell what additions are necessary, and how they are accomplished. c) If the extensions cause problems in the calling code, the callers tests identifies the problems straight away. d) If the caller has extensions of their own, the library tests tell straight away whether or not the extensions cause problems. In effect, runnable specifications enforce contracts. They do so in a way that can ensures correct semantics, rather than being limited to correct types. So the relative "safety" of static typing seems like something of a mirage, to my mind. (To take a page from Dykstra, you specify pre-conditions, post-conditions, and invariants. Then you prove those conditions are satisfied over a range of inputs.)
The more work it takes to achieve that degree of safety, the less inclined the programmer will be to consider (and the less time is available for) other measures that provide an even greater degree of safety.
Type inferencing is clearly necessary to minimize the time requirements. But is it sufficient? I don't see how it can be, given that static typing is itself insufficient.
Even so, it is clear that type inferencing would greatly reduce the cost of compliance, in return for a measure of safety and more readable contracts. :_)
|
|