> You have to think a bit more about what OO really is about.
If you want to have a respectful debate, I'm completely game. If you'd prefer to continue with your incredibly condescending tone, then I'll bow out here.
I've read at least a dozen papers on the history of OO, not to mention books and papers on current practices. This is what I came up with. I made what I think is a pretty coherent argument for why in the article. I'd love to hear your refutation of the points I made in there.
You can move over slowly by building new components using objectify, and leaving the rest of your legacy app the way it is, if you like. It's designed specifically to be able to coexist with what you've got.
> It's hard to strike a balance between a strong design which takes a lot of time to work within, and one that just allows you to get things done, but once your project begins to grow in size and complexity, and testing becomes even more important, these things really do start to matter.
The whole point of objectify is that it actually makes it pretty reasonable to work this way right off the jump. I would have a hard time believing that it's really any more work to build an objectify app than it is to build a vanilla rails app - at least once you become accustomed to the paradigm.
> That said, if you have a large amount of single method classes, you might need to take a look at why you need them and find a better approach (which will vary from project to project).
I don't buy that. My project has hundreds of single method classes and it's by far the best factored non-trivial application I've ever seen (anecdotal, obviously, but so it goes).
Mixins/modules and open classes do not separate your class in to multiple components - merely multiple files. As I explain in the article, for separate components to be useful, they have to be "protected" from each other - encapsulation, in other words.
> ...the division that would be caused by a fork...
You still haven't explained what the problem with this "division" is. Why will this be different than the rails/merb fork? Honest question: are you afraid of division or of your friends losing control of the project?
> There is no denying that Eric+Ryan have had personal conflicts with Loren...
As well as just about anybody else who has tried to work with them.
> However, Evan Phoenix...
Evan is a great and brilliant guy, but let's be honest here. He's another personal friend of the current maintainers and (former?) Seattle.rb member. We need fresh blood.
If you weren't paying such an enormous premium for your hardware, you'd have a lot more cash. On a per-dollar basis, you're paying anywhere from 2-10x the price for computing power on the cloud, depending on which resource you look at (CPU, Memory, Disk IOPS, etc).
The fundamentals of capacity planning do not change based on the magnitude of your data growth. Why would they?
We're mostly talking about looking at your data growth curve and extrapolating points in the future. Why would that become impossible just because the curve is steep?
First of all, there are managed hardware providers who can get you hardware online in less than 4 hours. Second of all, capacity planning can save you from "needing elasticity". Third of all, if you were on machines that gave you reasonable performance (i.e. not shared hosting), you probably wouldn't "need" nearly as much elasticity.