Looking back over my blog posts, my recent obsession has been much more about lazy, concurrent, asynchronous, and deferred computation rather than just static typing. Unfortunately, the trick with asynchronous computation in all of it’s form is less expressing the asynchronicity, so much as expressing it correctly. To my knowledge, asynchronous computation is by far the hardest thing programmers are doing right now.

And one of the reasons it’s so hard is that it is very easy to write code that mostly works, and only occasionally doesn’t. Which is why, of the two main ways we have to validate code correct (testing and typing), testing is useless in the face of this problem. Unless you’re willing to have unit tests that take days to run (yes, I have had to track down race conditions that only happened once every several days, even under extreme test loads). Typing, on the other hand, being the country cousin of code correctness proofs, has a lot of promise in attacking the problem. But it is very easy, in my mind at least, to make the argument that static typing is necessary (even if not sufficient) to solve the problem. So any deep post I do make is liable to have static typing as a prerequisite, either implicitly or explicitly.

Another point I will make is that typing is, itself, a deeper subject than most programmers know. I’ve been kind of reluctant to delve into the subject in a deep way myself, because I know how little I really know about the subject. But here’s a little something to whet your whistle on the subject, and maybe make you stare off into space a little bit. Consider the type ‘a -> (’a -> ‘b) -> ‘b. There are two ways to interpret this. One is as an (Ocaml/SML style) type- this is the type of a function that takes an argument of type a and returns a function that takes an argument of a function that takes a type a and returns a value of type b, and returns a value of type b.

Another way to read this is as a statement in propositional logic: if statement a is true, this implies that if statement a implies statement b, then statement b is true. Here, the -> operator means “implies”, not “function type”. By constructs like this, it can be seen that every correctly typed program is, by looking at it in a different way, a proof in propositional logic.

After digesting this for a bit, it should come as no surprise that the “patron saints” of functional programming- Alonzo Church, Haskell Curry, etc.- weren’t studying programming or computation, they were studying the foundations of mathematical logic.

Brian, take what you will from my post, but my intent was to suggest that we stop talking about this exact subject (static typing, unit testing, both, neither) and start taking about what makes programs *good*.

I admit, on a banal and trivial level, not having “typing errors” is a desirable thing. But Brian, of your whole brain, I suspect less that 1/1,000,000th of 1% is devoted to eliminating these errors. So when I read this post, I am thinking, “I am missing nearly all of Brian’s thoughts about great software.”

Now of course, we can fire up the flames and say “not having typing errors is neither banal, nor trivial.” But we would be confusing the necessary with the sufficient. It is necessary that we eliminate such errors. But it is not sufficient to write great software.

I exhort you both (yes, you too my friend Obie) to burn your bras… err… blankets and get back to the stuff that’s exciting. The stuff that’s deep. To writing posts that will make me drop what I’m doing and stare into space while mulling over your ideas.

Dan: if you want to have real fun, grab an open-source C/C++ project, and then turn on all warnings. Not just the default ones, not just the -W -Wall ones (there are dozens of optional warnings GCC has that are not turned on by -W -Wall), all of them.

Brian

In my experience, the amount of testing and enthusiasm required to maintain the TDD discipline is overwhelmed by the level of ambiguity in dynamic languages. It’s one of the strongest reasons that I prefer statically-typed languages.

How do you see the compiler’s type warnings as dampening the testing/enthusiasm? I’m looking for practical examples out of your experience here. I’ve never encountered this claim before, and I’m really curious about it, because it is so out of whack with my experience.

The average programmer ignores the feedback from the compiler completely, as well as feedback from unit tests and type information. For most programmers if nothing outright prevents the program from running they consider it good.

If you doubt me on this, grab any open source project out there, run through it’s build procedure, and see if you can even keep up with the amount of warnings generated by the “safety blanket”. Very, very few development teams seem to care what the compiler says.

My opinion is that strong typing, Ocaml style or otherwise strictly enforced, is one of the best first steps to proper code and bug prevention because it *prevents execution* if there is an error. It can’t be ignored and passed down the line until it is fixed.

For projects, the best practices should involve using a strongly typed language and requiring a *clean* unit test run before packaging. This won’t prevent bugs, but it is a good start on preventing obvious bugs, leaving more developer time for dealing with the less obvious bugs.

Static typing, in a language with a good type system (by which I explicitly exclude Java, #, C++, and Pascal, and instead mean languages like SML, OCaml, and Haskell) can check for more errors, and more subtle errors, than most people suspect. It can be used to enforce constraints like “you can not ansynchronously read a file descriptor opened for synchronous I/O” or “a Postgresql cursor may not be used outside of the transaction it is declared in” (both of these I’ve seen enforced in Ocaml). And when it gives a gaurantee, it means it. And when the constraint is violated, the compiler tells you exactly where- file, line number, even what columns are the problem. I’ve occassionally seen Ocaml be 20 lines off (where the problem really was was 20 lines away from where Ocaml thought the problem is), but 99% of the time it’s dead on. It’s a great advantage to debugging, let me tell you. And it comes free with your language.

But you’re right that it doesn’t catch all errors. Neither does. Neither does the combination. But the more errors are caught, and sooner, the better.

The professionals I know working with Java and .NET are practising test driven development and continuous integration.

And yes, TDD doesn’t catch all bugs either, but at least you can add regression tests when you find some. Oh, and it’s automated. That’s also good.