stack-graphs VS enso

https://github.com/pyjarrett/septum

The hardest part about getting code search right imo is grabbing the right amount of surrounding context, which septum is aimed at solving on a per-file basis.

Another one I'm surprised hasn't been mentioned is stack-graphs (https://github.com/github/stack-graphs), which tries to incrementally resolve symbolic relationships across the whole codebase. It powers github's cross-file precise indexing and conceptually makes a lot of sense, though I've struggled to get the open source version to work

[2]: https://github.com/github/stack-graphs

> It doesn't have the faintest idea where the name is defined, or if there's even a difference between a function name, a parameter name, or a word in a comment.

I don't think what you are saying is actually true for stack-graphs[0][1].

[0]: https://github.com/github/stack-graphs

[1]: https://github.blog/2021-12-09-introducing-stack-graphs/

I think GitHub still has some use for tree-sitter. In this post it's mentioned that their new code navigation system is based on tree-sitter. In a more recent post they welcome contributers to add special code navigation queries to existing languages. You can find their public repository here if you want to follow along with any developments. Since their code navigation system relies heavily on tree-sitter I don't think it's going anywhere soon (fingers crossed).

Which they implement in Rust. https://github.com/github/stack-graphs

As mentioned elsewhere on this thread, stack graphs and Semantic were built by the same team (which I manage). Semantic is not abandoned, we've just been focusing on a different layer of our tech stack for the past year or so. https://news.ycombinator.com/item?id=29501389

That PR on the Semantic repo was our first attempt at implementing these ideas. We decided to reimplement it in a separate library (also open source, https://github.com/github/stack-graphs), which only builds on tree-sitter directly so that there's an easier story for us and language communities to add support for new languages. It's a fair point that we could have closed the Semantic PR to indicate that more clearly.

> At least I have yet to see one that is actually useful in the sense of a generic (or even a single-purpose-built) language

Yeah as said, https://github.com/enso-org/enso seems to be a general purpose functional programming language with visual editor, but otherwise I haven't really seen any no-code solutions worth their salt. I'm not particularly a fan of enso either, but it's the best I've seen.

Although it's not quite the same, I do like what Enso[0] is bringing to the table, especially the 1:1 visual node/language interop. Whether this is generalisable to a fully decoupled interface remains to be seen, but there's definitely potential.

[0]: https://enso.org/

I think Enso is already taken by a YC company [0]. Could get confusing.

[0] https://enso.org

COMPANY: Enso Inc. TYPE: Full time LOCATION: Europe and United States of America – fully distributed company REMOTE: Only remote VISA: No VISA required DESCRIPTION: Hi, we are Enso (enso.org, Y Combinator S21)! We are looking for an amazing Cloud engineer to join our core team. We are a remote first company, working in Europe and the USA.

Friends of mine are developing Enso (https://enso.org/), an interactive programming language with dual visual and textual representations.

Even well before Bret Victor's time, there were tools for visual programming. I have been using LabView to maintain data processing in an optical laboratory.

> I'm convinced this entire space should be visual.

At my last 2 jobs I spent entirely too much time debugging Matillion jobs, which are visual. I have my doubts that it’s the panacea that it appears to be.

That said, you may find Enso particularly interesting: https://github.com/enso-org/enso