Live data from Hacker News

Visual Studio 2013

blogs.msdn.com

161–170 of 201 posts

Re: Visual Studio 2013

#161
post #151

Earlier quoted context omitted.

Most of HN criticizes microsoft for slow releases cycles Just because it's trendy to bash MS for not releasing new browsers/IDEs/whatever every few weeks, that doesn't mean the vocal critics speak for all of us, nor even necessarily for the majority. I get paid to build stuff that works, and doing so requires stable foundations and reliable tools. Lately, I wish we had more Microsofts in the world paying attention to…

>Lately, I wish we had more Microsofts in the world paying attention to things like backward compatibility and long-term support, and fewer Googles and Mozillas and Apples who are quite happy to push out updates that break useful things that worked before. Did you mean forward compatibility?

Did you mean forward compatibility?

No, I really did mean backward compatibility. Specifically, I was thinking of the degree to which MS have supported even very old (by IT standards) APIs and file formats and protocols even in much newer (again by IT standards) systems over the years, and the lengths they have sometimes gone to in order to maintain that support despite the potentially breaking changes not even being their fault in many cases.

However, I would also agree that they are better at forward compatibility than a lot of other major software developers today.

Re: Visual Studio 2013

#162
post #128

Earlier quoted context omitted.

Keep in mind that this is the group that thinks de-prioritizing 64-bit windows builds is a-okay while at the same time they need 64-bit windows machines running 32-bit linkers to build their 32-bit windows binaries. ...phew, what a mouthfull. Mozilla has never struck me as the most... forward looking.

For one thing, I don't think their JIT produces code that properly follows the Windows x64 ABI yet. It really should be disabled in 64-bit builds until they do.

Following the ABI is only an issue at module boundaries. If you control every callsite of a function, you can invent whatever calling convention you want.

Re: Visual Studio 2013

#163

Earlier quoted context omitted.

Keep in mind that this is the group that thinks de-prioritizing 64-bit windows builds is a-okay while at the same time they need 64-bit windows machines running 32-bit linkers to build their 32-bit windows binaries. ...phew, what a mouthfull. Mozilla has never struck me as the most... forward looking.

btw, Google Chrome doesn't have a 64-bit version* for Windows. The Chrome team also disabled PGO on Windows because of the same MSVC linker limitations that Mozilla hit. * Edit: oops, I corrected a typo where I wrote "32-bit build".

Yes, though that is far less a pain in the ass since they use multiple processes. I can't count the number of times I have run out of memory with firefox on windows despite having far more than firefox was using.

Re: Visual Studio 2013

#164

As someone who uses reharper to make the IDE cool, git for source control, teamcity for builds, nunit for C# tests, mocha and testacular for js tests, and a goddamn whiteboard, cards, pens, and blue-tack for "agile portfolio management", I'm not seeing a lot here that interests me. I'm underwhelmed with the desire to suck all activities into the one tool to rule them all. Especially when it rules them from bleh TFS.…

I want VS to let me write code. I want to find and manipulate text. I want it to compile fast and produce relevant warnings. I want a debugger. I want it to host duiverse plugins. That's mostly it. That's all I want Visual Studio for, too. Fortunately those things will continue to work and we can continue to ignore things like TFS and mstest.

It would be really nice if you could strip the things out of VS that you don't want. For me, all I really want is the code editor, R#, NCrunch, nuget, and the debugger. There might be a few other things that I didn't think of right away. I personally prefer to do source code management (git) outside of the IDE, because I find visual studio doesn't tend to make good choices about what should be controlled.

If I could make VS just do those things and nothing else, that would be really nice.

Re: Visual Studio 2013

#165
post #154
post #71

Earlier quoted context omitted.

Well, just to address the first point there is undeniably an "exodus" from Visual Studio. Just look at all the code shipped to run in browsers, or iOS, or Android, or on node or rails. A decade and a half ago a far (far!) greater fraction of that was spend in a Microsoft IDE. But that's really not the point. The upstream discussion was much narrower, and focused specifically on C/C++ support, which frankly sucks in t…

