Microsoft really does make the most outstanding developer tools. I admit that I occasionally miss that deeply integrated, seamless feeling.

You guys deserve some recognition. I'm not too frequent a user lately, but I'm continually impressed.

I'm developping on some platforms.

But i have to admit, nothing beats visual studio in awesomeness / completeness

I came into a shop that does a lot of .NET development over a year ago, and I swear I came into the experience hoping to learn what made lots of people say exactly what you've said.

6 months into it, I all but stopped caring, and overall, I felt like it actually created problems for me. But I'd like to understand what problems others feel it solved for them.

Honestly, coming into visual studio/c# from emacs/common lisp feels like going backwards in time for me.

Running my CL environment on Gentoo feels like the future; a not-quite-there-yet-but-still-awesome future; running VS on Windows feels like kiddie toys that haven't gotten around to growing up yet.

And that's a weird feeling when you realize the dollars, time, and research poured into each environment. :-)

The future! I can't imagine how anyone could say that. I started out with Smalltalk, then started doing C# professionally and eventually started doing CL in emacs. CL/SLIME/Emacs was by far the worst of that trilogy. I can't think of one single thing that the emacs combo did better or even as good.

Both Smalltalk and VS+Resharper have great refactoring tools. Both have great debugging tools (and in Smalltalk I can even do a lot of development right inside the debugger and watch how the code is reacting while I'm writing it). In the CL/Emacs setup debugging is so bad most people recommend not to even bother; just use tracing. And I can't understand why it needs to be like this, CL is closer to Smalltalk than it is C# (that is, CL is a "live" language as Smalltalk is or at least it very much can be. Even a compile-only CL like SBCL).

The other issue is project management. In Smalltalk it doesn't really come into play as much since the image is your "exe", but despite this Smalltalk has great tools for organizing classes, methods and so on (and Dolphin's way of letting your image be a "solution" and you make individual exes from that that drop everything they didn't use was absolutely brilliant). In VS, I create my assemblies, make dependencies and so on and the IDE just handles all this for me.

Contrast that with CL/Emacs: CL has ASDF files that can manage all your dependencies for you (people complain about it, but I've used them for several years and never had any problems) but you have to manage all this stuff manually. If you want a nice way of saying "create new package" or "create a new file that is in this package" you'll need to write all that handling, UI, etc. yourself. And after you write it all, what will you have? The interface will be hideous no matter how you do it because you're restricted to just text. In Visual Studio you can have the disapearable side bars approach, the "old school mac" approach of different info windows floating all over the desktop, etc. With emacs you'd be restricted to doing that stuff via ascii art or popping up more windows with ugly ascii art in them.

The only way I could see CL/Emacs as the future is if we're talking post-apocalyptic.

> restricted to just text.

I think that lies at the heart of our disagreement. I don't find text restrictive, I find visuals and GUIs restrictive.

What specifically do you miss about debugging?

Well, as I stated: in Smalltalk I can trace statement by statement (compound statements work flawlessly), make a change to a method and the debugger does the right thing. With SBCL under SLIME on Emacs I have to fiddle around with optimize statements over and over, recompile mutliple times before debugging does anything at all, at which point it still doesn't work very well. Randomly skipping over sexpressions, etc., etc. The experience is awful and every time I've ask on #lisp I've been called an idiot for trying to debug instead of tracing (not even exaggerating, sadly).

That's funny because I feel the same way if I have to use Emacs. It feels like going back to the early 90s with some DOS Borland IDE.

Regular text editors just feel so clunky next to the cohesiveness of VS/Resharper or Intellij.

At some point in time, Emacs is going to have get overhauled to join the 90s, much less the 21st century.

And I understand that CL is a special case with Emacs, but it's still clunky as hell compared to what could have been really awesome environments (think Smalltalk environments), but with lots of resources pumped into the development.

> Resharper

You've kind of hit the key here, Visual Studio alone is decent, but Resharper is really what makes the experience for me. I don't know a single .net developer who could live without it.

There's one here.

It stinks on our 1Mloc C# project to the point you have to disable it or it crashes VS every 5 minutes.

I have hopes that LightTable will, when finished and released as open source, become the answer for those seeking a modern extensible editor. I love emacs, but there are times when I feel that it's my hair shirt.

Are you a command-line only/mostly person? For instance, if you're going to delete a file - you always do it in a terminal, never a file browser?

Generally a terminal. Depending on the gnarliness of the path, maybe a file browser. I'm a very textual person. I'm sure that has something to do with it.

There's a difference between a platform (.net) and a programming language.

With visual studio, you develop for websites (MVC), apps (XAML based - WP, WPF, Silverlight, ...) and that makes it great.

I recently got back to android because of Android Builder and i'm still struggling with it (1 day or so). The visual studio experience is way smoother.

I have to admit, my little node.js experience with github and heroku felt awesome.. But it lacks a good IDE-experience and that is where Visual Studio really excels.

But command line tools can be integrated as wel in VS ;-), Azure is awesome to if you experimented with it.

With .Net you can integrate almost any language and Python is one of them. I recently talked to someone who does his PHP work solely on Azure because of the platform.

I guess you have to get in the .Net platform fully (Linq / Entity Framework / DDD (Repository / Unity Of Work / ...) to really comprehend what i'm saying.

Perhaps for some, i added a new threat on https://news.ycombinator.com/item?id=5981257 for more information on "Enterprisy" (can't name it better) apps on .Net.

It is such a pity that so many of their awesome products are so windows centered.

What do you use now?

> This doesn't even mention the most awesome feature of PTVS 2.0: mixed-mode debugging, which provides an integrated experience for debugging mixed Python/C processes.

That's really nice. I wish there would be something comparable for debugging JNI/Java code.

This times a thousand. Debugging ndk on Android is one of the worst development experiences I've ever had.

>[...] you're a hardcore PhD who wants mixed-language Python and C++ debugging [1] [...]

It is mentioned.

1: http://www.youtube.com/watch?v=wvJaKQ94lBY&feature=c4-overvi...

The guy that wrote this used to work on my team and is a great dev. If you run into any issues I could certainly point him your way.

Afaik that's exactly what the first all-in-your-face picture is showing? And man that is seriously awesome indeed.

Hah, you're right. A picture may be worth one thousand words, but Control-F "native" won't necessarily find it. Also, I apparently didn't search for "C++". sigh.

or "mixed" ;) - good points, I will update it to showcase that feature. It's amazing.

That was not in-your-face. THAT is in-your-face ~ http://i.imgur.com/IDPsWUu.png

nice.. It's stuff like this that makes me feel like a a wizard in control of the whole world and everything beyond when working in VS. Now if just every single bit of code I wrote would reflect this..

Can you expand a bit on how that works in principle ? Can you make it work with a standard python or did you need to insert probes' into the python interpreter to catch when it goes form C to Python and vice et versa

Some more specifics:

Stack walking works by rewriting the native stack. Basically we just let the native stack walker do its job, then strip out all python##.dll frames except for PyEval_EvalFrameEx. For that one we read the "f" argument and then parse the PyFrameObject to which it points, and replace the frame with our own using data from that frame object.

We parse the data structures ourselves, but use symbols to do so, which is why it'll work on any CPython build with symbols. This is why you can inspect objects even when process is stopped somewhere in native code, and it's impossible to eval using the interpreter.

We still use sys.settrace for breakpoints and Python stepping. Python-to-native stepping works by setting native breakpoints on code paths inside Python interpreter that can potentially invoke some user code (e.g. type_call invokes tp_init, which may point to a user function). When those breakpoints are hit, we eval the function pointer and see if it's outside of python##.dll, and if so, then set another breakpoint there. When it's hit, your step is complete.

So no, there are no special hooks added to the interpreter. We do end up relying quite a bit on internal implementation details, since we need to do things such as set breakpoints inside static functions, and read their arguments. However, because we use symbols for that, this works on any CPython build, including debug ones, and even customized ones so long as you don't rename anything that we rely on. E.g. adding a new field to PyObject is kosher, but renaming ob_type to something else would break us.

Thanks a lot for the detailed explanation.

VS 2012 added a new debugging framework for supporting debugging multiple code types at the same time. That model requires that the debugger work out of process - inspecting various data structures cross process and reporting them back to VS. That's different from how Python debuggers are usually built w/ sys.settrace and a debugger helper thread running in the process.

To accomplish that we require that we have symbols for the Python interpreter (which are typically available on python.org). The debug engine uses a combination of the native equivalent of sys.settrace, strategic breakpoints, and using the symbols to walk core Python data structures. There's a bunch of fun tricks for evaluating code when stopped at a Python frame and creating strings, ints, etc... when users type them into the watch window.

If you'd like to dig in more the source is at http://pytools.codeplex.com/SourceControl/latest under Python\Product\Debugger\DkmDebugger.

My understanding is that dual debugging works when your main process is oythin and you can the debug some C python module. Is ther a way to debug a C process loading python27.dll which then runs some pythin code using the oython-C api?

Mixed-mode debugging works in both of these scenarios (remember that python.exe is really just a "C process loading python27.dll"). You don't need a Python project at all, you can just attach to a running process (whether it is python.exe or your own host) and start debugging. You can even do that if the host process hasn't actually loaded python##.dll yet, though of course Python breakpoints etc will only light up once that happens.

Here's a screenshot of a debug session with a custom host process written in C# running Python code that in turn uses a C++ extension module: http://i.imgur.com/IDPsWUu.png