The Artima Developer Community
Sponsored Link

Weblogs Forum
To type or not to type

17 replies on 2 pages. Most recent reply: Mar 15, 2004 10:39 PM by Gregg Wonderly

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 17 replies on 2 pages [ 1 2 | » ]
Jim Waldo

Posts: 34
Nickname: waldo
Registered: Sep, 2002

To type or not to type (View in Weblogs)
Posted: Feb 27, 2004 5:50 PM
Reply to this message Reply
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.


Ravi Nanavati

Posts: 1
Nickname: nanavati
Registered: Feb, 2004

Re: To type or not to type Posted: Feb 27, 2004 11:33 PM
Reply to this message Reply
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?

Rick Kitts

Posts: 48
Nickname: rkitts
Registered: Jan, 2003

Re: To type or not to type Posted: Feb 28, 2004 9:43 AM
Reply to this message Reply
I see no reason to ruin a perfectly good religious debate by introducing a rational and considered point of view.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: To type or not to type Posted: Feb 28, 2004 10:03 AM
Reply to this message Reply
"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?


"Four-fold Increase in Productivity and Quality Industrial-Strength Functional Programming in Telecom-Class Products"
http://citeseer.nj.nec.com/wiger01fourfold.html

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)

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: To type or not to type Posted: Feb 29, 2004 9:16 PM
Reply to this message Reply
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.

Chris Dailey

Posts: 56
Nickname: mouse
Registered: Dec, 2002

Re: To type or not to type Posted: Mar 1, 2004 8:10 AM
Reply to this message Reply
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?

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: To type or not to type Posted: Mar 1, 2004 8:36 AM
Reply to this message Reply
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?

Eugene Wallingford

Posts: 1
Nickname: wallingf
Registered: Jan, 2004

Re: To type or not to type Posted: Mar 1, 2004 8:40 AM
Reply to this message Reply
> 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:

http://www.testing.com/writings/process-and-personality.html

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...

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Lost me in paragraph 2 line 2 Posted: Mar 1, 2004 3:23 PM
Reply to this message Reply
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.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Lost me in paragraph 2 line 2 Posted: Mar 1, 2004 5:08 PM
Reply to this message Reply
This debate is never going to go away until people start using proper terminology

Maybe we should go back to school for some proper terminology:

'So what is “strong typing”? As best as we can tell, this is a meaningless phrase, and people often use it
in a nonsensical fashion.' p205

Programming Languages: Application and Interpretation
http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/


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

Eugenijus Drabuzinskas

Posts: 1
Nickname: eudra
Registered: Mar, 2004

Re: To type or not to type Posted: Mar 2, 2004 7:48 AM
Reply to this message Reply
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.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: To type or not to type Posted: Mar 2, 2004 3:12 PM
Reply to this message Reply
> 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.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: To type or not to type Posted: Mar 2, 2004 3:17 PM
Reply to this message Reply
> 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.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: To type or not to type Posted: Mar 2, 2004 3:24 PM
Reply to this message Reply
> 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.

Peter Bailey

Posts: 1
Nickname: pbailey
Registered: Mar, 2004

Re: To type or not to type Posted: Mar 3, 2004 10:34 PM
Reply to this message Reply
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 [ 1  2 | » ]
Topic: How Mortal These Fools Be... Previous Topic   Next Topic Topic: One Assertion Per Test

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use