|
|
|
Sponsored Link •
|
Summary
My take on the debate of whether typing is needed in a language. Rather than taking sides, I revert to my previous incarnation as a philosopher, and try to see what we are really talking about when we seem to be talking about types.
|
Advertisement
|
Everyone seems to be getting their licks in on the subject of whether strongly typed languages are a good thing or not. So I thought that I would take my turn, and see if maybe this entry could cause a little less jerking of the knee and a little more firing of the neurons.
Like most of you, I have used all kinds of languages with all kinds of type systems. I've used weakly typed languages like lisp and smalltalk. I've used strongly typed languages where all types are checked at compile time like Pascal, C++, and Modula-3. My current language of choice is Java, which has lots of compile time checking but which also has a dynamic aspect (which I tend to use a lot) that sometimes makes it seem like a loosely-typed language. I've even written lots of code in COBOL, which has so many other quirks that it is hard to tell if it is typed or not.
I've also heard lots of arguments for and against strong/any typing. Types help you avoid errors, but also constrain your ability to evolve a program. Types let you see what is going on in the code, but they get in the way when you are trying to do rapid prototyping. Types give you important structure, but that very structure constrains what you can do in a program. I'm sure that there are lots of other arguments. I'm sure that I've presented these and others, since I've argued on both sides of the issue.
Quite frankly, I find none of these arguments completely convincing. The more I think about the issue, the more I think something else is going on here.
Back when I was studying philosophy, one of my favorite authors was John L. Austin, one of the founders of modern linguistic philosophy. One of Austin's great insights was that we do a lot more with language than simply state facts. We use language for ceremony ("How are you" is not necessarily a request for information), we sometimes use language to do things (when the minister utters "I now pronounce you man and wife", something is done, not claimed to be true or false). Many of the puzzles in philosophy, Austin argued, are based on confusing language that is doing something different with language that is making a claim about some fact about the world.
I have come to believe that the arguments over typing in a language are arguments of this sort. When we argue over whether or not a programming language should have types, we are not discussing a matter of fact. Instead, we are participating in what Austin would call confessional language; what we are really doing is saying something about ourselves.
In particular, I think that those who advocate typed languages are (generally) participating in different kinds of programming exercises then those who advocate untyped languages. In particular, people who argue for strongly typed languages tend to be involved in projects that are
On the other hand, people who like untyped languages tend to be involved in projects that
Now, before you post the tales of when you used an untyped language for a huge project with lots of engineers that lived forever and was changing all the time, or the equivalent tales of the small prototyping project you did in an afternoon that could only have been done in a strongly typed language, remember that my claim is one of tendencies, not of absolutes. Before getting all outraged, take a deep breath, perhaps a pill (or a drink), and get over it.
The point I'm getting to is that typing in a language is useful because it adds information and constraints to the programs that are written in the language. Looking at the signature of a method or function tells you more if the method or function is declared in a strongly typed language, and you can make more assumptions about the parameters and return values in such languages. But this information and these constraints also make it harder to do something quickly in those languages, since you have to add that extra information and abide by those constraints.
Which sort of language is best for the task at hand depends very much on the task at hand. If the overhead of strong typing (and there is considerable overhead) will be paid back over the life of the program by the added information and the built-in constraints, then a strongly typed language is your tool of choice. When the project is large, and involves a lot of people, or lives for a long time, that added information and those extra constraints pay off in the long run. But for a quick afternoon project, or one in which you are exploring and changing the rules as you go, the added information and the constraints just get in the way.
Of course, once you get really proficient with one style of language or the other, the overhead involved in changing languages trumps the overhead of typing or not. If you are used to a strongly typed language, then you think that way even when you are doing rapid prototyping or small projects, and the extra overhead is negligible. If you are used to working in an untyped language, you are used to filling in the extra information (either in comments or just by reading the code) so the extra structure seems unnecessary. The end result is that the debate become religious. While entertaining, it rarely leads to a conclusion.
So the next time you find yourself in the typed vs. untyped debate, ask yourself if you are really talking about the programming language or yourself. You may just be confessing your own history, and the person with whom you are arguing is probably doing the same. Given that you are both probably right about your pasts, there is really no disagreement, and hence there will be no resolution.
Have an opinion? Readers have already posted 17 comments about this weblog entry. Why not add yours?
If you'd like to be notified whenever Jim Waldo adds a new entry to his weblog, subscribe to his RSS feed.
 | Jim Waldo is a Distinguished Engineer with Sun Microsystems, where he is the lead architect for Jini, a distributed programming system based on Java. Prior to Jini, Jim worked in JavaSoft and Sun Microsystems Laboratories, where he did research in the areas of object-oriented programming and systems, distributed computing, and user environments. Before joining Sun, Jim spent eight years at Apollo Computer and Hewlett Packard working in the areas of distributed object systems, user interfaces, class libraries, text and internationalization. While at HP, he led the design and development of the first Object Request Broker, and was instrumental in getting that technology incorporated into the first OMG CORBA specification. |
|
Sponsored Links
|
Digg
del.icio.us
Reddit