Found Graham Glass' comments on X# through Jason Whittington's musings, and actually, I kinda agree with Graham, although this is an issue I'm ambivalent about...
I think it al comes down to what your problem domain and application type are. So, while I really like OOP¨, I think it really sucks at some tasks, and one of those is, hear this, Enterprise Applications. The problem is, that while OOP solves some of the difficulties that appear during Enterprise Application design and implementation, it also adds it fair share of limitations and difficulties of its own.
Most Enterprise Applications (EAs)I've worked on are all about manipulating data: Getting data out of a DB and displaying it, updating the data, moving data around, etc. While "Business Logic" sure is a large part of them, I found it's not necessarily the largest part.
Actually, the largest parts of most EAs are related to getting the data in and out of the database, preparing the data for displaying to the user, formatting data around, drilling down through data, etc. While there are tools here that help, still a large part of a project is done implementing this, which is further exasperated by the fact that most EAs need to present multiple representations of the same data, or with different levels of details, which usually implies yet more DB-access code, more formatting code, etc.
Now, if you're not object-freak, you might reach for a paradigm similar to what MS data access technologies have always projected: most data goes into a data-container (a Recordset/DataSet/whatever), and components (think objects here, really) have methods that act on that data. Again, this helps somewhat, but also brings yet another whole different set of problems and limitations with it, the least of which is not that you really loose a lot of control about the datatypes and data manipulation is relatively poor (yep, even in DataSets).
I guess my point is, I'd love to see a more flexible way of dealing with data, and one that allowed me to even deal with data types in a more flexible fashion (guess I'm finally catching on to Tim Ewald's "Loose-coupling and run-time typing" comment... or at least I hope I am), while still making it easy at design time to deal with the data. See, most strongly-typed languages, like C#, make it awfully hard to deal correctly with data for which no typed schema is known at compile time, and sometimes, knowing the schema at compile time makes it significantly harder to maintain and evolve the application...
Graham's idea of free-floating operations and entities is not that revolutionary, as I see it. It's very functional-programming like, and I for one, think it might make a lot of sense, specially in distributed applications.
Then again, this is just my opinion. I could be wrong, or I could change it tomorrow. No guarantees...
