"Peter Wood" <peter.wood / worldonline.dk> wrote: > "Ben Tilly" <ben_tilly / hotmail.com> 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.