Live data from Hacker News

The Era of Visual Studio Code

blog.robenkleene.com

271–280 of 698 posts

Re: The Era of Visual Studio Code

#271
post #214

As far as I know, there are no serious email clients for Visual Studio Code. So the kind of obsessive users, the ones that want to do everything with it, the presence of which indicates a really good piece of software, don't use Visual Studio Code. I consider that a fatal indictment of Visual Studio Code.

Surely even crusty greybeards would use a dedicated email client like mutt?

Re: The Era of Visual Studio Code

#272
post #264
post #255

Earlier quoted context omitted.

Java doesn't have a lot of friction. In fact, IntelliJ is probably the closest you'll get today to the "golden age" of programming with something like Turbo Pascal. Also, good luck doing major refactoring with a text editor. In 2020 we can do better than find and replace.

The way people use Java is a problem. Spin a blank "hello world" project in Android Studio and you get no less than 79 files, and it won't work the next time you update Android Studio because of some Gradle errors. I don't know what went wrong, but "hello world" should not be 79 files, it should be something that I can hand-code in something less than an IDE.

Heh. Some years ago, I thought I’d step away from highly available distributed systems and build an android app. Got to the point in the tutorial where we needed to define a string for “hello, world” and the tutorial said, “ok, navigate to such and such directory and add this xml file and ...”. Closed the tutorial assuming Java is not for me.

Re: The Era of Visual Studio Code

#273

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.

Right, but they would. Plugins aren't paid right now, so all I'd think it would take would be Microsoft saying "hey, people like your plugin, we'll pay you to maintain it, and if you don't want to maintain it, we'll inhouse it." To avoid left-pad situations

I don't know about VS Code, but in native VS, there are lots of paid plugins. There just isn't a store. You buy the plugins from the developers.

Re: The Era of Visual Studio Code

#274

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. 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. Unlike the FANG companies, Microsoft doesn't tend to rip the carpet out from under independent developers like that.

>Unlike the FANG companies, Microsoft doesn't tend to rip the carpet out from under independent developers like that.

No, they roll them into the carpet and sodomize them like they did with Keivan Beigi and at most just sheepishly say sorry after some public outcry.

Re: The Era of Visual Studio Code

#275

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

Re: The Era of Visual Studio Code

#276
post #238
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…

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.

Re: The Era of Visual Studio Code

#277
post #139

The thing that bugs me about VSCode is it's labeled as open source but a lot of pretty critical and interesting components are closed source so you have no idea what's going on under the hood. Normally that's not too big of a deal (I use plenty of closed source apps), but when it's Microsoft it's hard to trust what they are doing with that data. That and I feel that this promotes vendor lock-in at multiple levels. Ov…

Are you aware of vscodium? https://github.com/VSCodium/vscodium#why-does-this-exist

I have not personally audited it to see if it's better or worse than upstream vscode, but I believe the spirit of the project is closer to what you had in mind

Re: The Era of Visual Studio Code

#278
post #119
post #102

Earlier quoted context omitted.

Not to be that guy, but emacs has had this for years via tramp.

As someone who used tramp and switched to VS Code, it's absolutely not the same thing. The difference is plugins work on the remote side of the connection without having to be aware they're in a remote connection. VS Code makes this work by having an agent running on the remote host. For the first time I actually got autocomplete and code jumping working without a horrendous amount of effort.

> The difference is plugins work on the remote side of the connection without having to be aware they're in a remote connection.

This is cool when the machine you are connecting to is more powerful than the one you are sitting on. This is far less cool when the machine you are connecting too is less powerful than your desktop (RPi or Beaglebone, for example).

Re: The Era of Visual Studio Code

#279
post #255
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…

Java doesn't have a lot of friction. In fact, IntelliJ is probably the closest you'll get today to the "golden age" of programming with something like Turbo Pascal. Also, good luck doing major refactoring with a text editor. In 2020 we can do better than find and replace.

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 think in Java (rather than Java-esque pseudocode.) Try to write a Java program in advance, in your head, that only needs typing-in (in a plain text editor!), such that it's valid the first time you type it in. Imagine how carefully and meticulously you'd have to think, to get that code right. That required meticulousness is another measure of Java's inherent friction.

> good luck doing major refactoring with a text editor

A language can also be high-friction or low-friction when it comes to how hard it is to refactor code in that language. Though this comes from more abstract architectural constraints the language imposes, rather than things like syntax or identifier naming conventions.

For example: Erlang code is low-friction for refactoring, because code that lives in a separate process needs to be spoken to through a messaging ABI; which necessitates that every such process have an API-client module to encapsulate that ABI; where that client API then offers a de-facto interface/contract for clients of that API to hold to; which frees anything underneath that API from stability requirements, as long as the API itself remains stable. The fact that this is done "in the small", per process, rather than in the large, per package/library, means that Erlang "refactoring" almost always just consists of changing the shape of a process state-function, and then adding some polyfill logic to its client API module-function to keep the process working.

Re: The Era of Visual Studio Code

#280

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…

Geany plus Makefile with automated functions. Build keys can be assigned to avoid Window switching.

What walls were you hitting?

Disclaimer, I have used Pycharm on a really big work project but most of the time, don't.

Post reply on HN