Most software development these days is object-oriented to some extent. However, the object model stops in the application boundaries; we're still, in the end, developing applications, which run monolithically, based on a model not too different to what UNIX had in the 70s and DOS had in the 80s.
Instead, I want to write classes, interfaces, adapters, and have everything in my system potentially interact with anything else.
Almost every software project has to, very early on its lifecycle, decide on data storage. Usually there's some sort of library that does what the project needs. Usually, it has a non-trivial learning curve, and does a lot of magic to hammer your object-oriented data into relational database tables.
Instead, I want to just write my “business logic” code, then pick storage options from an off-the-shelf selection. It's a solved problem, why must every project go through it again?
The majority of applications today is tightly bound to its user interface. You close the window, it stops running. There's no way to “reattach” to the running application from, for example, a different computer. At the same time, a lot of state is lost when the application is closed.
Instead, I'd like to log out of my GUI session, and keep receiving updates from IRC, IM, and microblogging; I'd like my downloads to keep going, my music to keep playing, etc. I'd like to be able to open multiple different views on the same object, even simultaneously, to fulfill different UI needs. I'd like to be able to attach to my objects from a different computer. Finally, most of my state doesn't really need a process to be running; the system should be able to persist most of it even when nothing interesting is happening to my objects, so I can pick up from exactly where I left.
If a project requires client-server communication, it almost always will design its own protocol. The developers will spend a lot of effort improving, fine-tuning, optimizing, and securing this protocol, but at the bottom line it's really a simple, crippled message-passing system (assuming the project is object-oriented).
Instead, I dream of writing my “business logic” code, then just flip a switch to tell it I want the network message passing system enabled. Possibly register which objects are visible and “where”.
On the other hand, a lot of “client-server” has been replaced lately with web-based applications. Having been a web developer myself, for over a decade, I'm hardly a fan of the model. HTML was designed for documents, not for modern user interfaces; HTTP is stateless and sessionless, fundamentally pull-only (so-called “server push” is an ugly hack which does something not quite exactly what it advertises). Although our desktops have evolved to a wide host of modern programming languages and tools, there is in effect only one language that web applications can use in the client side, and this language suffers from nightmarish differences in implementation across browsers. Finally, web applications are still seen as “sites”, and therefore a lot of effort is wasted in making them pretty, sacrificing consistency, native looks, user preference, and quite often, good taste. Portability (for example, to mobile devices) usually means reimplementing the UI from scratch.
Instead, I would prefer to see my multi-user client-server applications using object-oriented semantics, a consistent, cohesive, hack-free model, a stateful and session-based protocol, and the flexible, portable user interface semantics already mentioned above. Portability would be automatic; once there is an UI “viewer” for a given platform, it can display any application, with native, consistent appearance and accessible semantics, and respecting user UI preferences.
More than 20 years ago, UNIX and its library model freed us from the language-lock; we can now easily make full use of system resources regardless of what language we choose to program in, and even implement different parts of our program in different languages. However, this freedom is mostly at the library layer only, making it relatively difficult to enjoy it. Furthermore, it helps a lot less with dynamic (or “interpreted”) languages. In practice, a modern project still has to pick a language and stick with it, with a few rare exceptions (where it picks two).
Instead, I see no reason why a central object model couldn't connect assorted pieces of code, regardless of language.
With the insistence in the “application” model, we got to a point where every piece of software interesting enough that you'd want to modify, is exceedingly complex and hard to understand. Want to fix a bug in Firefox or OpenOffice.org? Please, by all means, but you should set aside at least one week to understand the existing code and how things work.
Instead, I want a world of small, discrete components that talk to each other, each one relatively easy to understand and modify. That would also mean it's easy to modify them; you can change only the part you want to change, and you don't have to rebuild and restart a whole, enormous package in order to test your changes and discover you forgot a comma.