Live data from Hacker News

The Rise of Microsoft Visual Studio Code

triplebyte.com

301–310 of 327 posts

Re: The Rise of Microsoft Visual Studio Code

#301

Because of the popularity of VS Code on HN, I decided to give it a try. It's good. Much better than Electron or Atom for my workflow. And much faster IME. The one thing that keeps me from switching from my current IDE is the lack of Whitesmiths brace formatting. I'd pay up to $15 for a Whitesmiths plugin. Until then, I can't change. But I'll keep checking.

Hey, I'm familiar with VS Code language extensions. Depending on your language you may or may not be able to do this. The controls you have are:

- increaseIndentPattern: If a line matches this pattern, then all the lines after it should be indented once (until another rule matches).

- decreaseIndentPattern: If a line matches this pattern, then all the lines after it should be unindented once (until another rule matches).

- indentNextLinePattern: If a line matches this pattern, then only the next line after it should be indented once.

- unIndentedLinePattern: If a line matches this pattern, then its indentation should not be changed and it should not be evaluated against the other rules.

They are all regex patterns. If you think your language would let you do that, I can try and throw together something for you.

Re: The Rise of Microsoft Visual Studio Code

#302
post #264
post #234

Earlier quoted context omitted.

> My anecdotal experience says that 1) most programmers are monolingual, This surprises me as I've never worked on a nontrivial system that's also a monolingual system. There's nearly always another language to use to get the job done, whether for configuration, scripting/automation, or because backends and UIs are written in different languages, especially for internet-based software.

There's nearly always another language to use to get the job done Sure, but in most cases programmers spend most of their time only in one 'part' of the system and only really have to know the language that part of written. In general it doesn't matter if the back end server is written in Lisp, Java or APL, as long as it talks to my part of the system in the way it's supposed to.

> in most cases programmers spend most of their time only in one 'part' of the system

Perhaps that's a reflection of the structure of the organizations they work in.

Anyways, the other cause of multilingualism is switching jobs, projects, or problem spaces. All three of those often involve a language switch.

Re: The Rise of Microsoft Visual Studio Code

#303

Earlier quoted context omitted.

Depending on the task and the familiarity of the user with the editor, it can make a big difference! As an extreme example, a good 80s programmer might work efficiently on a file in ed, but nowadays approximately no human could do that.

But their tests don't measure "how efficiently" the candidates edit files, do they?

OTOH, I've found that having a mastery of Vim helps me out a LOT in interviews where I get a computer to work at. I can actually type faster than I can think at this point, so I get to express my ideas pretty much as soon as they come to me, which allows me to "look more impressive", I guess.

They certainly shouldn't judge based on the choice of an editor or language, but 1) seeing that someone is very comfortable in any editor and any language shows they've been at it for a while, and being able to express the right answer quickly is almost as important as finding it at all.

Re: The Rise of Microsoft Visual Studio Code

#304
What I would gladly pay 100$/month for is Vim with correct syntax highlighting, intellisense and nice plugins (such as fuzzy finder) by default.

It would not need to be Vim, but I have only tried one Vim emulator that didn't suck and was terminal-first: emacs with evil-mode. Let that be the bar for vim-emulation.

Why is nobody doing this? I think this would appeal to a lot of people.

The criteria for me to to pay for something like this would be:

1. Terminal first. It would either have to become my main shell or open fast within my shell.

2. Vim based or with GOOD Vim emulation. Macros, remapping and all normal mode key combinations must be implemented.

3. Fast terminaleditor loop. I don't want to wait >300ms to edit a file.

4. Actual production quality zero-config syntax highlighting, intellisense and fuzzyfinder.

Sign me up!

Re: The Rise of Microsoft Visual Studio Code

#305
post #141

Like it was said in this thread, as long as you have an editor that is built on something js-related like electron or node-js, it just cannot beat alternatives that are made in C++. I've tried VSCode because I wanted to have UI breakpoints with GDB, I admit that vscode seems better than atom, but for performance I have my doubts. I really don't understand why engineers choose to use JS to made a text editor. I know t…

Everyone is on the argument that because you use C++ you'll always be faster.

