The future is not objects
Managage code is language-neutral, right? No! Right now the CLI is very much tilted in favor of Object-Oriented languages (C++, C#, VB, Java). This is fine for now, but looking around the computing landscape leads me to a hypothesis:
Hypothesis: The interesting programming models in the next three years are not going to be Object-Oriented in nature.
There's just too much interest right now in other ways of doing things. XML andWebServices for example are both non-OO at heart (heck, guys like Tim Ewald and Don Box have even been talking about the joys of weak typing). This hypothesis is sort of academically interesting, but there is a corrollary:
Corrollary: The long-term success of the CLR may hinge on its ability to accomondate non-OO models of programming
and this is an interesting idea to me. So, Discuss. Am I all wet?
[Managed Space]
No, you're perfectly dry; I ranted similarly the other day. Object-oriented imperative languages are a pragmatic sweet spot today, but there are other programming paradigms thare are known to be more productive in certain situations. Several of the most talked-about challenges of building applications today such as persistence strategies and "business rules" are fundamentally easier to solve non-imperatively. The history of visual form builders, which are a type of non-imperative programming, argues for your point -- the primacy of reflection in language and library design emerged largely because of the realization that visual form-builders had become a necessity. So while visual form-builders are layered on top of OOP, they fairly dramatically influenced language and library design. Some changes, though, such as new multiprocessing paradigms, will undoubtedly require evolution (or even revolution) of the CLR. I'd submit that Microsoft's behavior re Rotor compared to Sun's behavior re the Java Community Process is a much better strategy for evolving the fundamental substrate of their platform.