<blockquote>Certainly Cocoa and Rails are not identical, but I'm curious if you have specific issues with Rails that are due to class structure, or you'd just anticipate problems based on what you've seen?</blockquote>
The world of problems that Rails is well-suited to solve is much smaller than Cocoa's. This isn't necessarily a bad thing, it just is what it is. For example, Rails assumes that the database schema does not exist beforehand, but is created to serve the app, and is managed according to the needs of the app. No, it's not "technically" a hard limitation since you can make Rails work with an existing db if you put in the effort, but it's clearly a poor fit.
Another example: Rails makes little effort to factor out common application model functionality into libraries that are reusable outside the web app itself. Most classes, if not outright assuming they're running in a Rails web environment, are at least decorated with features and methods that are specific to the web app. This is different than creating a completely generic data model and supporting classes, and then building a web app, offline batch jobs, a desktop app, etc. all on top of these generic libraries.
In general, Rails is up-front about its assumptions and limitations and scope of applicability. The less your app and dev environment is like the prototypical Rails app and company, the more "impedance mismatch" you'll experience while trying to use it.
For example, if you have a big, complex, preexisting database schema managed by a team of DBAs and accessed by many different apps owned by several different departments, Rails is probably not a great fit for your app.
Cocoa, on the other hand, has a much broader range of applicability, from NetNewsWire to Aperture, hobby/home-use apps to the Fortune 500 "enterprise" apps, or even games. As for Cocoa moving towards more sameness within apps, I think that's only true among apps that already do very similar things.
Cocoa is just much more mature and flexible than Rails. In a decade or so, if Rails is still kicking, maybe its toolset and range of applicability will have broadened. But maybe not, if the current design philosophy is still adhered to. Rails solves very specific problem in a particular environment. That's one of its greatest strengths, but also its most fundamental weakness.
by John — Mar 01
The world of problems that Rails is well-suited to solve is much smaller than Cocoa's. This isn't necessarily a bad thing, it just is what it is. For example, Rails assumes that the database schema does not exist beforehand, but is created to serve the app, and is managed according to the needs of the app. No, it's not "technically" a hard limitation since you can make Rails work with an existing db if you put in the effort, but it's clearly a poor fit.
Another example: Rails makes little effort to factor out common application model functionality into libraries that are reusable outside the web app itself. Most classes, if not outright assuming they're running in a Rails web environment, are at least decorated with features and methods that are specific to the web app. This is different than creating a completely generic data model and supporting classes, and then building a web app, offline batch jobs, a desktop app, etc. all on top of these generic libraries.
In general, Rails is up-front about its assumptions and limitations and scope of applicability. The less your app and dev environment is like the prototypical Rails app and company, the more "impedance mismatch" you'll experience while trying to use it.
For example, if you have a big, complex, preexisting database schema managed by a team of DBAs and accessed by many different apps owned by several different departments, Rails is probably not a great fit for your app.
Cocoa, on the other hand, has a much broader range of applicability, from NetNewsWire to Aperture, hobby/home-use apps to the Fortune 500 "enterprise" apps, or even games. As for Cocoa moving towards more sameness within apps, I think that's only true among apps that already do very similar things.
Cocoa is just much more mature and flexible than Rails. In a decade or so, if Rails is still kicking, maybe its toolset and range of applicability will have broadened. But maybe not, if the current design philosophy is still adhered to. Rails solves very specific problem in a particular environment. That's one of its greatest strengths, but also its most fundamental weakness.