Hi, I am Gregor Hohpe, co-author of the book Enterprise Integration Patterns. I work on and write about asynchronous messaging systems, distributed architectures, and all sorts of enterprise
computing and architecture topics.
Find my posts on IT strategy, enterprise architecture, and digital transformation at ArchitectElevator.com.
OOPSLA is not your typical developer conference. At first sight it can appear utterly disorganized and a little clique-ish. Dick Gabriel even created an unofficial schedule because the official one was nearly impossible to figure out. And the venue was a 60ies relic of a "resort" that would be more suitable as a backdrop for a teenage slasher movie than a professional conference. Alas, attendees came from pretty far away and for good reasons.
If I was marketing OOPSLA my slogan would be "If you are too smart to go to JavaOne or TechEd, you should come to OOPSLA!" OOPSLA offers an eclectic mix of tutorials, often taught by leading authors and thought leaders in their respective fields, and presentations from academia that can appear a bit on the intellectual fringe. In combination, though, it makes for an inspiring mix of pragmatic information and intellectual stimulation. Care to learn more about new programming languages and models, such as programming by example? Learn more about dynamic languages? It's all right here, including GoF fellow Ralph Johnson getting box lunches for the panelists (as seen on the right).
One observation I could not help but make is the fact that the letter "O" fares particularly
poorly when it comes to acronyms in our industry. First, we had to give up the "O"
in SOAP because SOAP has nothing to do with objects -- more likely the opposite. Subsequently,
Microsoft killed the "O" in all of its workflow related products: XOML became XAML,
WinOE became WWF. Somehow "O"rchestration must have fallen out of favor with the marketing
department. OOPSLA is in even bigger trouble as it has two O's. It seems that there
is simply not much left to say about objects these days. Everybody is using it, the
common patterns are well understood, and language support is fairly abundant. One
could say that OOPSLA has become the victim of its own success because only a small
portion of OOPLSA still has something to do with object-oriented design.
The most interesting discussions on objects seemed to center on two themes. First, not everything is an object and object modeling is not the best choice for all problem domains. This become more apparent as the SOA buzzword engine actually does draw attention to some useful non-OO programming styles such as process modeling, document-based interactions, and service composition. In the end it is the same old "hammer and nail" effect but the object success may have caused a significant amount of inertia that makes for a bigger hammer.
Interestingly, though, some talks also focused on areas where objects would be very useful but are not utilized. Brian Foote's talk in the Dynamic Language Symposium rightly challenged that the whole programming and execution environment should be available as objects: "Why is my source code not an object?" "I should be able to get the process object and invoke the kill() method". In fact, SmallTalk let you do this.
While the title of this panel did not necessarily catch my attention, the all-star
cast did: Having Ed Yourdon, Larry Constantine, Grady Booch, and Kent Beck amongst
the panelists suggested an entertaining and insightful debate. And we were not disappointed.
After all, panels live and die with the wit of the panelists and this one definitely
lived. Kent Beck's opening remark stating that he reread Structured Design to prepare for the panel was a reliable indicator of more good things to come.
Most of the discussion centered on the role of design techniques and modeling languages and the way we design software. Structured design, introduced by Constantine and Yourdon some 25 years ago was one of the early "methodologies" and also included a design notation. An interesting theme during the panel focused on how much a methodology and notation can help developers come up with good designs. There was also general consensus that using any structured design technique is more important than picking a specific approach. Structured design had many of the right ingredients to guide developers to think about the way they map the problem domain to the solution domain even though it did not provide the expressiveness of an object-oriented design. In a nice acknowledgment to Constantine and Yourdon 's work , Kent Beck remarked appropriately that "People who could not do a decent job with structured design went to objects so noone would notice."
The panel was dotted with memorable quotes from some of the more memorable names in the history of software engineering:
As the title might suggest, Brian gave a funny and insightful talk as part of the Dynamic Language Symposium. My key take-away was Brian's statement that the notion of a dynamic language that interacts transparently with the development and run-time environment seems to have been ignored in the last decade of language design. Brian showed a list of items spanning two slides that should be accessible as objects. This includes the run-time environment, such as running processes or the source code. Why would you want the source code of your program available as objects from your program? This may sound like an idea that only hard core geeks with too much time on their hands could find useful, but think again. Refactoring tools have very quickly matured from academic ideas to must-have tools (I will not code anything without ReSharper or IntelliJ). The key to these tools is the insight that the source window does not simply contain a sequence of characters but an abstract syntax tree. Parsing and manipulating this tree allows for the real-time underlining and refactoring that we have come to love so dearly. Now why couldn't this be part of the language run-time already rather than proprietary vendor technology?
Most interestingly, there are a few programming environments that are closer to the notion of everything being an object. Oddly these environments tend to use very clunky, XML-based languages. We are talking about the tools and languages that live in the Web-services / SOA space, such as BPEL and XSL. XSL must be one of the most hated languages of recent times, but the fact that XSL source code is an XML document means that you can easily modify an XSL "program" using XSL. This is something not so easily accomplished in Java or C#. Process modeling and execution tools based on BPEL (or comparable languages) also do pretty good in terms of making the run-time environment available programmatically. For example, most process engines let us enumerate the running process instances and interact with them. Once again the programming language syntax itself is debatable (and has been debated) but that should not make us ignore some of the good ideas that are part of the run-time environment. I think Dragos' Orchestration Patterns might give us some better appreciation for these types of features.
Grady gave an update on his work on the Handbook of Software Architecture. After helping create a unified modeling language (despite all the bickering about
UML, most people will agree that the creation of a unified modeling and diagramming
language was a good thing) Grady is taking things up one level and wants to document
what makes good architecture. I was excited to see that he views patterns as a key
element in this endeavor. Of course I was ecstatic when Grady showed the list of his
favorite patterns books and it included our book!!
Kevlin gave a nice tutorial on the design of programming interfaces. Unfortunately, my paper notes are in the office so I'll have to write about it in more detail later. I wish the Google book scanning project, which always draws grief from publishers, included my notes :-) The good news is that some time next year Kevlin's and Frank Buschmann's new book on patterns languages will come out.
You cannot complete your OOPSLA experience without attending one talk that is completely over your head. For me, this was Jerry Sussman's talk with the illustrious title Why Programming is a Good Medium for Expressing Poorly Understood and Sloppily Formulated Ideas. I was very interested in the abstract of the talk, which promised to focus on the expressiveness of computer programs and how the program can help us better understand and express our ideas. Sadly, the talk used overhead foils that were projected via a camera, which made it harder to read the slides. The AV setup aside, the talk still went pretty clearly over my head. Luckily there's a video available (also with difficult to read slides).
Gregor is a cloud architect and author. He is a frequent speaker on asynchronous messaging,
IT strategy, and cloud.