3 ms·

The file system is a storage medium that is ubiquitous and requires no install. It's an implementation detail, (and convenient for piggybacking on the Java clas

The file system is a storage medium that is ubiquitous and requires no install. It's an implementation detail, (and convenient for piggybacking on the Java classpath construction), but semantically Clojure can be represented as a graph where terminal nodes are forms and internal nodes are namespaces. I bet you could save all that to a db if you want, and load it all into a running repl again as well. You can put all your `ns` forms in one file, one after the other, and if you really wanted that top level s-expression, you could make a macro for that as well (check out the `ns` definition). Still you're stuck with the single file where everything lives, unless you want to move into a graph-db, but why? You'll have to bootstrap from code as text stored somewhere (even in your memory) at some point. > IDEs that can collapse and expand code tree as needed. This is "only" a representation problem, because the semantics are already there, you don't have to change the storage medium to buy this behavior.

jmiskovic 7y ago
Thanks for shedding some light on technical side. I'm still conflicted about the mental model. 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. 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. > This is "only" a representation problem What if I want to write new function? I still have to redirect it to specific location in specific file.
- sooheon 7y ago
  > 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.

jmiskovic 7y ago

Thanks for shedding some light on technical side. I'm still conflicted about the mental model. 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. 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. > This is "only" a representation problem What if I want to write new function? I still have to redirect it to specific location in specific file.

sooheon 7y ago
> 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.