I disagree, you get fast by using good datastructures and algorithms. Yes, for the same algorithm C++ may have some perf gains but it's so easy to shoot yourself in the foot. Visual Studio itself is written in Visual C++. It's slow and a memory hog.

Most folks who are not familar with JS don't understand the internals of V8. V8 does amazing things to compile the JS down to really fast bytecode. It builds hidden classes and structs just the way you'd write C++ and them compile them to machine code. There are many instances where the C++ code won't be much faster than the JS. In some cases naive C++ is even slower.

As for VSCode, it's a testament to show you can build very usable things by using the web as a platform. Chromium's blink's engine is fast if you know what you're doing.

Sublime is great, don't get me wrong, but VSCode's extension architecture gives it a leg up. It's so much easier to write a vscode extension than a sublime extension. Typescript gives the JS world a lot of sanity.

Re: The Rise of Microsoft Visual Studio Code

#306

Earlier quoted context omitted.

From a point of anthropological curiosity, do you work in a team where everyone uses that style of brace indentation? Is it actually common and I've just never encountered it before?

I don't think it's common, but one of the projects I work on has the entire codebase and documentation already in Whitesmiths. I don't know much about the history of how it came to be that way, but it's my understanding that pretty much everyone else who's ever worked on the project came either from big iron, or had big iron in their background. Maybe that's where it came from. I could just be used to it now, but I f…

I've never worked in a Whitesmiths codebase, but I always thought it looked nice.

The one downside compared to what I mostly end up working in is that it wastes some vertical space because the opening brace is on a new line.

Re: The Rise of Microsoft Visual Studio Code

#307
post #184

Earlier quoted context omitted.

I also very much related to this, the two exceptions I find awkward from the command line are: * Doing partial adds with `git add -p`. I see the hunk it presents see what I want from it, but then sometimes have to go through several iterations of splitting, skipping etc.. A visual tool (even like the tool in vim-fugitive) is a huge improvement. At the end of the day I'm still looking at the staged diff before committ…

There's a somewhat hidden gem in vanilla git which can be sometimes useful: git gui You can right-click on some line in the file and select "Stage Hunk for commit", etc. instead of `git add -p`. It can be also helpful for browsing history, esp. "blame digging".

I love git gui. I've used it for more than 5 years now. Has an ugly UI, but it's very functional and complete.

Re: The Rise of Microsoft Visual Studio Code

#308

The only issue I have with VS code is it's awful UI/UX performance - it behaves like an Electron app or something. I realize that's a fair insult around these crowds, but it really does have that lack-of-polish, weird-UI/UX feeling. I know Microsoft would obviously never build an IDE off it, but I'm almost curious to see what on earth they did wrong. Comparing it side-by-side with Xcode is certainly the easiest way t…

Because it is indeed an electron app

Wow. Any and all respect for the app - lost.

Re: The Rise of Microsoft Visual Studio Code

#309
post #90

Earlier quoted context omitted.

No, but why would that be a concern? If you're going to use Emacs as your environment, it's best to learn how to install additional packages, as you'll get a lot more functionality that way. If you're using Sublime or VSCode, I'm sure you'll one day install plugins for it as well.

At least for me, sometimes I have to work on servers where I don't have sudo privileges, so I usually can't install plugins.

You don't need sudo privileges to install packages for Emacs. They reside in the user's directory.

Re: The Rise of Microsoft Visual Studio Code

#310
post #98
post #2

Another interesting angle on this is that VS Code is free (and open source), while Sublime is proprietary and (nominally) costs $80. I wonder how many people don't use Sublime because of the price? Atom is free too and never surpassed Sublime.

A lot of people I know who use Sublime never paid. In fact, I don't know anyone who paid for it IRL except myself. If you don't pay, you only get a nag screen from time to time as you save. And cracks most likely exist if you want to get rid of it without paying. BTW, I still use Sublime Text. I gave a try to VS Code and it is really great. It has most of the things that made me switch to Sublime (from Emacs), plus s…

Funny tho, that purchasing prompt is the only "feature" I'd missed from Sublime after switching to VS Code.

So I made one for it [1].

[1] https://marketplace.visualstudio.com/items?itemName=cottonh....

Post reply on HN