home How to Argue About Typing

"Duck typing" evolving from "duct tape"? Are you sure? I thought its origin was "if it walks like a duck...". Sean McGrath?, http://seanmcgrath.blogspot.com

i am very much agree with you! lately,i have examined C# generics in a detailed way and find out that it really has the generic support in CLR,which means that there is now no type casting in generic method/class. That means, to C#,it has the capability and should have supported the template in C++,but to my disappointing, the generics in C# just behaves exactly the same as generics in Java.

only thing i could say is that it is BIAS that prevent those so-called OO people to add true generics feature to a language,which they think is perfectly Object-Orient. in their eyes Template is great devil. any trend to get closer to it should be eliminated. Justin Shen

Dave Thomas coined the term "Duck Typing" to give a name to the concept polymorphism without explicit interfaces ("If it walks like a duck, and talks like a duck, ..."). See http://www.ruby-talk.org/blade/78502. Some in the Ruby community may have confused the term with adding methods at runtime, but that was not its original intention.
Jim Weirich (http://onestepback.org).

typo: in C++ it's

template void speak(T& speaker) { speaker.talk(); }

Oops, I guess it's a HTML problem:

template < class T > void speak(T& speaker) { speaker.talk(); }

I've been reading your articles on typing with interest. I recently learned Python to write a small program that reads instruction files (xml) and executes the instructions against a database and then emails results. After learning enough Python basics and API's to do this, and writing the script, I came away very disappointed with Python and dynamic typing in general. I missed the self-documenting aspect of type declarations, and I missed IDE help in modifying my code.

I think your conversation with the Java wonk misses the point entirely. I don't care about the "safety" aspect. I'm entirely in agreement that type mistakes are likely to go hidden in my code. But, when I read code I wrote 6 months ago, I will have to wonder just what kind of object this or that variable is, and what it can do. My IDE won't help me out, because it doesn't know either. When I want to refactor my code, I'll have to do most of it by hand. When I change a method signature, I'll have to hunt manually through my codebase to find places that reference the method. When I write my unit tests, I have to accept that I'm behind the game compared to the starting point one has with declared type languages. It's not a question of compiling vs unit testing, as you seem to want to portray, it's the fact that with compiling, I've got an automatic boost on my way to full testing coverage.

What makes me like a language is not syntax or features nearly as much as ease of development and tools/API's. If a Python IDE could tell me as much about my program as Eclipse can about Java, that would be great, and I would enjoy its flexibility. I don't enjoy text searches or waiting till runtime to discover type mismatches. Earlier the better.

I would appreciate a discussion that focused on these practical development questions rather than theoretical bull about safety, security, and program correctness.

-Mike S

--typo correction--

I'm entirely in agreement that type mistakes are unlikely to go hidden in my code.

-Mike S

Writing Truely Generic Code in C# http://weblogs.asp.net/jezell/archive/2004/03/23/94694.aspx

Your articles miss the points entirely. Types are not about tesating but about abstractions. They are first class elements of programming language used for defining synctactical contracts. Onmce the developer kniows there's a synctactical construct he will also know there's a semantical construct associated with it.

So here we go: - Writing is nature's way of letting you know how sloppy your thinking is. - Mathematics is nature's way of letting you know how sloppy your mathematics is. - Formal mathematics is nature's way of letting you know how sloppy your mathematics is. (Leslie Lamport)

For just a small example: with good type systems, you'll never face a NullPointerException? as there are no null in the language (there's no need for nulls, inspite of 100% dynamically allocated structures). Just think about how sloppy most of the programs out there are (both Java and Python) with regards to checking for nulls, or specifying which parameters can be null and where.

And no, tests are not nature way of letting you know how sloppy your program design is. At best they can let you know how sloppy your implementation is.

