Based on the tarball available from a qmail.org mirror, all of the source used to compile qmail (along with tcpserver and daemontools) seems to be all C... thus rendering it quite compact and fast.

Blender 3D uses Python for API and scripting and is available on numerous platforms.

> You **cannot** pass a wrong argument to a function in a
> stong-type language

Of course you can. This is a common misconception. There are afew reasons. This happens when the type system doesn't allow you to specify a precise enough constraint on the values. For example you might divide by zero "divide(100, 0)" or take the square root of a negative number "sqrt(-1)". These function essentially must do runtime checks. Another case is when programming with component and collection frameworks. You may want to contraint a collection to say a map from integers to strings but of course, in languages like Java you can add incorrect elements to the collection. Whenever you have arguments of type Object, you have a problem. Another case is when using some variant of the factory pattern: your factory make be given a string 'factory = new Factory("java.lang.Int")'. It will use the string to find a Class and then use that to create instances. In this case I have used a wrong argument but javac would not complain. You get my drift.

Lisp (i.e. Common Lisp) has optional manifest types. Scheme is more like Smalltalk - not having manifest types.

I've kind of missed the debates I used to have about this (ex COBOL, C, C++ programmer in the '70s and 80's - saw the light doing Smalltalk in the early '90s, now doing Java). One thing I've noticed is usually the proponents of weak (I mean run-time) type checking have tried developing with both types of languages and have made a choice while the proponents of strong (I mean compile time) have only used languages with no checking (like C) with bad results, switched to compile time checking (like C++ or Java) and had better results and have never actually developed with run-time checking. They are confused about what is really going on and imagine disastrous things happening. In fact, the disasters don't actually happen. I have my own theories about why not but have no way of proving or disproving them.

While using Smalltalk I did have some type errors which were caught at runtime but not not nearly as many as you would think if you counted the number of compile time type errors I get in Java and assumed they would be equal. This is thoroughly tested Smalltalk code in large quantities, not something small or flaky that could be claimed to have a lot of bugs that just weren't discovered yet. Also, I honestly can't remember even once that a bug that was discovered in testing turned out to be a wrong type that wasn't caught by the run-time type checking. I was not only more productive at writing code, but also it seemed to have fewer bugs of any kind than when I developed in other languages. My guess is that it was because I was able to concentrate more on what I was doing as opposed to keeping a compiler happy. Most of my type mistakes caught by the Java compiler I think are less because I had an unclear notion of what type I was passing and more because I make some silly mistake in tediously explaining and reassuring the compiler that I know what I'm doing. A brain, mine at least, can only deal with so many things at once and I suspect that by not being distracted by satisfying a compiler (that has a very simple-minded way of trying to check correctness) I was able to keep my real intention in mind and actually made fewer type mistakes. And those I did make were successfully caught during run-time testing.

> One thing I've noticed is usually the proponents of
> weak (I mean run-time) type checking have tried developing
> with both types of languages and have made a choice while
> the proponents of strong (I mean compile time) have only
> used languages with no checking (like C) with bad results,
> switched to compile time checking (like C++ or Java) and
> had better results and have never actually developed with
> run-time checking. They are confused about what is really
> going on and imagine disastrous things happening. In fact,
> the disasters don't actually happen. I have my own
> theories about why not but have no way of proving or
> disproving them.

Well, I'd have to disagree with that generalization. I started with Java, fully embraced Python for several years, and now that I've had a chance to think about it, I'm on the static typing side - that doesn't mean I'm back Java, though! I was always irritated at Java's type system - the glaring holes (casts, e.g.), and the excessive finger typing. I switched to Python and never looked back. Free at last!

But then I realized something: Java and C++ are not the last word in static typing. Modern static typing involves very little finger typing (sometimes none), while providing stronger static checking than C++ or Java provide. There's nothing saying that static typing has to mean code like this:

SomeLongName foo = new SomeLongName();

