Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Towards Natural Language Semantic Code Search at GitHub

githubengineering.com

Post reply on HN
Print view View original

21–30 of 55 posts

Re: Towards Natural Language Semantic Code Search at GitHub

#21

Post by sam0x17 »

It is awesome that they are working on this, but can I just say there are a lot of basic search features they need to add before "doing the hard thing". Here are some things that I should be able to do easily but can't (or can't very easily or well) using GitHub's search mechanism:

1. exact or close string searches for code that involves ![]{}_-*() etc characters

2. searches across past commits (e.g. find a line that used to be in the code)

4. search across pull request + comments (not just issues and commit messages)

5. advanced search operators -- there should be a full filtering UI with ands and ors etc

Because of this I often find my self grepping locally, or (more often) totally out of luck.

Re: Towards Natural Language Semantic Code Search at GitHub

#22

Post by psychometry »

dgreensp wrote: post #14

It is a real cultural problem how engineers get more excited about machine learning than basic usability. GitHub search can't even search for a literal string, let alone a regex. It can't search a subdirectory. Ranking is indistinguishable from random. It's been this way for years. How about building an actual, usable, basic code search and then getting all fancy with your machine learning? I almost built my own "onl…

You also can't search a forked repository, which is pathetic.

Re: Towards Natural Language Semantic Code Search at GitHub

#23

Post by dgreensp »

kornish wrote: post #16
dgreensp wrote: post #14

It is a real cultural problem how engineers get more excited about machine learning than basic usability. GitHub search can't even search for a literal string, let alone a regex. It can't search a subdirectory. Ranking is indistinguishable from random. It's been this way for years. How about building an actual, usable, basic code search and then getting all fancy with your machine learning? I almost built my own "onl…

Agreed. Luckily, we as a community have tools like Sourcegraph which are based on battle-tested pragmatic systems from places like Google. Disclaimer: no affiliation, just love the team and product.

Thanks for the recommendation

Re: Towards Natural Language Semantic Code Search at GitHub

#24

Post by nkantar »

brian-armstrong wrote: post #12
mullikine wrote: post #2

I want to work at github. They're making cool things.

Do they? The main product appears to have 0 product velocity

I used to feel this way, but then I discovered https://blog.github.com/ and no longer do.

Sure, they may not be addressing your/my specific concerns, but the product is changing.

Re: Towards Natural Language Semantic Code Search at GitHub

#25

Post by lynxaegon »

hiccuphippo wrote: post #20
samlambert wrote: post #9

Earlier quoted context omitted.

We are very aware of the problem. I think you are going to really love what we are working on.

I really hope you are right and have your priorities straight when it comes to search. I'd love for a way to search for usages of a class::method, or for strings that contain the text "hello" or for variables named foo. And if you integrate that into the code itself, Ctrl+click a class method to find all usages, maybe even usages in other repositories, so I can see how other people use a certain library. And of cours…

They are tagging so much code with text, that i'm sure they have something groundbreaking.

Re: Towards Natural Language Semantic Code Search at GitHub

#26

Post by boyter »

dgreensp wrote: post #14

It is a real cultural problem how engineers get more excited about machine learning than basic usability. GitHub search can't even search for a literal string, let alone a regex. It can't search a subdirectory. Ranking is indistinguishable from random. It's been this way for years. How about building an actual, usable, basic code search and then getting all fancy with your machine learning? I almost built my own "onl…

To be fair its a hard problem to solve, especially with traditional search engine tools.

Take for example,

    for(int i=0;i
And then a search for i++ Due to the way almost every search tool works that would be split into tokens "for int i 0 100" which are not very useful. Even if you include the characters = ; Its totally possible to solve these issues using tweaks of the input into your index, which is what I did with searchcode.com or with a different approach which is what Google Code Search did. However neither have a requirement to be 100% in sync with the repository which I suspect is something that the github team value.

All the code search tools suffer from this in some way. At small scale its possible to just brute force the search. At scale you can do it by tweaking your algorithm and sacrificing accuracy. My feeling is that the github team chose accuracy.

Re: Towards Natural Language Semantic Code Search at GitHub

#27

Post by aaaaaaaaaab »

Now that’s what I call a misfeature!

GitHub is used by programmers. Surprisingly, they tend to be very good at telling computers precisely what they want, in the computers’ own language.

Natural language search is the exact opposite of this, invented for mom & pops who start their search phrase with “Dear Google, I’d like to search for ...”.

Re: Towards Natural Language Semantic Code Search at GitHub

#28

Post by amelius »

boyter wrote: post #26
dgreensp wrote: post #14

It is a real cultural problem how engineers get more excited about machine learning than basic usability. GitHub search can't even search for a literal string, let alone a regex. It can't search a subdirectory. Ranking is indistinguishable from random. It's been this way for years. How about building an actual, usable, basic code search and then getting all fancy with your machine learning? I almost built my own "onl…

To be fair its a hard problem to solve, especially with traditional search engine tools. Take for example, for(int i=0;i And then a search for i++ Due to the way almost every search tool works that would be split into tokens "for int i 0 100" which are not very useful. Even if you include the characters = ; Its totally possible to solve these issues using tweaks of the input into your index, which is what I did with…

But people use grep on their code all the time ...

Re: Towards Natural Language Semantic Code Search at GitHub

#29

Post by mullikine »

dgreensp wrote: post #14

It is a real cultural problem how engineers get more excited about machine learning than basic usability. GitHub search can't even search for a literal string, let alone a regex. It can't search a subdirectory. Ranking is indistinguishable from random. It's been this way for years. How about building an actual, usable, basic code search and then getting all fancy with your machine learning? I almost built my own "onl…

I made a regex search for GitHub and emacs plugin. In theory I could put this on GitHub. It uses the bigquery ghtorrent table. There's only so much time in a day though. If you want it upvote me

Re: Towards Natural Language Semantic Code Search at GitHub

#30

Post by boyter »

amelius wrote: post #28
boyter wrote: post #26

Earlier quoted context omitted.

To be fair its a hard problem to solve, especially with traditional search engine tools. Take for example, for(int i=0;i And then a search for i++ Due to the way almost every search tool works that would be split into tokens "for int i 0 100" which are not very useful. Even if you include the characters = ; Its totally possible to solve these issues using tweaks of the input into your index, which is what I did with…

But people use grep on their code all the time ...

People use grep on their local code repository, which is generally less than 2 gigabytes of source. A tool like ripgrep can process that in under a second on any modern machine with a warm disk cache.

Its when you get to hundreds of repositories or 10's of gigabytes of code that local tools cannot run fast enough. They are not designed for this use-case, and usually rely on the files being searched hitting the disk cache for repeated search performance.

It may be possible for github to shell out to grep for a single repository search (I have no idea how the back-end works but I doubt its impossible) but, I suspect that almost everyone wants/expects this to work across multiple repositories or across all of the github repositories.

Since its not easily possible to do so across everything they are not adding it to even a single repository to avoid search working differently for different situations, which is a fair approach in my opinion.

Post reply on HN