But for that nature's way of letting you know how sloppy your implementation is, well, that's called proof of correctness. And that's where Dijktra called for proof-obligation. But hey what does have the wishy-washy agile movement has to do with Dijkstra ? Well, almost nothing, it turns out that they turned everything upside-down. But a comparison is unavoidable.

2004/03/23 18:13 EST (via web):
Bruce, I think you're underestimating the importance of static typing on the availability of good tools. Static types not only make for better compiler messages, they also make IDE's like Eclipse and IDEA possible. If my choice is between reading and understanding a large Java project in IDEA versus reading a large Python project in emacs (or one of the many half-finished Python IDE's out there), I'll take Java, thank you very much.

Also, could you please stop making the straw-man assumption that folks who like static typing haven't tried Python.

2004/03/23 18:15 EST (via web):
(Spacer)

In my experience the assumption that static typing advocates have programmed in one language (usually Java) for their entire career is most often correct. I have worked on many teams at many companies and have only met one engineer who genuinely knew a language like Python and who was still a staunch advocate of static typing.

2004/03/23 21:05 EST (via web):
If I had to use vi or notepad or an equivalent generic text editor program to code language X, you can be sure I would not like coding in language X, regardless of any other factors. I wrote Python in UltraEdit? and with a Eclipse plugin - both of which did little more than color-code and provide bookmarks for functions.

Python is very nice and if there were tools for it the equivalent of what I have for writing Java, I would prefer it. I am sold on dynamic typing in the language construct sense. But, in terms of tools, can an IDE understand my code enough to help me out?

Mike S.

When I'm writing Java in Eclipse, one major benefit of static typing is real-time problem detection. If I misspell a method name or provide arguments with the wrong type, Eclipse immediately indicates my mistake, and I can fix the problem without losing my chain of thought. Instant feedback has made me a lot more productive.

Python has a fantastic syntax, and I'd definintely choose it over Java if were still programming in emacs. With state-of-the-art IDEs?, I'm on the fence.

Bruce, seriously, don't be scared of type inference, it's your friend. I don't see how you can wax rhapsodic about "latent typing" and then say type inference is "mind boggling". Reduce the finger typing, keep the static type safety, be happy. Some bugs can't be stopped with testing, but they can be stopped with a good static type checker (see http://www.xoltar.org/misc/static_typing_eckel.html if you haven't already). Type inference isn't limited to "weird" functional languages, either - Nice ( http://nice.sourceforge.net ) supports type inference for local variables, and it's an OO language for the JVM. For example:

let list = new ArrayList?(); list.add("A");

the compiler figures out from this alone that only Strings should be allowed in the list. Add another line:

let list = new ArrayList?(); list.add("A"); list.add(2);

and the compiler will complain. Note we got a statically checked list which contains only strings, without a single type declaration. How can this not the way of the future? BrynKeller? ( http://www.xoltar.org )

Gah, sorry about the formatting... how to edit?

2004/03/24 18:11 EST (via web):
"Wonk" would be talking about "Type Soundness" & "Type Safety" because he'd learned something from all those online school notes.

'So what is "strong typing"? As best as we can tell, this is a meaningless phrase, and people often use it in a nonsensical fashion. To some it seems to mean "The language has a type checker". To others it means "The language is sound" (that is, the type checker and run-time system are related). To most, it seems to just mean, "A language like Pascal, C or Java, related in a way I can't quite make precise".' p205

Programming Languages: Application and Interpretation http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/

2004/03/24 18:32 EST (via web):
"Implicit typing" & FORTRAN

Maybe we should refer to a reference work, something like the "Handbook of Computer Science and Engineering", Chapter 103, CRC Press, 1997, p3

"Typed languages are explicitly typed if types are part of the syntax, and implicitly typed otherwise."

2004/03/24 19:17 EST (via web):
"Latent typing" & "Manifest typing"

Latent is the antonym of Manifest: "Latent typing" is a synonym for implicit typing; "Manifest typing" is a synonym for explicit typing.

2004/03/24 19:29 EST (via web):
Some notes I collected... "Smalltalk developers usually refer to an interface indirectly by..."

This quote comes from an article devoted to adding explicit interfaces to Smalltalk, and from a paragraph titled "The Problem with Implicit Interfaces"!

2004/03/24 20:05 EST (via web):
The original authors of two separate class hierarchies cannot be expected to predict every commonality that might occur, nor to anticipate that you might want to write a single piece of code that is applied to both of them.

package test;
// Original classes Dog & Robot

class Dog {
void talk(){ println("Woof!"); }
void reproduce(){}
}

class Robot {
void talk(){ println("Click!"); }
void oilChange(){}
}

// Now we want to perform a common operation

abstract interface SpeakerKind? { void talk(); }

class test.Dog implements SpeakerKind?;
class test.Robot implements SpeakerKind?;

void speak(T speaker) {
speaker.talk();
}

void main(String[] args){
Dog d = new Dog();
Robot r = new Robot();
speak(d);
speak(r);
}

Nice programming language using Kinds http://nice.sourceforge.net/index.html

Kinds are the "types" of types, that is they are collections of types, just like types are collections of values.

Ooops that should be
void speak(T speaker) {
speaker.talk();
}

' void speak(T speaker){

2004/03/24 20:27 EST (via web):
you cannot rely on static checking to verify program correctness True - we only run out of memory when the program is run.

the illusion that it is somehow safer My car has a steel passenger cage, and multiple airbags, and I still wear a seatbelt. Is the truth that the seatbelt will not prevent me from being crushed a reason not to wear it?

your seatbelt would be the python runtime, your compiler would be some sloppy technician :-)

i was very sad to see the following code caused compile error:

using System;

namespace ConsoleApplication1? { ///

/// Summary description for Class1. /// interface ITest? { void testMethod(); }

class testType : ITest? { //public testType(int i) {} public void testMethod() { Console.WriteLine?("testing"); }

}

class Test { public static void foo(T t) where T: ITest? { t.testMethod(); } } class Class1 { ///

/// The main entry point for the application. /// [STAThread]? static void Main(string[] args) {

object o = new testType(); Test.foo(o); } }

}

the equivalent code in C++ will also fail to compile,thus i see no benefit of introducing Constraints Technique. While Constraints do have great harm on the using of Generics

Mike S. mentions it above, but the greatest value to me in static type checking is the ease of automated refactoring. If I have an interface like Speaker in your article, I can refactor a method of that interface using the tools in Eclipse or IDEA and be confident that every use of that method in my whole project, potentially hundreds of classes, is changed. In Python, since there is no interface, I'd have to manually track down every place that method is called and change it. Sure, I could run the unit tests and use them to guide me, but it would be a lot harder thant the single button press in Eclipse.

============================================================================

25/03/2004

It's sad to see Bruce Eckel risk his reputation with nonsense like that. His theory that "type" (or interface) talks about syntax and "class" about semantics ("describes implementation constraints") is a particularly bad case of a concept not understood. In Java, a class doesn't imply any more semantics than an interface. The Comparable interface is an excellent example of how to describe "implementation constraints", it's actually defined by a set of axioms. In C++, you have no choice but to use latent typing if you want to create a generic collection of comparable objects. But you don't have any guarantee that a particular implementation of equals() will satisfy any axioms. In Java, you don't need latent typing to achieve the goal - you simply refer to the Comparable interface and you not only get (syntactical) type safety but also a semantical contract - all objects exposing the interface promise to fulfill the axioms (maybe they won't, but this would be an implementation bug). I think the example is particularly revealing as the equals() method is actually defined for class Object so you can "safely" call it on any Java object. Still you will only call it on Comparable objects because it's the contract you want, more than type safety. Bruce is wrong to state that "the primary argument against true generic types in Java is that 'it isn't type safe'". As several contributors have already stated: He entirely misses the point. The above also explains why the reader and maintainer of code benefits from tha Java way: he doesn't have to guess what the programmer was thinking of when he called a method "equals" or "shoot" or "close" on an unknown object (even a method "equals", though it may seem obvious, may intentionally be designed to have nonstandard semantics). And he doesn't have to make a text search to find out to which classes a "generic" method call could possibly apply. To say that organizing your code in clean interfaces is "making the reader do more work" and thus making the code less readable is so ridiculous that I can only assume the author of "Thinking in Java" hasn't done any real-world Java development for a long time. Sad and disappointing.

