Dependency Injection.
Mocking frameworks.
And in a certain sense, any kind of “late binding”/plugin application at all. As I understand it, this sort of thing required major hoop-jumping in C/C++, resulting in the unleashing of COM upon the universe. All that is gone with reflection.

Strictly speaking, I think that anything that makes a type system unsound as a logic “subverts strong typing.” Side-effects, general recursion, and definitely serialization (aka pickling) do that. Whether or not you can reasonably avoid it (especially given an existing project and no mandate for reorganization) is a different question, but I think that if you accept that unsoundness you’ve got to be honest about what you’re giving up. There’s a reason that the PLT world moved on from Scheme.

You might be interested in the AliceML project’s approach to type-safe pickling (http://www.ps.uni-sb.de/Papers/abstracts/hotPickles2007.html). It got a lot of attention on lambda-the-ultimate a couple of years ago.

I think that this issue is actually very important. There’s a danger in dismissing the importance of type safety — in fact, just calling it “type safety” I think helps to cloud the issue. Really, it should be called “logical consistency” because (ala Hindley-Milner) that’s *exactly* what it’s about. Improving type systems to support *reasoning* about things like pickling and side-effects goes to make our programs more reliable. You know, when you build a house of cards you can blame the guy who walked by it too quickly for blowing it down, or you can do better to come up with a sound design (a design that can be evaluated before the house is built).

At the end of all of this, I think that we programmers may need to come to terms with dependently-typed programming languages.

Reflection enables (as you point out) many meta-applications not possible with any other mechanism (short of source code analysis or de-compilation). For example, one can programmatically create class diagrams, code complexity metrics, and more via reflection.

For attributes, in particular, reflection is a logical imperative. Since attributes are simply metadata (that is, at runtime the attributes themselves have no behavior), reflection is the only mechanism by which one can create runtime behavior from attributes. Reflection is the examination of metadata. This isn’t dirty or perverse. It is a decent separation of concerns.

What is dirty and perverse is your example of bad reflection usage. This is inarguably bad in most cases, hearkening back to IDispatch and late binding behavior in Visual Basic. The Invoke method on MethodInfo is clearly present for completeness, but I’m hard-pressed to imagine a good use for it in most code (as with other impure features of reflection such as SetProperty).

But, just as F# isn’t a bad functional language because it supports impure function calls, reflection isn’t a bad language feature because it supports impure behavior. On occasion, impure usage of reflection will raise its hackish head, but generally reflection’s pure usages will support elegant possibilities.

As the saying goes, “Reflection doesn’t subvert strong typing; people do.”