Live data from Hacker News

The Era of Visual Studio Code

blog.robenkleene.com

301–310 of 698 posts

Re: The Era of Visual Studio Code

#301
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…

The funny thing is that I can't tell if you're talking about intellij or vs code from the first paragraph.

I find vscode a horrifying experience that is forced upon me because of poor choices made elsewhere in the org.

I'm slowly picking up vim to replace it but I'd rather just not be forced out of my editor I still use daily (sublime.)

In hindsight I wish I learned vim instead of sublime.

Re: The Era of Visual Studio Code

#302
post #187

Earlier quoted context omitted.

Yeah but you need to pay separately because it’s based on ReSharper, there’s no .NET plug-in for IDEA Ultimate.

But if your buying the full version, then the full library is only another £100 to begin with. Cheaper for personal use, and free for students. https://www.jetbrains.com/idea/buy/#commercial?billing=yearl...

"only" another £100? That's a lot of cash.

Re: The Era of Visual Studio Code

#303

I like the enthusiasm, but this article is a little too breathless to be fully believed. > The most important thing I look for when choosing which tools to use is longevity. In my time, I've programmed using Director, Microsoft QuickBASIC, FutureBASIC, THINK C, CodeWarrior, BBEdit, TextMate, Visual C++, Visual Studio, Sublime Text, Eclipse, Atom, VS Code, IntelliJ, XCode, and probably a few others I'm forgetting. I d…

I've given VSC several months. I just went back to ST3. I find it refreshingly clean.

Re: The Era of Visual Studio Code

#304
post #256
post #238

Earlier quoted context omitted.

Fancy IDEs are lubricants for high-friction languages. If a language is already low-friction, there won't be much benefit to be gained from an IDE, as even a plain text editor will already get you near to optimal productivity in said language. Personally, I'd rather use a plain-old "code editor" (with at most syntax highlighting, but no snippets, let alone autocomplete), in part because doing so will actively steer m…

All of this is fine if you don't work with others. The point of these tools is to standardize around something to reduce the cognitive load someone has to experience contributing to code that they didn't write. The amount of possible paths are commonly reduced for the reader. Linting, snippets, autocomplete, are all things that prevent you from bending the nail or breaking off the head which makes maintenance harder…

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 dimensions of inter-module connectivity in the first place; and for what dimensions they do provide, they steer people away from using them too often, perhaps with opinionated linting, or by building the standard library out of the simple stuff, such that all code that interacts with the stdlib keeps to the same simple style to avoid style-clash.

This approach will also "reduce the cognitive load someone has to experience contributing to code that they didn't write"; but it reduces that cognitive load even for people reading the code in a text editor. Or for the maintainers throwing snippets of the code around in a PR / patch-submission mailing-list.

Re: The Era of Visual Studio Code

#305
post #83

Earlier quoted context omitted.

My only problem with it is performance when you load large repos and occasionally large files because it is an Electron app eventually. I know the extension ecosystem has thrived just because it is Electron but I wish MS worked on a native editor to achieve it.

People like to bash VS code performance, but try opening a 60MB JSON file in different editors on Windows for example. Notepad doesn't even load and crashes, Sublime will takes minutes to even load the file, Notepad++ will be unusable as scrolling will take a few seconds, and in VS Code it opens immediately and you can seamlessly scroll to any one of the 600k lines without any delay.

Load it in Vim and it works as smoothly as with a single line file.

Re: The Era of Visual Studio Code

#306
post #238

Earlier quoted context omitted.

Fancy IDEs are lubricants for high-friction languages. If a language is already low-friction, there won't be much benefit to be gained from an IDE, as even a plain text editor will already get you near to optimal productivity in said language. Personally, I'd rather use a plain-old "code editor" (with at most syntax highlighting, but no snippets, let alone autocomplete), in part because doing so will actively steer m…

C# is designed for comfortable with using IDE. I like both approach.

I can really appreciate the approach of designing a language to work alongside an IDE to allow both complexity and ease of use. That being said, in my heart of hearts I would rather have a language that I can use effectively without depending on a specific IDE, but I'm glad there are folks exploring that route.

Re: The Era of Visual Studio Code

#307

Question I have for everyone who doesn't use an IDE What is your workflow? I find the following to be true, in that one of 3 things happens inevitably: 1. The Text Editor becomes the IDE, (e.g., with VSCode, if you just live in plain HTML, CSS/SCSS/LESS and JSX/TSX/JS/TS all day, its actually pretty great, lots of well maintained extensions and Microsoft really put their energy into capturing into this market with VS…

I run a pretty much stock configuration of Sublime Text alongside gnome terminal. I have no issues navigating projects as large as gecko/WebKit/Linux and getting spun up on a new language is really fast: Open the project, maybe install syntax highlighting if needed and you're good to go - as opposed to finding/installing an IDE.

My last Job had a large Java codebase and all my colleagues used Java based IDEs. I didn't see any performance disparity. I more than once saw a colleague take 5+ minutes making the same edit on a large number of lines because they hadn't learnt how to actually efficiently edit code in their IDE.

The way I see it, you need to keep the codebases you're working on in your head anyway (the parts you're working with anyway) to actually be productive. You do this by reading and understanding the source code on the screen. Until an IDE can provide a tailored human interpretation of the code it's analysing rather than some narrow static analysis I just don't see the point.

Re: The Era of Visual Studio Code

#308
post #304
post #256

Earlier quoted context omitted.

All of this is fine if you don't work with others. The point of these tools is to standardize around something to reduce the cognitive load someone has to experience contributing to code that they didn't write. The amount of possible paths are commonly reduced for the reader. Linting, snippets, autocomplete, are all things that prevent you from bending the nail or breaking off the head which makes maintenance harder…

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…

For general interest, what programming languages do you classify as low-friction?

Re: The Era of Visual Studio Code

#309
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…

> To me the future is IntelliJ for Java and all other languages should seek to have such a nicely integrated experience with an IDE. If you think Java + IntelliJ is well-integrated, you should try C# + VS, C# + Resharper. I am not joking or being facetious - modern C# IDE support is on another level. And I don't even like C#.

Or swift/objective-C and Xcode

Re: The Era of Visual Studio Code

#310
post #159

Earlier quoted context omitted.

> Remote development one. Careful with the Remote Development plugin. It does NOT have an open source license.

I’m curious, why does this fact require that on be careful. I’m not trolling, I’d like to understand the cautionary stance.

I think this person wants you to be careful the way you should be careful around using Windows 10, or Apple App Store, or the iPhone, or Dell Laptops.

Absolutely everything we use has non-opensource components, unless you try to pursue the path of a purist.

Post reply on HN