Comment by jierenchen | Hacker News Reader

Comment by jierenchen | Hacker News Reader

Great post.

I see two big challenges.

1. How do you do this without changing the way we program? The most amount of value I would get from this kind of tool is being able to spelunk in a huge codebase with lots of legacy gunk. The cost of entry for this cannot be "rewrite all the codes."

2. What does the query language look like and how do you expose this to the user? This is especially challenging because the query language needs to serve so many different roles.

I'm excited to see what comes of this as I see this problem as a blocker for the next generation of software development. We've more or less solved infrastructure, yet taming complexity still eludes us.

Shameless plug, with a bit of fortuitous timing:

I just released an alpha CLI for my project SourceScape.

It's a tool that indexes your Typescript and Javascript code (Ruby coming soon.) You can then query your code by code structure instead of just raw text. As a trivial example, you can search for all classes with a render method that returns a jsx element with name div.

Install instructions here: https://github.com/sourcescapeio/sourcescape-cli#install

Marketing materials (a bit outdated, but looks pretty): https://sourcescape.io

Re: "How do you do this without changing the way we program?"

Let's change the way we program. If we outgrow trees, we've outgrown trees. I don't know if existing code will be easy to convert. It's kind of like when OOP IDE's fell out of favor for web stacks: the old OOP classes couldn't be reshaped for web because the web is state-poor and OOP is state-rich. We had to dump OOP libraries and stacks into the trash.

Re: "What does the query language look like and how do you expose this to the user? This is especially challenging because the query language needs to serve so many different roles."

I suggest using existing RDBMS and SQL. There's no reason to reinvent the wheel unless inherent flaws can be found in RDBMS for code management purposes. I haven't found any yet in my little experiments in "table oriented programming".

I take that back a bit. Different UI components/widgets will have different attribute structures. It's hard to change the schema every time a new widget type is added. Possible solutions include Dynamic Relational, or a Windows-Registry-like "attribute tree" for UI models. Attributes of UI widgets then could be accessed like:

     setAttrib("screenX.widgetY.maxHeight", 37);
     // context-based shortcut:
     setAttrib("currentWidget.maxHeight", 37);

The second form is handy because instead of writing explicit loops, event triggers may be used traverse and customize per-widget behavior. The traversal mechanism will create a reference to the "current" item per behind-the-scenes looping to simplify path references. More samples:

     // sequence control (display order):
     setAttrib("screenX.widgetY.sequence", 47.5);
     // deactivate:
     setAttrib("screenX.widgetY.active", false);
     // alternative:
     setAttrib("screenX.widgetY.status", "inactive");
     // more uses of "status" attrib:
     setAttrib("screenX.widgetY.status", "hidden");
     // Grid samples:
     setAttrib("screenX.grid4.row.7.col.9.value", "foo");
     setAttrib("screenX.grid4.row.7.backGroundColor", "green");

Helper API's would probably simplify grid path management.

I'm all for a rewrite of existing systems, but I think that's going to be a long-term thing (5-10 years) that will happen in parallel to developments in treating code as a database.

I've found RDBMS is quite limited in terms of graph traversal. Maybe you've found a way around this? Would be happy to riff on that.

Reply on news.ycombinator.com