Update: See the comments.
The paper by Meijer and Drayton is making the rounds. As long as Microsoft supports the popular "dynamic" languages I don't care much what other languages they support.
Since the paper is a work in progress and they admit to being provocative, I may as well comment...
First of all I would note that the term "test" does not show up anywhere in the paper. This is a bit of a shock for a paper whose opening sentence is...
Advocates of static typing argue that the advantages of static typing include earlier detection of programming mistakes.Moving on to a few unsubstantiated claims...
data intensive applications need to deal seamlessly with several degrees of typednessI did not see a definition of "data intensive" nor did I see evidence of what this "need" is.
not inferring the types of these variables whenever possible is literally throwing the baby with the bath waterEverything has a cost/benefit ratio, which informs the answer to "whenever possible". I could not find a description of this ratio in spite of that being the topic of the paper.
in general programmers want to express more advanced contracts about their codeYes, but the question is how, and at what cost. Testing, even model checking, could be brought into this discussion. The benefits of the specific proposals in the paper are not clearly proposed.
The compiler should verify as much of a contract... as it canMore of the same... "as much as possible", "as much as it can"... the problem is the paper should propose some eveluationc criteria otherwise it is your word against mine. I will go with my word every time in that case.
Perhaps the most useful example [of coercive typing] is "auto-boxing" from value types to reference typesIf that's the best example then... ahem. One could simply choose a language that does not even have such things that contribute nothing to the real problem.
the compiler can automatically "lift" addition on normal integers to addition on nullable integersOne could simply choose a language that does not even have such things that contribute nothing to the real problem.
[generics make it] possible to create highly reusable languages, while maintaining the benefits of compile-time type checkingThose benefits have a cost. The point is people disagree on the accounting of the cost/benifit ratios. The paper does not propose an accounting that can be examined.
I want lazy evaluation... the power of the Unix shell lies in the fact that programs consume and produce lazy streamsAgreed. But this has nothing to do with type checking. Maybe this would make a better paper than one on type checking for many readers.
Overall the paper has some ideas on how typical type checkers for C# and Java can be improved. That these checking approaches would be better than "dynamic" languages seems to be an assumption the authors chose not to question. Too bad, I thought that was the point. I don't see many people arguing to stick with the poor checking done currently by C# and Java.
14 comments:
"test" does not show up anywhere in the paper... This is a bit of a shock... advantages of static typing include earlier detection
Why the shock?
Is it so hard to imagine "earlier detection of programming mistakes" could mean earlier than test?
One could simply choose a language that does not even have such things...
Which takes us back to "Defending the fact that delaying all type-checking to runtime is a good thing, is playing ostrich tactics with the fact that errors should be caught as early in the development process as possible."
ideas on how typical type checkers for C# and Java can be improved
Ideas on how to use both static checking and dynamic checking in a language like C# or Java (humbly suggest that doesn't really conflict with the title of the paper).
an assumption the authors chose not to question
"errors should be caught as early as possible"?
"Earlier than test"
Since the "dynamic" languages rely on very early testing, I expected the paper to address this. The argument is that test-driven design (in a REPL, a Smalltalk workspace, or an xUnit test, e.g.) more than accounts for the lack of compiler type checking. Maybe that argument holds, maybe it doesn't, in the face of their type checking suggestions. Either way, the paper should address this.
"ostrich tactics"
This is a derogatory remaek, not a technical argument. They need to address how errors are caught as early as possible in each of these kinds of languages, and then evaluate whether their approach catches more errors earlier, and whether the effort of catching those errors earlier is worth whatever the cost happens to be.
"Earlier than test"
quibble: dynamic languages don't rely on very early testing - some such programming practice (TDD) may be used with dynamically checked (or statically checked) languages, or not.
Isn't "errors should be caught as early as possible" implicit in TDD?
Of course, in our favourite Smalltalks, the compiler catches syntax errors when we define a method or class - before programmer tests can be run.
"ostrich tactics... They need to address... and then evaluate..."
Look back to the XP and TDD polemics - did they provide the level of justification which you now require of these authors?
"dynamic languages don't rely on very early testing"
Successful programming with dynamic languages relies on early testing. Show me a successful Lisp or Smalltalk programmer who does not use the REPL or a workspace (or now, xUnit) for test-driven development. This practice predates XP and TDD by a few decades.
xUnit is simply a read-eval-print loop for languages that do not support such a thing directly.
"Smalltalk catches syntax errors before runtime"
Yes, this is always a question of balance... Smalltalk catches what it can without interfering too much with the programmer's flow. I agree in principle that more kinds of checking can be done without interfering with flow. I don't think this paper addresses the issue well, nor do I think the type checks described in the paper find that balance.
"Look back to the XP and TDD polemics - did they provide the level of justification which you now require of these authors?"
I am criticizing this paper, not justifying everything or even anything that has been written about XP and TDD. The paper's main claims are not substantiated in the paper... that is a big miss.
REPL or a workspace (or now, xUnit) for test-driven development
Conflating testing with TDD?
Isn't there a big difference between micro-testing (even using REPL) and TDD.
I agree in principle that more kinds of checking can be done without interfering with flow
Hallelujah! ;-)
nor do I think the type checks described in the paper find that balance
It would be so much more interesting to see point by point criticism from that perspective, rather than 'just use a dynamic language' rhetoric - but that's just me.
criticizing this paper, not justifying everything...
Let me rephrase - do you think you made the same type of criticisms about papers on XP and TDD?
"Hallelujah!"
This is not a new position for me. Previous blog posts, posts to LtU, etc. should show I have been in favor of new kinds of checking. But I am still looking for someone to demonstrate they will work for me better than the dynamic languages I use now.
"do you think you made the same type of criticisms about papers on XP and TDD?"
I don't know that I have, but I would be willing to. I teach XP and TDD and I do spend time debunking unsubstantiated claims in general in my workplace.
"It would be so much more interesting to see point by point criticism from that perspective, rather than 'just use a dynamic language' rhetoric - but that's just me."
That's what I was hoping for from the authors. If they don't have the time to do so, then certainly I don't. My interest is in programming with the languages I have found useful. I am not out to analyze why they are useful or why something else might be useful.
I will tell you from my experience what I like, but I am not interested in convincing you of it formally.
The authors seemed to want to do this. I am interested in their thinking. But I cannot see their reasoning, at least not in a form that is meaningful to me.
"Conflating testing with TDD?
Isn't there a big difference between micro-testing (even using REPL) and TDD."
Nope
Isn't there a big difference... Nope
Really!
"One of the ironies of TDD is that it isn't a testing technique... It's an analysis technique, a design technique, really a technique for structuring all the activities of development." p204 Test-Driven Development: By Example
"One of the ironies of TDD is that it isn't a testing technique... It's an analysis technique, a design technique, really a technique for structuring all the activities of development."
One of the ironies about the Read-Eval-Print Loop as well is that is is simultaneously a testing, analysis, and design technique.
TDD is an interactive software development technique whereby a little analysis and a little design are used to produce a little repeatable test. The same goes for a REPL or Smalltalk workspace. This is where TDD and xUnit came from. They predate and inspired xUnit.
Seems that you equate repeatable tests with TDD, I don't agree but it isn't something I'm interested in arguing about.
"Seems that you equate repeatable tests with TDD, I don't agree but it isn't something I'm interested in arguing about."
The result of TDD is a suite of repeatable tests, but that is not all. As I said, TDD is a little analysis, a little design, a little testing, etc.
The interactive inner loop of programming with xUnit is not unlike the interactive inner loop of using a Lisp REPL or a Smalltalk workspace. That is the heart of what I am saying.
Post a Comment