|
Re: Are Ruby's Open Classes a Poor Fit for Large Projects?
|
Posted: Aug 27, 2006 11:55 AM
|
|
> It seems logical to me that all these things in static > languages that slow individuals down may help groups work > together more effectively. But I just don't know because I'm > not willing to take a chance building a large project on a > dynamic language unless I'm sure ahead of time.
Groovy.
No one will ever force you to do anything differently, at least up to the point where your employer (or client) decides to go in a different direction and throws you under the bus. No one forced Cobol programmers to do anything differently until they started to not be able to find jobs (other than the ones hired to maintain all the old Cobol code).
Java is more productive than Cobol. By this, what I mean is that if you hand two teams of equal baseline skill a set of requirements -- one with Java, one with Cobol -- and each team can figure out how to work together effectively, the team using Java is going to get more done. It's going to have a better ROI, etc.
My claim, for which I'm not going to try to provide direct evidence here, is that by the same standard, Ruby is more productive than Java. *If* you can find a way to get a team to work effectively together, you will get more done in Ruby.
Your code base will be smaller and more flexible, so that when management changes direction and forces you to gut a whole bunch of requirements that everyone told you were set in stone, it won't be like trying to navigate through quicksand.
Your team members, once they know the language and tools, will get more done in a day when they output the same number of lines of code.
By virtue of being more concise, well-written code will be easier to understand to newcomers, because there will be less constructs to understand.
Because compilation goes away, the development cycle (write, build, test, repeat) will be reduced and your developers will be less frustrated by theor environment.
So that's why you should care about languages like Ruby: they potentially increase productivity, ROI, and all the other things that make your team a valuable asset to your employer (or clients).
The $64,000 question is from my qualification above: "*If* you can find a way to get a team to work effectively together, you will get more done in Ruby." So can you get a team to work effectively in Ruby?
How about this, instead: as a compromise, try Python. It's nearly as powerful as Ruby (though Python advocates will presumably say it is as good or better), it looks a lot more like Java, and the language comes with a substantial prebuilt consensus on what well-coded Python looks like, so you don't have to go to the trouble of writing 100 pages of coding standards to keep rogue coders from writing code that looks like obfuscated Perl. You just teach people the language, then enforce best practices that someone else has already written.
It *is* dynamically typed, and you are going to have to write unit tests. Think of unit tests as part of the overhead of doing software engineering in a dynamic language. Even with the overhead of unit tests, there is a significant net productivity win, and you will catch other bugs in unit testing that you wouldn't have caught until later.
Now maybe you've read all this and you still think that it's not really important for you, personally, to start learning dynamic languages. After all, there are a lot more Java jobs in the world, and you likely have a massive base of pre-existing code in Java. Fair enough.
But remember: Cobol programmers had all the same reasons to not bother to move to newer languages. The technology industry thrives on evolving new technologies to improve on old ones. It you let yourself stagnate, you run the risk of becoming obsolete.
|
|