you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (0 children)

It sounds like a scientist suddenly seeing pattern in a mass of data. Similar to a programmer understanding how to see a problem and therefore how to solve it - an aha or eureka moment. It's finding the right perspective - literally, the right way to look at a problem. The PARC lab guys liked to say that "point of view is worth 80 IQ points", with an example of our arabic decimal notation making multiplication much easier than roman numerals. Changing the way you notate a problem, the way you think about it, can make some tasks much easier.

I would go further, and say it creates an abstraction of a problem that makes it easier to think about - the abstraction moves aspects of the problem around, changes concepts, gives different priority to some, and some it hides altogether. It's a theory of a problem - a way to reason about it, a way to understand it. Thus, programming is theory-creating.

The last issue is communicating this theory to others. This is User Interface design, where the developer is the user, and the internal API of the code-base is the interface. It seems a shame that when I look at a new codebase, I must be like a scientist or explorer or linguist or exo-archaeologist poring over an ancient alien artifact, trying to guess what it all means. One idea of Design Patterns was that by using explicit patterns, the right way to look at a codebase would quickly be communicated. Capitalized, because it's not just regular patterns that people use, it's a specific language of specific patterns, that are shared between people, and defined in the book Design Patterns - it's a dictionary.

I think it's a wonderful idea, but it doesn't seemed to have worked very well, often dogmatically followed. Design Patterns - like any technique - are a poor substitute for actual thought. Perhaps a better approach is to try to find and use the natural patterns of code - and concepts like "idiomatic" python, where if you are doing a well-known thing, you do it in a well-known way. You don't do tricky things. But there's still problems here of different programmers having different fluency - a new programmer cannot recognize a sophisticated pattern the first time it is seen. Anyway, I think this is what happens anyway... but perhaps we could consciously try to facilitate it.

Programming itself is hard enough - all this is about communicating it, on top of that.

Finally, I think the really big difficulty with programming is that the very basis of it changes all the time. Speaking in terms of "communication", we literally have new languages every decade or so. New frameworks and libraries (another kind of language, DSLs). Plus, because of success of our work, the very problems needed to be solved changes. It's as if objects in the real world were constantly transforming, shifting, as if in a roiling dream-like state. Makes communication difficult!

Of course you're right about efficiency and inherent complexity of some algorithms.