Building Blocks

Building Software Better

Why dynamic typing?

Posted by Mark on August 27, 1997

Why use dynamic typing for programming languages like Smalltalk, Ruby, etc. and what are the effects of that dynamic typing on application stability. Back in the mid 90s, the emergence of Java ‘opened’ the topic because Java was clearly more dynamic in typing than C++ [primarily through the ‘interface’ mechanism] but not nearly as dynamic as Smalltalk [which was a very active language in some circles at the time]. Now that Ruby has become mainstream as a kind of rebirth of Smalltalk into an updated world, this topic may be interesting again.

The below is the Smalltalk version of the topic, but it would be just as applicable for Ruby. I believe there are few Smalltalk-specific references in this series.

Anatol Fomenko wrote:
> ...Why Smalltalk is dynamically typed, and why it
> does not affect negatively the stability of the large Smalltalk
> applications?

Rephrasing slightly gives the two following questions:

  1. Why is Smalltalk dynamically typed?
  2. Why does dynamic typing (as done with Smalltalk) not negatively
    affect the stability of large applications?

The first question would be better answered by Alan Kay and the
Smalltalk team more than anyone else relaying their reasons. Alan Kay
has described some of his reasoning in the book “History of Programming
Languages II”, various OOPSLA & Smalltalk talks, and other sources.

In my own words, the main reason is that Smalltalk has a simple &
powerful concept of building software out of Objects that send Messages
to other Objects. This is more powerful in both the small and the large
than a language that adds the additional concept (and constraints) of
“Types”. Note that biology has Objects (e.g. Cells) but no Types,
Humans are Objects but there is no compile-time type-checking between
humans, and even electronics do not have compile-time Types: you can
plug the GROUND pin into +5V if you want although some physical
constructs will discourage (but not prevent) it. These highly scalable
areas (life, civilization, electronics) have done fantastically without
the support of Types, growing in orders of magnitude of functionality.
Alan Kay (who has a biology background) leveraged insights on how cells
and other highly-scalable areas could scale, and applied them to
Smalltalk. The main concept was membranes/encapsulation and little else
was needed.

The second question may partially support the first. The short answer
is dynamic typing can scale well because one tends to create much less
code as the system grows bigger. As the system grows, objects will get
reused in many different situations for which they work well, and the
layers of “membranes” allow clients to not worry about internal details
very much. It still requires a good architecture to build a big system,
but the generalizable functionality of the objects is helping a lot with
the design/implementation.

Now someone could argue that static typing should have the same
property: you write less code as you create more functionality. But the
truth is that static typing does not just avoid/remove bad code, it
REMOVES GOOD CODE too. And this good code that static typing is
removing is exactly the code that makes Smalltalk so scalable: it is the
code that can be reused in many different situations that were never
planned for by the original authors. Dynamic typing excels because it
allows this highly reusable, good code that would not pass a static
typecheck.

Quantifying the benefit of dynamic typing

To quantify this a bit, consider that ultimately both a correctly
running Smalltalk program and a correctly running Java program will do
the same thing, so lets consider just one aspect:

  • How much extra code needs to be written to support static-typing
    vs. dynamic-typing?

The following are all rough estimates between Java and Smalltalk, but
they are based on years of experience doing very similar tasks in both
languages [but Your Mileage May Vary]. Smalltalk requires about 1/2 to
1/3 the number of statements within a method to accomplish the same
thing as Java [this is one of the most painful aspects of switching back
and forth between Smalltalk and Java/C++], so the extra code is at least
100% (2x). The next level is the number of additional methods needed
because of static typing. From my experience this is probably about
20%: one in six methods in Java would simply not need to exist in
Smalltalk because they are solely solving a static typing problem and
could otherwise be collapsed into the remaining five methods. The next
level are additional classes, which is at least another 30%. Finally, I
will end with additional “packages” of functionality which have to be
rewritten or somehow significantly copied/changed to use in the desired
context. Again, I would say this is about 20% or so (where the ‘or so’
can get really large). All totaled this is a minimum of:

   2.0 x 1.2 x 1.3 x 1.2 = 3.75  (275% larger)

and could get as large as

   3.0 x 1.3 x 1.5 x 1.7 = 9.5   (850% larger)

If you take out the method-statement-level multiplier (people don’t seem
to mind this growth as much and it is well localized) you get an 85% to
230% growth in overall system size (packages of classes of methods).

It would be better to have real experimental numbers (say for TOPLink or
another cross-language product). But the above gives the general
concept of an advantage of dynamic languages and the penalty of static
typing.

If you need a specific example, consider the [completely randomly
selected] JDK 1.2 Collection code of:

    public boolean AbstractCollection::removeAll(Collection c) {
        boolean modified = false;
        Iterator e = iterator();
        while (e.hasNext()) {
            if(c.contains(e.next())) {
                e.remove();
                modified = true;
            }
        }
        return modified;
    }

The static-typing problem in this extremely simple code is that ‘c’ only
needs to respond to ‘contains’, not be a Collection. This means I can’t
just use any containment concept I want to (say, remove all people who
are 6′ tall) by passing in an object that understands ‘contains’.
Because of a static-typing restriction on what would be perfectly good
code, I have to create extra code that reproduces 90% of the above with
the one variation that ‘c’ is something other than a Collection (and I
am likely to pick something as silly [i.e. too specific] as ‘Collection’
again). This is the type of ‘package’-level punishment that static
typing tends to cause.

Affect on stability

So returning to the question:

  (2) Why does dynamic typing (as done with Smalltalk) not negatively
      affect the stability of large applications?

Because large applications written in a dynamic OO language still have
well encapsulated parts that can be verified independently, and the
total implementation can be about 1/2 to 1/3 the size of the
implementation in Java (or another static-typed language)[2].

In the small you may get a type error that static-typing could have
catched, but you also get to build a system such that you never have to
write 40-70% of the code you might otherwise have to. And a line of
code not written is a 100% guaranteed correct line of code.

A way to really think about the negative impacts of static typing would
be to consider (as you walk around) how many things in the real world
would be extremely difficult to do if static typing was enforced on
them. For example, could you have a shoe-rack? (no, someone would have
to ‘cast’ their shoes when they took them out again). Could you use a
key to cut open a package? Could gas-injection cork removers exist?
Heterogeneity, flexibility, extensibility, and reusability are all
punished by static typing.

Not that I think static-typing isn’t useful… it just has serious
drawbacks. Certainly Eiffel does it better than Java. But
dynamic-typing has conceptual advantages that even the best static-typed
languages (e.g. Cecil) can’t remove and those advantages are very
helpful in building real, large-scale, applications.

--Mark
mark.fussell@chimu.com

[1] If you would like a longer example of completely removing static
typing from a Java program and then re-adding it incrementally, see:

   http://www.chimu.com/publications/smallJava/index.html

[2] On the other hand, the value of a programming language is determined
by how well it helps developers solve their problems. Although the
quality of a language itself can make it a better tool, the real power
comes from high quality libraries and frameworks available to that
language. Smalltalk has an inherent advantage but if the number of
skilled developers creating for another language (e.g. Java) is high
enough, than that inherent advantage will go away because enough better
frameworks will exist in the other language such that Smalltalk would
not be as close to the solution as the other language is.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: