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
large, with lots of interacting components;
require multiple people to work together;
will take a long time to develop (weeks or months, not hours); and
will live for a long time, changing over that time.
On the other hand, people who like untyped languages tend to be
involved in projects that
require lots of prototyping;
are done by one person, or a small group of people;
tend to be small or short term; and
often are used for a short period of time, or are not altered
through their lifetime.
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.
Out of curiosity, have you ever tried a language with a good (i.e. Hindley-Milner) type inference system like Haskell or Standard ML? I think they have a good balance between safety (because the type system is sound) and rapid development (because the vast majority of the time the compiler can type-check a program without your writing any explicit types). What do you think?
"people who argue for strongly typed languages tend to be... people who like untyped languages tend to be... Now, before you post the tales of..."
Here we go again... We've gone from making a direct claim that statically-checked languages pay off in the long run for "huge" projects, to an indirect claim that the folk who argue for statically-checked languages tend to be involved in "huge" projects (join the dots).
(Could it just be more difficult to overcome the intertia of doing things the old way on "huge" projects?)
We're still asserting the superiority of statically-checked languages for serious programming, while damning dynamically-checked languages with faint-praise - they'd be fine for making prototypes.
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. And here's the crux - does static-checking really pay off?
For non-stop, soft-real time, long-lived, high-capacity applications dynamically-checked Erlang seems to be an excellent choice.
The unfortunate aspect of this static-checking vs dynamic-checking confrontation is how much it drowns-out other significant differences between languages. For example, in Erlang: - variables are dynamically checked
and there are other significant design decisions - all variables are local (no global variabes) - a variable can be bound only once (single assignment) - no explicit memory management (no new, no dispose)
I think you have a point, to an extent. I think many arguments about typing have to do with who the arguers are. However, I also think that the winds of change are blowing.
My thesis is that the next great wave of languages (after the .Net wave crests) will be more dynamic than the last three waves (C++, Java, .Net).
I am not arguing from my history, since I am an old C++ hacker who has written more statically typed code than dynamic code by a factor of at least four orders of magnitude. My argument comes from a different vantage.
The benefits of strong typing cannot be denied. You listed them, and I won't repeat them here. However, there is another way to get all those benefits. Unit tests.
Test Driven Development is not going away. More and more developers and teams are adopting it. And as they do, they slowly realize that the advantages of strong static typing are dilluted by the tests they are writing. This dilution changes the balance.
Whereas before there was a strong argument to use a statically typed language in a large system with many developers; the arguments are weaker if the developers are practicing TDD; and the benefits of dynamically typed languages are therefore more attractive.
As the balance changes, more and more teams will move towards dynamically typed langauges. Language designers will add more and more dynamically typed features to current statically typed languages.
Whereas before there was a strong argument to use a statically typed language in a large system with many developers; the arguments are weaker if the developers are practicing TDD; and the benefits of dynamically typed languages are therefore more attractive.
Would you say that TDD and dynamic typing has the effect of moving some of the contract of a method from the method definition to the test?
The benefits of strong typing cannot be denied Depends which paragraph we read: "Quite frankly, I find none of these arguments completely convincing."
You listed them, and I won't repeat them here. However, there is another way to get all those benefits. Unit tests. Let's see, if: "Types help you avoid errors... Types let you see what is going on in the code... Types give you important structure..."
How do unit tests help avoid errors? How do unit tests let you see what is going on in the code? How do unit tests give you important structure?
> Here we go again... > > We're still asserting the superiority of statically-checked languages > for serious programming, while damning dynamically-checked > languages with faint-praise - they'd be fine for making prototypes.
Yes, that is Jim's result, if not his intent. I agree with Jim's article insofar as arguments for and against typing do tend to confessional speech acts rather than statements of fact. Brian Marick has written about this idea on the more general topic of software methodology:
But Jim's final conclusions imply that dynamic typing is the weak stepsister to industrial strength static typing.
And Uncle Bob may be right: if we get the benefits of static typing from a practice that offers other benefits, too -- unit tests -- then maybe folks won't feel the need for static typic so much. Paul Graham has also argued that language design is adopting more and more of the dynamically-typed world's language features for the last couple of decades...
Right off the bat I stopped reading when you characterized lisp and smalltalk as weakly typed. They are no such thing. They are strongly dynamically typed.
Weakly typed would be something like C - where there isn't enough information to figure out what a chunk of memory contains and any given chunk of memory can be interpreted differently. Things like unions and C pointers are the epitome of weak typing.
OTOH, Smalltalk and Lisp don't bother to type their references (you know - variables) but given any reference it is always possible to know exactly what it references and the system will never crash as a result of misusing that reference (instead a nice error handling mechanism kicks in and helps you fix your program).
Java, is a strongly statically typed language - C++ is a weak statically typed language (although stronger than C, it inherits many of C's warts including a dearth of meta information allowing catastrophic failure for simple programming errors).
This debate is never going to go away until people start using proper terminology.
Or we could choose some definition: "the strict observance of either or both of these techniques (sic static or dynamic checking) leads to strong typing, intended as the absence of unchecked run-time type errors" p3 http://citeseer.ist.psu.edu/cardelli89typeful.html
OTOH, Smalltalk and Lisp don't bother to type their references (you know - variables) So, some might say they are untyped and safe, in contrast to C - typed and unsafe. p5 http://citeseer.ist.psu.edu/cardelli97type.html
One more argument for strong typing: weak typing also means late binding which also means poor perfomance. Even in small amateur chess engine project you will never be satisfied with weak typing language.
> Whereas before there was a strong argument to use a > statically typed language in a large system with many > developers; the arguments are weaker if the developers are > practicing TDD; and the benefits of dynamically typed > languages are therefore more attractive. > > Would you say that TDD and dynamic typing has the effect > of moving some of the contract of a method from the method > definition to the test?
I suppose, in a way, the contract of a method is implied by the unit tests.
> Let's see, if: > "Types help you avoid errors... > Types let you see what is going on in the code... > Types give you important structure..." > > How do unit tests help avoid errors?
When you write the tests first, you must think through the methods that you are testing, before you write them. You continue writing test cases and making them pass until you can't think of any more to write. Any errors covered by those test cases have been avoided.
> How do unit tests let you see what is going on in > the code?
If you want to know how to create an object, there is a unit test that creates it. If you want to know how to call an API, there is a unit test that calls it. Every action that can be performed in the code is performed *first* in a unit tests. The unit tests are living examples of how to use the code.
> How do unit tests give you important structure?
In order to test a unit you must isolate it from other units. Therefore you must manage the dependencies surrounding that unit to keep it isolated. A testable unit is a decoupled unit. Moreover the tests show you how the unit is decoupled. If you want to know the "types" of the input variables or the "types" of the return values, or the "types" of the associated objects, the tests will tell you.
> One more argument for strong typing: weak typing also > means late binding which also means poor perfomance. Even > in small amateur chess engine project you will never be > satisfied with weak typing language.
You might be surprised. Late binding need not be any slower than static binding. Indeed, it can sometimes be faster. The reason is that late binding has more semantic meaning that static binding does. To simulate the semantics of late binding in a statically bound language you have to use if or switch statements, or a jump table.
I like Uncle Bob's comments about TDD. I'm also interested that no one has commented about Ravi's query about use of type inference systems.
In my experience, the value of statically typed languages (whether using type inference or requiring manual type specifications) is that they remove one category of errors before the program is executed. Writing tests does the same thing, assuming you write the tests correctly as well. I typically prefer to spend my energy writing them from a functional perspective, and leave the mundane mechanics of preventing me from adding a string to an integer to the type checker.
A strong value of type inference is that it eliminates the need for the programmer to write the type specifications themselves. That said, in my experience, once I start writing a moderately complex programs, I use type specifications as a form of documentation - about how the (parts of the) program should behave in certain situations. Writing tests serves the same purpose - documentation about how the (parts of the) program should behave in certain situations.
A major use for static typing is when gluing together multiple modules or routines from libraries. At the moment, it is very rare for people to distribute their unit tests with their libraries. (I'd love it if they did.)
Even if they did, although they may have written lots of great tests, they may never have put one in for the way I choose to use their routine. For certain categories of my use of their routine, a static type system will report an error before I even execute it. Of course, if I write a complete set of tests, then I will have the same effect. However, I am then reliant on being able to create a complete set of tests a priori. Usually I find that the number of tests is not sufficient for the number of ways that the program may break, and when it does, I then need to add more tests.
In summary, it doesn't hurt to have both in place - in fact it benefits you. Static typing will eliminate a certain category of tests from needing to be written, thus saving time. It doesn't obviate the need to write tests however.
Getting back to Jim's original post - his assertion that strong statically typed languages are slower to develop rapid prototypes in - I think is also missing the point. The key to developing code rapidly is using a programming language with fewer average lines of code per function point (e.g. Perl, Smalltalk, ML) than ones with more (e.g. C, C++, Java). Most research that I know of (McConnell in Rapid Development is a great summary) says that average programmers write the same number of lines of code a day, regardless of the programming language. So choose one which has fewer lines and you'll develop faster. Other than that, I thought Jim's analysis was great.
Flat View: This topic has 17 replies
on 2 pages
[
12
|
»
]
Previous Topic