The same thing in Nice ( http://nice.sourceforge.net ) would look like this:

let foo = new SomeLongName();

or maybe you'd like this:

String[] strings = new String[] {"one", "two", "three"};

reduced to this:

let strings = ["one", "two", "three"];

Doesn't look much different from Python, right? But this is statically typed code.

The compiler can very well figure out for itself what the types of foo and strings should be, it shouldn't need me to tell it explicitly. I think we should more from our compilers, rather than giving up on static typing out of disgust with C++ and Java.

> While using Smalltalk I did have some type errors which
> were caught at runtime but not not nearly as many as you
> would think if you counted the number of compile time type
> errors I get in Java and assumed they would be equal.

Yet many new Haskell users are shocked and amazed to find that in many cases, if the compiler will accept their code, it runs correctly on the first try. These people don't receive runtime type errors at all. They don't have to write tests to catch them, they just don't have to worry about a whole class of errors. This is a much stronger guarantee than you are probably used to from Java/C++.

I'm not proposing that static typing is a replacement for testing, but it's a valuable tool that we shouldn't be so quick to throw away. See my article "Modern Static Typing: Less Code, Better Code" at http://www.xoltar.org/misc/static_typing_eckel.html for a more detailed statement.

> Also, I
> honestly can't remember even once that a bug that was
> discovered in testing turned out to be a wrong type that
> wasn't caught by the run-time type checking.

Sure, we're not talking about bugs that can't be caught by run-time checking, we're talking about not waiting until runtime to catch them.

> My guess is that it was because I was
> able to concentrate more on what I was doing as opposed to
> keeping a compiler happy. Most of my type mistakes caught
> by the Java compiler I think are less because I had an
> unclear notion of what type I was passing and more because
> I make some silly mistake in tediously explaining and
> reassuring the compiler that I know what I'm doing.

Fair enough. You need a smarter compiler! You might try Nice http://nice.sourceforge.net , Haskell http://www.haskell.org , or Ocaml http://caml.inria.fr . There are many others also, but these are the ones I'm most familiar with.

I came upon this old thread and it got me thinking again. First, I wondered if it counts as a conversation if it takes me over a year to reply? It will just be me talking to my self by now, but it won't be the first time. :)

I stand by my generalization that the majority of opinions I've seen expressed over the years have been uninformed ones. Yours would be the exception in that you seem to not only have experience working in different languages, but that experience is broader than mine. I read your article on Modern Static Typing and it causes me to refine and restate my opinion: Static compile-time type checking as I've experienced it in C++ and Java is enough of a nuisance that I question if it is worthwhile.

I am all for the idea of compilers detecting and informing me about errors as early as possible. What I don't like is the amount of finger typing, syntactic clutter, and mental distraction from the real problem required in those particular languages just to placate a compiler that should be able to figure out most type information on its own. One of the features being contemplated for Smalltalk when I last used it years ago was the option of providing explicit type information that the compiler could use to check for errors and for optimization. I don't know where that ended up but maybe it was a workable compromise, or maybe the type system in one of the other languages you mention will inspire the next mainstream language.

Anyway, if intelligent type checking at compile time can be accomplished without the amount of effort I have to put into Java code, that would be great. And in any case, because of Smalltalk I have lost my fear of leaving it until run-time.

Static compile-time type checking as I've experienced it in C++ and Java is enough of a nuisance that I question if it is worthwhile.
And we understand that this may be a specific problem with the C++ and Java implementations, or a more general problem with static type checking.

-snip-
just to placate a compiler that should be able to figure out most type information on its own.
So take a look at some languages where the compiler tries to figure out most type information on it's own! You're familiar with Java, so take a look at Nice - just having method-local type-inference can remove a lot of clutter.

I've found two ideas I would like to discuss:

* "Static type checking is only intended to quickly detect errors, in compile-time". The type checking is also information for the developer in order to figure out what the method that he is using is supposed to do, and what it is supposed to expect as arguments. Following that sense, the errors are quickly cleaned even before the compile-time, because the programmer adopted the conventions explicitly expressed in the method signature. And it also saves developers time figuring out the arguments any method needs, and how it needs them. The same when you are reading code not written by you, without static typing you often find yourself wondering what kind of data the variable "a" is transporting.

* "Strong testing vs strong typing". The testing is supposed to find the errors that the strong type checking is not detecting. Ok, I like JUnit testings and find them useful and convenient, but they burden the developer with an important aomunt of typing also. And the very important point: they are not explicit! No automatic IDE can use them to help the developer to correctly use the methods and classes, or to automatically generate Javadocs.

Although I find problems in the verbosity of Java, I keep thinking that "static type checking is your friend". Even I think current static checkings are poor, and more automatic checking would help developers in their work.

For instance, Java lacks "const" keyword as in C, C++. That makes using "unmodifiable collections" a nightmare. And consider how many articles recommend you to code your methods to aggressively test that the arguments are not illegal (not null, greater that 0, with at least one element, ...). Static checking conventions would not only remove the possible errors, but also effectively inform other developers how to correctly use the methods.

I'm sure that the future will bring many more static checking conventions, and that they will make developers life easier.

Really late to the party, but it seems to me that static typing is best for projects where the developer count is high and inter-developer communication is limited ( like corporate IT ), but dynamic typing is better for a single developer or a small team in close contact ( OSS or scripting ).

Because the API *is* the most important semantic communication, and static typing conveys more information.