Fog Creek Software
Discussion Board




XP founder explains how....

Sorry if this has been posted before. It's a brief interview with the guy who created extreme programming.



Working smarter, not harder: An interview with Kent Beck

XP founder explains how better applications can arise from the ashes of failure

"Extreme Programming (XP) founder Kent Beck likes to say he made up XP's fundamentals during a particularly troubled project in 1996. While strictly true, from talking to him you sense he'd really been formulating the process for quite some time. Find out what Kent thinks about the contribution of the Java platform to software development's success (or lack thereof) in this exclusive developerWorks interview."

http://www-106.ibm.com/developerworks/java/library/j-beck/?open&ca=dgr-jw16j-beck

www.marktaw.com
Wednesday, July 09, 2003

The thing I found interesting was this comment:

dW: Is the Java language a good tool for producing quality products?

Beck: Java is so pessimistic. You have this compiler saying, "I'm not sure this program isn't going to run so I won't run it." I find that attitude disturbing in a program. I notice that the safety in pessimistic languages is an illusion.

Well, he completely dodges the question, but the answer is probably even more interesting.

I'd have thought that static type checking is like a set of unit tests you get for "free". Given that XP is heavily into extensive unit testing, I'd have thought you'd be happy to have it. After all, any unit test written by the compiler is one less that you have to write.

OTOH, I suppose it can make the "constant change" a bit harder to do, since you spend more time on types and making the compiler happy.

And the horse you rode in on
Thursday, July 10, 2003

Bruce Eckel debates this point, static typing and unit tests.

http://mindview.net/WebLog/log-0025

anon
Thursday, July 10, 2003

Well, I'll state upfront I'm disinclined to trust Bruce Eckel because I think his books are worthless driven not much above "Learn X in 24 hours!" ...

Anyway, I think there's two things here:

a) Test is better than no test.

Yes, we know that, it hardly takes a rocket scientist to work that one out. My point is that a statically typed language already runs some tests for you. I didn't say that it runs all the tests you need.

b) Python is greater than C++ for productivity

No argument from me here. I'm a python admirer myself. But that has as much to do with the vast number of other ways its superior to C++, even setting aside their respective type systems.

Python vs C++ is a ridiculous comparison, because they have virtually nothing in common. JavaScript vs Java is probably a better match, and even then, I'm going to offend someone if I try to make it, so I wont. ;)

I'm undecided on the strong vs weak type checking. I think the way it's implemented in Java and C++ is needlessly restrictive, but I also know there are other languages that have strong type checking and dont get in your way as much. Not having used such a language "in anger", I can't say I'm sure I prefer one or the other.

As for testing, well, its good for some things. Other things are damn hard to test (something which few advocates of XP style testing ever seem to acknowledge). Furthermore, there's some evidence that reading code finds bugs faster than testing. I guess that plays into the idea of pair programming somewhat.

And the horse you rode in on
Thursday, July 10, 2003

Interesting read.  Few random thoughts...

-The solution to the Chrysler software mess had nothing to do with XP (at least in the answer Beck gave).  Basically, it seemed like "all" Beck did was limit feature creep, set milestones, and work through them.

- The thing about design patterns *feels* right.  I've seen a number of cases where the use of a design pattern makes no explicit sense and is being used "just to be used".

-  The evils of obfuscated code.  Of course this has been talked about by many experts, but I'm glad to see him repeating it here. 

- I agree with another poster about him completely dodging the question about Java and quality products.

Crimson
Thursday, July 10, 2003

As far as unit testing is concerned, I think "horse" missed Eckel's point.  Unit tests subsume type-checking, so type-checking become redundant.  Thus no extra benefit is gained from type checking. 

Crimson
Thursday, July 10, 2003

