My physics teacher likes to say that physics like to make problems they face look like ones that they know how to solve. A simple harmonic oscillation was one he frequently used in class, as is presumably the case in physics in general.Anyhow, why they do such is simply so that you can solve a problem to meet homework deadline, get a novel prize or whatever.
In computer programming, I think, there is a similar case as well. A newbie, as he learns programming for the first time, quickly realizes that he can and need often use a common pattern when writting code. For example, in dealing with a set of elements, handing each item at a time iteratively is a quite common technique. If not in procedural programming, one but programs in functional programming, still, recursively calling a function with unfinished items and results is almost only way to go. You hardly get surprised: everyone solves a problem in the way you are so familiar and so knowledgable. Extreme programming works nicely because most of the time, what you have to do is code and test things very very carefully rather than solve problems you don’t know how to solve. You have to create a text editor? Then immediately you expect you are going to make a program with a big data buffer that is modified as the user wants and GUI components displalying the content of that buffer. MVC is but a natural consequence.
The situation changes when you start programming using OOP, reusable components, concurrency, Haskell or anything looking unusual. Code become a manifest of the world view, philosophy about computers. The creators of Next thought it is insanely great but not many people, many enough for being commercially feasible, shared the view. Smalltalk was meant to be intelligent tools for all of us humans, but it simply did not solve our problems for computers: number cranking. Then we ask why? The following are reasons I suspect might be a case.
* No one knows what is OOP; it’s not like math we all have struggled for years, nor is von Neumann machine that every computer user is familiar with (we cannot do real programing for the turing machine). The claim that OOP modeling the real world is rubbish; diamond inheritance, subclassing, the principle of subtyping, danger in down casting, etc, etc, cannot be found in everyday lives.
* Concurrency is a fantasy; After all, computers do one thing at a time. Trying to make things look like happening at the same time only leads programming to the hell of scheduling operations, resulting in a profound fear that someday the program might halt all of a sudden due to deadlock.
* Reusabiliy, once seen as a key to solve never-materialized software crisis, is a fallacy of false analogy. Making software is not quite the same as manufacturing automobiles. A software component can be copied without any cost. The term reusability and scenarios it tells us will not happen. We need a different jagon.
* Haskell, despite the affection of computer scientists, is miserable failure. Lisp and its derivatives like Scheme are ones that are used largely and taught in school as a general functional programming language. Haskell may improve productivity dramatically but if non-geniuses cannot use it, it will remain as a toy not a tool for real programmers.
* Prolog? AI? Genetic algorithms? Voice recognition? Agents? …. Who has any clue about them.
In other words, this is the core of reasons why script programming; C++ style OOP, as oppose to Objective-C style or SELF-like style; UNIX-style IO operations, as oppose to Java-style; are so popular. As the creator famously noted, Perl was designed to solve real problems for real programmers. C is still a favorite of many real programmers. Computers cannot be more than computers. And so we must try to solve problems in the way we know, or the way that was used to because the architecture of computers is still the same today as decades ago.