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

Visual Studio for Mac

msdn.microsoft.com

Post reply on HN
Print view View original

281–290 of 435 posts

Re: Visual Studio for Mac

#281

Post by Kipters »

josephg wrote: post #242
brazzledazzle wrote: post #182

Earlier quoted context omitted.

I don't care about the touch bar and while I'm miffed about the magsafe I can deal with shelling out extra for accidental damage insurance. Personally my disappointment is with the specs which no time with the machine will change. The mac I'm currently using was purchased 3 years with 16GB of RAM and if I replace it I will be stuck with the same capacity. I imagine there are a lot of "Pro" market segments that are we…

I've spent the last 4 years doing development from a 2012 macbook air with 8 gigs of ram. Its been totally fine, except when I've got a million chrome tabs open. (Declaring bankrupcy and closing them all at once feels great though.) The posted article is about a mac version of visual studio. Coincidentally, visual studio only runs in 32 bit mode and hence can only make use of 4 gigs of ram total: https://blogs.msdn.m…

Talking about VS for Windows, that's the maximum footprint of the VS main process. If you use one of the WP8/W10M/Android emulators, then you need an additional 1/2/3 GB for the VM (plus overhead). Throw in some browser tabs, git (in VS15 it will be in its own process instead of eating up the main process' memory), some .NET Native/LLVM, the OS itself and you'll find that having 16 GB will give you quite some comfort

Re: Visual Studio for Mac

#282

Post by dep_b »

joeblau wrote: post #166
madeofpalk wrote: post #39

Earlier quoted context omitted.

If we're comparing Apples-to-Apples (seriously, pun not (originally) intended), Apple continues to rev on the XCode IDE every year adding more features to it. Most recently, they added a nifty visual memory debugger[1] and have taken another stab at device & certificate provisioning. [1]: http://useyourloaf.com/blog/xcode-visual-memory-debugger/

You're right, Apple is revving Xcode, but feature wise and bug wise, Xcode needs serious TLC especially on their Swift side. The regressions that are introduced every version don't help and tools like Interface builder, while seemingly helpful, usually make development within teams worse. I still use Xcode every day, but it defiantly needs hardening.

There goes good ol' anti Interface Builder rant again. The real problem is that Interface Builder is too easy to use while there's real depth and challenges to using it just like with doing everything in code.

- Don't throw all your screens into one file, you can even use one screen per file just like xibs

- Use code to style items and create controls you use more than once

- Render all the controls in code dynamically in interface builder so you won't end up with "ghost town" storyboards but everything is visible at a glance

Unless you're working at "Facebook scale" Interface Builder in the hands of an expert will get you very far.

Would you throw all your code in one big 8kloc controller? Of course not, but somehow people manage to cram every screen into the same .storyboard file, just because you can do it. Then they'll complain about merge conflicts, which isn't really a surprise given the fact that you're managing an 8kloc file.

Would you set the background, border, font and color of every button every time you use it in code? Of course not. You specialise a button class. But somehow people are selecting every button manually and setting those properties time and time again once they start using Storyboards while you can use a specialized class that will render in Interface Builder exactly like it will look in the app.

Re: Visual Studio for Mac

#283

Post by rietta »

coldtea wrote: post #63
rimantas wrote: post #29

Earlier quoted context omitted.

Apple is not saying anything like this, just a bunch of whiners twisting things. Just like they did after any Mac upgrade.

> WRONG. The removal of a dozen keys from an already gimped keyboard is decidedly anti-developer. I am a developer and I could not care less about function keys. Why the duck would developers need function keys? Even for Vim, the age-old advice is to remap Esc so that you keep your hands on the home row. A flexible multi-touch strip of context-aware keys can do much more things -- e.g. map debugger step moves when I'…

In Terminal, I have mapped common commands that I use all the time into macros assigned to function keys. For my Ruby workflows, I have various rake commands a single key press away. For when SSHed into Linux servers I have stuff like "sudo apt-get update && sudo apt-get upgrade" ready in a split instant. I tell you, it really is a party trick at work.

Re: Visual Studio for Mac

#284

Post by Kipters »

xrisk wrote: post #241
Kipters wrote: post #190

Earlier quoted context omitted.

I usually don't have to _remember_ keybindings, I use them out of muscle memory and feeling the actual keys with my fingers, using the larger cracks in desktop keyboard between the function keys to find the right way quickly without averting my eyes from the screen. No touch bar can replace that kind of efficiency.

Maybe, but for the average user who doesn't have keybinds committed to muscle memory, the touch bar is going to be a real boon.

