21–30 of 37 posts
I think making development as simple and accessible as possible is essential for our software-driven economy to scale efficiently.
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 that wire things up to the IDE is hard.
My main pain-points have been:
- Initial integration: Each IDE has its own extension framework, and it takes a lot of work to get my LSP server to work at all
- Deploying updates: Once I have it working, I then need to spend days automating updates for each IDE.
- Distributing LSP updates: For VSCode, I bundle the executable, but that means extension updates for every LSP update. I could have system level installation, but I don't want to ask users to take that risk (nor manage installers myself)
- Syntax highlighting: There is no good standard for semantic highlighting (technically textmate, in practice not). LSP doesn't include highlighting.
- Settings management: Each IDE has a different way of managing settings, and gluing that to the LSP isn't easy.
Basically, I have to spend a week or two of my free time to support an extra IDE at all (not well), which is frustrating. Probably a month or two for full support, and that would be for maybe a dozen users.
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…
These are lofty goals, and sorely needed.
We've come a long way but there is a lot of "suckage" both in developing software and in using it still.
I wish Sourcegraph all the best :)
> At Sourcegraph, we want to fix this and eventually enable everyone to build software. For now, we're revealing our master plan for phase 1: how we're going to make it easier and faster for today's developers to build software. These are lofty goals, and sorely needed. We've come a long way but there is a lot of "suckage" both in developing software and in using it still. I wish Sourcegraph all the best :)
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 by restricting ourselves to just lists.
And that's not all. Spotify is also annoying in terms of looking at the currently playing list of songs. If you go someplace else and look at another list and then go back to the current playlist you'll usually be brought back to the top and if the list is long then you have to scroll a lot in order to get back to where you were.
And I would like to make arbitrary queries like "show me all playlists in which song x occurs".
And I would like to have access to the full history of songs I've listened to, including information about leaving the song before it was done, and skipping forward and back. And I would like to have the point in time in a song where I starred it or added it to a playlist.
Then I could query for example "show me all songs that I've listened to in the past six months, that I listened to at least 80% of the full length of, but which I have not listened to within the last two weeks" and play the resulting list.
Of course, the playlist being a simple concept makes it easy for users to understand. I guess the amount of people that want what I want is probably not many...
> At Sourcegraph, we want to fix this and eventually enable everyone to build software. For now, we're revealing our master plan for phase 1: how we're going to make it easier and faster for today's developers to build software. These are lofty goals, and sorely needed. We've come a long way but there is a lot of "suckage" both in developing software and in using it still. I wish Sourcegraph all the best :)
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…
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.
> At Sourcegraph, we want to fix this and eventually enable everyone to build software. For now, we're revealing our master plan for phase 1: how we're going to make it easier and faster for today's developers to build software. These are lofty goals, and sorely needed. We've come a long way but there is a lot of "suckage" both in developing software and in using it still. I wish Sourcegraph all the best :)
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…
Though, I do still see the point of your example.
Programming is hard because it's hard to define the problems that need to be solved, hard to design good solutions and often hard to implement them efficiently. A smart IDE is a useful tool but it does little to nothing to address the fundamental difficulty of programming. The real challenge to making programming more accessible is how to teach/train people to be better thinkers and problem solvers (and I include myself in needing that).
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…