[ | smalltalk dot org ].
Community and industry meet inventing the future.
Validations Are Best Done At Runtime With Full Language Symantics
written by Peter William Lount
Version 1, 20040813 2:46am PDT

[Note: The latest version of this article is here.]

This article is a rebuttal to comments made about Here's to Dynamic Freedom. Please see the comments after James Robertson's blog entry Dynamic Freedom. Some people that posted comments possibly didn't grok the article's meaning fully for if they had it would be abundantly clear that when it's necessary runtime class, type and data validations can - and in practice are - performed limiting access to specific pathways throughout a program that is written in Smalltalk. Just in case I wasn't clear in the article I'll expand and reiterate.

First let's take care of the most mistaken of perceptions and conclusions created by black and white thinking that says that "type safety" can only be achieved via locked down "typed variables".

"Dunno what sort of world you're programming in... but lets see... four extra days of programming time versus losing $1,000,000 on that bank transfer... or not notifying the customer of their flight change... or landing that plane 4 metres BELOW ground level hmmmmm... in programming, safer == better. ALWAYS. Because the impact of extra programming time is known and controllable. The impact of an unexpected bug is NOT." - Darren Oakey

Ok, wow, Darren, sorry to say, your theory is backwards to some very real world spectacular working production systems! Also read on, dynamic untyped variable languages don't toss out "type safety", we embrace it when and if it's actually a needed requirement! This allows us to manage project development costs and implement tailored type safety mechanisms as appropriate using the validation extendablity of Smalltalk! This is a matter of design using the appropriate methodologies at the right time rather than taking a blunt and blind approach that clearly cuts dynamic power and the range of flexibility possible in an application or system. Read on and learn the ways of the untyped dynamic masters.

Here's a counter example to Darren's fearful pitch for "type safety", and the proof from a real life project that I worked on. JP Morgan, a very large investment bank with huge assets, built a very large financial application in Smalltalk, known as Das Kapital. They trusted it with very large sums of money (likely your pention is involved in some deals that use Das Kapital to manage the risk on a daily basis). Can you spell "billions and billions and billions"? The last time I checked the Smalltalk they used isn't a typed variable language. Das Kapital did (and still does) use appropriate runtime validations (when they were identified as an actual important issue) including data validations and class validations (also known to some as type validations) using the full semantic power of the Smalltalk language. I'll demonstrate some code fragements below.

What most "static typers" are missing is that a very large percentage of all programs are made up of a wide range of validations of various sorts and that type validations are but a limited variety (and of limited use, mainly the so called "type safety" uses and some of the well known compiler optimizations). Unfortunately typed variable restrictions cause severe limitations by creating "brittleness" with a program's flexibility. Sure if that's what you want, go ahead and code that way, but don't delude yourself that the precious "variable type safety" is really buying you all that much. It usually costs you much more than you are even (or ever will be) aware of.

The brittleness caused by improperly applied "class" (or type) validations is something that you have to watch out for when programing in Smalltalk using "class" (or type) validations. Fortunately you usually have to do out of your way to restrict your program too much using them.

Let's look at a typical type specification in typed languages such as C, Java, Objective-C, etc...
SomeClass aVariable;

Deceptively simple as all you do is specify the "type" that the variable is permitted. The compiler then "enforces" program statements such that they only allow "types" of that which is specified to be allowed. All others are "errors"! YES, this means that the dynamic freedom gained by not having variable types at all is considered an "error" in typed langauges! Cool, the dynamic freedom I'll show you below is an error in those langauges! They miss out from the dynamic power and most of them aren't even aware of it! The serious issue is that this form of "typed variable validation" actually causes major havoc on software projects.

