![]() You could scroll through them with the mouse or keyboard, and click or ENTER the one you want and it would paste in. A little tooltip would pop up with completions. That would be an interface I could get behind.įor completion, it ought to work like the IDE I used back when I was writing Scala. A symbol would be a link, and when I ctrl+clicked on it, it would open in a new frame. Imagine for a moment that I was browsing and editing code in Google Chrome instead. Google Chrome, or any modern browser for that matter, has a much better way of doing things. I hate it when completion buffers, or anything related to a second buffer, pops up in my frame. Some people find keyboard navigation through a second buffer that pops up on the bottom to be not-good. Unfortunately, though, it just can't be our primary focus - both because I think that would be focusing on the wrong part of the problem and because at the end of the day we have to pay ourselves and there's just no way for us to do that.Īh yes, the good old "mouse? you're doing it wrong!" bit of elitism. But either way we will do our best to make sure that it continues. It fills an important part of the ecosystem and we hope it continues to infect other tools and organizations who have significantly greater resources than a couple of guys in SF. With Eve there's a much clearer path towards creating a sustainable business that is able to continue towards the ridiculous goal we set out with from the beginning: to empower the world's creators. Plus it seems programmers are increasingly less interested in paying for anything in general, so that didn't make our prospects all that attractive. Matching the millions of man hours that have been poured into vim/emacs and so on is just not in the cards for a couple of guys with not much funding. ![]() We'd have no way of sustaining ourselves if we couldn't find some avenue to eventually turn this into a business - we looked and couldn't really find a reasonably quick way to do that. ![]() Hell, even orders of magnitude improvements are hard to sell to programmers. More practically, though, incremental improvements are hard to sell - not just to VCistan, but to programmers as well. Instead, there's an opportunity to embrace that change and take the ideas of LT to their logical conclusion: what would a stack built for today's machine that is meant to be used by humans look like? We stumbled on a solution as we did more and more user testing of LT and in the interest of self preservation we ran with it. If we continue pushing LT for that way of thinking, it's unlikely to make much of a difference. We're already starting to hit a wall as a result of that - reasoning about highly concurrent systems with the programming models we have now is nearly impossible. My suspicion is that programming is going to change substantially over the next decade, because while we've been worried about machine learning, rails, and hadoop, the notion of the machine changed out from under us. We didn't have that benefit and along the way we learned that it actually wouldn't help that much anyways.Īny single tool is going to be an incremental improvement (at best) on programming, because the source of the issues is really the model itself. That's why Apple's effort with Swift is so important: they're designing the language to be tooled. The interesting things LT offered were around connecting to running pieces of software and the truth is that we just ran against a wall in what we can do with our current languages. As just a plain editor, it's hard to compete with vim/emacs/sublime.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |