Home

Grady Booch: AOSD keynote

The slides from Booch's AOSD keynote The complexity of programming models are online.

If you have been following Booch's recent presentations, you'll recognize many of the slides. Only towards the end does AOP come up.

Relate to PLs are the slides about simplicity in languages, programing models, the discussion of abstraction, and of course AOP.

The presentation was already mentioned in the LtU forum.

By Ehud Lamm at 2005-03-17 22:03 | Software Engineering | other blogs | 7954 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Power Point?

I can't read the document. The name ending suggests power point but my power point refuses to open it. Any help on reading it is appreciated.

By Josef Svenningsson at Fri, 2005-03-18 16:35 | login or register to post comments

PDF

Keynote handled it ok on my Mac. It converts to a 1.7MB PDF file, which I've put up here for a short period of time (about a week).

By Neil Madden at Fri, 2005-03-18 18:02 | login or register to post comments

A few (disjoint) thoughts

Booch says that
In the presence of essential complexity, establishing simplicity in one part of a system requires trading off complexity in another
But many of his other comments on complexity seem to agree with the work of researchers like John Warfield, who claim that there isn't any such thing as "essential complexity" - the perception of complexity is largely defined by how we view the problem/solution space.

Every single one of the "forces" on software development that Booch identifies is also a force on every engineering project. What he is defining are forces on the "product development system", not on the "product". Are there any forces on the software "product"? Maybe things like resource constraints (memory, disk space, etc.)?

Is the software problem domain really inherently more complex than other engineering endeavours? I'm skeptical (mostly because I've worked on projects in non-software fields that were just as complex as the software projects). I'm also skeptical about the supposed "difficulty of managing the development process" compared to other engineering disciplines. I think he's on to something wrt the fluidity and discrete nature of software though - although even there, I'd argue that the math exists, and the tools are coming along pretty well (they just don't get used).

BTW - Someone needs to teach Grady how to use Excel's charting capabilities. His plots full of spurious '0' values look bizarre.

By Allan McInnes at Fri, 2005-03-18 18:42 | login or register to post comments

Rising levels on abstraction

(slide 53)
As far as I can see higher levels of abstraction means getting less done (except for Processes: Agile is much better than the Waterfall):
* from Assembly to Java (lose lots of expressivity, control over memory, tail calling ability)
* from general hardware to domain-specific stuff (that can only do one thing really)
* from procedural prog. over OO to service oriented (never heard of this new thing; so I guess it's about not doing anything at all anymore, just talk about how to build software?)
* from individual to organization (again, no work getting done there!)
* from early tools (nice hand-crafted) to CDE (!)

Yes, I guess he doesn't mean Solaris CDE, but it's funny :)
Slides about software engineering should be accompanied by a dictionary that explains all the terms in *concrete*. Unfortunately most of SE is about *never* explaining a term in clear, because then 90% of them would just vanish :D

By Ulrich Hobelmann at Sun, 2005-03-20 23:32 | login or register to post comments

Yes, it is tricky

service oriented (never heard of this new thing; so I guess it's about not doing anything at all anymore, just talk about how to build software?)

I hear about it a lot, but still don't get it completely. It seems to be a marketing word covering many nice things, including: message-passing concurrency, components with behavioral contracts, distributed computation, or sometimes nothing at all.

By Andris Birkmanis at Mon, 2005-03-21 09:20 | login or register to post comments

Service Oriented

It seems to be a marketing word covering many nice things, including: message-passing concurrency, components with behavioral contracts, distributed computation, or sometimes nothing at all.

I think the origin of the term is "web services". The idea is that you have a "simple", web-based interface to a "service" (could be anything really) and magically you have robust distributed programming.

So I think in typical IT fashion, it is a new word for something that didn't work very well the first several times around (RPC, COM, EJB, etc). Makes it harder for people to make the connection and makes it sound easier than it is.

By Marc Hamann at Mon, 2005-03-21 14:41 | login or register to post comments

Web services

Yes, as if accessing an (possibly active) object over the web is any different from doing the same in Smalltalk, Java, or any other language.

I wonder why they're still beating that horse, considering how many technologies you mentioned failed.

I'd suggest they take a look at CSP, CCS and the pi-calc. That might give more to concurrency than just making it (method invocation) more complex to keep the programs that are written simpler :D.

By Ulrich Hobelmann at Thu, 2005-03-24 05:27 | login or register to post comments

I am afraid they took that look :(

I'd suggest they take a look at CSP, CCS and the pi-calc.
Ironically, pi calculus became a marketing word as well (in addition to its usual meanings).

Just google for "pi calculus buisness process", "pi calculus services", or "pi calculus market" to get an idea.

By Andris Birkmanis at Thu, 2005-03-24 06:55 | login or register to post comments

A recipe for immobility

Any time you depart from established practice, make ten times the effort, ten times the investigation. Especially on a very large project.

What a perfect argument for an intellectually lazy manager who wants to kill an innovative project but can't find any legitimate reason to do so. The problem is that "established practice" is in the eye of the beholder. There are many, many different communities out there. Even a so-called "niche" community can be very large in absolute terms and have its own established practice.

By Peter Van Roy at Fri, 2005-03-25 15:14 | login or register to post comments

This is Particularly True...

...when one is a C++ programmer, because "established practice" depends almost entirely upon what the decison-makers are comfortable with. I still have some code that, at review time, gets looked at askance for its use of boost::bind, Spirit, or Alexandrescu's "TypeInfo" wrapper from "Modern C++ Design," even though each of these tools is now a minimum of three years old, proven in the real world, and assiduously documented.

Of course, I could back up a step and observe that developing a distributed system with stringent security requirements in C++ already reflects poor requirements and "established practice" analysis skills...

By Paul Snively at Fri, 2005-03-25 16:04 | login or register to post comments