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. -- https://mail.python.org/mailman/listinfo/python-list