To clarify a little Chuck's projects were not rewrites in the usual sense, but they can still be read that way, as derefr suggests. His famous BASIC compiler f

To clarify a little Chuck's projects were not rewrites in the usual sense, but they can still be read that way, as derefr suggests. His famous BASIC compiler for example was an implementation of BASIC, something that's been done a thousand times before but Chuck's was not a rewrite of any particular program. Much of Chuck's code reduction comes from simply not implementing parts of the problem that most people would not think of eliminating. Other parts he will eliminate that most people would think inconceivable to eliminate. Other "secrets" of Chuck's ways are that he uses the CLI as a front end, or, spends a great deal of time working on an algorithm and finds a simpler way that is good enough in the application he's working on today. So instead of spending time optimizing for speed or modularity he's willing to specialize his subroutines per application to optimize for concision or simplicity. Somewhat like Woz's optimization to save chips. I bet most people who investigate Chuck's methods will feel disappointed that the methods don't seem as clever as the end product. What I think most people can take away from Chuck is skepticism about the utility of most programming technologies, which do automate tedium but tend to substitute their own architecture and complexity, for a net loss.