Smalltalk Tidbits, Industry Rants

Comment by Dennis Smith

I would like to ask the "compile-time-type-checking" proponents a question I asked a group in another context the other day. "Where do you think things will be in 100 years? 1000 years?" -- do you think "Mr. Spock" would have to tell the enterprise computer the types of each piece of data he is going to work with? How about we let the computer handle it -- then it can decode what is reasonable -- at run time, think about the added flexibility that would give, and has given (in fiction in the future).

IMHO, there is so much confusion on typing because it is a multi-dimensional issue which people often "flatten". Perhaps we can develop a tutorial? Perhaps there already is one, or subsets that can be merged? I started out this response writing such a thing until I realized what a huge and complex topic it is. It needs lots of examples in lots of different languages. Here is my starter set of issues, while I go off and research.

• Dynamic typing vs. Static typing
• Variable carries type vs. Value carries type
• Strong typing vs. Weak typing
• Manifest typing vs. Inferred typing
• Explicit type conversion vs. Implicit type conversion
• Allow casting vs. No casting
• Monomorphic typing vs. Polymorphic typing
• Mutable variables vs. Immutable variables

The bottom line:
Programs should be easy for a human to write and read. The resultant program should be safe, correct and fast enough.

All forms of typing have tradeoffs. Different languages suit different purposes. And we always prefer the one(s) we know.

James: "Strong typing has nothing to do with..."
Richard was certainly unwise to use a meaningless term, 32 months ago - no wonder his comments became confused.

James: "nothing to do with... compile time or runtime ... you can't get a type error... you'll get a well understood exception."
These comments are just as vague and misleading as the ones Richard made - what distinction are you making between type error and well understood exception, that doesn't have something to do with compile-time and run-time?

This bad terminology was understood and fixed years ago:

Allen, the only problem I see with your remarks is that the type theory community has co-opted the term ``strongly typed'' to mean ``statically typed.'' I believe the term they use to refer to the notion you (and I) call ``strongly typed'' is ``type safe.'' So, ST is a dynamically typed type-safe language. ParcPlace Type-Safety Discussion

I'm pretty sure Java is strongly typed -- type casts in Java are assertions, not actual casts. The static typing system isn't comprehensive, which is why it needs assertions to move between type-generic and type-specific code.

As Isaac pointed out, that thread is nearly 3 years old. You gotta love Shriram's comment on the PLT thread "The problem, as you indirectly note, is that this whole thread has FAQ status. There's nothing here that hasn't been said a million times on newsgroups and in classrooms." Incidentally, the language Richard's talking about is VBScript, not a C family language. The straw man Richard had set up is pretty weak; in Java, something analagous might be passing a BigInteger to a method accepting int. The compiler just makes you tell it to shut up by converting to an int, but the conversion comes with it's own problem, as documented, it just truncates the BigInteger a 32 bits.

After lots of Googling, two nice definitions surface:

http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?strong+typing

In a strongly typed language, conversion between types requires the use of explicit conversion functions as opposed to implicit type coercion


http://c2.com/cgi/wiki?WeakAndStrongTyping

What is the difference between a weak and strong type?

In a weakly typed language, the type of a value depends on how it is used. For example if I can pass a string to the addition operator and it will AutoMagically? be interpreted as a number or cause an error if the contents of the string cannot be translated into a number. Similarly, I can concatenate strings and numbers or use strings as booleans, etc.

In a strongly typed language, a value has a type and that type cannot change. What you can do to a value depends on the type of the value.

The advantage of a strongly typed language is that you are forced to make the behaviour of your program explicit. If you want to add a number and a string your code must translate the string into a number to be used as an operand of the addition operator. This makes code easier to understand because there is no (or less) hidden behaviour. However, it also makes your code more verbose.

The advantage of a weakly typed language is that you need to write less code. However, that code is harder to understand because a lot of its behaviour is hidden in implicit type conversions.

Strong vs. weak typing is comparable to static vs. dynamic typing. In a statically typed language, type checking is performed at compile time; in a dyamically typed language type checking is performed at run time. In practice, weakly typed languages are usually dynamically typed.

All languages can be placed somewhere in the 2D "typing" space whose axes are strong <-> weak and static <-> dynamic. E.g. types in SmalltalkLanguage are very strong, completely dynamic; types in PHP are quite weak, completely dynamic; types in LISP are completely strong, completely dynamic; types in C are quite weak, completely static; and so on...

Personally I think that if you have to use a cast then something is wrong in the design. If the language wont let you do what you need to do without a cast, then the language has a problem. I dont like having to cast, it's like banging the hampster through the star shaped hole. Very messy indeed.

Comment by Vincent Foley

I blogged (http://www.livejournal.com/users/gnuvince/64629.html) about the difference between dynamic, static, strong and weak typing. I hope this can help some people still in the dark about those issues.

How easily we forget change!

Oh sure you can make your code more verbose and your behavior more explicit by actually coding everything... and maybe it will be easier to understand (even in the face of papers that imply it's not the case).

But will strongly typed languages, and all their early decisions based on data that becomes more and more inaccurate as time goes by, be flexible enough to adapt to change that comes at an ever quicker pace?

I don't think the "language" life works on is strongly typed because it would force the being's workings to make all the decisions correctly when they're being done at random.

The last time I checked, It Just Does Not Work Like That.

Strongly typed languages, or languages where you have to explicitly declare the type of every distinction, are good for commandment tables. But it ain't necessarily so. Such monolithic pieces of software are, IMHO, forever doomed because of an intrinsic inability (or misdesign so that they are not suited) to cope with change.

Change happens. So our languages should be designed to be able to deal with change effectively.

I am hoping this truth will make developers free. Unfortunately, it will make them miserable first.

Alex: "After lots of Googling, two nice definitions surface..."
After lots of Googling, you may have noticed how many different definitions there are?

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. To some it seems to mean "The language has a type checker". To others it means "The language is sound" (that is, the type checker and run-time system are related). To most, it seems to just mean, "A language like Pascal, C or Java, related in a way I can't quite make precise". For amusement, when someone mentions the phrase "strongly typed" at a cocktail party, ask them to define it, then sit back and watch them squirm. And please, don't use the term yourself unless you want to sound poorly-trained and ignorant.
Programming Languages: Application and Interpretation, page 205