You used a framework because the 60% to 20% initial development was fast? Non-static typed languages are quite hard to maintain (some types can’t be guessed, especially with lots of meta-programming-magic involved). So the 40 to 80% maintenance will be hard and expensive. As a project manager I had to drop some massive Perl and Python programs in the 90s due to maintenance problems.

“So the big question now is, have we [...] finally hit the point where the cost of maintaining our code in Ruby is higher than the savings by writing it in Ruby in the first place?”

Yes.

“… (and perhaps we’re the first team to do this, as I haven’t heard much about it from others) …”

People talk about this all the time, especially people with experience in large legacy apps. The RoR and Ruby community has shut it’s ears and has scorched everyone who suggested high maintenance costs for massive Ruby/RoR systems.

Peace
-stephan
–
Stephan Schmidt :: stephan@reposita.org
Reposita Open Source – Monitor your software development
http://www.reposita.org
Blog at http://stephan.reposita.org – No signal. No noise.

[1] I talked to some CTOs and project leads about this, and they all shared RoR maintenance problems with big deployments.

In the technical space it’s usually the different level of expertise (or lack thereof), personal preferences, prejudices and basically anything that can be described as trendy that will surely overtime make you application look like a big pile of poo.

The best defense against this is to keep things separate and truly orthogonal. Bolting onto the same system just makes code rot that more egregious.

Refactoring tools and such are getting better, though, as most Java IDEs (including, as it happens, IDEA) are gaining Ruby support. NetBeans, for example, already has some rudimentary refactoring support. I daresay things will only get better.

It’d be interesting to see Rubinius going in the direction of the StrongTalk VM that seems to have added type inferencing (whether it was limited or not, I don’t know) to Smalltalk.

Regardless, it amuses me greatly when people seem to imply that dynamic languages are hard to add refactoring to (and perhaps that’s not what Stephan was implying when he made the comment about dynamic languages — that’s how I understood it) when refactoring practically came out of the Smalltalk community, Smalltalk being a dynamic language in exactly the same vein as Ruby.

I know the community to shut it’s ears to maintenance problems, the argument usually is: Ruby is less noisy, leaner, smaller, more powerful and therefore more orthogonal, so there is no maintenance problem. This attitude might change, but at least from 1998 to around 2006 when I was active with Ruby/RoR projects that was the answer to maintenance problems with Ruby.

Type inference will not help you with all refactoring problems, not all types can be inferenced with DSL frameworks like RoR.

“… though, as most Java IDEs (including, as it happens, IDEA) are gaining Ruby support”

Working on a bigger Grails project, IDE support is great but doesn’t help you with refactorings and maintenance. Most of the time, especially as said with meta frameworks as Grails, the IDE has no clue about the type.

For example:

def person = request.map.person

person.smile()

What type is person? The IDE can guess, that person is Person.groovy – or not – and can narrow the type to all types with a smile method – not when I have dynamically added the smile method – or could try to simulate and trace the application (as JTest and others do) and see what one puts into person. Smalltalk has some advantage here, because it not only has compile time information, but runtime information and therefor can deduce what person is, at least at the time when Smalltalk checked the runtime type.
This information might be incorporated from a Ruby VM to a Ruby IDE, but we’re years from there and even then, not all types can be guessed correctly.

“Regardless, it amuses me greatly when people seem to imply that dynamic languages are hard to add refactoring to [...] when refactoring practically came out of the Smalltalk community, Smalltalk being a dynamic language in exactly the same vein as Ruby.”

First, Smalltalk refactoring is about refactoring Smalltalk applications, not about meta-programmed framework DSLs like RoR. I know of no Smalltalk refactoring paper which talks about meta-programmed DSLs.

Second, under the umbrella of refactoring, there are hundreds of concrete refactorings. Some are easy for every kind of language, like “Extract method”. Some are harder to do like “Extract superclass and use super class instead”. And some IDEs guarantee that your refactorings work, with some refactoring tools you need tests and a lot of manual clean up if something goes wrong. So refactorings are always possible, but some languages do not support secure refactorings (which people call “no-refactorings”).

Third, “Smalltalk being a dynamic language in exactly the same vein as Ruby”, there is a difference between Smalltalk and Ruby. Smalltalk is dynamic reference/static object language, while Ruby is a dynamic reference/ dynamic object language, at least more than Smalltalk is. So what applies to Smalltalk does not automatically apply to Ruby.

Last not least, Smalltalk uses runtime information to do refactorings, an IDE for Ruby doesn’t do that.

Peace
-stephan

–
Stephan Schmidt :: stephan@reposita.org
Reposita Open Source – Monitor your software development
http://www.reposita.org
Blog at http://stephan.reposita.org – No signal. No noise.

