We consider how to organize a program when there is one thing to do and you want to get it done. I favor a single collection of functions in invocation order with a single and flexible entry point. This is similar to the way Roger wrote code. wiki
# say what this does # say how to start it import libraries define this define that define main call this, that call main
This would be the preferred structure of a ruby script or a sinatra service. Functions are defined before use placing the entry point at the bottom. This is natural when developing bottom-up where the purpose of main grows with the program.
See Grades where automating an end-of-semester chore resolved nicely for me within Pascal's define before use organization.
I've come to prefer arrays and hashes to objects that don't serialize to json automatically. When I feel the need for an access method I just write one and pass in the structure to be accessed. Circular structures are rarely worth the bother.
I contrast this with opinionated organizations such as ruby on rails which has provided considerable leadership for programming in the large. Prefer this technique when it is important to not be large.
I write many custom print functions where others might write tests. These emerge from temporary main programs written when a program is started. A programmer's text editor will run these with a single keystroke. I leave informative calls in comments and reuse them when returning to a program months later.
See Io Game for a variation on this were print functions had expected values and were written only when I felt progress slowing.
Projects often consist of a collection of scripts kept in a directory and checked into source control. They might call each other or be orchestrated by another script or cron.
Projects might present themselves as web services with a minimal ui for reference and health checks. Here I would keep logs in an in-memory circular buffer and print them nicely when asked.
I remember reading a paper in the '70s explaining how Lisp programmers of the era incrementally wrote code. It was pretty much this with the aid of backtick macros to keep thing orderly.
I've seen my small programs turn into large ones and have been criticized for being insufficiently object-oriented in the process. I respond suggesting we start over with careful attention to object roles and responsibilities. This turns out to be just refactoring but allows for thoughtful discussion of the code's future with new colleagues.