Oscar Wilde, is, of course, one Ireland's most gifted minters of colorful epigrams...
	Wilde, when, visiting America for the first time, was asked upon arriving at the New York Customs House if he had anything to declare, and is said to have replied: I have nothing to declare except my genius . -–Oscar Fingal O’Flahertie Wills Wilde (1854-1900) (Wow, when he was my age, he’d been dead for nearly five years.)
	I’ve always thought this would be nifty / ideal / epigram for a talk on dynamic types. Hence, here goes nothing.
	Of Type Systems and customs posts. Goal posts…
	It seems rather bizarre that one still has to make the case that dynamic types are as “strong” as static types, but one does. I’d claim they are, in fact stronger.
	Close-form, close world type theorists seem like soccer (er, this is Europe so “football”) coaches who seek to show that their game plan is so foolproof that it can be conclusively shown that no shot on goal is possible, conceivable, and hence no goalie is even necessary. In fact, they seek to assert that the game need not even be played, since victory is certain, and any rational adversary would capitulate, forfeit in the faceof such claims, of such an irrefutable demonstration.  With a dynamic type system, we just keep the goalie. Which approach makes YOU feel safer?
	Earlier this year, I finally came across one of the greatest “classic” papers I’d never read: “End-to-End Arguments in System Design” by Saltzer, Reed, and Clark. The end-to-end argument was developed in the realm of internet protocol design. Succinctly put (and this format allows for no alternative) it argues that facilities, such as error checking, which one might be tempted to place at the lower levels of a system or network, might actually be redundant, and therefore useless as the lower levels, when they must be included in the upper levels of the system as well.
	We argue that this argument applies as well to programming language design as it does to networking. For instance, facilities that some languages provide for security, protection, synchronization, namespace management, or type checking must often be re-implemented in applications programs in a variety of different ways, many at odds with the manner in which these facilities were provided in these underlying languages. Such duplication raises the question of why these now redundant facilities need be present in these programming languages at all.
	This argument suggests a simpler, more dynamic approach to programming language design, based on an end-to-end analysis of the kinds of facilities users really use, may be better suited to the demands of our clustered, networked, threaded multi-core 21st world.
	Real applications live, and breath, function, and yes fail, in a world well beyond our “formal” logistics train. Real computer science is an empirical, even behavior science, and not the feeble parody of seventeenth century closed-form mathematics some in CS make it out to be.
	There are patterns of programming language design. Objects for lists of states, or zip codes, these are the types our clients demand. Will the legacy of the reflection movement be that we get out of their way, and finally give people the tools to build these as first-class runtime entities?