In response to this post, Matthew Adams wrote:
I think we should look at the problem the other way around. OO was a great paradigm for in-process, in-memory software development, but it really doesn't map well to an enterprise (viz orchestrated, out-of-process, distributed) application....I think we should be looking at a transition to new implementation tools. And I think that, on the whole, that's exactly what we *are* doing. Especially with things like the WS- standards, the appearance of loosely-typed languages again, etc.
Half-full or half-empty, Matthew agrees that there's a tension between OOP (absolutely the dominant teaching paradigm) and enterprise-worthy design (absolutely the market direction). This is a big deal: software development does shift in the face of such tensions (OOP, strong typing, structured programming: all gained industry dominance not because of theory, but because of just such tensions between need and productivity). I can't see how dynamic / loosely-typed languages are a step forward, as I think large dynamically typed systems are very hard to understand for anyone but the original writer (although second-generation test-driven frameworks like Fit would certanily help).
For those of us who are interested in programming languages as such, it's a very interesting time. My gut tells me that something else is going to emerge, something more declarative, with implicit parallelism, and multi-representational (by which, I mean that source code can be represented in both visual and textual means. [Does this contradict my previous statement that UML As Programming Language is a bad idea? Very well then, I contradict myself -- I contain multitudes.]).
\<
p dir=ltr> For awhile, I thought Aspect-Oriented Programming was going to be a big deal, but it doesn't seem to be taking hold. Then there's Intentional Programming from Charles Simonyi and Gregor Kiczales (did anyone blog the demo at Software Development?). Personally, I think there's huge potential in dataflow, but my theory is that programming paradigm shifts are contingency-driven, not theory-driven, so it's a matter of something "catching fire."