Live data from Hacker News

The Rise of Microsoft Visual Studio Code

triplebyte.com

131–140 of 327 posts

Re: The Rise of Microsoft Visual Studio Code

#131

There are some warts, but it seems nice from afar. The biggest wart is/was the "FUCK FUCK FUCK" git clean vs git reset UX error: https://github.com/microsoft/vscode/issues/32405 . This is a fantastic demonstration of why i exclusively use git from a command prompt -- i know what will happen and nobody's going to reinvent terms to put on buttons that just confuse me. In my life: - I'm committed to emacs for org-mode a…

P.S. VSCode has multi-cursor as well: https://code.visualstudio.com/docs/getstarted/tips-and-trick...

Re: The Rise of Microsoft Visual Studio Code

#132
post #37

There are some warts, but it seems nice from afar. The biggest wart is/was the "FUCK FUCK FUCK" git clean vs git reset UX error: https://github.com/microsoft/vscode/issues/32405 . This is a fantastic demonstration of why i exclusively use git from a command prompt -- i know what will happen and nobody's going to reinvent terms to put on buttons that just confuse me. In my life: - I'm committed to emacs for org-mode a…

> This is a fantastic demonstration of why i exclusively use git from a command prompt... Thanks for this. I've always felt the same way but haven't been able to put my finger on why. As more things get integrated into my editor (I use VSCode) I feel like I should use the shiny features, but for source control I think I'm going to only use the commandline forever. (Edit: though plugins such as GitLens that give you s…

I also very much related to this, the two exceptions I find awkward from the command line are: * Doing partial adds with `git add -p`. I see the hunk it presents see what I want from it, but then sometimes have to go through several iterations of splitting, skipping etc.. A visual tool (even like the tool in vim-fugitive) is a huge improvement. At the end of the day I'm still looking at the staged diff before committing * Looking at diff or blame logs. Once again these are super low risk for unexpected behavior, and for larger changes that span multiple files, I find the shiny editor features make it easy to see the context quickly.

Re: The Rise of Microsoft Visual Studio Code

#133
post #102

Earlier quoted context omitted.

Could you give some examples? I keep seeing annoying Triplebyte ads popping up and not sure what it is.

What kinds of examples are you asking for? Like specific parts of the interview?

https://triplebyte.com/interview_guide

Re: The Rise of Microsoft Visual Studio Code

#134
post #37

There are some warts, but it seems nice from afar. The biggest wart is/was the "FUCK FUCK FUCK" git clean vs git reset UX error: https://github.com/microsoft/vscode/issues/32405 . This is a fantastic demonstration of why i exclusively use git from a command prompt -- i know what will happen and nobody's going to reinvent terms to put on buttons that just confuse me. In my life: - I'm committed to emacs for org-mode a…

> This is a fantastic demonstration of why i exclusively use git from a command prompt... Thanks for this. I've always felt the same way but haven't been able to put my finger on why. As more things get integrated into my editor (I use VSCode) I feel like I should use the shiny features, but for source control I think I'm going to only use the commandline forever. (Edit: though plugins such as GitLens that give you s…

> don't have to 'git add' and type filenames manually

Another option is git add -p, which asks you about each change so you can review them once more and maybe leave some (parts of) them for future commits.

Re: The Rise of Microsoft Visual Studio Code

#135

> Engineers who use Go are also especially strong. If you know why, please let me know. Because there is almost no reason to learn Go. Most shops want JS/Java/Python/C# etc... The primary reason to learn a language like Go is because you want to for it's own sake. It's not that you must learn Go in order to be good, or that knowing Go makes you better. Rather it's difficult to be bad and still have the desire/interes…

This is what Paul Graham calls the Python Paradox; namely that in 2004, when Python jobs were relatively more rare, you could find smarter Python engineers than Java engineers for any given project.

"[I]f a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it. And for programmers the paradox is even more pronounced: the language to learn, if you want to get a good job, is a language that people don't learn merely to get a job."

