The title is actually from Oscar Wilde - he is reputed to have said that when he first entered the US and he was asked what he had to declare.

With static type checking, it's like trying to declare that no shot on goal is possible, and thus there's no reason to even play the game. Heh - Brian apparently started in on this talk at customs, after they asked him what he was speaking about :)

We are in are in the era of "Architectural balkanization in the post linguistic era". Brian says there are three ideas that have come out of OO and Smalltalk:

• Dynamic Polymorphism - dynamic dispatch - easy as pie, great for wrapping stuff. With dynamic compilation, you can replace things at all levels - module, application, component.
• Callipygian Compilation - JITs - hotspot VM's, the work of Deutsch and Shiffman.
• Reflection - grew out of Lisp. self representation, introspection/intercession.

Smalltalk-80 - "Everything I know about OO I learned from the Image" - browsers/IDE, Windows/GUI, JITS, building up from objects. The notion that the program was built out of mutable objects was what really stuck.

With reflection, you can have a manifest (which, to Brian's mind, explains XML's popularity). You end up with user configurable code. You can cope with things at runtime that you haven't seen before with ad-hoc reflection.

Last summer, Brian worked on MOP and multi-methods in Smalltalk - produced a paper on it, which reflects his particular style of humor - there's a segment on whiskey consumption :)

Asynchronous messaging is only now coming into vogue. Brian asserts that this was prefigured by Actors.

One of these is true (the second)

1. Meta Considered Harmful
2. "Meta" Considered Harmful

The Vision: Languages built out of objects instead of text. Open Languages, Open JITters, A framework for languages. Compile time is anytime. A part of the Smalltalk vision early on was Linguistic Imperialism (to be fair, Java has this going too).

The Reality

Utopian moncultures are good idea incubators, but not actually workable. We live in a pargmatic, heterogeneous, polyglot world. We need to work and play well with others. As Brian puts it, there was a schism in 1997:

• Objectivists
• Pragmatists
• Formalists
• Academics

They all retreated into their own conferences and languages. Heh - "Of Slugs and Bugs" - a tale of types, or "How Star-Crossed software lost the Mars Climate Orbiter". So you had a perfectly good spaceship, with perfectly good software - and yet it dove into the ground as it was told to do by the software. The culprit: A "Simple" unit conversion.

The carpetbaggers came in with their own pet theories as to how it happened - no testing, bad methodology, bad management, bad integration, bad testing.... lots of text got written. The root cause: using English measurement units in a software file that was input into something that expected metric units.

The previous Mars probe that used the same software worked fine, but they changed the number of solar panels on the MCO - so they had to use the thrusters more often to compensate for the way it ended up moving. They had software to track the changes this introduced. When they reused some old code to compensate for all this, the developers assumed that the English-Metric conversion was already in the system. It wasn't, so the frequent use of the thrusters ended up introducing a larger and larger error into the landing scheme.

There were plenty of papers at OOPSLA that said that having units added to Java would have prevented this. Sadly, paper is not executable. The bottom line was that the code for MCO was a hatchet job: "Faster, Better, Cheaper - pick two". There was no end to end testing - the programs were late. Managers trying to save money don't win games - the players still have to suit up. The reused code was trusted because it had worked before (in different conditions).

In the end, it blew because reading code is, in general, hard. Large bodies of code are unreadable (we are all in denial over this.

The Olfactory Method

If it stinks, change it. Code Smells are a subtle indication of a problem. The end-to-end principle applies to programming languages too. You can just leave the goalie in at runtime instead of pretending that type theory disproves the need.

The program model is the central thing. Programs built of objects can be changed. That lets you use dynamic polymorphism to swap things out. Software isn't like "real" engineering. We can't type each line of code three times, for instance :) What we can do is leave the goalie in. We can engineer our objects to test themselves. The network and databases are slower than reflection. Runtime type errors? Welcome to the 21st century - we have to learn to deal with them.

Static languages throw away all the information we need at runtime. Why? It's not 1982 anymore. No one is infallible, and we have to realize that bugs will continually exist. This is a lesson I've learned with BottomFeeder - generally speaking, I ignore runtime errors and let the program run. And somehow, it does :)