Dynamic Languages Permit and Benefit from Multi-Type Variables
written by Peter William Lount
August 13th, 2004
Version 1, 12:21pm PDT

In Type errors in Dynamic Typing "verbat" comments:


First off the "nil" object does understand numerous messages so sending it a message isn't an error. In fact "nil" objects play an important role in Smalltalk based programs enabling existance based logic.

In Smalltalk we often use multi-type variables with nil being a valid value for the variable. For example:


In languages that don't support multiple types per variable this type of compact existance logic isn't possible. In C you'd need to use two variables, one for a flag and the other for the value. Why? Because when you define a variable in C or Java it can only be of one type. Actually C does allow casts for variables and unions for structures but both are generally considered bad programming style.

In many ways Smalltalk preserves the freedom of Assembly Language by having untyped variables. Languages like C, Java and other typed variable languages implement "declarative" style programming that "constrains" the variables to particular types thus robbing the programmer of the possibilities opened up by untyped dynamic variables that can take on multiple types.

The benefits that open up when variables are unconstrained from declarative type restrictions are powerful dynamic run time flow control choices, multi-type variables, existance based logic, extensible runtime type safety validations with full semantic expressiveness of the langauge, less time coding, more focus on the solution than being hindered by the tools, more compact programs, applications that can actually run faster than statically typed systems, less code thus potential for less bugs, plus many more... Typically during development messages do get sent to objects that don't understand them, and yes this includes commonly messages sent to nil.

The tools, specifically the Smalltalk debugger, enable you quickly find out why. Often it's that you might have forgotten to write a method. This is actually a feature for rapid development in that you can keep going fast with what's flowing in your mind and focus and fill in the rest as needed or later on. Think of this style of rapid pace as just in time programming via the debugger. It's often said that some Smalltalk programs were written mostly in the debugger and this is why! The debugger is more than a debugger, it's the live program with it's internals revealed and can go in and make changes and have it start that method over without having to completely restart the program!

Sometimes a program needs to have a few class or type or data validations inserted to cover cases where it's actually appropriate to have those kinds of restrictions. One way to learn about these is during development and testing. I would agree that a finished program needs to have a high enough quality that prevents or catches unintended #doesNotUnderstand runtime errors. Naturally if a program is having lots of these it's either not been designed well, or really hasn't been tested enough and likely was rushed.

It's interesting to note that the use of implementing #doesNotUnderstand on a class is a powerful way of enabling it to deal with messages it doesn't understand in unqiue ways. A simple yet highly remarkable example is it's use on a proxy object class that will forward valid messages to the object the proxy is standing in for. Try doing that in a typed variable language!

Smalltalk is a language that is highly extensible. It allows you to build your own custom language capabilities within it's range of expandability - which is much wider and thus more powerful than typed variable languages. In Smalltalk you can customize your variable type validations at runtime when they are the most flexible and you can implement your own control structures, both within minutes. This flexibility enables solutions to be fine tuned to their target applications and systems.

Smalltalk is also not standing still. There are a number of variants being developed that evolve the language further to access additional dynamic power. The Zoku variant of Smalltalk that I'm developing takes these ideas further and opens up additional areas of expandability while retaining the simplified syntax. While "static" and other typed variable languages keep users and their programs chained to the illusion of "type safety" systems like Smalltalk and Zoku are evolving to meet the real world needs of application and system developers.

"Type specification declarations" occasionally have their place in that they present a "simplistic" view of data and program interfaces that many find conforting. As we progress into the future the pace is quickening and there won't be time to get muddled in the extra details and code created in programs that over use type constraints.

Coming back to Verbat's question:
I think that the answer is clear. The so called time saved isn't worth it as there are compelling benefits to programs and systems that use untyped dynamic variables that superceed the limited methodology and benefits of "typed variables" languages. When varaibles truely need to be constrained they can be using runtime type safety validations that are written in the full semantic power of the Smalltalk langauge.

Programming in a pure object languge like Smalltalk obviously isn't as simple as removing the type restrictions from variables. It can take three months to half a year or more for people to "grok" Smalltalk's style of programming. I've had clients that I've mentored come to me a month into their first Smalltalk project and say "wow, I get it, I'm able to focus 90% of my concentration and efforts on my application domain rather than on computer science!". It took that developer a while longer to fully appreciate the nuances of the language and why you benefit from the variables being untyped, and how to really apply it to his application and take advantage of it. Old habbits and thinking styles can take a while to change. Download a version of Smalltalk and learn a new style of thinking. Liberation awaits. Once you've taken the red pill of dynamic freedom you won't go back willingly.

---

Copyright 1999-2010 by Smalltalk.org™, All Rights Reserved.