Experience with OOP is certainly essentially, but mostly for the reason that the OOP language you're using sucks. Most of the "handy dandy patterns" that have sprung up are to recover properties that should have come for free, but didn't. As a result, code isn't objectively good or bad -- you must consider how it will be used. All of the boilerplate crap you have to write has a flat cost and a benefit proportional to how things scale in certain ways. The author of this piece is advocating "don't write any boilerplate crap at all", which we agree isn't the right answer. But experience or no, you'll get the design wrong too, because you can't predict how your requirements will change. In summary, repeating my earlier point, your OOP language sucks.
Let's take C#'s advancements over Java as an example. The LINQ features are clearly imported from the functional and/or dynamic world as replacements for iterator patterns. C#'s closures make Strategy and Command patterns basically irrelevant. Events and Delegates replace wiring up an Observer pattern.
A meta-concern, if you will, is that general OOP principles don't apply in the same way in dynamic environments the way they do in statically typed environments. When I'm in Ruby I'm not nearly as concerned with coupling and some of the larger architectural concerns the way I am in Java/.NET. Because the language is dynamic, to some degree everything is an interface, and there's no need for complicated frameworks like IOC, etc.
There's also no need for all the overhead of learning and managing generics/parameterized types. All those angle brackets and abstractions just to support what amounts to a more robust compile-time unit test. Makes me tired just thinkin about it.
Java is Java and I don't know if I would say it "sucks." I do know between it and Ruby/Rails which one makes me about four times more productive.
Have you found your productivity level stays the same as a project matures? My experience has been Ruby or Python allow me to ramp up quickly, which is great, because quick wins help boost morale early on. But after 6 months or so, I found productivity roughly evened out on several projects. Right now I'm fighting with a lot of things in Ruby & Rails that I know would be trivial in Java and on the JVM. FWIW, I'm trying to cut over to JRuby to see if I can somehow benefit from the best of both worlds.
I'd have to say yes, once I got comfortable with good Ruby practices I found it was as easy if not easier to keep the code clean as projects mature.
Some of the code-browsing and refactoring tools aren't as smooth, but they're also not as necessary.
I suspect you're dealing with concurrency issues? In that case, yes the JVM is brilliant at that and JRuby might be a great option for you. Ruby concurrency is coming along though. 1.9 is no longer green threads, and Rubinius has gotten rid of the GIL altogether.
Most of the issues I've run into are environment related. I can make 1.9.2 segfault with ease, but there's mounting pressure against supporting REE. Libraries seem to rarely support backwards-compatibility, so I spend an inordinate amount of time backporting fixes or trying to upgrade a large dependency graph. And as you noted, concurrency is problematic.
So, when looking at productivity, I'm not necessarily looking at the language itself, but the entire environment I need to work in. I may just be doing something grossly wrong, which is why I inquired.
If it helps frame things at all, my primary project is coming up on 2 years old and started as a Rails 2.3 app that recently had a very painful upgrade to 3.1 (took on the order of 75 hours). And I had a couple years experience prior to that doing Ruby & Rails stuff.
Ah, gotcha. Yeah, config issues can be painful in many environments, and Rails has its own brand of frustrations, particularly when upgrades are concerned.
This is just a shot in the dark, but if you're on REE/Passenger and getting thread/segfault issues, you might try Apache's Passenger config with the conservative spawn method. I've had similar issues in the past resolved by simply not using REE's shared memory.
Thanks. I had to do that recently because of issues with the prepared statement pool in 3.1 + Passenger. But I can segfault in 1.9.2 just by loading a console or running tests. It doesn't instill a grand sense of stability.
Thanks for the feedback though. I find it helpful to do periodic sanity checks.
But I'll also say that crappy OOP (CROOP?) is a language-independent concern. Those guys who I talked about taking six weeks to refactor? That actually happened and they were on a Rails project.