Eckel has so far failed to give any meaningful example of when latent typing might actually be useful in Java. He says: "However, it's still possible to have disjoint hierarchies in Java and C#, with common methods but no common interfaces. The original authors of two separate class hierarchies cannot be expected to predict every commonality that might occur, nor to anticipate that you might want to write a single piece of code that is applied to both of them." First of all, in Java, you can have disjoint hierarchies with common interfaces - that's the magic of interfaces. I can't conceive of any situation where different authors would design class hierarchies that just happen to have a method call in common - same signature, same semantics - except in very trivial cases as in the "equals" example.

Take a nontrivial example, a parse() method for an XML parser. If two authors independently invent such a method, it's hard to imagine that their syntax would be identical. Who would rely on such a coincidence, rather than on interfaces like XMLReader??

Again: Java doesn't need C++'s latent typing mechanism because its interface mechanism is always superior. Show me a counter-example, and I'll show you an example of bad design.

Toni Menninger ========================================================================

2004/03/25 13:29 EST (via web):
"Mike S. mentions it above, but the greatest value to me in static type checking is the ease of automated refactoring."

It's illustrative that although Bill (William F.) Opdyke's thesis focused on refactoring C++, automated refactoring tools were developed and adopted within the Smalltalk community. Years later (most of) those capabilities now appear in the most advanced Java IDEs?.

