[ruby-talk:9380] Re: 101 Misconceptions About Dynamic Languages

"Christian" <[e-mail]> 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