Lately, we saw the emerging trend that newspapers are beginning to die. Good riddance. I've never bought a newspaper, I will never buy a newspaper, and I am pretty sure people younger than my age won't as well. The market is gone, so how are newspapers going to survive? Currently, they have placed their hope in advertising. As Steve Ballmer has said, it is all about advertising, advertising, advertising! This to the point where newspaper sites are infested to the brink with ugly colored flash behemoths in odd colors with nasty animations. Don't even get me started on what I want to do to the marketdroid who imagined that sound is a good idea, but let me divulge it includes a meeting with Mr. Garotte at the very least. I don't buy that advertising will be helping them anytime soon. First, I love to block Ads. I utterly despise ads, so I block them with AdBlock+ in Firefox. I don't want some idiotic marketdroid to invade and misuse my precious desktop space. Goodbye. This also has the nice side-effect that it undermines the Ad-industry and every industry basing their income system on Ads. Luckily, the majority of people can't block it, because they are too uneducated to install ad blocking software. Consequence: I can have my free stuff without paying for it or seeing Ads. But the majority will learn eventually, and that will be the slow and effective demise of Newspapers as we know them. We already face the first part of the "crisis" in Denmark as a major danish newspaper will have us pay for their service. This is a really good thing! I would probably like to pay others who use their time producing interesting material I can read about topics in my sphere of interest. But I also do not lament the death if everything I can get is the "Extended nobility package" where I get Wine and Restaurant reviews, news distilled to 99% irrelevance off of Reuters, and "Feminist" crap. Either newspapers will get a new networked revival or they will die. To survive, newspapers must produce something with a greater pastime value than perusing the /b/ board off 4chan (Might I add that the /b/ board is the sewage spill of the internet) -- or else irrelevancy will hit them where it hurts the most.

People are talking about the RailsConf keynote "What killed Smalltalk?" by Robert Martin. You can watch the keynote talk at blip.tv. Of course, the Smalltalk guys weren't slow to answer the argument, which revolves around the fact that code easily becomes cluttered in Smalltalk programs. The arch-angel that will save this problem with Ruby is, of course, unveiled to be "Test Driven Development" much to the rejoice of the Audience.

Martins presentation is flawless in the sense that he does a really good job at capturing the audience. Another interesting point is that he has no slides, just a stack of paper cards on which the key points of the talk is written. In Academia, this would not have worked for most talks I note. Sooner or later you'll at least need a blackboard to draw up and explain a formulae or similar.

A side argument however is that the dynamically typed languages won over the statically typed languages. It is driven by the observation that Java now has reflection, which must mean it is dynamically typed, right? Unfortunately, this viewpoint is misguided in the sense it lacks delicate detail about the situation at hand. This blog postseeks to remedy the omission.

Static vs. Dynamic typing is uninteresting

Taking the argument as being static versus dynamic typing alone is a moot point. Here is why: suppose we want to embed a Java program in Ruby. This can easily be done, if we choose to ignore the types and strip them out. In fact, any statically typed language can be embedded in the dynamic world by stripping the types away. After all, assembly language is untyped, so compilers will at some point have to eschew the typing information for good in their transformation.

But any dynamically typed language can also trivially be embedded in a language with static type discipline. We invent a new type, lets call it T and then proceed to give everything type T. This is what happens inside the Ruby interpreter written in C. Of course we must then have a way to discriminate the different values of T but this is exactly what low-level operations will do in a dynamically typed language anyway.

Thus we have a way to convert back and forth between the static and dynamic world, so why do we not regard them as equal? We know they are not equal, but in what kind of sense are they not equal? If we convert from Java to Ruby and then back to the static world, everything will have the magic type T. We have lost the Java type information in the process. But this merely states that the conversion is not isomorphic.

If one thinks about it, there is little to be gained by studying the trivial world of dynamic typing: everything would look the same once it has been converted into the dynamic world. If we look at the static world, we obtain a different picture.

Meta-theoretic properties, baby!

Since Ruby would be trivially typable in the statically typed world, the whole debate about static typing versus dynamic typing falls apart. It is uninteresting because the level at which we communicate is too low. What really matters are the properties of the type systems: what kind of guarantee do we have from the type system weighing in favor of complex type systems -- and the hassle of maintaining well-typed programs weighing in favor of trivial type systems.

In Ruby, or Smalltalk, the contents of a value (an object) can be changed without having to retype big parts of the program. This is not always true in Java. It holds when there is a certain subtyping relationship between the objects in question, but it can't be done in general, since there is no "duck typing" available. Reflection in Java adds the magic type T so to speak so we can embed any type in a T and we can project any type out of a T. The latter might incur a runtime-error when done however; this is no different from Ruby where everything might potentially incur runtime errors.

The static type system on the other hand tends to guarantee varying levels of type safety. If the program is well typed (read: passes the type checker), then there will be no type errors at runtime. Since there will be no errors at runtime, we can just strip away type discrimination at runtime as well -- yielding great speedup compared to dynamically typed languages.

The difference is that Java, even with the addition of reflection, still have better meta-theoretic properties than Ruby, though we have added a way to poison the type system safety. This is not at all new to most static type systems out there, which allows coercing types unsafely if you really know what you are doing.

Java is also a fairly simple language from a type-complexity perspective. ML is much further up the scale. And Haskell is even further up, with many more complex concepts in the type system. Most theorem provers rely on even more complex type systems to get their work done. In fact they have type system; so powerful they can, in principle, encode correctness specifications of the program. You do not really need unit tests at that level. But it becomes increasingly harder to write correct programs, so most proponents of static typing settles on something further down the scale.

Also, most advanced languages will infer (deduce) types automatically. For ML it is customary to just specify types at the API-level and omit typing details elsewhere. This brings some of the ease from dynamic typing back into static typing.

Wrapping up

One can't possibly say that "dynamic typing won" when the world is much more complex. In reality one must ask: "What static type system won?"; which is not trivially answerable and subject to individual level of expertise, viewpoint, ideology, religion and what not.

What is clear though should be that the type systems of Java with reflection and Ruby are far from equal. Neither are Java or Haskell for instance. Or Haskell and Coq. Or...

Based on that, I think the view Mr. Martin puts forth is a bit too quick and simplified. I also hope we can move beyond the simple dynamic/static debate which is hardly interesting.

And finally the snide remark: What is interesting is the viewpoint that type systems are chastity belts or impose Bondage & Discipline upon programmers when I have just shown, by trivial conversion, how to embed dynamic features into any statically typed language. You just got the skeleton key to the chastity belt, should you need it!