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

> Dave> 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.


Ahh I see an issue here, and it embaresses me a little. I am a game
developer; more specifically a game systems programmer (mostly graphics and
networking). I replace and update my own code continuously as required, and
not many other people need to understand how it all works in every little
detail. It must be efficient, intuitive, and expressive to use however.

The rapid prototyping technique you listed is a rational and appropriate way
to solve many small to medium scale problems. I use that approach myself
when introducing myself to new issues and problems, recent examples being 3D
pathfinding, simulating cothing, and filtering object state. However in my
case I just used C++ (and OpenGl or GTK or ANTLR etc) for each stage of the
development. Occasionally I'll use stackless Python instead, but I prefer
C++ when things become large. Yes, I've already been told I am a masochist
:P

Either way, at the end I get an application. But that application at this
point is very simple: all of the complexity is provided by a newly-born
system that I then integrate into the general game systems used by the
company.

One might think our respective tool sets would differ. But I'd argue that
that isn't necessarily true. I am here aren't I :)? Similiarly, you /can/
rapidly prototype in C++.

> 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.

Very true. The term 'specification writing' is functionally equivalent to
'problem description'. But excepting a few examples, although a language
generally suggests a framework to solve problems, one can easily 'overide'
this framework, or build completely new and completely unique frameworks.
Isn't that the beauty of programming?

As well as language intolerance, I have also experienced intolerance for new
techniques within a /fixed/ language. But in my experience, when faced with
good efficient software any argument soon dwindles.

> Dave

Christian.