That said, I'm in the midst of an interesting project at work. I'm using XOTcl in AOLServer, which pulls the design in a direction that's quite different from what you would find in apache/mod_perl. Basically, a whole mess of code is loaded into an interpreter at startup, and that interpreter is cloned (via memcpy) to provide the necessary state for worker threads to respond to a request. Furthermore, closures are missing, lexical scopes are kinda there/kinda not, and object finalization/destruction doesn't occur automagically at end-of-scope (it all piles up until end-of-thread).
But there are some interesting features that XOTcl offers: mixin classes, and per-object methods (like binding an unbound method to an object in Ruby). And the whole define-the-world-and-clone model feels more like Smalltalk's "live objects" mindset than the "dead code" model used by C/C++/Java/etc. In fact, XOTcl+AOLServer naturally lends itself to thinking about "live objects", where the system constructs a mess of singletons at startup, which send messages back-and-forth to each other to get stuff done. (This is due to the fact that creating temporary objects has a rather nasty side effect, since discarded objects are not automatically freed.)
In an informal design review today, I had to describe this system, which uses many concepts that XOTcl borrows from hither and yon, none of which are found in C++/Java. And my review partner is a C++ programmer from wayback, so this presents a mild handicap.
In a project such as this, there are two classic organizing principles used to structure the codebase: a big pile of functions (like any standard C, Fortran, Tcl, etc. project), or a forest of classes (as projects in C++, Java, C#, etc. tend evolve into). But with XOTcl, there's another model: the smalltalk-style "live object soup".
All of which brings us to a problem. How do you model a mixture of classes, mixins (at the class- and object-level), inheritance relationships, interface specifications, per-object methods and composition-through-delegation using UML? If some form of UML is your primary means of conceptualizing software design, then concepts like these are outside your field of vision.