Eckel has missed the good things that static type checking gives (Personally I agree with his Java Exception argument, but then so did the C# designers). Having spent so long programming in VB where we use things of type object. We often get runtime errors out in the field were some static type checking at compile time would have sorted the the problems (Now we'd use an interface class, but when some of this code was written it looked like a good idea). VBs exception model of "On Error" is so awful to use in a production environment because you often don't find out where the error occured. We have code that looks like this:

Property Get Thing(Index as byte)
  If (Index<1) or (Index>10) then err.raise "Out of range in property thing"
  Thing=m_thing(Index)
End Property

Looks ok until you try something like
y=-1
x=Thing(y)
Which falls over with an out of range error in a generic error routine giving no means of getting a useful line/module pairing. Testing doesn't solve this, you get the same problem with VBScript in ASP pages as the type system uses variants, so you HAVE to type check every single parameter on the way to make sure it will work. People will pass strings into your variable which you're going to use as an integer, often the intrinsic type conversion will work, but when it fails it will do so dramatically and without warning.
Unit testing won't come up with enough BAD data, you end up having to add a whole extra layer of "bad" type data testing that you need to do, to give a decent test, once per parameter type.
After programming in a typeless manner, give me interfaces any day of the week for overall system reliability. Implicit conversions of types are bad for most programmers, they help initially with productivity but for bugs later when the programs encounter users they are awful. I don't care HOW good you are you WILL screw up somehow, typeless script languages cause problems (I did write one in C once upon a time and with hindsight it was a bad idea)

Peter Ibbotson
Thursday, July 10, 2003

I think there are two different areas in type checking that are often treated the same:

1. Difference between fundamental types (bool, int, float, string). For example, can you pass a string where a function expects an integer? This will never work if the string doesn't contain a valid integer. The same applies to bools, ints, and floats. If C++ wouldn't automatically convert an int to a bool, you wouldn't have to worry about writing "if (3 ==x)" because "if (x = 3)" would give a type error.

2. Difference between object types. In strongly typed languages, you can only call methods that you know the object will support. In a weakly typed language, you can pass any message to an object and will get a run-time error if the object doesn't support it. This means that you don't have to worry about properly inheriting and upcasting objects: it just works.

Wouldn't the best solution be a language with strong checking of fundamental types, and weak checking of object types?

Another thought: a benefit of strongly typed languages (in the object sense) is that method calls can be compiled as a fast indirect call, where a weakly typed language would have to check method names and arguments before a call can be made, which is not nearly as efficient.

Frederik Slijkerman
Thursday, July 10, 2003

Interesting stuff. I've been wondering about the point that strongly typed code still needs to be tested, so what's the point other than an extra layer of obfuscation to make the compiler happy.

The issue with weakly typed languages allowing for incompatible primitive types to be used is easily solved in most cases by using a type prefix on variable identifiers.

Big B
Thursday, July 10, 2003

Uh-oh, the great typing debate. ;)

FWIW, I'm not a fan of static typing, it's a defense against others' bad code more than something to help your own.

anon
Thursday, July 10, 2003

The problem with other peoples code is in this modern world of multi-tier objects being called by scripting languages and web services you have to be robust and not crash that shared component.

So if your program language is "untyped" then your unit tests MUST test what happens if you pass a string into a parameter expecting a number, otherwise someone will pass the wrong thing in (either on purpose or not) and your software will crash or do the wrong thing.

Having written code where we exploited the weak typing of object/variant in VB 5 & 6 and then had to deal with the bugs this caused (Usually down to duff data in) we now use interfaces to clamp down in all new code.

Those who say it doesn't matter haven't yet been burnt.

Peter Ibbotson
Thursday, July 10, 2003

btw, I agree typing is nice to give the compiler more information so it can optimize your code; this is why I hope Python eventually has optional type declarations, like Common Lisp.

anon
Thursday, July 10, 2003

Eckel makes some interesting points.  But one problem with his argument that comes to mind is that it relies on perfect testing.  Now obviously we should strive for perfect testing.  However, I don't know about you, but I have never ever seen a piece of software with zero bugs.  This means that software didn't have perfect testing.

Without perfect testing, Eckel's argument sort of goes down the drain. 

Another thing that he didn't point out is that with a weakly typed language you need MORE tests.  In a strongly typed language your tests can be constrained to valid types for input, since the compiler won't let you do anything else.  For weakly typed languages though, you must also test a variety of improper inputs.

Furthermore, if you are developing shared code (ie a library) you are pushing the burden of type checking and testing onto your users.  On the other hand, with a strongly typed language, you can (with enough testing) virtually guarantee that any input that compiles will not break your library.

Mike McNertney
Thursday, July 10, 2003

Which is easier and safer, using strongly typed parameters for a method, or writing an assertion for every loosely typed parameter?

