My new law of Ruby complexity:
For a Ruby application increasing in size at rate of X, with an amount of cleverness to cover up the complexity increasing at rate Y, the quantity Y is always greater than X, and Y eventually approaches positive infinity.
Working on Ruby projects has given me enough examples of "Where did that method come from?" to last a lifetime.
This is the personal site of Kurt Schrader. I'm currently working on a stealth start-up.
In past lives I've done a bit of the start-up thing, worked on some open source projects, did more than a little chemoinformatics work, and did a bunch of consulting stuff.
This is the current version of my website, which has been on the web since 1996 in one form or another.
If you want to reach me I can be found at kurt@karmalab.org.
So, is infinite cleverness good or bad? Are you arguing for more abstraction or less?
For discovery, there are good tools like Unroller (unroller.rubyforge.org). Decent IDEs should be able to tell you which methods are object methods, and which are mixed in. I think NetBeans Ruby can do this and I wouldn't be surprised if Ruby in Steel and RadRails can do it too.
Infinite cleverness is bad. Really bad. Especially when you're trying to bring someone up to speed on a piece of code that they've never seen before.
I'm all for some well placed abstraction, but a lot of the Ruby code that I've seen takes it way too far.
NetBeans Ruby is getting better at helping here, but it's still far too unstable for daily use in my experience.
Mark, I shouldn't need an IDE to know what a program does.
And you shouldn't need an IDE to do all your refactoring and setters and getters either. Just because you can easily generate a mountain of visible code and XML doesn't mean the poor slob who has to maintain it will appreciate it.
@cag: How do you refactor an 5.000 classes application without and IDE?
Peace -stephan
@Stephan:
You generally start any project with a document that describes the deliverables. This document serves as the basis for what the customer/user is paying for.
Then, we move to the design phase, where a document, or person in charge, relays what the client wants to the UI team. From this agreement the developers create an interface that meets the requirements. In some cases one might use an agile environment to proceed. If so, then the agreement will be much more flexible, but the deliverables document will, and possibly should, remain the same.
You see, the end result is that software is created that the user pays for, either through time (which you get back in the end when factoring ROI) or through actually paying for the software. The bottom line is that the line is black!
After you figure out what the client wants, and have the client accept the document describing what the client wants, you then pass that on to the developers. Who gives a spit to the wind what the developers do so long as they give the client they want...
However, it should also be of focus that the developers have enough forethought to actually develop software that WILL scale to the customer's needs. This means more money for less, makes perfect $$, eh?
Now, in order to properly assume, or at least take into consideration, a large ROI that your developers might provide, you have to have confidence in them. People will only give you money if they have confidence in YOU after all.
If your developers can not create an ROI that is acceptable, what does that say for your ability to hire those who you 'trust' to get the job done?
What I'm getting at:
If you hire developers who make, or lack the initiative to make, less of the cost of doing business, why are they working there?
Where's your doc?
Don't have any? Well, who hired the person who created the code... YOU, not the lack of an IDE.
Who are you going to blame, thin air? If you seriously think that the person in charge of hiring is not at fault for hiring a person who is not capable of creating code that's easy to understand, and/or learn from, then you're just plain nuts.
You've got one of two people to answer to: the guy in charge who's put in his marbles; or the guy in charge who answers to the people who've put their marbles in.
Saying you need an IDE to understand 5,000 classes is not going to cut it in the end.
grep works pretty well in most cases. for those dynamic methods and super abstract metaprogramming, i think you should look at the programmer rather than the language. bad programmers can use the most beautiful language and produce garbage with it.
If you mean that as we go along with a Ruby project and with the size of the project you start using idiomatic ruby more and more then I agree with that....