> code diet . . . (limit of 10K lines) Yes, sort-of, although . . . A simple example 'in the small' to consider: function/procedure size. Should we (syntactic

> code diet . . . (limit of 10K lines) Yes, sort-of, although . . . A simple example 'in the small' to consider: function/procedure size. Should we (syntactically) limit functions to, say, <30 lines? What we are really trying to do here is limit complexity. And that is not simply a result of length, but more of interrelation. If we recall Dijkstra's intent with 'Structured Programming', it was to make complexity proportional to program length. It is not the total amount, but the way it is arranged or broken up. Strict size limits in effect sort-of do that -- they make complexity nearer constant (since it is bounded) within each part. > should create a DSL at their particular level And that leads to why the DSL idea (or something else to do a similar job) is more important than the simple limit idea. What we want primarily is different structuring. In terms of the function-size example, we can (rather ideally) compare imperative with functional programming. FP languages seem to tend away from the length problem: because they are more trees of expressions instead of sequences. They have different structuring basics that control interrelation complexity more. To put it briefly: we want it so you cannot add length without also adding 'depth' (of abstraction, of levels, of separation). Expressed more fully here: 'Should there be hard limits on program part sizes?' http://www.hxa.name/notes/note-hxa7241-20101124T1927Z.html http://www.hxa.name/notes/note-hxa7241-20101124T1927Z.html