[ | smalltalk dot org ].
Community and industry meet inventing the future.
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 OpenBSD. 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).

Smalltalk in Use lists many companies using Smalltalk.
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 business.
Copyright 1999-2010 by Smalltalk.org™, All Rights Reserved.
Tuesday
July 22 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.