Refactoring in a large code base

[Thomas Mellman]

On Fri, 22 Jan 2016 04:04:44 -0800, Rustom Mody wrote:

> These are just specific examples that I am familiar with Chris' general
> point still stands, viz take the large and complex program that is
> cpython and clean up these messinesses: You will still have a large and
> complex program

I'm not really sure what the point is we're working on...  let me
propose these:

- unix principle is good: keep things simple, limited in scope.
  Then leverage that.

- there will always be complexity, but if the complexity is
  modularized, it's controlled.

  In particular, the complexity of a program should represent the
  complexity of the problem.  I call that "structural complexity".
  To be avoided, corrected, is "superficial complexity",
  where the complexity of a system is squished into a single (or
  reduced number of) planes.  Like vomiting a program onto a desk.

- "Advice" that the program needs to be refracted is generally not helpful.