2004/03/25 13:31 EST (via web):

2004/03/25 13:44 EST (via web):
"your seatbelt would be the python runtime, your compiler would be some sloppy technician"

The seatbelt would be the Java, C#, Ada,... runtime; the steel passenger cage would be the static analysis performed by the compiler. The missing brake fluid would be the missing programmer test, that the sloppy python programmer intended to perform to make up for the lack of static analysis.

Addendum: and I forgot to mention that there are many different kinds of parsers. "Anything that has a parse method" just isn't a useful absraction. ==========================================================================

Toni Menninger is completely right. However, what he said has already been pointed out in the replies to "Generics Aren't". Unfortunately Bruce Eckel simply repeats the errors he made.

The discussions between advocates of static versus dynamic (and whatnot) typed languages is not a new one. Many people seem to forget that it is mostly a matter of preference, and state what they prefer as the best way to go. Bruce makes the same mistake. For example: the way generics are implemented in Java are not inferior to the C++ (or whatever) way, just different. I happen to like the Java way more, but anyone is free to disagree.

I can also confirm that not all people who like static typing are oblivious to other kinds of type systems.

To summarize: * Don’t judge a language (-feature) unless you've studied it thoroughly enough, especially if your readers expect you know what you're talking about. * Don’t fight religious wars over programming languages or paradigms.

2004/03/26 12:36 EST (via web):
"The biggest payoff is this: I am able to think about things in Java or C++ that I was unable to conceive of before I learned Python... Your language really does constrain your thoughts."

Heed that lesson, learn a "modern" statically-type-checked language.

When you might have used C++ try OCaml? instead http://caml.inria.fr/ocaml/

When you might have used Java try Nice instead http://nice.sourceforge.net/index.html

When you want to open up your mind to other possibilities write some small programs in a pure functional language with type inference, like Clean http://www.cs.kun.nl/~clean/

_______________________________________________________________________

I've written a response up here:

http://diary.recoil.org/pixel/

