The article makes a point of MS being focused too much on itself, and I wholeheartedly agree. One of the things I was praised for was knowing what the rest of the tech world was doing (I worked on VS).
I have to admit that I find this odd for a few reasons:
1) VS is one of the best products MS ships. And its probably best in industry.
2) VS has done a fair bit of really good work in the past few years. The work in C# has definitely been ahead of its peers in the industry. The debugger continuously seems to get better. And even where it plays catch up, like ASP.NET MVC, its doing so rapid and smartly.
3) VS is where it seems like there are a lot of people who look outside the company. I've never met Scott Hanselman, but he seems like the type of person who could rattle off every open source project in existence.
4) Scott Guthrie seems pretty visionary and he's in VS isn't he?
I'm not doubting any of what you said, but it seems like VS is the one place in MS that I'd tell the rest of the company to look for inspiration -- although as an insider it appears otherwise.
1) I agree. It's probably one of the best IDE's out there and C# is undoubtedly a fantastic language.
2) In what ways is C# ahead of its peers in the industry? I think Async is a great step forward, but it's been in other languages for a while now.
3) He could and he has no impact on VS whatsoever. Scott is essentially a community PM. He talks for a living about stuff. He's a great guy and he's done some good on the web side, but he has no influence on the core of VS.
4) He's actually on the platform, not VS, though he does take a lot of interest in the core component itself. I like ScottGu a lot, I've worked with him a couple of times, but he's driving something very specific (.NET framework and its components).
MS is quite good at building platforms and not nearly as good at building interfaces. A big part of what I did before I left was prove that most people don't understand how to use VS. Moreover, there's a lot you don't see - all of the failed attempts to do things even more amazing than async. While VS itself seems like a model citizen, I would argue that's because it started out as the conglomeration of fairly strong original products and hasn't needed to move too far from where it started to be "best in industry."
I think in general we agree -- you just have an insider perspective so you can see some of the strings that I can't.
The only big contention is "In what ways is C# ahead of its peers in the industry?" This comes down to a language war where there is no winner, but the way C# has put together great feature sets around key scenarios. Generics done right, much improved co/contravariance, nice lambdas, dynamic support which is actually pretty useful, extension methods, and of course async. While async exists in some languages, it doesn't exist in what I'd consider peers (other popular languages) from Common Lisp, Python, Ruby, Java, C/C++, and Javascript. And frankly, I think this probably isn't all that important -- and more religious than anything else.
But I am curious about one thing you said, A big part of what I did before I left was prove that most people don't understand how to use VS. Moreover, there's a lot you don't see - all of the failed attempts to do things even more amazing than async.
There's a big difference between the c# language team and visual studio. The c# language has left java for dust, they are doing a bloody brilliant job but on the other hand were essentially playing catch up with python and ruby until 4.0. The dynamic CLR stuff has really changed the game.
VS, on the otherhand, has stagnated, between 2005 and 2010, apart from integration with the new hotnesses like Silverlight, MVC and LINQ, I can't really point out any improvements. While I must admit I love MVC over ASP.Net (keer-spit), even now you feel the meddlers interfering and making it do unnecessary magic.
Its javascript integration is still shockingly bad. It doesn't even highlight brackets or braces and the auto-indenting is erratic. Javascript is so key to web programming these days and yet for the first time I find myself juggling VS with Notepad++ because that free open-source program is actually a lot better.
C# programmers are always bragging about how generics are so much better than Java's. But when I've looked at the common day usage cases they're really about the same. I know about the type erasure issue but unless you're doing some crazy reflection stuff it never comes up. I'm not trying to start a religious war here but what is it that in practice makes C# generics so much better than Java's?
The lack of erasure means that you can use generics to do sophisticated type magic, sort of like in C++ templates - specifically using reflection. You don't usually want to do this too much, but doing it in one or two places can simplify code tremendously. This also allows you to eliminate boxing and reflection overhead in a lot of places by letting you use generics to bind to reflected types/members at runtime, which is really important if you're trying to build a performant app in C# that's got extensibility support.
For example, I use this to create strongly-typed bindings to individual fields/properties of class instances at runtime, which lets me pass around objects of types like 'BoundMember<int>', and generically store into them - essentially the same as 'ref int', except it can outlive function scope. This is really useful when doing asynchronous programming, and it lets you kill duplication when building things like configuration dialogs.
Hmm, sounds like what I said with "unless you're doing some crazy reflection stuff ", and it sounds like a solution that reduces the readability and maintainability. But maybe I'd need to see a good example to appreciate it.
In what ways is C# ahead of its peers in the industry?
I'm assuming that the most obvious peer in the industry is Java. As I've recently worked in both, it comes down to Linq and the fact that Visual Studio + ReSharper is just a better IDE than anything I've used in the Java realm.
While VS is good I think they made a huge mistake pricing Team System to up to $10000 per developer. The Express versions are nice but they don't contain a profiler for example.
I don't think it's smart trying to make money from developers. Apple made the same mistake with the Newton when they priced the dev kit at $800 (not sure if that's accurate but it was expensive) while the Palm dev tools were free.
I think the original Team System pricing which was probably there to compete against IBM Rational in the enterprise ignoring they had a much broader customer base.
They eventually folded it into most of the MSDN freebie programs for partners and startups...
Recently I started digging how one could write a debugger for VS, and integration for a language (dynamic one). I stared by looking at pytools, and I was confused by all COM objects, classes, etc. I was not sure at what I point I'll get it to work - do I press F5, and it's installed? Do I make a DLL and it has to be registered?
Now that other plugins are easier - I'm looking now at MonoDevelop and SharpDevelop (Windows Only) but I wish something simpler - like emacs - straight to the core of the system - functions exposed, communication channels right there for you, etc.
Anyway I won't give up, it's just taking too much of my free time.
It sounds like there’s two parts of the debugging APIs that you’re confused about – how to get your debugger to run and how to implement the debugger where you have all the AD7 classes and interfaces – it’s certainly not a very discoverable API.
On the first part – how your debugger gets used – you ultimately need to have a DLL with your debugger in it which provides the correct registration. Like all things in the managed package framework this is provided by a ProvideAttribute – in this case a ProvideDebugEngineAttribute. So you’ll need a VS package which uses this attribute. There’s some other attributes which might be useful related to debugging and you’ll see those in PythonToolsPackage but I think you can ignore them for now. Once you have a package loaded which provides the debugger to VS you can use VsShellUtilities.LaunchDebugger to launch your debugger and start debugging. In PTVS we do this in DefaultPythonLauncher.cs. The standard VS debug engine sample (http://archive.msdn.microsoft.com/debugenginesample) also ships with an add-in which adds a menu item which does this for the current startup project. Note PTVS is built on this sample but PTVS might be easier to use as its all C# vs the mix of C# and managed C++ in the sample.
The second part you mention is all the AD7 classes. I would actually suggest that you try and ignore these for the most part – at least as you get started. Instead you should look at the PythonProcess class which exposes a simple C# API and a number of events which all of the AD7 classes are simply wrapping. If you completely replace this class with your own you’ll pretty much have a working debug engine. There may be a few things you’ll need to update (for example launch options over in AD7Engine.LaunchSuspended, or parsing expressions to see if they’re valid) but there shouldn’t be much need to look at those classes. And by the time you do need to look at them hopefully you can do it within the context of calls to and from the PythonProcess API and it’ll make more sense.
I like VS, but I'd say VS has a lot of great stuff in it, but "VS as a whole", if you could somehow abstract away what it contains, is actually pretty shoddy. i.e. VS is less than the sum of its parts, although the sum of its parts is great enough that VS is, despite that, still pretty good.
I have to admit that I find this odd for a few reasons:
1) VS is one of the best products MS ships. And its probably best in industry.
2) VS has done a fair bit of really good work in the past few years. The work in C# has definitely been ahead of its peers in the industry. The debugger continuously seems to get better. And even where it plays catch up, like ASP.NET MVC, its doing so rapid and smartly.
3) VS is where it seems like there are a lot of people who look outside the company. I've never met Scott Hanselman, but he seems like the type of person who could rattle off every open source project in existence.
4) Scott Guthrie seems pretty visionary and he's in VS isn't he?
I'm not doubting any of what you said, but it seems like VS is the one place in MS that I'd tell the rest of the company to look for inspiration -- although as an insider it appears otherwise.