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

The Era of Visual Studio Code

blog.robenkleene.com

Post reply on HN
Print view View original

631–640 of 698 posts

Re: The Era of Visual Studio Code

#631

Post by ilrwbwrkhv »

varispeed wrote: post #228
willbw wrote: post #198

I find this post along with the comments in "A Picture of Java in 2020" https://news.ycombinator.com/item?id=24551390 to be incongruous with my experience as a professional developer. My first couple of years writing software I used Vim, then VSCode, then worked in a Java shop and was forced to use IntelliJ. I didn't like it at first, but now after a couple of years I cannot see how I lived without it. The idea that…

From my experience out of the box you get poor performance and you have to spend a lot of time figuring out how to change configuration to improve it as knowledge is scattered in many places and not always up to date. Then it still likes to stall from time to time or sometimes doesn't register key presses properly. It's a poor user experience, but even worse is that alternatives are often worse. I wish there was an e…

What are some of those config that improves performance for Jetbrains IDEs?

Re: The Era of Visual Studio Code

#632

Post by lakecresva »

greggman3 wrote: post #474
tjpnz wrote: post #398

Earlier quoted context omitted.

People have written the same hype driven articles about Sublime, Atom and even IntelliJ. The same articles will continue to be written for whatever comes next. Just use whatever you feel makes you most productive. Having tried VSCode I ended up sticking with PyCharm/Goland.

it's not that simple is it? I've been programming for ~40 yrs. I've used a bunch of different editors. I certainly don't know each feature of each one but many features I find to be force multipliers so ignoring them is a disadvantage IMO. I'll be wasting my time doing something manually the could be automated for example. Unfortunately it's hard to know how to configure every editor and know how to get these time sa…

Out of curiosity, are you using the vim plugin for VSC? There's only one, but it has a huge install base and causes really insane performance issues in a wide variety of situations. It really should have a disclaimer in its description.

Re: The Era of Visual Studio Code

#633

Post by leetcrew »

andrewstuart wrote: post #111
barkingcat wrote: post #91

Earlier quoted context omitted.

You don't need all the plugins. You just need a curated set. And some of the plugins are fantastically high quality. The Microsoft Python one is excellent, as is the Remote development one. I'm a fan of VS Code because in spite of it having a plug in system, there are great plug ins there. And that one single great plugin is all that is needed (for that specific purpose)

I'd be more interested in VSCode if Microsoft's strategy was to relentlessly implement the most popular plugins into VSCode natively such that the most commonly used and needed functions were built in and did not require plugins. The problem with systems that are really just frameworks for other to build on is they become reluctant to build stuff that plugins exist for. The philosophy becomes to depend on the plugins…

> I'd be more interested in VSCode if Microsoft's strategy was to relentlessly implement the most popular plugins into VSCode natively such that the most commonly used and needed functions were built in and did not require plugins.

