Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Visual Studio Code 1.0

code.visualstudio.com

Post reply on HN
Print view View original

451–460 of 487 posts

Re: Visual Studio Code 1.0

#451

Post by ajdlinux »

danjayh wrote: post #361
KirinDave wrote: post #344

Earlier quoted context omitted.

Because not everyone wants 20% below market rate, consntant negotiation headaches on stock dilution, an "infinite" vacation policy that actually means none, or being part of a culture that expects 70+ hour work weeks as normal, 3 months of maternity leave being ruinous to the company, etc. It's a tradeoff, for sure. But also most companies are waking up to the notion that trusted network models are not effective. It…

Ugh. 'Infinite' vacation policies are starting to infect corporaculture. I work for a megacorp (that I actually rather enjoy working for) that recently went this way, and since my megacorp is a bit of a trend setter, you can expect it to spread. During the explanation meeting, it was made clear that we really aren't supposed to take more vacation than what we used to have, but that we are expected to still actually t…

I'm glad I live in a country where it's illegal not to pay out unused leave entitlements upon termination, and where there is a sensible statutory minimum leave entitlement...

Re: Visual Studio Code 1.0

#452

Post by deprave »

One thing I've gotten used to and find missing in VSCode (and Atom) is auto-saving of untitled/unsaved buffers to temporary storage.

When I have an idea or want to use a new editor tab as scratch space, it's really important to me that whatever I put there isn't lost if I exit the editor. When I close the tab, sure, ask me if I want to save it somewhere. But when I close the editor itself, I want it to reopen and restore everything exactly as I left it.

The last thing I want to deal with is coming up with a path and filename when the editor can easily create a temporary file and map some unique id to it for later use until I tell it explicitly to save or discard it.

Re: Visual Studio Code 1.0

#453

Post by skun »

k__ wrote: post #437
pbreit wrote: post #337

Earlier quoted context omitted.

Agreed that Microsoft has developed a very fine code editor and a worthy competitor to Atom & Sublime. And if you can believe it, Adobe actually produces a decent code editor: Brackets.

Is it open source? (VSCode) Wikipedia: "Visual Studio Code is an open source source code editor"

Yes sir: https://github.com/microsoft/vscode

Re: Visual Studio Code 1.0

#454

Post by ajdlinux »

TeMPOraL wrote: post #282
crispyambulance wrote: post #149

Earlier quoted context omitted.

"a few hours" ??? Come on, let's not pretend that EMACS is going to take "a few hours" to come to terms with and become more productive in than an IDE.

Actually, you can get decently proficient in just few hours. Have you actually tried sitting in front of Emacs or vim for more than 30 minutes, to the clock ? Humans have this funny thing as they grow older - they look at a thing, maybe try it out for few seconds, and then immediately determine it's too difficult and it will take forever. They rarely bother to spend actual five minutes, to the clock. If they did, the…

I've used emacs as my main text editor at work for the past 9 months, and I can safely say I am still nowhere near proficient. I'm getting better, but I can fully appreciate why emacs has the reputation it has.

Re: Visual Studio Code 1.0

#455

Post by NoGravitas »

Analemma_ wrote: post #43
mjt0229 wrote: post #32

Earlier quoted context omitted.

Really? VSCode has already transformed the way code was written on Unix/Linux? I beg to differ. 10 years ago (when I discovered Eclipse, not sure when it was originally released), Eclipse was a staggering leap forward for Java programming. I'm no Eclipse fan, but I don't think that VSCode has already changed the world in the way that Eclipse did, and certainly not in its short lifespan.

I think what the parent meant was that VSC (along with Atom, and to lesser extent SublimeText) is a good example of "the middle way" that is rapidly gaining popularity. First we had console editors, but they weren't powerful enough, especially for newer languages/frameworks. Then we had full IDEs (VS/Eclipse/IntelliJ), but they got to be slow and clunky. Now the trend is toward "enhanced text editors" (VSC/Atom/ST):…

I kind of agree with this. The thing is, Emacs has always been "Generation 3" in your terminology. Atom and VSC are kind of bringing the Emacs way (extension language is implementation language, not restricted to a narrow plugin API) to a new generation, along with the graphical experience that Emacs doesn't provide (yes, I use GUI Emacs. Yes, Spacemacs is nice. Atom with Material-UI plugin is still prettier).

I'll be an Emacs user for life, but I am currently recommending Atom to people wanting to move away from language-specific IDEs and dabble in a text editor, because it has enough of the Emacs nature while not being too daunting.

Re: Visual Studio Code 1.0

#456

Post by sixbrx »

