I wholeheartedly agree. As a matter of fact, that was the topic of my talk at this year’s GigCity Elixir.

It wouldn’t be popular with the VI EMACs crew but for those that are willing to use VSCode, might find an IDE that is more like the Smalltalk IDE very useful.

Features like

• Show me the call tree for this function
• Show me the headers for functions of this type in this module. Types defined by an @tag.
• Just show me the function I am working on and just the headers in a list window for all the others. So I don’t have to constantly scroll through a wall of code.
• If the module file name is by convention, then just use that convention and let me say “new Module X” and create the file but just show me the module definition. I should never need to look for the file. Just apps, modules and functions.
• Show me the function @doc as it would look rendered in a separate pane from the function definition.
• Let me easily see all callers as a list based on the AST. Then let me select each caller to drill down. Or let me trace a series of calls using AST and again make each reference a link to the definition. Without losing my place in the tree.
• Let me select code to be executed right now using local constants and ask me for sample argument values. Or run the @doc iex test by selecting it and run with output in a separate pane/space.

It’s kind of crazy that we somehow haven’t moved past files when it comes to storing our code.

As Kent Beck said: Source code in files? How quaint. How seventies.

I think that at the very least it should be possible to add tags to modules/classes/whatever a language uses so that we can always view the codebase the way we need to. This would remove the endless war between structuring directories by layer vs by domain. We could easily get a by-domain view when working on business logic and a by-layer view when dealing with project-wide infrastructure code, for example.

Of course, the potential is much higher than that and I would love to work with a richer representation of my code.

After playing with Pharo and Glamorous Toolkit a few years ago, I totally understand what you mean by this!

I’m hoping the end-game of the upcoming official Expert LSP implementation gives us a similar experience with Elixir. I’ve not had many issues with ElixirLS and friends, but a unified/official LSP will make our lives so much easier!

I’ve built my own tool for that kind of problem:

mix archive.install hex modkit
mix mod.relocate -i

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

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