Just one small correction: Bell's theorem states that quantum mechanics and theories with local hidden variables are inconsistent. A. Aspect et. al. experiments "proved" that quantum mechanics is right. There are theories with global hidden variables.

So God's a crappy programmer. Just our luck.

Looks like you've never seen OCaml? :)

2004/04/01 02:01 EST (via web):
" "your seatbelt would be the python runtime, your compiler would be some sloppy technician"

The seatbelt would be the Java, C#, Ada,... runtime; the steel passenger cage would be the static analysis performed by the compiler. The missing brake fluid would be the missing programmer test, that the sloppy python programmer intended to perform to make up for the lack of static analysis"

Why do you need a steel passenger cage if your car is not going to start because some sloppy java developer forgot to write unit tests to check that the car has wheels in the first place. What I mean is that I'd rather spend my development time to write unit tests instead of fighting with java/c++/c# language just to make its compiler happy without any real benefits.

----------------------------------------------------------------------------------------- "Why do you need a steel passenger cage if your car is not going to start because some sloppy java developer forgot to write unit tests to check that the car has wheels in the first place." This discussion starts to become ridiculous. If I would take this statement serious, I would say that a bug that prevents a program from running in the first place is nothing I worry about too much. I worry about bugs that make the program look as if it was running. If the car has no wheels, you don't risk an accident. If it has the wrong type of wheels (to come back to type safety), the worst can happen.

Anyway, "Checking that the car has wheels" is not a good case for unit testing. I don't believe that you write all the unit tests to check the possibly hundreds of constituents of an object, and that you remember adding a test each time your class changes. Object integrity should rather be enforced by design (e.g. by specifying reasonable constructors). Unit tests won't compensate for bad design.

Toni Menninger ----------------------------------------------------------------------------------------

(This debate is really a confrontation with some of the ugliest programming attitudes. lest we forgot that they still exist.) =========================================================================================

Hi Bruce, hi Toni!

Toni request for a meaningful example:

I won't deliver you code, but perhaps I can create associations or ideas for some. I have often seen java code, e.g. that wants to use something like a list or exception. That code does not define or expect/use a List interface. It only uses/calls reflection and searches for one (or even several) appropriate method name(s), e.g. getElement or getCause with an appropriate signatur (parameter). E.g. it does some filtering on the list or extracts a nested exception.

It exactly has the benefit, that it can cooperate with foreign librarys, that does not regard own interfaces. But of use of reflection is more complicated than a direct language feature.

Not so clean as in Python, it would also be possible to add "latent typing" to java as a feature, just for purposes like the code i have seen!???

best regards

Thorsten van Ellen

P.S.: nice, to be able to discuss all your topics, now, Bruce!

2004/05/05 13:55 EST (via web):
Would like to better understand your example. Why would you want to use a nonstandard list in Java instead of using the List or collection interfaces? I have always regarded it as one of the greatest achievements of Java that collection types are built into the language standard. The drawback, up to JDK 1.5., was always that you couldn't specify the type of collection elements, so sometimes it made sense to use nonstandard, "typed" collections. Is that what you are talking about?

Toni

