The real problem isn't "how do we organize files better?" but rather "why are we organizing files at all?"

I’ve been brainstorming about ways to solve the N-dimensional code organization problem, and am thinking about developing a Smalltalk-like code-browsing experience. Even after I left my Smalltalk job and moved to Java, I configured Eclipse to give me the same IDE experience: an object browser that let me focus on Classes and Methods, which was the level of abstraction I was working at. (And not files.)

How I see the problem:

When developers ask “Where does this file go? What do I call it?”, they’re really asking:

“How do I map this multi-dimensional concept onto a single hierarchical path?”

Example: A customer email notification worker

  • Domain: Customers
  • Technology: Worker
  • Integration: Email
  • Access: Internal

I think that the unit of thought should be:

  • Modules (not files)
  • Functions (not line numbers)
  • Concepts (not directories)
  • Relationships (not imports)

This is probably the most promising direction for truly solving the n-dimensional organization problem.

4 Likes

I think the problem can be solved by having a child so that you don’t have any time to worry about things like “where does this file go” and just put it somewhere and move on with the important business of having AI generate shoddy code to go in those files.

11 Likes

Some editors, e.g. VSCode paired with ElixirLS, let’s you view and navigate your project by symbol.

That can be both symbols in the current file or global across your project.

Nice thing is it also works for multiple languages, so that you can also navigate to say JS symbols and even Markdown headers (e.g. to jump to READMEs or documentation).

Maybe a setup like that would provide a similar experience to what you described?

I think you might like some of the ideas behind unison.

Each Unison definition is identified by a hash of its syntax tree.

1 Like

Wow, that’s very interesting!