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

"Peter Wood" <[e-mail]> wrote:
> "Ben Tilly" <[e-mail]> writes:
>
> > I like analysis.

[snip interesting text that I'm going to mull over later]

> This was a very interesting post.  I would like to ask you whether you
> think the following description fits the algebra/analysis gap:
>
> (1) Use the most straightforward mapping of the problem description
>     directly into [...] code.

It seems to me most natural to think deeply about a problem, construct a
conceptual hierarchy for the problem space, and design a set a supportive
classes, algorithms and adaptors that can be used to provide solutions.

I have found that by designing template structures and functions, you can
defer the details til later. But 'later' never comes: the structures are
complete as soon as you have provided all of the necessary concepts (I use
the term 'concept' in the formal, STL sense).

You can very easily drastically change the nature of a solution by using
different parameterised types. The concepts remain the same, but when you
concretise them, you find yourself confronted by a different beast. A
vector<set<string> > is a very different thing to a set<vector<string> >,
but you are using the same concepts in either case.

By factoring out the underlying concepts and expressing them as a system of
generics, you often find that
you can reduce their number further and further. It is exactly
like distillation; constantly removing the scum off the surface then
applying
more heat. I think it was Tolstoy that said "A novel is finished when not
one more word can be taken away".

The most enjoyable part of the design process based on concepts is when you
collapse two concepts into one, simpler but deeper concept. That is
wonderful. When you started, the problem seemed murky and complex. Over
time, through continued refactoring, another concept arises that removes the
need for two or more other, previously disparative concepts.

Now, this is conceptual algebra. To me, this is programming. The Pattern
People would have you believe that they can produce a taxonomy for all (or
at least many, or maybe some) useful concepts. Rubbish. It is my life's goal
to track down and burn every Pattern text in existance :P. They are
intellectual Nazis. You must be able
to make your own concepts to suit the problem at hand.

Build your own taxonomy, willing all the while to throw out or replace that
which is no longer useful or that which constrains your ability to express
efficient solutions. Yes, it is hard to know what is a fetter when we think
only in terms of fetters.

> (2) Use the most natural notation available to solve the problem, and
>     then worry about writing an interpreter for that notation.

I love this approach. That is why I love using ANTLR (www.antlr.org).

However it really is just like the first approach, it is just more work.

Providing a hierarchy of concepts and models, supported by a set of global
algorithms and adaptors (yes, STL was very influential) is exactly what you
are doing in either case. When you do so, you provide a 'language' in either
case. One is just more explicit about it than the other.

> Christian (and presumably you?) would appear to favour (1).

You are right, but I also favour (2). It's just that I rarely have the
luxury of making a new language to solve a problem. If the problem is large
enough (say, defining the behaviour for AI's or scripting object
interaction), an explicit language is useful.

> Regards,
> Peter

Christian.