Undeniably? Not quite. Your reasoning is really faulty because you aren't accounting for overall growth in the industry. If the world Irish population increases by 20% does this mean that the Asian population shrunk? Of course not. Consider that Tablet and Smartphone platforms are in addition to flat PC sales. http://www.guardian.co.uk/technology/2013/feb/01/tablets-cro... http://www.wcu.edu/ceap/houghton/edelcompedu…

Did you miss the bit where I said the "exodus" (I even used scare quotes!) wasn't the point?

Re: Visual Studio 2013

#166
post #164

Earlier quoted context omitted.

I want VS to let me write code. I want to find and manipulate text. I want it to compile fast and produce relevant warnings. I want a debugger. I want it to host duiverse plugins. That's mostly it. That's all I want Visual Studio for, too. Fortunately those things will continue to work and we can continue to ignore things like TFS and mstest.

It would be really nice if you could strip the things out of VS that you don't want. For me, all I really want is the code editor, R#, NCrunch, nuget, and the debugger. There might be a few other things that I didn't think of right away. I personally prefer to do source code management (git) outside of the IDE, because I find visual studio doesn't tend to make good choices about what should be controlled. If I could…

I strip down the UI a lot. I don't have any toolbars visible, for example. It's not exactly the same thing, but I have no complaints, really.

Re: Visual Studio 2013

#167

No mention at all about missing C++11 features. I hope their continued silence is not an indicator of nothing to come. http://cpprocks.com/c11-compiler-support-shootout-visual-stu... It should be noted that features listed as included in the VS2012 Nov CTP, such as initializer lists, variadic templates, etc., should not in my view be listed. The CTP does not work via the Visual Studio interface, but only from the com…

Yeah, it seems I was overly optimistic when I wrote that post on CppRocks. I was thinking that they would release another update of the CTP features pretty soon, but it doesn't look like it's happening...

Re: Visual Studio 2013

#168

Earlier quoted context omitted.

Mozilla has been fighting the MSVC linker's 3GB virtual address space limit for years. Mozilla has asked Microsoft for a 64-bit linker that can produce 32-bit code, but Microsoft apparently has no plans for such a configuration. https://groups.google.com/forum/?fromgroups#!topic/mozilla.d...

Disclosure: I'm a new guy at Microsoft, not in the VS team, just speaking from prior experience as a Win32 developer. There are still internal limits in the PE32 format which mean parts of the output as a whole will be limited to 2 GiB or so, regardless of the address space available to the linker. I too have hit internal linker limits from time-to-time, but the span of computing history in which it makes sense to ha…

In Mozilla's case the _output_ is nowhere close to 2GiB.

What hits the 32-bit limit is the link-time code generation, which has to have the entire program's AST, plus all the profiling information, plus whatever other data structures it's using in memory all at once.

Re: Visual Studio 2013

#169
post #139

Earlier quoted context omitted.

I'm not sure where that fits in. Are they wanting to use a 64-bit cl.exe and a 64-bit linker to make 32-bit output? Does mixing and matching the cl.exe and the linker change how much memory the linker can use? I am baaarely familiar with Microsoft-world development.

Yes, they can use a 32-bit cl.exe and 64-bit linker, but most build systems don't make it easy.

You can't use a 32-bit cl.exe and a 64-bit linker to produce 32-bit binaries if you're doing PGO (which is the whole point of this "using lots of memory" issue). In particular, the 64-bit linker can't produce 32-bit binaries when you're using link-time code generation, which PGO does.

Re: Visual Studio 2013

#170
post #59
post #17

Yet another Visual Studio, yet another truckload of "features" that do nothing to help day-to-day, heavy-lifting programmers. (And which probably help by adding bugs or just bloating the system). Sigh. I am hoping they have made substantial improvements that are not mentioned in this blog post.

Try R# with VS.

But the point is, we have to buy the costly VS AND pay a third party to get the real goodness of an IDE.
Post reply on HN