People seem to have very strong emotional reactions to this issue. The flamers above should perhaps go read this (http://mail.python.org/pipermail/python-dev/2001-July/015966.html) and see if they recognise themselves?

Here's one real-world example where latent typing can come in handy: crossing language boundaries. Imagine you have functionality in Java or C++ that you wish to make available to users of many programming languages (Java, C++, Python, DotNET?, COM/IDispatch?, Excel, Mathematica, and so on). One way to do this is to make paramters/returns latently typed, and to write code to carry out marshalling between the different languages' ideas of a generic object (java.lang.Object in Java, System.Object in DotNET?, and so on). Another way is to use swig/roll your own code generating tool to explictly map static types between the languages. I have done this using both approaches, and found that the latent typing approach worked very well when there were many client languages (all those listed above) and many client projects (more than two dozen) using the functionality. Go down the code generation route, and you've got an extra tool/process in your build step, which can get very complex and need a lot of faffing around to get working with all your desired languages. For instance, every major family of Java projecst seems to have its own substitute for the horrid native Date class. If your organisation has (say) 5 such families, that's 5 different statically typed wrappers you'll need to provide! Of course, if you're only bridging between one pair of langauges, code generation might work for you straight out of the box.

Re testing: as far as I'm concerned, if you're not developing with thorough unit and functional testing as an integrated part of your process then your software will not be very high quality anyway. Use of latent typing pales into insignificance by comparison with inadequate testing in terms of problems that I have seen in the real world. But you obviously want to keep the use of latent typing only to those areas where it actually provides a real-world benefit. Users of statically typed languages might typically want to add their own facade around a latently typed subsystem to integrate it with their own local static types. They'll then just talk to the statically typed layer.

Incidentally, note that static typing typically does not catch all the information in an interface anyway. One example is an option pricer which takes two dates: option expiry and underlying deal maturity. Typically both inputs will be of the same type ("Date" or whatever). Get them the wrong way round and you'll get an error that your type system's failed to catch. Of course, you could specify a different type for every possible use of a Date, but this feels like overkill. So you are making a tradeoff between static typing and dynamic error checking right there. It's not some kind of black/white issue.

2004/05/06 11:34 EST (via web):
"Incidentally, note that static typing typically does not catch all the information in an interface anyway." This raises the question, what is an interface and what represents its semantics. (Bruce Eckel disputes whether an interface has any semantics at all). You are in effect saying that the formal description of an interface (including parameter types) doesn't tell us a lot about its meaning (what its methods and parameters represent in the business domain). That is of course true, and the compiler will never be able to check any semantics in the business domain sense. However, I argue that the meaning we humans attach to those formal definitions is an important part of why we are using interfaces. The compiler doesn't care whether your class is called sahgdfQw12 or 'OptionPricer?'; similarly, whether you call your parameter optionExpiryDate or something doesn't bother the compiler but it helps us to understand how to use the interface and to avoid obvious errors (otherwise, we would have to design tests to find out in what order to pass the parameters; do you really do that?). I have stressed before that compile time type checking is only one aspect in this discussion. Readability and maintainability are in my view at least as important and they are greatly enhanced by the need - in Java - to define clean interfaces. That this doesn't dispense us from "thorough unit and functional testing as an integrated part of your process" is so obvious that it shouldn't need to be stated. But I dare say that any mildly complicated software system is far too complex to explicitly test even a significant fraction of all theoretically possible cases. There is no way that the thousands of tests performed automatically by the compiler can be replaced by manually written unit tests; and maybe even more to the point, not only development but also testing is guided by so many implicit assumptions (e.g. about what this parameter means and that method is supposed to do) that in can't all be tested. Good software design aims at making those assumptions both explicit and thus more readily testable (by specifiying types and interfaces) and reliable (for example by breaking down the model into appropriate logical units, by encapsulation and reuse of reliable code). Testing your assumptions is vital but it is an illusion to believe that you can test them all. Isn't that what makes software design a hard problem?

Toni

Well, it depends on what information you expect. Obviously, the compiler cannot check whether you are passing the right parameters, only whether they have the right type. It is possible to represent additional information in an interface, for example by excluding null values (as is possible in Nice but not in Java) but

(sorry, forget the last two lines - I discarded this line of argument but didn't remove it (this text box is a nuisance)).

2004/05/06 12:26 EST (via web):
A remark about unit testing. I admit that I have always been a little sceptical about the unit testing movement. I don't doubt the necessity of unit testing but I'm sceptical about it's ability to catch hard bugs. Hard bugs usually arise because of a condition that the programmer failed to take into account when writing the code. How, then, should the same programmer be far-sighted enough to write a test case testing exactly this condition? I don't buy it. I agree, however, that it's absolutely important to test the code as early in the process as possible (and note that the compiler is an indispensible test tool acting at a very early stage!). Among other things, it helps to become comfortable with your own code (we humans want to actually see some output, not only imagine it in the abstract), can help to ask the right questions, identify dubious design and improve the code at a very early stage. It also helps to make assumptions explicit. This notion doesn't necessarily call for automated test frameworks. On the contrary, I regard testing as a creative part of the design process. I'm highly sceptical when people claim that if only they had more time to write more tests, quality would be better. More tests don't necessarily mean higher quality, just as little as more classes are proof of good design. The important thing is to write the right tests!

Of course, writing more tests can't hurt (as opposed to writing useless classes). The danger is that a wrong quantitative attitude to testing might compromise the process. For example, test tools measure how much code is ever reached by unit tests. But this measure is irrelevant because those tests might only cover trivial cases. No test tool can quantify how useful the tests are. Isn't it paradox that sometimes, the same people who declare compiler checks to be irrelevant or even a nuisance have so much confidence in atomated test tools?

Toni

P.S. check out Mike Spille's blog on Bruce Eckel's "embedding JUnit? tests" piece, http://www.jroller.com/page/pyrasun/20040408#the_power_of_obsession. He's prettyr harsh with Eckel and I agree with him: "What you have going on in the industry is a bunch of Thought Leaders like Eckel obsessing over unit tests to the exclusion of pretty much everything else. They're bending their minds to the problem of "How do I make unit testing easier", and are mostly ignoring a number of larger issues in software development today."

2004/05/07 05:26 EST (via web):

I just read the piece. I think people get tied up in knots about unit testing because they focus on one piece of the puzzle. But I don't think that Bruce Eckel, on a good day, would deny that unit testing and what I call functional testing, the testing of emergent behaviour from a system of classes, are different beasts and are both vital. Unit testing is very important for refactoring ease, which is in turn important to keep systems moving in tune with changing business requirements. But unit tests alone are incapable of catching problems due to emergent behaviour, or at a higher level from the interfaces between separately developed systems. And they're not adequate to catch less deterministic problems (eg threading issues). Problams can start when people focus on the unit testing aspect and believe it will solve all their other problems.

And, incidentally, I don't think unit tests should be embedded in source. That just seems daft to me. I always write unit tests stuff as separate programs to stop muddying things up. Why entangle abstractions only used by testing with the rest of your code? I just can't see the upside.

There is some very counter-productive, over-simplifying rhetoric from some quarters of the agile movement, with a corresponding backlash gaining strength. I find this a very interesting dynamic. As the C2 wiki page says, "all panaceas become poison". Anyway, I've personally found a lot of the agile techniques invaluable in helping with development. But it's not for every project, everywhere. I'm not an evangelist by temperament. Eckel is, to a certain extent, and that needs to get factored in to one's reading of him. Heck, he's not as bad as some of the more extreme XP-rapture people...

Matt Morris

2004/05/07 14:29 EST (via web):
I would add, as this brings us back to the original topic of this thread, that if "unit testing is very important for refactoring ease", the same can be said about compile time tests (including type checking). Without the help of our friend the compiler (which we usually just take for granted), refactoring must be a nightmare. The opposition of "strong typing vs. strong testing", as Eckel has put it, really doesn't make sense.

Toni

Bruce, in case you actually read this feedback, I'd like to note that I've actually been bitten by a bug caused by lack of typing in Java pregeneric collections. It took me about a day to find and fix. I use collections a fair amount, and concluded (pre-1.5) that this was substantially cheaper than it would have been to have written type safe wrappers around all the collections I'd used - though it was probably more expensive than using parameterized collections in all those cases if 1.5 had been available.

I would note that the bug was nonlocal - unit tests would not have caught it. I don't believe unit tests are a substitute for static type checking.

I don't have a point to make, really, just data for your information.

Warren Dew

subtopics: