Possibly a question that you never thought would (or should?) be asked and one to which the one-word answer has to be “no”. But its “no” with some interesting caveats.
Dabbling with force.com reminded me of my experiences with Smalltalk. The most striking thing about it is the thing I really loved about Smalltalk: you develop in the same environment the user uses. This is an incredibly powerful concept that allows programmer and customer to literally work side by side in developing a solution (Dave Thomas called this a ‘super pairing’ in a conversation a couple of years ago).
The next most interesting thing is how quick and easy it is to do what you want. In Smalltalk/GemStone, adding a new field to the database was a simple as adding a member to a class. No SQL to generate and run and no object-relational mapping layer to define. In DST (the Smalltalk CORBA product if you remember CORBA), making a method available remotely was a simple as including it in the IDL; no stubs and skeletons to generate and tailor. In force.com you add a new field to an object and there it is available in your forms, reports, via the REST API, and so on. Ruby/Rails may be a step forward from J2EE but its still not as easy as this.
These two combined means its very easy to work with your user to thrash out ambiguity, explore difficult concepts and making small change without having to resort to mock-ups or smoke-and-mirrors ‘rapid prototypes’. It might not be the way you want to do everything but its great for many of those features that are really important to the user.
Like Smalltalk, everything in force.com – including, tabs, object definitions, classes, pages and workflow tasks – is an object, a degree of simplicity that Java can never hope to achieve regardless of how much autoboxing and annotation you put in it. Everything the user uses in force.com has state, relationships and behaviour that are easily accessible by the developer in a single technology. Simple and powerful.
There are a number of rough edges, the such as atrocious support for debugging (back to the days of printf(“You are here”) again!) and the Apex language is, shall we say, pragmatic rather than elegant (as I said, I do have a passing interest in language design) but I can see those being smoothed off quite quickly as the developer community grows and the force.com developers have to start supporting this community.
Clearly force.com is a product delivered as a service run by a for-profit company where as Smalltalk is a general purpose language supported by a community of enthusiasts and commercial organisations so there is no direct comparison. But some of the old ‘Smalltalkness’ that Java never really gained despite trying very hard is very much present.