Live data from Hacker News

The Era of Visual Studio Code

blog.robenkleene.com

291–300 of 698 posts

Re: The Era of Visual Studio Code

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

(disclaimer: I am an IntelliJ fanboy)

> 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.

I don't know if you are talking about IntelliJ or VCS, but IntelliJ can quickly start an empty project. And you don't to spend time to figure out how things work. I mean, there is literally no entry barrier for a bare bone project.

> I wish there was an editor with low latency, smart search, some proper file system database

You are describing an IDE here. Smart search and a proper file system database, it means operating not on a collection of text files but on a project and a code tree, which is the main difference between IDE and Editor.

> I think the success of VSCode is because you can easily open it in your current directory from the terminal and it will show you your folder etc.

IntelliJ is adding this functionality slowly: https://blog.jetbrains.com/idea/2020/04/lightedit-mode/ It's not on par with opening a folder in VCS, but it's a matter of time until the close the gap if they choose to.

Re: The Era of Visual Studio Code

#292

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 use a simple code editor with as few extensions as possible, and a terminal.

My goal is to keep my setup as simple as possible so that I’m able to switch easily, but I’m not really looking for more features or functionality.

Re: The Era of Visual Studio Code

#293
post #159

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)

> 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.

Re: The Era of Visual Studio Code

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

It's remote server support over ssh is seamless. It's pretty amazing it took this long to get to this point. Pity it gobbles so much memory.

Re: The Era of Visual Studio Code

#295

The "Aggressive development" point is what got me to switch to VSCode from Sublime. While most of my colleagues were switching to VSCode, I stuck with Sublime, after never fully jumping into Atom for performance reasons. However - and I'm assuming due to the open source nature of the platform, or the accessibility of JS vs Python, extensions were just higher quality on VSCode. I think the Go extension is maintained b…

It would be killer if the sublime guys could just support the vs code extensions.

Re: The Era of Visual Studio Code

#296
post #117

Earlier quoted context omitted.

Note that this feature doesn't work in open source builds of VSCode, it's an MS only thing.

I read about this fact elsewhere also. Could you expand on this a bit? My impression was that VSCode and its associated extensions are open source, so I'm curious how Microsoft could make certain parts exclusive to its own build of VSCode.

Because VSCode is under a permissive license (MIT) rather than a copyleft license (GPL), Microsoft can add any proprietary extensions it wants. "Permissive" licenses are only permissive for the creator and other developers (only sometimes), not for the end user.

Re: The Era of Visual Studio Code

#297
post #268
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…

> Imagine if there was a hammer that was so badly-balanced that—despite being not too hard to lift—you needed to be wearing a powered exoskeleton to accurately hold and swing it. That'd be a bad hammer, right? Hammers are hand-tools; it's an expectation that they'll work when used "manually", i.e. with raw human capability alone. I remember people making similar arguments when cars started to have power steering. > P…

> and expecting them to be skeuomorphic to a particular approach may hold us back

Whatever a programming language is, it has to be something you can hold onto in your head, because the human mind is where "programming" takes place. And there really aren't many forms that such a thing can take.

The step-sibling of programming languages, the mathematical proof, can really take any form we like; we're not limited to maths that can run on a computer, as long as we can "run" them in our minds. But we've still ended up with only two basic formalisms that almost(?) all mathematics is expressed in terms of: geometry (visual mathematics), and algebra (symbolic mathematics, including formal logic.) Because those are the formalisms that we have mental hardware to comprehend.

Anything that isn't in one of those shapes (say, an exhaustive computer-assisted proof-by-parts) might still be productive to prove; but we humans won't like it, and will always seek to replace it with something that we can get a mental "handle" on.

We'd certainly never take the formalisms that do work for us, throw them out, and replace them with non-human-mind-comprehensible formalisms instead. Why would we bother? What would we gain?

> Being able to push secondary parts of a program to be foldable, or visible on mouseover but not by default, makes it easier to communicate understanding to other humans. And actually that's a more faithful recreation on how you'd communicate in writing - on a blackboard you might use small text, or footnotes, or a verbal explanation.

Oh, I don't disagree. But all those things are useful for plain text, too. As you say, humans already think and manipulate text that way. And "advanced" text editors already provide facilities to manipulate text that way, without any understanding of programming-language syntax.

You can get very fancy about how you manipulate symbols... as long as "just manipulating symbols" is truly all you're doing. As pure symbol manipulation is something you can always also do in your head. Go much beyond that, though, and you stray from the land of "things humans can keep track of in their brains."

