Become a fan of Slashdot on Facebook


Forgot your password?
Slashdot Deals: Cyber Monday Sale! Courses ranging from coding to project management - all eLearning deals 25% off with coupon code "CYBERMONDAY25". ×

Comment Re:I'd rather maintain Ruby than J2EE (Score 1) 295

The creator of Rails has expressed regret for that video, because it gives people the impression that CRUD generation is the most important feature of RoR. 99% of the J2EE work I've seen doesn't require high-performance, low latency distributed messaging engines. That's the edge case that Rails doesn't and can't handle right now. If JRuby ever progresses, it will get that. (I wonder if we could bolt a messenger framework to a Rails app, open sockets maybe?) Speaking of edge cases, Hibernate still kicks ActiveRecord's ass. For those of us who live in that 99% of projects that don't require those edge cases (or can drop down to SQL when AR doesn't hold up), there's a lot of productivity and elegance to the Rails community's projects. Have you seen Migrations? Things like that are a delight to code with. In the same vein, check out the config for URL mapping if you've ever been frustrated by web.xml. Tag libs and filters, features I appreciated when going from PHP to Java in 2001 are more straightforward in Rails. In the Java world I was already convinced that Hibernate/Spring was the way to go, and wanted to avoid EJB's as much as I could. I've worked with them, and they're f&*()g messy, barely testable, slow abominations. In Rails, I've got all the features I wanted to deal with in J2EE... so far, no regrets. But speaking of edge cases and awesomeness... have you played at all with Ruby (not Rails)? There's been a few times I've done thing in Ruby I simply couldn't have in Java, thinking "Fuck, I always wondered why it was so complicated".

Programmers used to batch environments may find it hard to live without giant listings; we would find it hard to use them. -- D.M. Ritchie