Live data from Hacker News

Sourcegraph Master Plan

about.sourcegraph.com

31–37 of 37 posts

Re: Sourcegraph Master Plan

#31

Earlier quoted context omitted.

One thing in particular that grinds my gears about a lot of software is how limited the actions I can perform on data are. Take Spotify for example, a fantastic product by many measures, but which even so does suck in some ways. Being able to create playlists and to enqueue songs is a start, but think about a list as a special case, limited kind of graph, and think about what kinds of operations we are missing out on…

Arbitrary data querying are literally the problem databases exist to solve. It's a monumentally hard problem. And there's another issue on top of it, the company 'crown jewels' problem. If Spotify makes it too easy to query Spotify, then it becomes ridiculously easy to compete with Spotify. Which isn't a bad thing necessarily, but not something we should expect Spotify to expend millions of dollars to enable.

> And there's another issue on top of it, the company 'crown jewels' problem. If Spotify makes it too easy to query Spotify, then it becomes ridiculously easy to compete with Spotify. Which isn't a bad thing necessarily, but not something we should expect Spotify to expend millions of dollars to enable.

Yeah that's true. But mainly the data I want to be able to query is the data that is directly connected to my own activity. If Spotify made it possible to get access to metadata about my activity and the songs that were involved in my activity then it's useful for users but still limits somewhat what a would-be competitor could do. Combine that with a ToS that forbids redistribution of the data and I think Spotify could provide this without helping would-be competitors too much.

Even if a would-be competitor had access to various data from Spotify they would still need to both negotiate agreements about streaming rights with the IPR owners of the music itself, and they would need a lot of marketing in order to get users. In other words they would need a lot of capital. Where would a would-be competitor even get that kind of money? I don't see why any VC or startup accelerator would be willing to fund someone to build this given how big Spotify is and how limited the group of people probably is that would decide to leave Spotify for this feature.

Whereas on the other hand, this kind of access to data could be a premium feature, and then it could be another reason for users that cared about these things to pay for Spotify Premium. Open source third-party clients could implement query engines, building on exactly what you mentioned in the first paragraph;

> Arbitrary data querying are literally the problem databases exist to solve.

Open source clients exists today, and using them with Spotify requires premium. If Spotify provided the data, someone would follow suit in making use of the data in open source clients. Which could further boost sales of premium membership, while at the same time like I said would still not make it too easy for would-be competitors.

Actually, the client wouldn't even need to be open source, it could be a commercial product, and by integrating with Spotify Premium they would still not be a competitor, and they would not need to go through licensing, and marketing might be easier as well. "Enjoy advanced interaction with your Spotify Premium listening experince by using our client."

Re: Sourcegraph Master Plan

#33
post #30

This all sounds like useful stuff I'd potentially use but I don't see it solving the core problem that programming is difficult. I've long worked in environments where "basic code intelligence" works and it is certainly useful but the problems it solves are not what makes programming hard. Programming is hard because it's hard to define the problems that need to be solved, hard to design good solutions and often hard…

The best way to define the problem is iterating on it. This (and other tools) allows you to iterate faster. That's why tools like this are useful.

I'm not saying its not useful. My daily work currently is VR development in Unity and so I'm using C# in Visual Studio with ReSharper which together give one of the best and most complete "basic code intelligence" experiences I know of. It's great and useful but while it makes me more efficient it just doesn't have much impact on the actual hard parts of programming. It improves the workflow for the routine parts but they are merely time consuming, not difficult/hard problems.

Re: Sourcegraph Master Plan

#35
post #10

Isn't Kythe[0] trying to achieve this already, with a graph based, multi-language framework? Of course, there are no integration with current dev tools, but the core is there to make it work, maybe? [0] - https://kythe.io

Sourcegraph CEO here. Yes, Kythe is a very ambitious project and we have a lot of respect for the team building it inside Google. source{d} ( https://sourced.tech/ ) is another company doing awesome things in the code analysis space. From our POV, the more people trying to accomplish these things, the better, because: 1. As developers and humans, we want these things to exist! 2. Our business and product is a code se…

> From our POV, the more people trying to accomplish these things, the better

Sure, im totally ok with this vision, given this is how people create new things, even if it looks 'solved' in a given context.

> As developers and humans, we want these things to exist!

The more iteration, the better.. we definitely need more polished tools in this space.

> LSP (https://microsoft.github.io/language-server-protocol/) is a better fit

Oh thanks, thats kind of the context i was looking for.. in what problem domain you guys were pointing to.

It makes perfect sense giving the current goals of Sourcegraph, to create a more complete solution to the dev community it targets.

(I didnt wanted to sound the "Dont reinvent the wheel" kind of guy here, just curious about what you were trying to acomplish, and used Kythe as a reference to the problem domain)

Re: Sourcegraph Master Plan

#36
post #7

I don't get what problem this solves that Emacs with appropriate language modes doesn't already solve.

People use a lot of different editors. The solution isn't "everyone switch to emacs".

Not suggesting that. I was asking why I as an Emacs user should switch to Sourcegraph. And now I have a pretty good answer.

Re: Sourcegraph Master Plan

#37
post #23

So, I've written a language server for a very niche programming language (Paradox Interactive games' scripting language). I started it as a VSCode extension (via LSP), and am halfway to getting a Sublime Text extension to work, and gave up on intellij. Emacs/Vim shouldn't be hard, but I have no idea how I would release updates. While I agree LSP is technically making it an "n-plus-m" problem, implementing the plugins…

Sourcegraph CEO here. We have a project underway that lets you write one editor extension and use it on multiple editors (and other tools with code views, such as GitHub, GitLab, Sourcegraph, etc.). We intend it to solve your problem. https://github.com/sourcegraph/sourcegraph-extension-api

Awesome mission. But god I wish JS weren't eating the world like this.
Post reply on HN