Let's look at a typical class (or type) validation in Smalltalk.
(aVariable isKindOf: #SomeClass) ifTrue: [ ... ] ifFalse: [ ... ].

The above is but one simple "guard" on a variable that's commonly used in Smalltalk systems. In this case it's directing the flow based upon the object "class" or "type". If the variable, "aVariable", was typed you'd not need this code, BUT, you'd also not have gained the flexibility from the runtime "type validation" to direct the flow of control however you see fit! If you want you could raise, catch an exception and handle it as needed. You could even examine the live stack and adjust the objects and restart the thread and try again!

That's part of the dynamic power of Smalltalk, and all possible due to "untyped variables"!

Wow, it's amazing to me that such a simple programming technique as typed variables can limit a program in so many ways beyond it's intended goal of "type safety". I prefer type safety that's under my control, not under the control of a language designer who's not working on my project! Let me add my own validations where and when I need them! Let me use the full semantic power of the programming language, such as Smalltalk, and not a simplistic "type specification" syntax that makes programs hard to read, write, debug, and maintain! Thank you very much.

It's abundantly clear from this that "typed variable" languages limit flow of control possibilities that are available in some dynamic programming languages, such as Smalltalk. The lack of these "control flow possibilities" is a serious limitation that users of "type safety" pay. It is a serious benefit that the dynamic programming users can use to implement the next generation of powerful applications and systems.

Expanding our example further we have:
aClass := self aMethodThatDynamicallyFiguresOutTheClass.
(aVariable isKindOf: aClass) ifTrue: [ ... ] ifFalse: [ ... ].

Now we have a variant of the first example that dynamically chooses the class (or type) to validate at run time. I repeat, the variable's permitted class (or type) is determined at run-time! Now that's flexibility and very useful especially for applications that need to dynamically reconfigure themselves to meet the demanding needs of today's rapidly changing software business requirements and thus applications.

In most Smalltalk applications binary logic, using true and false, and existence based logic, testing for object existence or non-existence (i.e. nil or null), is prevalent. In addition it's fairly common to solve the "type" or "class" based logic due to the built in "reflection" meta capabilities of the Class object system. In particular classes like "Class" and "MetaClass" are excellent places to begin to explore.

Explicit "class based logic", also known as variable type constraints, is applied to the variable methods in Smalltalk in the cases where and when it's appropriate. The full language semantic capabilities are available at your finger tips to enable whatever you need. In effect Smalltalk allows for extensible variable type safety! Try do extensible type safety in C or Java! In Smalltalk it takes seconds!

Let's try an experiment. Start your timers. I'll start coding now.
aSet := Set new.
aSet add: Integer.
aSet add: Ball.
aSet add: Chainage.
aSet add: FooBar.
(aSet includes: aVariable class) ifTrue: [ ... ] ifFalse: [ ... ].

Done in less than 60 seconds!!! WOW! In less than a minute I coded the above example that implements "type safety" on the variable "aVariable" such that any of a group of classes are permitted! In this case instances of Integer, Ball, Chainage and FooBar are all permitted in this variable. It should be noted that NONE of these classes are super classes or sub classes of each other. Try that in under 60 seconds in Java, C, C++, Objective-C, C#, etc...

Update. Isaac Gouy provided a Java implmentation of the above example. See Addendum 1 for details. No word yet if he did it in 60 seconds.
- Peter, 20040813, 5:05pm

So, in fact Smalltalk has extensible dynamic run time type safety with the full explicit power of the language behind it. Users can extend the type safety at will!

Typically in Smalltalk you write accessors and settors for each instance variable in an object. This is the place where example code like the above provide gateways and guards or "validations" of type, class, and data values and attributes to find out if the objects being stored are acceptable in cases where it's prudent to do so.

Some in the "type safety crowd" think that professionals using Smalltalk abandon legitimate concerns regarding safety within programs. We have learned from experience that much more is gained from untyped variables (such as user extensible semantic rich type safety benefits and flexible control flow issues) than the "type safety crowd" thinks is lost.

Active State's David Ascher has this to say about the benefits of Dynamic Languages:

"Optimizing person-time, not computer-time
The driving forces for the creation of each major dynamic language centered on making tasks easier for people, with raw computer performance a secondary concern. As the language implementations have matured, they have enabled programmers to build very efficient software, but that was never their primary focus. Getting the job done fast is typically prioritized above getting the job done so that it runs faster. This approach makes sense when one considers that many programs are run only periodically, and take effectively no time to execute, but can take days, weeks, or months to write. When considering networked applications, where network latency or database accesses tend to be the bottlenecks, the folly of hyper-optimizing the execution time of the wrong parts of the program is even clearer. A notable consequence of this difference in priority is seen in the different types of competition among languages. While system languages compete like CPU manufacturers on performance measured by numeric benchmarks such as LINPACK, dynamic languages compete, less formally, on productivity arguments and, through an indirect measure of productivity, on how "fun" a language is. It is apparently widely believed that fun languages correspond to more productive programmers-a hypothesis that would be interesting to test."

I must concur with David. However, if you read his full article you'll see that he usurps the phrase "dynamic languages" to his own ends. David please find a different term as that one is already in use and your new definition just confuses the issue. Not all "dynamic langauges" are "open source"! Also you've neglected to mention LISP and Smalltalk as two of the first dynamic programming langauges that are still popular.

Oh, Dave, by the way Smalltalk is generally considered a fun langauge to program in by people who've used it. It's also been shown that Smalltalk programmer's productivity is typically above those of programmers in other languages and tools.

In any event, David has hit the nail on the head, it's about optimizing people time. When programmers (who usually are people at this time) write "typed code" they are taking time to concentrate on the types. They are spending valuable time debugging those variable typed programs. Time better spent. Lives better spent.

A final note, "type safety", is often a club used against the benefits of dynamic langauges and the power gain of "untyped variables". Valid and safe programs are not the sole domain of "typed variable langauges". It's always been a primary responsibility of professional programmers to ensure that their programs are safe and valid in addition to being built within reasonable time scales, budgets and other resources. The claim that dymanic programs are somehow "unsafe" and that the only tool available it to use "variable typing" is simply silly and ignores the rich culture and technological history and success of systems like Smalltalk and LISP which predate almost all other dynamic languages.

Spend you life wisely. You only have one. Which would you prefer? To write your programs so that they are fast, or to write your programs fast so that you have a life?

Addendum 1 (response to Isaac Gouy).


Copyright 1999-2010 by Smalltalk.org™, All Rights Reserved.
Wednesday
October 01 2014
Travel Adventure

Costa Rica

El Salvador

Guatemala

Honduras

Panama

Enjoy a tropical vacation in the sun, surf, in the jungle for adventure, yoga and massage for relaxation or learn the culture, history and langauge. Visit, live, work, play, retire. Enjoy.

Central America
Interoperate.org, the place to find out how to interoperate.
Google
Web
Smalltalk.org

64bits.net AMD64, Intel Pentium EM64T, Intel Itanium
Meet other Smalltalk people, contribute, learn, earn.
lingoize.me
On speaking languages
naturally with ease
aiming for fluid fluency.