Hacker News Reader

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.

Could you expand?

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.

"Its javascript integration is still shockingly bad."

Sooooo very shockingly bad. =(

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.

Easiest example: You can do "instanceof T" with generic T in C#. You can't in Java.

Take a look at: http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java#...

Good examples there of the differences.

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.

fwiw, I agree and actually fought to try and get a lower priced VS out there.

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 hope that helps!

That was very helpful! Thanks Dino!