Dynamic Systems are where Capability Rules
written by Peter William Lount
version 1, 20050715
version 2, 20050716, fixed some typos.
version 3, 20050717, added the "Smalltalk in Use" link.
"Isn't the Meijer/Drayton paper
trying to bridge the divide by pragmatically adopting what form of type checking is necessary at
any given point instead of taking absolutist positions?" - Dilip asked.
Ah NO! What gave you that idea? Their paper has very little to actually say about dynamic typing.
Essentially it rants about the authors desired "type" straight jackets and does little if nothing to
bridge the "gap" between these very different styles of programming languages.
Maybe the misleading title did it's job by coloring your perception. The title, "Static Typing Where Possible,
Dynamic Typing When Needed: The End of the Cold War Between Programming Languages" says it all. In a fell swoop,
"Static Typing Where Possible", the authors declare themselves the winners of "the Cold War".
Static typing where possible, give me a break, that's not a peace offering. Saying something like
"Choose the style best for your needs" would be.
The paper, which the authors say is a working copy, sure needs work, and in particular a new title.
How about "We really like Static Typing and here's the details of the kind of Static Typing we really want."
Ok, that's fine. All I ask is that the authors change the title of the paper to reflect the actual contents.
Just to clear things up a little. Sure I prefer run time dynamically typed languages, and Smalltalk
"keyword message passing languages" such as Zoku, in particular. I know how to use them. It took me a
while to learn Smalltalk, about half a year to gain a high level of proficiency with it and all the tools
Smalltalk-80 offered in 1984. I had used Assembly language before then, and have learned C, Objective-C,
Java, and other "typed" languages since then. Actually, like many professionals I speak -
or is that write - many computer languages fluently and can read many more. I'm no stranger to typed languages,
they work and get can usually be made to get a job done. The question is at what cost when compared to other programming languages?
In English (and other human language) literature circles it's "respectable" to engage in "comparative literature".
I wonder why comparative literature of computer programs and programming languages draws such fire from people?
I suppose one reason is that the participants are highly passionate about language, often to the point of being
characterized as "religious" about their language of choice. This seems to be similar to what people passionate
about this or that great work of literature in English or French would seem like. Or, to quote a fictional character,
"You've not read Shakespeare until you've read it in the Original Klingon!".
Needless to say, I am passionate about Smalltalk. I am passionate about Zoku, the variant of Smalltalk that I am creating.
Even being passionate about a dynamic language does not blind me to the advantages and benefits of statically typed,
development time compiled only, file based programming languages such as C, Java, C#, etc... Let's take "C" as an example,
it's a powerful systems language in use today as the foundation language in almost all successfully running operating systems,
even the ones of questionable quality.
One operating system development group that takes it's development and commit to quality seriously -
it clearly shows in the results - and that's
. They are an experienced group successfully using the "typed"
language "C" in a serious operating system. It's their extra dedication to "quality" that ensures that the
pitfalls and traps of "C" don't get in their way. Microsoft could sure learn from them, not their code, but
their "process" of "auditing code" and the dedication to quality. They would surely point out the flaws of "C",
and in fact they routinely find programmers making the same mistakes in the thousands of software packages that
come with their system. To give you an idea of their commitment to quality, they don't just "audit" their own code
base, but that of all the packages they include in their system, over 300MB of source code. However, the cost of this effort
is huge, although the participants seem to feel satisfaction in a job well done and are passionate about what they are doing.
Hey, with a commitment to quality who wouldn't be thrilled no matter how primitive the tools?
Oh, and I do use OpenBSD in production.
A few basic facts are obvious but need to be restated in the face of the new "typed where possible onslaught" that
the above mentioned paper throws the gauntlet down on.
Any programming language that enables users to build usable programs is, well proven to be useful and thus "valid".
It's very existence proves that. However, that doesn't mean it's worthwhile using the language.
statically typed languages work. Indisputable fact.
Dynamically untyped-languages work. Indisputable fact.
Dynamically untyped-languages work very well without types. Indisputable fact.
Dynamically untyped-languages work very well without types and thus "types" are not "needed". Indisputable fact.
Types do allow for some limited kinds of performance optimizations by the complier. Well known "advantage" of development
time compiled languages.
Some very large applications have been written in Smalltalk, the most well known of the dynamically untyped-languages. In fact,
Das Kapital, in use by JPMorgan is a huge application that is used by the company to manage vast sums of money. Obviously they
think it's "safe" to use an "untyped" language like Smalltalk. They are not just betting their company on it, they are betting a
large part of the well being of the USA and Global economy on their Smalltalk based applications.
The Java effort to replace Das Kapital failed, in part because the users had become accustomed to the power and leverage that
Smalltalk enabled us to build into it. They revolted and Smalltalk rules. Yes, I worked on the core team that build the first
initial version of Das Kapital while consulting with JPMorgan on Wall Street back in 92-93 when C# wasn't even conceived of
and Java was just a malformed thought. Oh, maybe it still is. Hmmm... anyway I digress. The layer we built upon Smalltalk wasn't
possible to develop using other development languages due to the requirements of the business stakeholders and simply because of the
flexibility of Smalltalk.
Ok, now back to the, ah em, draft paper and some of it's silliness.
The authors write "I want type inference". Why of course they do, as it's a useful addition to any programming language - at
runtime! Type inference is a "run-time dynamic" technique developed long ago at places like Parc Xerox and other places. Please
take it and incorporate it into your runtime environments in Java and C#, as it'll assist developers in seeing what's going on.
And if it can help remove the darned requirement to type, as in typing keys on a keyboard, from new programming languages, all the better.
The advocates of "typed" programming languages - from C to Haskell to the attempts to add it to Python - are simply over focused
on a tired little feature, namely the pre-specification of a few very narrow definitions of what "type" of data or object can
"exist" or be placed into a "variable".
Oh the other hand a key innovation of Smalltalk was to shift this "externally maintained" information about what's in the
variable from the variable to the actual data or object itself. The variable becomes "free" and "unconstrained". Truly
Smalltalk is "free software".
Why the heck would this make any difference? It's making a vast profit for JPMorgan, that's a difference.
Another, even more serious difference than billions in profits annually, is that it enables programmers, systems designers,
and architects to "express" themselves with a freedom of thought "unconstrained from pre-ordination and pre-conception" of
the "earlier-work-in-progress-usually-faulty-designs-that-were-best-re-done-before-the-code-makes-it-to-production that is
typical of "typed" programs.
What this means is that the design and architecture of a program in Smalltalk is much easier to grow, adapt, evolve overtime
since less of the system is "locked down" with "pre-conceived-type-definitions" that are required in languages such as Java
and C#. Yes, these languages require you to "type" your variables. No choice. In Smalltalk the variable are free so that you
can be free to move your code, your system ahead through the necessary evolutionary steps that all software systems must take
on their path to a successful production deployment and sustained earning power for the stakeholders.
A common misconception is that free, unconstrained variables leads to all sorts of bugs. Oh, and here I also am referring not
just to variables, but to method "signatures" or method protocols and the parameter types and input types. The rampant bug
misconception isn't the reality. However, no programming language is going to save the user from "poor designs" and "complexity"
which can creep into any software project.
It's unfortunate that many in our industry are dedicated to complexity to such an extent that they worship at it's altar. Now,
maybe that's not really fair to all those who must work with integrating dozens of systems with decades of barnacles of legacy
code and methodologies old and new alike. Complexity, after all, can even arise in simple systems as Stephen proves in Chapter
Two of "A New Kind of Science". While Wolfram, and I, intentionally research and work with "simple systems that give rise to
complex behavior" it's interesting that the flip side, working to keep things simple is also a strategy worth pursuing. This
is of course more challenging considering that often people have different ideas of what "simple" really is or isn't, which of
course, is often a result of their knowledge and unique perspective in the various systems they are experts in. It's important
to respect their point of view.
It's important to state that while I am professionally critical of the conclusions and "choices" of the authors of the
aforementioned paper, I do respect them, even though I've not met them. I respect them for daring to publish a "self stated"
incomplete work in progress paper on a "hot button" topic.
What concerns me and my clients over the years are results and results that can consistently be take to the bank. We live and
work in a society driven by capital after all. As a technopreneur it is my responsibility to provide the best value to the
stakeholders and users of the systems as possible given the resources available.
As an expert in dynamic and static systems I know the choices and trade offs required to make a project succeed. While the authors,
Meijer and Drayton, have a point of view on "Typed Languages" it's certain that they had little to say about "dynamic systems"
in their paper.
Let's delve into dynamic systems deeper. Dynamic has it's roots in "dynamo", something that is "fluid" in the face of change and
yet stays the course. As IBM says: "pertaining to an operation that occurs at the time it is needed rather than at a predetermined
or fixed time." So that concurs with our usage of the word.
In developing a next generation dynamic system I've looked at Smalltalk and have made some improvements and changes that support
industrial strength dynamic systems. In addition, other languages have influenced the design of Zoku, such as Lisp, Forth, Rebol,
Java and C#. Java and C# as examples of designs to keep away from. Lisp as a key example of a system that has incredible dynamic
as needed power and flexibility on demand.
There will always be key reasons behind any "decision" to use one programming language over another for any specific project.
Speed through optimization performance, the main "compelling" aspect of statically typed languages such as C, C++, C#, Java,
are for the large part moot in these days of ubiquitous and fast low cost commodity PC's. Need more power for your dynamic Smalltalk
or Zoku system, just get a couple of more boxes, and presto the workload distributes, assuming that you've designed your application(s)
to be scalable and to take advantage of your application(s) "natural parallelism" (which is present in almost all business and technical
applications). Just add one, ten, one hundred new servers and boom the performance improves.
Dynamic systems provide benefits that static systems can only emulate by building in dynamic features! Just look to the aforementioned
paper and it's evident that their desire for type inferencing and other features again draws on much of the research originally done
in dynamic languages.
Oh, before I'm assaulted with a plethora of emails complaining about "type inferencing" being a "compile time" activity and thus "not
dynamic" and certainly not "runtime" you should note the following. Compile time "type inferencing" is a limited form of type inferencing
highly developed over the last decade in "functional" languages such as Haskell. "Dynamic runtime type inferencing" occurs at runtime by
collecting and recording the actual kinds of objects passing through variables. Oh, you don't need to do that in "compile time type inferred
systems" as they over constrain the variables, parameters, etc... with simplistic type constraints so that variables can't have
unknown and "unauthorized" types at runtime thus limiting the solution domain of their applications significantly. By letting the
dynamic program choose what data values and objects are allowed and not allowed into variables at run time dynamic systems can provide solutions
unconceived of at design time. By the way, the Self language was one of the first successful
language implementations that used runtime type inferencing to dynamically recompile and optimize the code.
While many in the "typed" and "functional" world have for some non-rational reason rejected "runtime type inferencing" as not being
valid "type inferencing" their argument is mute and without basis. Both forms of type inferencing are valid forms. However, compile
time type inferencing isn't dynamic, a serious limitation, but then that's the constrained nature of the compile time distinction.
While compile time distinctions are useful for certain aspects they are a tiny corner of the full potential of the computing space
whose majority of solution space exists at runtime. The proof? You can't use a computer, other than as a boat anchor, without
"running it", thus by it's very definition, it's all about runtime.
The key difference between static and dynamic systems is whether or not your systems stagnate or can adapt through time. Do the
applications you use, that you provide to your staff to make you money, and that all computer users use in daily usage, do they adapt?
Can they be adapted? By whom? How fast? If you have to compile the whole application and package it it's too late, as a dynamic system
will beat you to the punch. Time waits for no man and the future of computing interfaces waits for no compile time file based
pre-decided type-encrusted code to make it's way through the complier and waterfall development process pipeline.
"Time is not just money, it's life, spend all three wisely by choosing to create a compelling future."
- Peter William Lount
To wrap up this exploratory essay, the aforementioned paper requires a serious rewrite and at least a more appropriate title to
reflect it's "pro-only-typed-is-best" wolf attitude dressed in a sheep's title. It's unfortunate that the authors were so one sided with such a misleading title.
Please change the title.
Face it, dynamic systems are very sexy now especially with
the desktop super computers and desktop clusters coming that the typed folks are scrambling to catch up technology wise.
Capability matters more in the real world than raw performance (in 99.99999% of applications and systems).
Let's be clear, if you choose a typed system, are willing to pay the price to make it work,
and actually make it work, all the power to you. Success breeds success and there is nothing like the success of dynamic systems
(like the Smalltalk based Das Kapital) for economic benefits.
If you are a business stakeholder deciding whether or not to use Smalltalk or another dynamic system, choose wisely, and my advice
is to let an expert in dynamic system have an opportunity to assist you in creating a compelling future that sustains and grows your
1999-2010 by Smalltalk.org, All Rights Reserved.