Can you think in terms of what a JetBrains codebase will look like after you refactor it, without actually doing the refactoring and seeing the result? How about with two or three such applications in play? It gets pretty hard, no? Because those aren't just pure symbol-manip. They're not just moving letters around on the mental blackboard that represents the current module. The non-local effects aren't strictly intuitive. Each layer of that that you have to hold solely in your head, bogs you thinking down. In a high-friction language, you just don't bother to try to work too far ahead with such changes; you just "take things one step at a time", applying each change and then re-learning the codebase in light of it; sometimes applying a change and then backing out once you realize you're got your sequencing wrong.

Sometimes working "with blinders on" like this is necessary (e.g. fixing up a big ugly three-way git merge); but why subject yourself to it if you don't have to? Wouldn't you rather be able to understand what you're doing, and where you're going?

> A mathematical paper is almost never "plain text" in the sense of being a linear sequence of ascii characters and nothing more.

I mean, they're usually written in LaTeX ;) But to be clear and precise, I was trying to invoke the concept of a https://en.wikipedia.org/wiki/Formal_language. Programming languages and (symbolic) mathematics are both formal languages. You manipulate them algebraically, by moving the symbols around, applying transformations that turn one valid statement into another valid statement.

Yes, there are isomorphisms, e.g. visual "programming languages" like Scratch. They're certainly neat, but as far as I've been able to ascertain, people can't really think in them the way they can think in symbols.

Ask a composer: what do you think about when you compose music? Do you think of the sound; or do you picture the score? Where music's concerned, I would guess pretty much everyone is thinking about the sound, because that's a lot more intuitive. Someone could probably write a song entirely by manipulating a score in their mind—and make it sound good!—but it'd be hell to do, in comparison.

Re: The Era of Visual Studio Code

#298

Earlier quoted context omitted.

I used to use Intellij for everything (and I'm not even a Java dev). It is indeed very nice and comes with so much out-of-box around languages and popular libraries. However, Intellij is _sooo_ very slow to load and edit with. This is more tolerable if you work on one project. But in the past couple years, I've had to work on many smaller projects, and loading up Intellij for multiple projects meant gigs of RAM disap…

Are the projects related? Or all unique? If related, you can create a uber project and import each directory as a module. I’ve got a project right now with 5 modules - 2 JS, 1 Go, 1 Python, and 1 Ruby (Rails). I’ve found this keeps memory usage down.

They're for separate clients. I've thought about doing something like a giant monorepo of client projects even though they aren't related. It's hacky at best, but ultimately I felt I should just use the right tool for the job and VSCode seems like a better fit for this scenario.

I'm sure someone else will benefit from this suggestion though. Intellij is pretty flexible and it is amazing what it can do, if you don't mind the performance trade-offs.

Re: The Era of Visual Studio Code

#299

I'm not a fan of VS Code because everything is a plugin. And plugins are inconsistent, buggy, inconsistently documented, hard to use and find and update and goodness knows who developed them. Plugins can be duplicated, outdated, abandoned and incompatible. But worst of all, a big pile of plugins isn't a consistent integrated product vision. I gave VSCode a solid go, and I had to keep installing plugin after plugin, b…

I think it's the core product values for me. JetBrains IDEs are development environments, meant for editing code, in specific primary language. They really try their best to understand code that user works on (which is a hard problem, because code is frequently invalid while it's being actively edited), and make it as convenient as possible. VSCode is - in my understanding - essentially, a step over older glorified e…

> JetBrains IDEs are development environments, meant for editing code, in specific primary language.

I've used RubyMine and IntelliJ. IntelliJ kept me sane for the thankfully-short time I worked with Java, and I appreciate it. But I can't get past how SLOW RubyMine is. Even on my $4,000 MBP, it just feels sluggish. Maybe that's because I'm at home on Rails, and I can think faster than the IDE, but there's really not much excuse to my mind for being that slow, especially on top-end hardware. It once helped me debug a plugin of plugin of a gem, and I'll be forever grateful for that, but I keep trying it every so often, and failing to part with my cash for it. I pay a lot for software, in general, but that one's just too steep for my taste, when tools like vim, Sublime, and VS Code exist.

Re: The Era of Visual Studio Code

#300
post #186

Earlier quoted context omitted.

IntelliJ Ultimate has support for all of the languages except C/C++, C#, and Swift/Objective-C.

But there are JetBrains IDEs for those too — CLion, Rider and AppCode respectively. No IDEA how well they work though.

I'm aware. They cost more money though.
Post reply on HN