New Generation of IDEs (part 2): Multidimensional Navigation in Photo Libraries

In part 1, I wrote about Visual Studio navigation. In part 2, I will compare IDEs with modern Photo Libraries

I had a digital camera (now just a camera) since the top models were just a few megapixels. I quickly concluded that I could not just copy pictures to the folder with a description of the photo session. I needed something sortable, so I added 'perfect date' as the prefix in the folder name.

<YYYY>
  <YYYY-MM>
    <YYYY-MM-DD> - <Device> - <Description>

This structure works, even after ~20-25 years.

The problem is, this is not enough. Sure, I can somewhat find the pictures I want, but I cannot easily find all the photos we as a family took from vacations with all devices.

If we want to add additional dimensions for organizing photos, we can use Photo Organizers. With photo organizers, we use for example timestamps to extract just the images from specific periods, even if it is from different folders (dates and devices).

The next problem the Photo Organizers can help with is when we want to show all the pictures from some specific place. Geotagging and map views work great for that.

Then, sometimes, I want the pictures of my children. AI and face recognition work excellently for that.

Organizing a group of pictures by folder with date is a good first step. But adding additional "dimensions" for navigation, with Photo Organizers, greatly enhances the usability of digital Photo Libraries

Multidimensional Code Searching

There are many possibilities with "multidimensional navigation" of the code. For example, when I want to create a new database query, as a true pro, I find it easier to copy and modify the existing code than to write everything from scratch. Wouldn't it be great to have the capability to browse classes by some characteristics like have sql query, is MediatR Handler, etc?

Sure, you can argue that you can already do many things with clever searches. But I believe we can do better in the context of searches.

I'm solving most of these problems with strict naming and class rules. But, for legacy applications or on projects where I'm not the one 'making rules,' I find it much more challenging because, in most cases, I'm not looking for what I need; I'm searching for the specific implementation of what I wanted.

Does code discovery in legacy applications (or the ones you have not worked on) have to be so complex? Can we search and browse classes by some better criteria than by projects, folders and files?

Code Browsing?

Just by searching for something, you may find all the instances, but you still don't have the ability to easily browse those instances. Yes, modern IDEs give us a list of results and code previews. But can we do more? How can we make it easier to switch from one class to another?

Are tabs in multiple windows the best we can do?

Computation Cost of the Indexing

Modern IDEs can index many of these things already. Yeah, I'm angry because IDEs are getting slower and slower, and this indexing is one reason. But I'm sure we can create smarter local indexing than we have now. Just think about it: we use these IDEs to develop applications with petabytes of data and billions of rows! And, for some reason, we cannot make local IDEs work fast on computers with 16-24 cores and 32 threads with 32-64GB RAM. That's usually much more than a single node on the server! Also, modern CPUs and GPUs have specialized chipsets that are great for AI-assisted tasks.

Indexing should not be a problem with modern computers! We could even run a decent-sized LLM locally and analyze every class whenever there is a change for better indexing.

Conclusions

With modern computers we should be capable of actions like opening IDEs instantaneously. Multidimensional indexing should not only be much faster, but we should be able to index many more things. With our high-end PCs, we could run more advanced code search engines and even preemptively run local LLMs for code analysis and tagging in the background. And maybe we could put more effort into code visualization and representation.

Why are we not doing that?