What is most thought-provoking for me is the striking difference in the ways people approach programming. For now, I identified for myself two main camps: "a program as a formal system" (which should be considered as a mathematical theorem, and hence can be proven) and "a program as a piece of writing" (after all, we use language to create it, so all style and compositional considerations are valid). And there is the third "programming as engineering" camp somewhere in between.

One of the explanations I have is that maybe it is no more sense in discussing programming per se as in discussing text writing. It all depends on the nature of texts, and we cannot demand that poetic, technical, nonfiction, juridical, etc. writings satisfy the same requirements.

Similarly, if we accept that a computer program is an implementation of a certain mental model, we have to ask what does this model reflect, and consequently, formulate our requirements.

Say, I tried to adopt test-driven development practices, but with very mixed results. For a set of classes that implement certain well-defined algorithms, TDD works fine, since it's easy to formulate preconditions, postconditions, find out border cases, and create a list of reasonable test cases. But then I needed to write a program that graphically renders a mathematical formula defined with an XML-based language, and it turned out to be a different story. The formula simply looks right or wrong, and there is not much to be done with testing; here I ended up with iterative refinements that improve the overall look of the render.

Similarly, I see a vast difference between the programs that model "reality" and those that calculate, e.g., an income tax rate and consist primarily of huge amount of if-else clauses, being a verbatim reflection of the corresponding articles of the tax law.

There are myriads of ways people use computers now, and our views on programming are greatly biased with our personal practice. Sometimes I feel being occupied with a problem that is actually not a problem for most specialists in the industry, who are much more interested, say, in a software architecture that can be more suitable for a team work (even if it isn't the best for the given task).

Maybe I can go as far as claiming that in general such debates as "OOP vs. functional programming" are rather misleading: if I want to model a flock of birds, let me have an object "bird" and create a flock of them; if I create a package for solving equations, the need of OOP can be disputed. In other words, in each case I simply need a language that translates my problem domain into a code in the most straightforward and terse manner.

Given all this, I believe that EM needs success stories and well-defined domains where its instruments are most efficient.

---

Just correct me if I'm wrong:

• empirical modeling is the process of analysis and modeling of a certain domain with the help of construals;
• a construal is a model, which, on the one hand, reflects the reality, and on the other hand, reflects the mental world of its author.

---