Disclaimer: I used to work on IronPython.
You guys deserve some recognition. I'm not too frequent a user lately, but I'm continually impressed.
But i have to admit, nothing beats visual studio in awesomeness / completeness
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.
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. :-)
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.
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.
It stinks on our 1Mloc C# project to the point you have to disable it or it crashes VS every 5 minutes.
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.
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?
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.
That's really nice. I wish there would be something comparable for debugging JNI/Java code.
It is mentioned.
1: http://www.youtube.com/watch?v=wvJaKQ94lBY&feature=c4-overvi...
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.
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
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.