From: Dave Thomas Date: 2001-01-16T23:42:54+09:00 Subject: [ruby-talk:9380] Re: 101 Misconceptions About Dynamic Languages "Christian" writes: > I understand that. That's why I compared reading to *execution*, not > to writing. Most code (at least, most good code) is executed more > than it is either read /or/ written. The rubber has to hit the road > at some point. What I meant by the carts and horses reference is > that it is a trap to worry too much about either syntax or > semantics: what we do is write software, and the practical use of > that software is really all that matters. Actually, the sad reality of the development world is that what we _mostly_ do is to maintain software, and often software that's not our own. In that environment, code readability becomes critical. I think that you may also be over simplifying the development process itself. In the business worlds where I consult, clients are rarely 100% certain about what they want. They'll either come out and admit that up front, or they'll say they want something, only to change their minds when it is delivered. Traditional "big design up front" techniques just don't play in that environment. Instead, we want a tool that lets us deliver quickly, and then refine in light of client feedback. (This is one of the bases of XP). Code is not write once, nor is it rarely read. The reality is that there is no one "best" language: it depends on the individual circumstances. I personally am coming to believe in a hybrid approach. It works something like this: 1. A client says "I want this" 2. Implement functionality in a language such as Ruby 3. Show to client. They say, "close, but change this and that" 4. Implement changes in Ruby 5. Repeat 3 and 4 until client gets tired or correct functionality achieved. 6. Ask client about performance. If acceptable stop. 7. Identify most serious bottleneck. If due to speed of Ruby, try to improve. If not possible, reimplement that section of the code in something like C or C++. Otherwise do normal optimizations. 8. Repeat 6 and 7 until satisfied. This approach is actually more subtle than it appears. Steps 1 through 5 could be called programming, or they could be called specification writing. Often what we call it depends on the client's tolerance for new languages. Regards Dave