Really? I feel MS has really dropped the ball with VS. VS2013 was OK, but not great. A lot of random lock-ups in really annoying situations where you can't even fathom why (like opening a text file). VS 2015 is actually awful - it wasn't until Update 1 that typing this (below) in C# would pop-up an on screen exception dialog:
class Foo : Bar
{
public Foo()
:
I often find myself staring at the screen, saying in my head 'What the hell are you doing now!'. The new DNX project system is unusably slow (compiling) and the tooling for it is non-existent. And for me it still crashes all of the time. Other devs on my team are having similar problems.
TFS and TFS explorer is a total joke. The 'offline mode' is slower than online mode, and also causes crashes. If I lose my VPN connection then I have to shutdown VS and restart before TFS will reconnect again (this has been an issue for every version of VS I've used). Luckily we're moving away from that travesty of a system to git very soon (the VS git integration is actually pretty good).
I used to feel that VS was a really solid piece of tooling, and I agreed with your sentiment that I quoted. I don't any more. I will check this out, and if it works then I'll happily drop VS, two years ago I couldn't ever imagine myself saying that.
Competition can only be a good thing here.
I've been rather pleasantly surprised at how much support MS are giving git and github - they offer git hosting on Visual Studio Online and the Azure documentation is in github.
Edit: Added pleasantly! :-)
This has been the case for C++ for a while now. Every version of VS has gotten worse since, IDK, 2006 or something (and that's ignoring how long it takes them to finish new versions of the language). I had a suspicion that they had moved their A team over to work on C#, but hearing this... maybe they're just getting worse.
Sarcasm notwithstanding, that was a terrible decision that still annoys me almost daily when I want to automate a repetitive task in the text-editor.
With 1 notable exception of 1 huge project.
On large, 40+ project, solutions it seems like Visual Studio just falls on its face. Our new team is redirecting toward microservice approaches in light of some of these frustrations.
Not that your arch should be dictated by your editor, but quality of life is what it is.
I suspect some of the problems are, for sure - our big internal project is a multi-million line app, maybe 70-80 csprojs. VS2013 dealt with it OK, but had its occasional problems (the TFS issues weren't occasional though), VS2015 is much worse in general. It's very unstable.
My open-source project LanguageExt [1] uses git and isn't that large. I still get crashes and lock-ups. It was the first project I migrated to DNX also. It takes an age to build (where the sln/csproj system doesn't), and nails the CPU (99% usage). Something is very wrong, and very unfinished.
I can see where MS is going with this new open-source tools approach, but at the moment the whole thing seems to be a mess, and VS just can't deal with it. The one ray of light is the git integration. That works for the most common scenarios. I only occasionally have to drop back to the cmd line.
It seems like every time there's a new project format the first version is just really awful. I think they really only test it on small almost toy-level projects thoroughly but fully conjecture.
That's a very cool project though - what got you going on that? If I could convince my coworkers to not kill me for doing so, I would try to introduce using that at work :-) I've definitely gotten them on to the immutability by default train of thought tho - a lot of people very happy with that mindset considering how much of work has become parallel processing. It's amazing how much faster you can do things like build invoices of thousands of items when you can process the whole thing in parallel :-D
My pref has always been command line tbh - getting away from TFS was the best thing that ever happened for me.
Thank you :)
> what got you going on that?
Heh, long story...
I'm a CTO of a healthcare software house in London, we've been developing a very large web-app in C# over the past 10 years. Over the years it has evolved as any project does, but I started noticing more and more that OO was really not the right tool for the job of managing large inter-dependant systems (well, the Java/C# brand of OO anyway). The promise of re-use, decoupling, composition, ... all seemed to be lies. On top of that I started to get a sense of the common bugs that were coming through: null-reference errors being by far the biggest. The in-your-face bugs like null-ref errors are relatively easy to spot though, what becomes more problematic over time is shared mutable state logic errors. They can remain buried for some time.
I'd already had an interest in functional programming piqued by LINQ and Erik Meijer's talks on Haskell. I spent some time learning Haskell and F#, and came to the understanding that the stability and reliability of a system could be massively improved if null didn't exist, if objects were immutable by default, and if functions were pure/referentially transparent. Expression oriented programming became my order-of-the-day, but C# kept getting in the way. Unfortunately I couldn't just drop it and move to F# because our code-base is huge and written in C#.
So that's when I started writing csharp-monad [1], it was my first attempt at bringing functional concepts into C#. It had a couple of problems though, and they were:
* The types were classes, and therefore if a function returned Option<T> then it could still be null
* It followed the '.NET BCL way' of having functions like GetValueOrDefault() - again breaking the safety net that an Option type (for example) is supposed to give.
It had benefits though, primarily that I could make composable computations with the various monads (using LINQ). The problem with that approach was that it quickly bumped up against the rest of the BCL. And, in my case, the rest of our multi-million line C# OO app.
So I mothballed that project to an extent. I'd use it now and again where I had control over a process end-to-end. But it got me thinking, that the main issues I had were:
1. Non-expression based C# constructs (if/else, switch, etc.)
2. OO-heavy core types, like List<T>, Dictionary<K,V>, etc.
3. Whenever I brought in 3rd party libraries that 'did functional', they wouldn't work with my Option type in csharp-monad, or any of my functional types - and they never could because there's no baseline for functional (other than LINQ) in C#.
4. The lack of more expressive LINQ grammar makes it less useful and sometimes more cumbersome than Haskell's 'do' notation or F#'s computation expressions.
1-3 cries out for an equivalent of a BCL for functional constructs. I was under no illusion how big a job that would be, but I could see real value in it: a unified set of types for Option, Either, Try as well as collections Lst, Map, etc.
"A functional prelude for C#"
Item 4 was more problematic. I couldn't create more LINQ grammar. So I started thinking about it in a different way. Mostly I wanted to create expression oriented code. It was just safer. But with C# OO you always hit that expression boundary. So I thought about how I could control the boundary. Some of that was to build 'matching' constructs into the core types, but that wouldn't deal with all boundary issues. That's where the actor system comes in (LanguageExt.Process [3] ). I'd looked at Akka.net and its very Java-like API horrified me - it looked like C# 1.0. So I took the idea that a LanguageExt Process (an actor) is a fold over a stream. That suddenly created a very powerful idea that I could create packets of pure computation and wrap them with their state, and each message would evolve that state. In one fell swoop it created a better and more controlled OO that can interact with pure functions - and all fully integrated with the functional BCL I'd developed. It also allowed us to start breaking up our monolithic app in a much more controlled way.
So yeah, that's the back story! Sorry if it turned into War & Peace.
Btw, I am in the market for two developers at the moment. So if none of what you just read horrified you, please drop me an email with your CV to plouth AT gmail :)
[1] https://github.com/louthy/csharp-monad
[2] https://github.com/louthy/language-ext
[3] https://github.com/louthy/language-ext/blob/master/LanguageE...
I had tons of problems with it when I was running it in a VM on a MacBook Pro though...
Having worked with VS for many years, things not so glorious in my opinion. The main criticism is an increasing lack of stability and error prone refactoring. I've basically given up on automatic renaming with VS2015. The IDE crashes more often as it should, especially during debugging.
Furthermore the solution/project-file concept (instead of using just folders to organize projects) is ancient and a real PITA when working in a team repository. I understand that this will hopefully be better in the future with .NET Core.
Another thing are licensing issues, which is really a uprising problem at MS (this is also the case for other MS products). You're not allowed to open your IDE when the license - falsely - expired.
I really enjoy working in VS code nowadays, which seems to be the more future oriented product.
Don't get me wrong, VS is still a solid IDE, but not as stellar as often claimed in my opinion. As others already said, competition is a good thing.
You might as well be right: on OS X, Linux or *BSD however, it will be a completely different story due to the absence of Visual Studio.
At work I am using a Mac Pro 2008 with a WDC WD20EFRX-68AX9N0 in it (no idea of rotational rate, thanks Western Digital!!) and VMware is slow. Perhaps it is the antivirus I am forced to run inside Windows in a VM but it isn't snappy.
Developers not using SSDs is like a race car driver using an Impala off the car lot for a race.
BUT! we should not be quick to ignore hardware like this and suggest to upgrade as a solution. Since there is a lot of hardware in use with that spec, it is best to cater for it. You wouldn't recommend someone went and used a fibre Internet connection when your mobile web page takes too long to download, would you? You'd fix your massive mobile web page.
I do get the feeling that OSX developers are all using SSD at Apple, because they obviously don't realise how unbearably slow the experience is with the 5200 RPM drive they sold me...
You use a slow machine for testing, not building.
This is like saying my fucking carpenter shouldn't use power saws.
Maybe you should have gotten a better machine then. If by a few years ago you mean 2010, then sure. We're 1/2 a decade past that now.
I disagree as a developer who does (personal) development on a 2010 laptop (1st gen Westmere, upgraded to SSD). My laptop is perfectly adequate for my development work (Android, Python). Besides, no ones should have to run Windows via hypervisor in a multi-platform world such as the one Microsoft is promising for C#, this is what makes beefy machines 'necessary'.
So it's not 'necessary', it's a choice you're making.
The bottleneck is indeed the hard disk but everything else about the machine is perfectly acceptable. Unless I need more cores in my CPU and all software has suddenly been rewritten to do everything in parallel and nobody does queue based operations now?
(FWIW, I prefer VS to Xcode, despite preferring Mac to Windows. IntelliSense and editor tabs seem nicer to use than Xcode's UI, and Xcode with a Swift project only a little bigger than a toy demo hits periodic freezes. On my home iMac which does have an SSD.)
As a consultant and contractor this is the first thing I point out. However, it's their money, not mine.
And I say that as a longtime VS fan and advocate!
(Of course, I guess JetBrains products would suffer exactly the same problem now with the new SaaS model - I just needed a rant about this particular issue.)
It's a bit of a silly name in my opinion.
I don't think that MS have any plans to add debugging, or build tools into VS code.
For production there's a new command line tool to compile it.
I am using another JetBrains product, PHPStorm, on the Mac at the moment for some Front End Dev, which is another IntelliJ based product. This has recently become quite sluggish and is starting to annoy me, after all, who wants the tool to get in the way of the work. I hope this gets sorted soon.
That said, I think JetBrains do a great job focusing on develop tools and I've used their dotPeek product to untangle the mess left by the absence of release control in a recent contract.