CONTINUOUS NUISANCE DOUBLE TYPE COGNITIVE DISSONANCE TAX
Written by Peter William Lount, [ | peter at smalltalk dot org ].
A "DOUBLE TYPE TAX" is a perfect way to describe any language that forces the
user or programmer to "type" as in typing characters the "type" specification of
every variable. How tedious typing type information is, and it's only of limited
use. Anytime type information is really needed in a program it can be checked at
runtime with minimal or insignificant cost. In fact many programs ultimately run
faster with type-less languages, aka dynamic languages, such as Smalltalk. This
is because many programs tend to be disk bound or thrash the cache anyhow, and
significantly because of the poor implementations of class libraries in
languages that force type specifications upon poor unsuspecting programmers who
don't know any better or who don't want to change and adapt to a world of
programming free of type specifications on variables, parameters, etc...
By virtue of their success dynamic typeless languages are valid programming
models which drives type-focused programming types crazy.
All type checking is simply redundant at compile time. It's effectively useless
except for detecting a few categories of errors and for a few optimizations.
Languages with types are effectively not any higher level than C or Assembly
What especially drives "type fiends" nuts is that there are those of us who
recognize that dynamic languages are far superior to typed language programming
paradigms. We rain on their parade.
Types have their purpose but it's very limited and should be banned from
programming languages for the most part. The main difference between a type and
an untyped language is that in untyped language, say Smalltalk for example, the
so called "type" information is attached to the object itself and not to the
variable/parameter slot. This allows tremendous flexibility and most importantly
FREEDOM from the DOUBLE TYPE TAX.
The DOUBLE TYPE TAX creates rigidity in a program and leads to a proliferation
of code to deal with specific variants of the code to implement each variant.
This unnecessary code growth is a source of bugs and takes time; time that costs
the programmer and their boss, client, customer additional money and resources.
Most of all it takes time, the most precious resource that any living being with
a shelf life (i.e. that means you) has.
The Smalltalk IDE is essential in working to reduce and eliminate "type" bugs
from the code. Often they are caught in the development cycle, which by the way
is just a few seconds compared with many minutes for other languages like Java.
Code coloring solves many problems with messages that might otherwise result in
The TYPED Variables and Parameters in typed languages won't save you from the
need for automated test cases which are essential to ensure program correctness.
This is true for Java and all typed languages. Wise programmers (and wise
development team leads) use automated "unit testing" on their objects and
automated "use case tests" on their human interface and systems interface
components. These automated tests will catch the vast majority of errors that
the proponents of "typed languages" want caught. For the other errors, Smalltalk
has a fully realized run time error-exception catching and handling system that
puts Java's try-catch to shame.
Not even Java's vaunted type system catches all "type" errors at compile time.
Witness the proliferation of "null pointer" errors and their ilk in any serious
Runtime "type/class analysis" during testing and during production usage can
find out all the "classes" that pass through variables and parameters in
Smalltalk methods. The untyped dynamic language, "Self" (a descendant of
Smalltalk), implemented a level of this that was used to custom compile special
versions of methods for each "class" of objects being passed into a method
invocation, often generating many different versions. This proved highly
effective and Self set speed records in the process. Self is a perfect example
of making a language simpler but not simplistic; a perfect example of providing
a clean programming language without unnecessary concepts like "types" on all
the variables while finding ways to optimize for performance.
The feed back of variable and parameter "types or class" information can be
added to Smalltalk and other dynamic untyped languages easily. This would
provide a number of advantages and capabilities in the Integrated Development
Environments (IDE) of languages such as Smalltalk. For example the runtime class
info of what's flowing through variables and parameters could be shown in a
method browser much like syntax and valid known message names are highlighted.
This provides programmers with information that could help them improve their
designs. One could imagine seeing that the way the method is written could be
adjusted to make it more generic and allow an even wider range of object "types"
or object instances of various class to flow through the method - thus greatly
expanding the capability of the program and likely reducing it's code foot print
in the process.
Mandatory type information added by the programmer takes programming into a land
of details usually irrelevant to the task at hand. The programmers end up
focusing way too much on computer science (what ever that is) and not enough
time focusing on the problem they are being paid to work on. It's really an
economic issue that costs companies that used typed languages huge amounts of
resources in terms of extra people, larger time budgets, larger monetary budgets
and larger and more difficult debugging and maintenance cycles.
The bottom line is that dynamic languages have proven themselves as viable and
highly reliable systems. Static typed languages or any language that forces
variable and parameter types upon you are going to force you to pay the DOUBLE
TYPE TAX - one payment for all the extra language goo they make you type with
your fingers, and another larger payment in brain power that you have to use to
specify all the variable and parameter type information all the time, every time
you want to use a variable.
Message passing unary, binary and keyword languages, such as Smalltalk, have the
added advantage that they are "literate programming" as well; in essence a
Smalltalk method is often self documenting and usually lacks a need for comments
as the language flows naturally into ones mind. Some projects even eschew
comments due to this aspect of Smalltalk, although I recommend any comments that
clarify the programmers intentions or the specifications or details that just
aren't apparent from reading the code. Due to the nature of Smalltalk often
methods are short, in fact many teams prefer methods to be less than ten lines
or even three lines or less if at all possible. This makes methods highly
reusable and reconfigurable. This makes their objects more flexible.
You'll often see typed languages have methods that run into many pages as common
practice. This means that there will be many more "duplicated" chunks of code.
Even if a team uses the best practices from Smalltalk and writes short Java
methods it's simply not possible for Java methods to be as short overall in a
large project as a result of the extra syntax type goo that must be typed by
programmers fingers and minds.
Basically types steal too much brain power for their worth. They can be caught
using a good IDE, a well thought out set of objects and classes, a good testing
methodology, and at runtime.
Typed languages gain very little from their typed capabilities and they pay a
huge price too. Too huge a price to stay competitive in this busy business
May you be type free. Freedom from the DOUBLE TYPE TAX is not only possible but
will alter your programming for the better.
The CONTINUOUS TAX definition that Crazy Bob and Cederic use is just nonsense.
As James Robertson pointed out you've got it backwards, the CONTINUOUS TAX
really refers to the CONTINUOUS NUISANCE THAT TYPING VARIABLE AND PARAMETERS
brings you. Besides you must pay the DOUBLE TYPE TAX plus the WHAT ARE THE
PARAMETERS TAX all the time with typed languages that use the round parenthesis
unnamed parameter lists. That's a lot of TYPE TAX to pay for TYPES. Oh, yeah,
there is even more, the COGNITIVE DISSONANCE AND COMPUTER SCIENCE TAXES that
take you away from the actual problems at hand in the solution space down into
the unless and irrelevant computer science details.
I taught a programmer Smalltalk who had used types for over 30 years in his day
to day professional career as a civil engineer. After one month of using
Smalltalk, he came into my office and told me "Smalltalk is amazing, I can do
90% civil engineering and only 10% computer science!". He was very excited. He
used Smalltalk for sixteen years after very successfully in his career and
business until he passed away recently. The programs that he (and I) wrote still
provide a huge competitive advantage for that his old firm and will do so for
many years to come.
Type are simply unnecessary and are a hinderance for leading edge software
systems. Eliminate types whenever you can. Use a powerful dynamic literate
language with unary, binary and keyword message passing syntax (UBKMPS) such as
Smalltalk. Get it on today.
You can download and use one or more of the many versions of Smalltalk. See
for information on them.