microsoft already has an IDE like this for their core languages; it's called visual studio. it's kinda bloated, but it's still a great tool for languages that microsoft has deigned to grace with its direct attention. for anything else, you're SOL; the plugin ecosystem is pretty limited for VS. the more VSCode reimplements plugins "natively" (isn't it all JS anyway?), the less it has a reason to exist.

Re: The Era of Visual Studio Code

#634

Post by moron4hire »

kmonsen wrote: post #275
moron4hire wrote: post #132

Earlier quoted context omitted.

>> I'd be more interested in VSCode if Microsoft's strategy was to relentlessly implement the most popular plugins into VSCode natively such that the most commonly used and needed functions were built in and did not require plugins. Unlike the FANG companies, Microsoft doesn't tend to rip the carpet out from under independent developers like that.

Wasn’t there recently a thread were Microsoft interviewed someone that has a third party dev tool, declined to hire him and then recreated the same tool with almost the same name without acknowledgement?

You mean the app that he named almost the same name as another, long-existing Microsoft product? (NuGet) It's not like AppGet was developed in a vacuum. And it's definitely nowhere near the situation like Facebook cloning Virtual Desktop, threatening to crush the original developer if he didn't join them, and naming it the exact same thing.

Re: The Era of Visual Studio Code

#635

Post by scarface74 »

mdekkers wrote: post #446
scarface74 wrote: post #254

Earlier quoted context omitted.

IntelliJ still has that Java GUI stench that made me stay away from Java over 15 years ago.

There are some pretty good theme options. Have a look at the material theme for example https://www.material-theme.com

It’s not just theming. Java GUI apps just don’t “feel” right. It’s like the uncanny valley of interfaces.

It feels less native than Electron apps.

I pay for Resharper every month. JetBrains makes excellent products. But I tried IntelliJ, I quickly went back to VSCode.

Re: The Era of Visual Studio Code

#636

Post by qppo »

joaomoreno wrote: post #605
qppo wrote: post #67

There's a couple big knocks against VS Code that don't get brought up enough The extension API is underdocumented. It's very difficult and time consuming to onboard yourself as an extension author with just the MS docs, since they don't cover the entire API and the vast majority of data structures are undocumented entirely. This is really annoying when functions take structures as arguments and have optional fields.…

Hi, VS Code dev here. We actually put a lot of effort into documenting API and extension development. This is why `API` is one of the main sections on our home page: https://code.visualstudio.com/api . It's also why we have very restricted API guidelines: https://github.com/microsoft/vscode/wiki/Extension-API-guide... We'd love to hear more about the lack of documentation you're referring to. It's definitely a solvab…

Thank you!

Re: The Era of Visual Studio Code

#637

Post by TaupeRanger »

BeetleB wrote: post #405
TaupeRanger wrote: post #247

Earlier quoted context omitted.

I find comments like this incomprehensible. Are you using a Vim emulator in VS Code? If not, how can you possibly be more productive? People use Vim precisely because it offers a faster more efficient way to write code. What is it about VS Code that makes you more productive?

There are more aspects to productivity than typing efficiency.

Sure - that's why I asked. I haven't seen any explanation for why VSCode is more productive than Vim. I hear about viewing files and folders, but you can do that in Vim very easily with no friction.

Re: The Era of Visual Studio Code

#638

Post by derefr »

dreen wrote: post #575
derefr wrote: post #279

Earlier quoted context omitted.

You're conflating the language and the prosthetic used to code in it. Java is a high-friction language. Write it in a text editor, and measure how long it takes to write some working nontrivial Java. What you're measuring there is the inherent friction of Java, as a language. The IDE adds negative friction — lubrication — to the process. But that's a separate thing from the language itself. As I said, just try to thi…

Offtopic, what do you use for editing Erlang? I'm quite interested in trying out Eralng or Elixir in near future.

Erlang is a particularly low-friction language, in my experience; it’s just as productive (for me, at least) to edit Erlang code in vim (with no active extensions other than Erlang syntax-highlighting) as it is to edit it in Sublime Text with the whiz-bang Erlang Language Server compiling it in the background. Code that won’t compile just looks wrong in Erlang, and it’s not subtle.

Elixir is slightly higher-friction; all that weird extra Erlang syntax that Elixir eschews (the comma and semicolon statement-binding operators specifically) has a purpose in making Erlang “mentally lintable”, so Elixir loses some of that.

It gains in other places, though; for example, Elixir’s hygenic macros impose much less of a mental load than Erlang’s parse-transforms do. (Just the fact that you have to explicitly require the definition-site module before using any macro from that module, is a big boon to predicting what’ll happen when you go to run the code.)

Re: The Era of Visual Studio Code

#639

Post by derefr »

oblio wrote: post #564
derefr wrote: post #304

Earlier quoted context omitted.

High-friction languages allow you to pump your codebase full of unbounded coupling and complexity, to turn your codebase into a hypercube of connections (subclasses; interfaces; macros; annotations; DSLs; monkey-patches; etc.) IDEs for these languages give you a fancy N-dimensional submarine to efficiently navigate this "wondrous" landscape. Low-friction programming languages just don't give people all those N dimens…

> subclasses; interfaces; macros; annotations; DSLs; monkey-patches; etc. I think this excludes every programming language known to man, since 1980 or so :-))

It’s not having just one of them is bad; it’s that striving to include as many of them as possible in your language—and not having any convention or constraint discouraging using them all at once—is bad. Look at the code that implements the C++ STL, for example.

Re: The Era of Visual Studio Code

#640

Post by thebigspacefuck »

andrewstuart wrote: post #111
barkingcat wrote: post #91

Earlier quoted context omitted.

You don't need all the plugins. You just need a curated set. And some of the plugins are fantastically high quality. The Microsoft Python one is excellent, as is the Remote development one. I'm a fan of VS Code because in spite of it having a plug in system, there are great plug ins there. And that one single great plugin is all that is needed (for that specific purpose)

I'd be more interested in VSCode if Microsoft's strategy was to relentlessly implement the most popular plugins into VSCode natively such that the most commonly used and needed functions were built in and did not require plugins. The problem with systems that are really just frameworks for other to build on is they become reluctant to build stuff that plugins exist for. The philosophy becomes to depend on the plugins…

It’s pretty easy though. You open a Python file, it asks if you want Python plug-in installed. Then you’re pretty much done except specifying your virtualenv. If you have linter settings it will ask if you want the linter installed.

The big thing with Jetbrains is the cost. PyCharm is $9-$25/month and VSCode is free

Post reply on HN