Oh, I know a lot about ORMs. You just seem a little angry that people don't agree with your views on them. You calling me inexperienced demonstrates this when, in fact, the contrary about me is true.

Also, they put the ability to write your own code in there for a reason. Reasons like I discussed in the GP. I'll bet that between your code and mine, people will pick up and learn my code faster than your convoluted object model ;-).

Peace.

I'd guess they compare RoR to PHP because that's the only "compelling" tool in Ruby to use for web development. At least, it's the most well-known one, meaning it's better for production environments, because it will be more stable and have more developer mindshare than X framework in Ruby.

So, I think the real debate is over whether to do things in PHP, where mindshare is massive and there is no ORM (which I think is great... though maybe a PHP ORM does exist) or whether to do things in Ruby+RoR, where mindshare is much smaller and ORMs are in play (you already know my personal opinion about this).

Any RoR developer I've ever talked to was just into it because it was "hip". That's fine and all for toy projects, as I've used that excuse in the past, but it's not an appropriate reason for choosing production-level languages. For that, you just have to sit down and hammer out the details of what the tools/languages are going to offer you or prevent you from doing (easily).

My comments aren't to say that RoR doesn't have benefits that actually make it useful. In fact, that'd be difficult for me to say either way, because I have not used it.

I do know that, in general, ORMs are slow, difficult, and language/library-specific when compared to some more general DB access libraries out there. Really, it doesn't take a lot of code to setup an object that can use a DB in an optimized fashion if you just write that code yourself, and it'll be a lot clearer without all the "magic objects" floating around.

For examples of slow code, try writing Hibernate apps in Java that must use saveOrUpdate() when you could easily write some more explicit code to do any pre-caching for you. Same principle will apply to other ORMs.

No, you can just use set a boolean in your inner-loop that outer-loops use when you break from the inner-loop. Also, you can create inline functions if you really wanted to go that route.

As for C++, 64 KB of bloat for exceptions is nothing compared to the performance cost of handling exceptions. For the architectures you mentioned, it's an issue, which is why C++ either isn't used or is used without exceptions. However, for the majority of systems, exception-handling performance trumps a boost in run-time size.

How much time did you spend getting your desktop running? I've run them as well (and still do), and it took a lot more time to get it running than it did the first time I ever used Windows or OS X. I haven't ever heard anyone say that they had a first-time full multimedia setup going in a FOSS OS faster than their first-time full multimedia setup in Windows or OS X. Newbs just don't know about Xine, VLC, all the codecs they'll need, where to get them, or how to handle their package management systems until they spend plenty of time reading about them. And, really, time is money, and it may cost too much in certain situations.

I think perhaps I wasn't clear with what I meant. I meant that people aren't going to create an innovative solution as a FOSS platform, because there is no immediate reward. Because, like I said, people want and need money. As far as I know, none of the products you mentioned are open-source; by the time they are (if ever), it will be because they see no more benefit in keeping them proprietary.

So, you give FOSS a higher default rating based on an ideological reason rather than an objective one? It sounds like you let personal views cloud your judgement when making software decisions. FOSS should only be one factor in the acquisition of something for use. I also think that in terms of TCO, going with an excellent proprietary solution, even if it is converted to a better FOSS alternative in the future, will be lower with the proper development team in place. The only time this may not be the case is if you have a team of developers that's really going to broaden the base product and make it genuinely awesome for your task.

Really, the software we use should be used because it's the best tool for the job. If it's a FOSS solution, great. If you have to pay for the appropriate tool, do it. Vary your choices according to objective reasoning and budget constraints. If you feel a FOSS alternative should be created, do it, but that points back to my point about people not innovating on FOSS platforms.

I think you're mistaken about proprietary software being on the way out. We haven't had a "Year-of-the-Linux-desktop" yet, and some proprietary software is just plain better than FOSS alternatives, if a FOSS alternative even exists.

I don't think most companies are ever going to innovate on a FOSS platform, because there isn't any real money there. Innovation is driven by money, and people want it. FOSS, thus far, has typtically shown itself to be promising when commoditizing solutions.

Not to say that I don't love FOSS applications. I have a FreeBSD NAS/router I built at home, and I use lots of FOSS components on my systems. However, some of the coolest new apps I see are proprietary, at least until a good FOSS alternative is released, in which case it's no longer new.

At work we also use lots of FOSS, but we also use lots of proprietary tech. I think the real value comes by using both to get the best of both worlds, and I think most people in the world that care about staying on top think this way as well.