> We should organize our code into deeply nested tree (with exception of cyclical references for recursions), but at top level we use linear and procedural mode

> We should organize our code into deeply nested tree (with exception of cyclical references for recursions), but at top level we use linear and procedural model A filesystem with nested directories and files is a tree. The contents of a file are read in linear fashion, for the same reason you'd read an s-expression character by character--because it's simple and consistent. > In each s-expression there is typically 3 to 5 elements, but at top level there's usually more than dozen definitions. It seems jarring especially when contrasted to elegance of s-expressions There is no law for the "branching factor" of code. It depends on your style, the problem, etc. It seems like a somewhat superficial elegance you're chasing. > What if I want to write new function? I still have to redirect it to specific location in specific file. I'm trying to picture what your ideal alternative is, and it doesn't seem much different. Codebase backed by a graph representation that explicitly encodes dependencies in code loading order? When you add a new sexp you add a new edge and node? That is essentially what we have now, `require`s `refer`s and `declare`s as needed, and the convention that you may depend on everything introduced above your current location in the file.