So... the common non-pro user that would look down on the keyboard anyway?

Re: Visual Studio for Mac

#285

Post by hvidgaard »

ubernostrum wrote: post #179
hvidgaard wrote: post #163

Earlier quoted context omitted.

His argument falls short the second you want to use non optimized software - he even touches upon this, but "I understand people need to use programs from other developers, but at some point they need to play catch up". This is rather difficult to take seriously. So you can efficiently do what Apple say you can do, but nothing else? That might work in his line of work, but it doesn't for the rest of the world.

For his use case there is a pairing of software and hardware optimized to work with each other. In "professional" situations this is not, as I understand it, particularly unusual. And yet the unsuitability of the new MBP for "professional" use cases has been widely assumed on HN. It's interesting to see someone who actually has one of those use cases and has actually used the new MBP, weighing in to say "it works, an…

While it is not unusual, it's not what Macbook Pro has been known for since their transition to Intel CPUs. So it fits some specific use cases, at the expense of every other. And if they did make the hardware faster, all usecases would benefit.

All those people with a different usecase, are right to be annoyed by that. But just as this piece completely lacks unbiased opinion, so does the noise coming from HN (and the tech community in general).

Re: Visual Studio for Mac

#286

Post by Kipters »

yulaow wrote: post #261
Arcaire wrote: post #60

Earlier quoted context omitted.

Really? They seem to be opening up quite a bit more with regards to Linux (.NET Core, WSL, etc).

We are waiting since years for a simple xamarin studio for linux, even just supporting only ubuntu and letting the other distro to manage the packages for them... The reality is it seems they don't want at all to bring Xamarin on Linux, sadly Miguel was very clear about it in the years.

IIRC he said they discontinued Xamarin for Linux because of a lack of demand

Re: Visual Studio for Mac

#288

Post by 7Z7 »

JonnieCache wrote: post #246
7Z7 wrote: post #223

Earlier quoted context omitted.

>..musicians,.. I'm running a Logic set up on my 2012 MBP, and I've never felt limited by its capabilities. I've been running Macs for music production for almost 20 years, and in my experience they have all at some point not had quite enough in the bag to let me do what I wanted of them. This is the first one (now fours years old) that has stayed ahead of my needs. I can run multiple copies of Massive, and rows of W…

The people who make film/game soundtracks need a LOT of ram, and fast disks, because they're using terabytes of samples in each project. Also massive has pretty low requirements. The main gripe musicians have with apple is the new OSX breaking their setup every year. The sandboxing in el capitan was particularly disastrous.

That's fair. I definitely have done a lot of sample-based and multi-track audio work and again have never hit that limit (on this MBP). However I do agree that if you rely on 3rd-party plugins there is a crapshoot every year as to how long you have to wait before compatibility reaches 100% and you can upgrade your system without breaking previous mixes or set ups.

Re: Visual Studio for Mac

#289

Post by brazzledazzle »

bardworx wrote: post #230
brazzledazzle wrote: post #182

Earlier quoted context omitted.

I don't care about the touch bar and while I'm miffed about the magsafe I can deal with shelling out extra for accidental damage insurance. Personally my disappointment is with the specs which no time with the machine will change. The mac I'm currently using was purchased 3 years with 16GB of RAM and if I replace it I will be stuck with the same capacity. I imagine there are a lot of "Pro" market segments that are we…

Lately, my main machine has been a mid-2014 mbp with 16GB of RAM and I recently purchased the new mbp with 8GB of RAM. Comparing them side by side is a very strange experience. _Technically_ it should be slower but it doesn't "feel" slower. However, at times, there is a bit of shutter that I can't put my finger on - am I just looking for an excuse to say its slow or was the loading time on opening this project always…

Thanks, that's a helpful review. It has me wondering if it might benefit from the hardware improvements enough that swapping would be noticeably faster.

Re: Visual Studio for Mac

#290

Post by Clubber »

anupshinde wrote: post #272

This is great news! I was a c# developer for many years and absolutely loved it. But then I gave up the Microsoft ecosystem 7 years back just because it felt like a lock-in and also a bit backward compared to non-MS tech. But in the past one year, Microsoft has got me in again: a. Moved to TypeScript from JavaScript (including my hobby projects) b. Moved to VSCode from Sublime c. C# is a great language and I just hat…

C# is a lot different today than it was 7 years ago. You might be in for a shock. The nice thing is you can develop it today as you did 7 years ago, but with heavy use of lambdas and var, it reads almost like another language.
Post reply on HN