soft_dev_person wrote: post #438
dsl wrote: post #339

Earlier quoted context omitted.

From a security perspective, we ask: why are you developing applications that can't be ran by normal users? For the 1% of devs working on system level stuff we provide VMs or separate physical servers that aren't joined to the corporate domain and don't have sensitive information on them.

As an example, VS needs UAC permission to integrate with a local IIS install, so there's a big group of .NET-based web developers that really need it with such a setup. But honestly, giving a developer non-admin privileges of their own (as in their work environment) computer is like giving a carpenter a rubber hammer to hammer nails. I find it insulting.

At a lot of workplaces (like mine) it goes beyond that - developers aren't allowed to install software even under their own user account, where admin privs aren't needed.

Consider the irony of that, when one of the approved pieces of software is a compiler. We can make our own programs, hello!?

Re: Visual Studio Code 1.0

#457

Post by NoGravitas »

ctangent wrote: post #29
yisheng wrote: post #20

Are there any emacs/vim users here who moved to GUI editors like atom or VS code? I would like to know what potential gains could come from using a GUI text editor.

I'm a longtime Emacs user and I dabble with atom and code. The main thing that I get out of GUI editors is that extensions generally just work . I spent a lot of time debugging emacs extensions to the point that I kind of expected extensions to not work right when I install them - especially ones related to autocompletion. Nowadays I use spacemacs to keep my package management sane, but it's inflexible and complicate…

I'd say that's almost true. I'm also a longtime Emacs user. My work development is C# on Windows, so I've dabbled with VSCode and Atom.

My experience so far is that extensions on VSCode "just work", but they're scarce, and difficult to discover and install.

My experience with extensions on Atom is that they are numerous, cover a very wide variety of needs/wants, and that they frequently break when the main editor updates. I haven't been able to install/update the Omnisharp extension successfully since the npm debacle a few weeks ago.

I dabbled with Spacemacs, and it seems nice, but I couldn't work out how to migrate my existing extensive org-mode customizations without digging deep into the Spacemacs package management system.

Re: Visual Studio Code 1.0

#458

Post by Delmania »

dsl wrote: post #339
jasonjei wrote: post #267

Earlier quoted context omitted.

How do corporate developers test and debug things without the root password? In some cases, you need to be able to start Visual Studio in UAC mode, and debug an already running process...

From a security perspective, we ask: why are you developing applications that can't be ran by normal users? For the 1% of devs working on system level stuff we provide VMs or separate physical servers that aren't joined to the corporate domain and don't have sensitive information on them.

> From a security perspective, we ask: why are you developing applications that can't be ran by normal users?

Really? This question from a security engineer on Hacker News? I can tell you've never developed on Windows because (as pointed out) Visual Studio needs root level permissions to operate. The level of access a user needs to run my program has nothing to do with the level of access I need to build the program. They are completely disjoint.

Re: Visual Studio Code 1.0

#459

Post by eric-hu »

Razengan wrote: post #401
reitanqild wrote: post #388

Earlier quoted context omitted.

No, it is implemented by each editor/ ide independently with their own modifier. On the contrary we have mostly consistent ctrl/shift + arrow behaviour over the last 15 or more years(I don't know before that). :-)

> On the contrary we have mostly consistent ctrl/shift + arrow behavior Are you saying Windows has consistent Control/Shift + arrow behavior? OS X is pretty consistent about this too, though Control+Arrow moves between Desktop Spaces, not related to text, but you can modify a lot of system/app shortcuts from Preferences -> Keyboard -> Shortcuts.

Ctrl arrow in Windows jumps by word. In os x, it's option arrow. I believe it's widespread but not global.

Re: Visual Studio Code 1.0

#460

Post by itomek »

Delmania wrote: post #458
dsl wrote: post #339

Earlier quoted context omitted.

From a security perspective, we ask: why are you developing applications that can't be ran by normal users? For the 1% of devs working on system level stuff we provide VMs or separate physical servers that aren't joined to the corporate domain and don't have sensitive information on them.

> From a security perspective, we ask: why are you developing applications that can't be ran by normal users? Really? This question from a security engineer on Hacker News? I can tell you've never developed on Windows because (as pointed out) Visual Studio needs root level permissions to operate. The level of access a user needs to run my program has nothing to do with the level of access I need to build the program.…

I'm sorry but you are incorrect. VS needs admin rights to install into Program Files, registry updates and GAC install, etc. Otherwise the apps a developer builds are run in in their own process and unless there are special circumstances, should not need admin privs; VS should never be run as admin apart from those special circumstances.
Post reply on HN