“Regardless, it amuses me greatly when people seem to imply that dynamic languages are
hard to add refactoring to [...] when refactoring practically came out of the Smalltalk community,
Smalltalk being a dynamic language in exactly the same vein as Ruby.”

First under the umrella of refactoring, there are lots of concrete refactorings. Some are easy
in every language, like “Extract method”. Some are easier in dynamic languages, because
you do not have to change every type declaration. Others are harder to do, like “Extract superclass and use superclass instead.”.
Others are harder still like “Move method” or “Rename method”. Some IDEs and tools guarantee
secure refactorings, for some tools and languages you need tight tests and a lot of manual clean up after the refactoring should
something go wrong or not as intended. Every language supports
manual(!) refactorings. You could argue that unsafe refactorings with manual
rework are not the same as safe refactorings or are no refactorings at all. But I hope for the best in IDEA with Groovy.

Second there should be some success in the future with tools but not now.

“Refactoring tools and such are getting better,
though, as most Java IDEs (including, as it happens, IDEA)
are gaining Ruby support.”

Support in IDEA – the best IDE will not help much.
Working on a bigger Grails project, IDE support is great to have in IDEA. But
most of the types in my Grails application cannot be guessed by the IDE, because
Grails is a meta-programming DSL not a conventional framework.

Sometimes guessing the type is easy, as in

def person = new Person()

But assuming the Groovy code

def person = request.person

person.smile()

the IDE has problems guessing the type of person. It could guess the type as
Person.groovy based on the name – but the programmer could just have been
thinking of something else. It could narrow the guess to all types with a
smile method, at least when noone has added one during runtime. It could
simulate and trace the application (as JTest does to find null pointers)
to see what has been put into request.person. Smalltalk has some
advantage here because it not only uses compile time but also runtime
information. But still it can’t guess the type correctly all the time
and we’re years away from a Ruby VM which supplies runtime type information
to an IDE.

Compare that to (legal Groovy code):

Person person = request.person

person.smile()

In that case, the IDE has much fewer problems to “guess” the type of person.

Third, “Smalltalk being a dynamic language in exactly the same vein as Ruby”.
Ruby is a dynamic reference/ dynamic object language while Smalltalk is a dynamic reference/static object language, at least
more static than Ruby. So not everything said about Smalltalk applies to Ruby.

You can write and maintain code with dynamic languages. But it is harder, it needs more discipline and planning. Both of those are seldom available with average programmers and the usual corporate enviroment.

Peace, -stephan

–
Stephan Schmidt :: stephan@reposita.org
Reposita Open Source – Monitor your software development
http://www.reposita.org
Blog at http://stephan.reposita.org – No signal. No noise.

With respect to unsafe refactorings+tests, you may save some work with so-called `safe’ refactorings, but they’re not really safe at the end of the day. They’re type-safe. The difference is large, because maybe the refactoring broke something that didn’t directly have to do with the type. So you have to run tests anyway; the only thing that changes is that you have a few problems that you don’t have to deal with immediately.

Nonetheless, I don’t deny that static types make certain refactoring tasks easier than they are in dynamic languages; the issue is that by doing that, you also sacrifice some flexibility. It’s a trade-off, as with many things, and different people prefer different sides of that trade-off.

Now, with respect to type inferencing and guessing — you’re right, of course, correct guessing is often near impossible. But when I was talking about type inferencing, I was talking about the SML/Haskell kind. The one that introduces static types without type annotations. I think it would be interesting to see a Ruby VM (or even an IDE) that could go into a statically typed, type-inferenced mode. You’d lose a lot of the value of duck typing, but it’d be interesting to see what kind of advantages that would give you.

As for Smalltalk being somehow more static than Ruby, it really isn’t. What’s different is the approach of Smalltalk programmers, who aren’t quite as keen to use metaprogramming as Rubyists (who tend to consider the programming-metaprogramming distinction semantic at best). Smalltalk itself is just as dynamic, what with support for doesNotUnderstand: and runtime compiler access. Certain things may not be quite as straightforward, and Smalltalkers seem to be a little more reticent in using some of the metaprogramming features in Smalltalk, but they’re there. In fact, occasionally Smalltalk is *more* metaprogramming friendly. For example, the VisualWorks implementation of namespaces allows you access to the list of classes in that namespace, something which isn’t quite so simple in Ruby. (/me munches his words; never mind, I’d missed Module#constants )

Another interesting addition to Ruby would be optional type annotations like Groovy has.

All this aside, I think your final comment is fantastic:

“Both [discipline and planning] are seldom available with average programmers and the usual corporate environment.”

Yes. I’ve been saying for a time that Java is what you use when you can’t rely on all of your programmers being great at what they do. When you can rely on that, your options are far more open, because you can go with more dynamic languages that require more discipline, because you trust that your programmers will have that discipline.