Live data from Hacker News

The Era of Visual Studio Code

blog.robenkleene.com

311–320 of 698 posts

Re: The Era of Visual Studio Code

#311

Earlier quoted context omitted.

It seems like Emacs shares the same product philosophy of VS Code. Outside of the core functionality everything is an ELisp/Javascript plugin. That explains Emacs amazing longevity, but as the article points out, Emacs longevity is actually a problem as its keyboard and UI conventions predate the modern conventions that came with Windows and MacOS.

It's a slightly different philosophy. Emacs is best viewed not as text editor with plugins, but as a Lisp Machine emulator with a text editor. The joke about it being an OS is more true than people think: what you get is a (2D, not 1D like shell) text-oriented programming environment, back from the times where "a programming environment" meant a fully end-user-programmable OS. This has an important downstream consequ…

Keyboard conventions do come and go but muscle memory is expensive to reprogram. Your hands are also irreplaceable. So I go for the most efficient that's not too radically unfamiliar or painful.

And honestly one could spend a career learning every editor/IDE in depth without ever accomplishing anything else. Embedded is especially bad as one often must use the IDE integrated into the platform's SDK.

Re: The Era of Visual Studio Code

#312
post #172
post #119

Earlier quoted context omitted.

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.

This is also true with TRAMP. Anything in core Emacs, and any package outside it that isn't aggressively poorly written, works transparently with TRAMP. The core utilities for interacting with the OS such as start-file-process are all TRAMP-aware. (Or more specifically, TRAMP provides file handlers which customize start-file-process)

One area I have found where TRAMP really suffers is when you have a relatively high-latency connection. I'm living on the east coast right now and connect to a dev box in Washington to work, and tramp is basically unusable. Every time you enter a folder in a project, emacs will stall for 1-2 seconds (unless the folder has been entered and cached before: unfortunately every time you restart emacs you'll have to go through it all again). If you've forgotten to disable autocomplete in a remote shell buffer, the first character you type will cause emacs itself to hang forever. There's unacceptable lag when opening and even navigating files. Good luck ever running grep or magit.

With VSCode on the other hand, I have no issues at all: couldn't even tell the project was remote.

I still use emacs (emacs -nw via ssh), but it's nowhere near VSCode's responsiveness and now I cant use GUI emacs. It's definitely a source of frustration :/

Re: The Era of Visual Studio Code

#313
post #264

Earlier quoted context omitted.

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.

The tutorial also said that you are placing this string in an xml file for easy localization in the future. I am not defending their setup, but it sends a wrong message when you skip parts of the sentence.

Re: The Era of Visual Studio Code

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

That's why... (insert brain's attempt to argue for vim)... you don't open files on Windows.

Re: The Era of Visual Studio Code

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

If you think c# with resharper is good, cut out the middleman and just go with rider.

Re: The Era of Visual Studio Code

#316
post #297
post #268

Earlier quoted context omitted.

> 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 mat…

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

I don't think the IDE should do "everything" for you, and you should understand how its building/compiling the software. But with statically typed languages and library definition hints. I think I would be wasting time searching docs if I didn't have the hints and type info. I can't remember everything I work with, it's impossible.

Re: The Era of Visual Studio Code

#318
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 doesn't replace the IDE, it replaces the simple text edit like Notepad++.

Re: The Era of Visual Studio Code

#319
post #74
post #43

Earlier quoted context omitted.

Which IDE? If you mean Visual Studio, that's a Windows only product and it's really only good for Windows specific development like C# and MSVC. If you do C# or C++ development on Windows or XBox then you're likely already using Visual Studio and the community edition is a free product for individual use or open source products. If you mean some future IDE that MS is working on that they plan to evolve VS Code into,…

Visual Studio for macOS (and Linux) exists, it was previously named Xamarin, and before that MonoDevelop.

Visual Studio for Mac is nowhere near as good as on Windows. I can't speak for how it is on Linux. I'm glad it exists, but I've found it a pain to use.

Re: The Era of Visual Studio Code

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

My experience of IntelliJ is that it looks nice but it is very complex and offers little compared to Eclipse. For professional reasons I had to learn Eclipse, and now I see that IntelliJ gives a more polished product. But when I need to relearn all that I had with Eclipse, I don't see the point.

IMO Eclipse is dying. Its new release cycle is pain because it fixes bugs only on quarter releases, they don't release patch releases even if very problematic. I encountered a few bugs.
Post reply on HN