Python Tools for Visual Studio

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.

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.

Another possible cause can be extensions. Not that VS doesn't have its own problems of 'doing too much work on the UI thread', but there are TONS of callback points that third parties can hook into, and lots of times people do very ill-advised things on the UI thread, leading to poor responsiveness.

We monitor it actively (via PerfWatson[0], you should install it if you want your perf problems brought to the attention of Microsoft, it should have low overhead at runtime, only kicking in when the UI thread is already unresponsive), but of course with a product as large and complex as VS, and with said product being extensible, inevitably customers run into stuff we never see internally, so we rely on getting repros/data from them to understand what is going wrong.

[0] http://visualstudiogallery.msdn.microsoft.com/fa85b17d-3df2-...

To be specific, what they did was take the EDG C++ front-end, and use it to drive all code intelligence features (code completion etc) - see http://blogs.msdn.com/b/vcblog/archive/2009/05/27/rebuilding.... That's why it can correctly handle all templates, macros etc.

Here's a nasty trick that I love to play on unsuspecting C++ IDEs:

  template<int = sizeof(void*)> struct foo;
  
  template<> struct foo<4> {
    template<int> struct bar {};
  };
  
  template<> struct foo<8> {
    enum { bar = 0 };
  };
  
  float baz;
  
  int main() {
    foo<>::bar < 123 > baz;
  }

Now, if you try the above in VS (2010+), you'll see that it will parse this correctly and give you the proper type info for baz (and "Find References" etc), which will change if you switch project configuration from "Win32" to "x64" and back.

VS2008 C++ build system with CMake.