Slashdot Mirror
Microsoft is Bringing Visual Studio To Mac (techcrunch.com)
Microsoft will finally bring Visual Studio, a "true mobile-first, cloud-first development tool for .NET and C#," to Mac later this month, the company has said. From a report on TechCrunch:The IDE is very similar to the one found on Windows. In fact, that is presumably the point. By making it easy for OS X users to switch back and forth between platforms, Microsoft is able to ensure coders can quickly become desktop agnostic or, barring that, give Windows a try again. From the release: "At its heart, Visual Studio for Mac is a macOS counterpart of the Windows version of Visual Studio. If you enjoy the Visual Studio development experience, but need or want to use macOS, you should feel right at home. Its UX is inspired by Visual Studio, yet designed to look and feel like a native citizen of macOS. And like Visual Studio for Windows, it's complemented by Visual Studio Code for times when you don't need a full IDE, but want a lightweight yet rich standalone source editor.
I cannot stand Visual Studio's project/solution hierarchy. Xcode allows for an additional tier; target/project/workspace. 8 files build in parallel, not projects. Build times in Xcode are so much faster for the same C++ library.
Been doing .NET forever and with .NET Core running on macOS now, this is welcome news. Visual Studio Code is nice, but it isn't the solution full Visual Studio is. With full blown Visual Studio, .NET Core, Docker, I won't even need to run VMs anymore on my macbook to get work done.
I'd be happy if software companies who made the mistake of using platform-specific APIs and languages could cross-compile. Are you listening, Intuit?
I've been debating the past few weeks on whether or not to buy a new Windows laptop just so I could run Visual Studio....this solves that problem, thanks Microsoft!
Probable disclaimer from Microsoft:
Users of Microsoft Visual Studio for Mac OSX may find certain features of Visual Studio do not function as expected under the Mac OSX platform. For those users, we recommend using Visual Studio on a Microsoft Windows-based platform, to improve reliability.
Translation:
You didn't really expect us to write quality software for a competing OS that didn't eventually drive you over to Windows, did you? Silly user...
I've been using Qt for this purpose for years.
Remember, You are unique...just like everyone else.
I usual Visual Studio from version 6 to 2010 for MFC development and found it got worse and worse with each new version. The interface turned into a train wreck and reduced your productivity and made it unpleasant to work with. The install size became absurd with it installing a lot of crap you didn't want (even if you unchecked all components the install size was still 8GB). Despite the insane bloat it lacked basic functionality (why wasn't something like Visual Leak Detector included as standard?). Furthermore, Microsofted treated C++ as a second class citizen while they focused on crap like .NET and HTML+Javascript.
In the end I got sick of it all and now use Qt in Qt Creator. Microsoft's development strategy appears to be "continue development until the product is unusable". They've done this with Windows, Office and Visual Studio. I'm therefore left wondering why any Mac user would want Visual Studio? Surely people have switched to a Mac because they're sick of Microsoft's ever-worsening software.
The original announcement that was the source of the article in the OP has since been pulled; I've seen mention that it was just posted too early. Presumably it will be back at the regularly scheduled time or perhaps earlier when they realise that the genie is out of the bottle.
If it can do 64 bit IDE then why not PCs?
I haven't used Visual studio for any real work since 2008, but as I recall their debugger was fantastic for debugging C++. The other aspects of it were kinda "meh", but the debugger was freaking amazing. (And I'm a Mac/Linux guy who uses either Xcode or Makefiles most of the time.)
Avoid Missing Ball for High Score
a true mobile-first, cloud-first development tool
There can be only one!
Fast Federal Court and I.T.C. updates
to bad there no real workstations on the mac.
the mac pro is 3 years old and was cut down from dual cpu to 1 cpu. If you want real power HP, DELL, Supermicro, and others have it for you.
My all-time favorite IDE was CodeWarrior on classic Mac (the Windows version was the best on that platform at the time.) I tried Visual Studio 6 and wasn't impressed.
Then I had to use VS every day and got used to it. Most of its problems were/are horrific UI design (hidden/obfuscated settings!) and twitchiness (hangs; recreating projects from scratch when they refuse to build.) Overall usability is now quite good, and automation (intellisense, etc) is first rate.
I haven't tried XCode recently, last time it was still a mix of all the things I didn't like about the early VS's. It's free and I could get used to it if I had to work on Mac's: Apple got all the money they will ever get from me between 1986 and 2008 or so. (I still have one MacBook left, mostly running Windows, from the days when I still thought OS X would eventually suck less.)
I'd be delighted to have a modern VS on Macs for odd projects that need a text editor and project manager. I've experimented with Code for fiction writing, not bad (lots of customization.)
That was also my first question.
Of course, I'm not sure that I would care, even if they announced it was available today. There would be some catch. Maybe the EULA allows Microsoft to sneak in while you are sleeping and harvest your organs. (Assuming your internet service provider hasn't already taken them first.)
I'll see your senator, and I'll raise you two judges.
Visual Studio 15, next version not VS2015 which is actually version 14 go Microsoft numbering, is supposed to fix this.
It's broken out so you only install what you need to you'll have to much smaller footprint and patching will be faster. If you do a full install of everything it will probably still be slow. But you'll be able to choose a setup like I want to do just Windows apps in C# and it only installs the bare minimum to make that work.
No point in getting all excited about it.
We suffer more in our imagination than in reality. - Seneca
According to Ars Technica it is different product
http://arstechnica.com/informa...
I'm already using Qt and am happy to stay away from the painful VS.
- under Windows, Qt uses gcc/MinGW (or VS compiler if you wish)
- under Mac OS X, Qt uses XCode compiler
- under Linux, Qt uses native and easily installed gcc
At the time of the version 3, I also had the opportunity to work with the embedded version (user interface in trains, running on PPC computers).
So there is Qt, and there are many other solutions described in the other comments. M$, what are you doing here, then ?
By the way, since Skype is made using Qt : M$, please, explain why there are so many differences between versions, especially with the Linux one ? Need some lessons in portability ?
Totof
VC 2015 dropped the all caps menus, went back to a sane UI. *Much* better than 2013
MS said they're not going to, I posted the announcement here some months back. Devs are still whining about it in the initial request on one of their feedback sites.
You've been able to turn those off for a long time now, and I believe Visual Studio 2015 defaults to title case styling.
It will no doubt come with telemetry fully enabled by default, perhaps with direct parallel feeds to FBI, NSA, and the CIA.
I would gladly switch to Visual Studio on Mac since Xcode feels like a straight jacket. I want file-based tabs, not workspace-tabs and Visual Studio gives me proper tabs. If I could develop macOS & iOS apps using Visual Studio, then I'll never need Xcode again :-)
The hourglass is meaningless when Windows has marked the program as non-responsive. If a program is stuck in an infinite loop it will show an hourglass too, how is a user going to know the difference? When I see a program labeled as "Not Responding" I give it a few seconds to sort itself out and then I force kill it. This has been a solved problem for decades now, it's terrible user interface design, and it points to piss poor coding internally.
:= True; := dupIgnore; := 0 to OrigStringList.Count - 1 do
Do better then talk? Here is the code to deduplicate a TStringList while updating a progress bar and preventing your app from being labeled as non-responsive:
OrigStringList.LoadFromFile('names.txt');
DedupStringList.Sorted
DedupStringList.Duplicates
for i
begin
DedupStringList.Add(OrigStringList[i]);
if i mod 1000 = 0 then
begin
ProgressBar1.StepIt;
Application.ProcessMessages;
end;
end;
Brain dead simple, tested on a Pentium Dual Core T4500 laptop with 2GB of memory, sample data set was 250 unique first and last names randomly distributed over 6,000,000 entries creating an 84 MB text file. In a simple console application, the file was loaded to OrigStringList and deduplicated by transferring the to another TStringList with TStringList.Duplicates set to dupIgnore using TStringList.AddStrings(). This took 43 seconds and resulted in DedupStringList containing the original 250 unique strings. For the next test the same dataset was used in a graphical application using the code above to deduplicate the list. It took 46 seconds to process, updated the progress bar, and the application remained responsive allowing the window to be moved, minimized and maximized, as was not labelled "Not Responding" by the Task Manager. That can be further spread up by increasing the number of iterations between calls to Application.ProcessMessages and how often the progress bar is updated, that can be adjusted to the number of entries be processed, the type of progress bar being updated, etc etc. Using this method you'll want to either disable the form, or better yet, disable the individual controls that you don't want users clicking during the processing. You'll definitely want to disable the De-Deplicate button to prevent inpatient users from clicking it multiple times and stuffing the message queue.
That's the Amateur Hour was of doing this, all simple intrinsic methods and minimal work on your part and still performant enough. Especially as you advertise your program as being "multi-threaded" it is just embarrassing that your UI locks during processing. That leads me to the better method, doing your processing in a background thread and updating your UI with TThread.Synchronize, but the above method is good enough for a simple list processing app. Your app ran on my desktop, an Intel i7 4790 with 16GB memory and was still not responding after MINUTES of processing. This is absolutely ridiculously under-performant when we're talking about megabytes of data, even with fancy Delphi string processing. You constantly harp on the speed of in-browser ad blocking, so ask yourself this: if these extensions (which I believe are written in JavaScript!) can run through their blacklists on every page load in seconds, if they can install and update their lists in seconds, how come your app can't process a few million entries is less than five minutes using native code? The answer is very basic knowledge of data structures and algorithms on behalf of the developers.
Go ahead, install this stuff on your mac, what could happen?
Next thing you know, a big skull and crossbones shows up on your screen telling you to call - rasomware fix.
Since you're on a mac, you have just 1 day to pay up with bitcoin.
What if someone want's to minimize your program while it is processing? What if someone want's to move it to a different monitor while they do some other work? What if they want to close it? They can't, because you're not processing any redraw events or anything while you're working on your list! In this case it doesn't matter if Application.ProcessMessages drops events or not, it's a hack to keep your UI somewhat responsive to the window manager.
As far as the VCL not being threadsafe, that is correct, however I don't think you understand what that means. All UI updates should be handled from the main thread, which is why you do the processing in a background thread and use TThread.Synchronize to update the UI.
RTFM:
http://docwiki.embarcadero.com/Libraries/Seattle/en/System.Classes.TThread.Synchronize
Using a few cpu cycles to update your UI and process messages from the window manager isn't bad practice, it's good design. Accuracy over speed is just a silly argument, computers don't make mistakes, programmers do. The fact that you are throwing a tantrum over this tells me writing a "Host Files Engine" is most likely the biggest project you have ever worked on. I don't care if a few people on Slashdot use your program or that MalwareBytes says it is safe, I'm glad your decade of spamming, stalking, and trolling has paid off.
If anyone is interested in using a large host file to block ads I recommend checking out StevenBlack's unified host file on GitHub. It's written in what APK calls a "slow interperted language", but somehow it's still faster than his shitty Delphi app!
https://github.com/StevenBlack/hosts
Affordable Apple hardware with quality Microsoft software?
Website Just Down For Me? Find out