The compiler is there to help you write bug-free code.  Every condition that isn't checked at compile time is a condition that must be check at run time by you.

Dave
Thursday, July 10, 2003

I think the folks who are arguing that static typing finds problems that might otherwise be missed, are themselves missing a point: if the productivity gain of dynamic typing is greater than the loss, then the smart business decision is to use the dynamically typed system.

Also, let's clarify our terminology.  A strongly typed language is one where objects/values are of a fixed type.  A statically typed language is one that requires variables, parameters, etc. to have their types declared in the source code.  A dynamically typed language is one that does not require such declarations.  A weakly typed language is one where values types are not fixed, and may be subject to interpretation.  Thus:

Java, C++: strong, static
Python: strong, dynamic
JavaScript, Tcl, Perl: weak, dynamic

There is a big difference between weak typing and dynamic typing.  In Perl, for example, a scalar variable can be interpreted as a reference, a number, or a string.  It doesn't have "type".  This is an example of "weak" dynamic typing.  In Python, all variables are objects, but at any given moment an object is of only one type.  It is not subject to interpretation.  That's "strong" dynamic typing.

Phillip J. Eby
Thursday, July 10, 2003

Phillip:

No, I understand that point, which is why I said that I'm undecided on static typing. It's often a pain in some languages (eg Java and C++), but others make it less so (eg Haskell and OCaml).

Unfortunately, the less painful languages aren't used much "in the real world", so I can't say I have real world experience to know whether the pain is small enough that the benefits win.

And the horse you rode in on
Thursday, July 10, 2003

Re: 'a defense against others' bad code more than something to help your own' (anon).

I am that bad programmer as well as the good programmer. That's why I litter my code with ASSERTs: they protect me from myself.

Likewise I prefer static typing, because it protects you from yourself.

The problems with static typing come when you need to change a declaration from one type to another, because you need to do more - er - typing to change it. However, changing the type of a variable or parameter tends to indicate that you haven't thought properly about the allowed type and range of values that the variable should hold or that the function should process.

Extreme Programming seems attractive, but I worry that the idea that you always refactor your code tends to mean that no design at all happens (which isn't suggested by XP, but people have interpreted it that way). It suggests time wasted refactoring something because the initial design wasn't right. Don't fear the code, but don't get complacent either.

Mike Dimmick
Friday, July 11, 2003

What I would like is an IDE that has nice little boxes where you can specify "hints" that get turned into unit tests or contracts.  For example, I can say that with fun(a,b), I want a>b.  Or String a and int b.

People have been trained to expect very little from their IDEs.

sammy
Friday, July 11, 2003

Philip, I understand the idea that the benefits of a dynamically typed language may offset the advantages of static typing.  It depends on the project.  I'm just not sure I agree with the way this is presented (that unit testing encompases static typing.  It sort of does, but not really.  What they are really trying to say is that unit testing in combination with other benefits of the language outweigh static typing).

I would also tweak your definition of static typing a bit.  Static typing does not require the types to be explitictly stated in code, it just means that the type checking is done at compile time.  Take ML for example.  It is definitely a staticly typed language, but it does this through type inference.  You don't have to declare what types your arguments are, for example.  But if you call a function with an argument that doesn't support the operations called on it, the *compiler* issues an error.  This is in contrast with dynamically typed languages where the *runtime* issues the error.

One other thing that nobody has mentioned is that C++ and Java are not completely statically typed.  Since you can cast a variable in a way that is legal at compile time but illegal at runtime, C++ and Java are sort of hybrid static and dynamically typed languages.

Mike McNertney
Friday, July 11, 2003

My experience in unit testing, first in Classic VB, some in Classic ASP, now in C# is this:

I don't feel I need more tests whatever the language. What I feel is that I no longer need the compiler supported tests.

Two things I like from my compiler/IDE: When it tells me I forgot to implement something (wouldn't it be nice if the IDE asked me if it should create it for me?).
The other is intellisense.

Most of the annoying compiler tests are issues about type casts. I have yet to see when this warning does something useful, because most of the time the compiler should see that an implicit type cast is valid, the other times nobody can, so only runtime will tell.

Thomas Eyde
Sunday, July 13, 2003

*  Recent Topics

*  Fog Creek Home