http://www.paulgraham.com/pypar.html

Re: The Rise of Microsoft Visual Studio Code

#136
post #37

Earlier quoted context omitted.

> This is a fantastic demonstration of why i exclusively use git from a command prompt... Thanks for this. I've always felt the same way but haven't been able to put my finger on why. As more things get integrated into my editor (I use VSCode) I feel like I should use the shiny features, but for source control I think I'm going to only use the commandline forever. (Edit: though plugins such as GitLens that give you s…

Same here w/o fancy tooling around Git, but a couple of aliases. I will refuse to use any Git tools or UIs, but the standard CLI, until the end of my career. Besides that, my IDE/Editor is neither a build tool manager nor should it run my app from within an integrated console having specific settings. The projects people are going to inherit from me will always be editor-agnostic, the environment they run in will nev…

God bless you.

Re: The Rise of Microsoft Visual Studio Code

#137

> Engineers who use Go are also especially strong. If you know why, please let me know. Because there is almost no reason to learn Go. Most shops want JS/Java/Python/C# etc... The primary reason to learn a language like Go is because you want to for it's own sake. It's not that you must learn Go in order to be good, or that knowing Go makes you better. Rather it's difficult to be bad and still have the desire/interes…

Go is a language designed to take CS college graduates to productive engineers at Google with as little fuss as possible. Considering it was designed for an organization in the scope of Google, it's less likely to be the best option for something like a startup, small business, or even a medium size business.

Re: The Rise of Microsoft Visual Studio Code

#138

> Engineers who use Go are also especially strong. If you know why, please let me know. Because there is almost no reason to learn Go. Most shops want JS/Java/Python/C# etc... The primary reason to learn a language like Go is because you want to for it's own sake. It's not that you must learn Go in order to be good, or that knowing Go makes you better. Rather it's difficult to be bad and still have the desire/interes…

This is what Paul Graham calls the Python Paradox; namely that in 2004, when Python jobs were relatively more rare, you could find smarter Python engineers than Java engineers for any given project. "[I]f a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it. And for programmers the para…

Both of these are still just very roundabout ways of telling yourself you're awesome because of whatever mildly unusual thing you think you might be doing.

Re: The Rise of Microsoft Visual Studio Code

#139
It seems strange to me to compare VSCode against PyCharm, IntelliJ, and Android Studio separately. While PyCharm, IntelliJ, and Android Studio are distinct applications, I believe they share much of their code, UI, 3rd party plugins, and workflows for all being JetBrains language-flavored IDEs.

On the other hand, VSCode supports different languages through its extensions instead of having separate language-flavored applications like "VSCode Python", "VSCode Java", or "VSCode Android".

So I feel that reaching for IntelliJ vs. PyCharm vs. Android Studio is roughly equivalent to installing a particular set of extensions in VSCode. If you look at it that way, the data from the article seems to tell a different story - while VSCode has grown significantly in popularity, JetBrains IDEs seem to dominate in terms of overall usage (11.3% + 6.9% + 4.1% = 22.3% vs. VSCode's 16.8%).

Re: The Rise of Microsoft Visual Studio Code

#140

Earlier quoted context omitted.

Which is weird because with all of its inconsistencies, git must have been designed with the idea that someone would build a sensible shell over top of it. I can't imagine Linus expected people to interact directly with git when he built it.

git has its problems, but it's a consistent, centralized (in the sense of origin/repo), well known set of problems. I use multiple IDEs/editors, and they all handle git differently. It doesn't make sense to learn yet another N sets of quirks.

> git has its problems, but it's a consistent, centralized (in the sense of origin/repo), well known set of problems.

Consistent? Ha! Change branch: git checkout my-branch. Reset file to committed version: git checkout -- my-file. Git is many things, but consistent it is not.

That said, I still use CLI precisely because I don't trust other software to make sensible abstractions on top of it, given that foundation is so inconsistent. Besides, those CI scripts only know git cli...

Post reply on HN