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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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
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.
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.
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
Another Microsoft's best kept secrets is using Javascript for shell script. It has been there forever since Javascript first came out. It's called JScript but it's just Javascript with Windows support like running ActiveX Objects, which let you access the file system, OS, network, etc. You can pretty much drive the Windows system with it through ActiveX Automation. Also you can do Office application integration like Excel Automation with it.
Related, but for the same reasons, you could also write classic ASP using JavaScript (as opposed to VBScript). Years ago, I spent months trying to convince my team to let me use JavaScript instead of VBScript in our ASP files.
I know. When I need to do some Windows scripting, I'd do it in JScript rather than VBScript. Like when a user wants to merge two Excel files, nothing beats to whip out a simple JScript to do it. Running it is simple. They just double click on the JScript file and done. Business users love it.
And more: you can create new ActiveX Objects from within that JScript script giving you access to just about anything. This has been there forever (I started using this in 2006) and I use it to let my users insert their code into the process of my desktop application.
For me, Msft and JetBrains provide the best IDEs for getting work done. The majority of my work is in Java, C#, and Python.
At the moment, I use PyCharm for python projects because I'm usually working on OSX (and prefer the local unix-y environment instead of the Windows-virtual-machine thing.) However, I started with PTVS years ago and really like it.
MSFT adding IDE support for Python is a good thing -- as developers, we need more options, not less.
...which would be detrimental to Microsoft. Limiting our options to theirs is precisely their goal by giving us a great IDE that only works on Windows.
They're never gonna go it. They stand to win nothing from that.
Even on a modern, high-powered laptop, Visual Studio still runs slowly for me. Some actions inexplicably cause the UI to hang for a few seconds. I really appreciate how OSX seems to prioritize UI responsiveness, which doesn't seem to be the case in Windows.
Do you have specific examples? This is an area of interest for me. VS architecturally has a lot of things tied to the UI thread due to COM STA requirements (well, that and the fact that historically people created their STA objects on the UI thread, thus tying them to the UI thread).
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.
I don't have a specific example at the moment, except that it's often unresponsive during builds. (I guess this should be expected? Other work I do is in interpreted languages, so there is no "build" step)
Well, I wouldn't say it should be expected during builds. In the past the build architecture was somewhat questionable, i.e. they ran builds synchronously on the UI thread, which works fine if your build takes like 50 ms :) I don't work on the project build team but I believe most languages now build off the UI thread, and any that have long sequences of activities they are doing on the UI thread should still be pumping to prevent UI lockup. That said, running your own pump in an app as complex as VS is...not something to be undertaken lightly, so it is possible their pumps are not correct or their 'in between pump' tasks are taking far longer than they thought/expected. If you can repro it even without repro steps I can give you some instructions on getting a perf trace I could take a look at, they generally point to the culprit pretty clearly.
Which version of VS, and what language? If you're using VS 2010 or earlier, then both C# and VB were running the build (MSBuild and compilers both) on UI thread, so responsiveness was as bad as you'd expect it to be with such architecture. From VS 2012 onwards, VB builds on a background thread, and C# builds out-of-process (which also makes it scale on multi-core systems).
I definitely notice the performance improvements in VS2012. I wonder how many people reporting performance issues are also running ReSharper. JetBrains do great work, but ReSharper (<=v7) is very resource-heavy.
I find that a little odd, as my mid-2008 macbook seems to run VS2012 pretty smoothly even through parallels. I have to wonder what else you might be running simultaneously.
Making Office on the Mac earns them money through direct sales and helps maintain the monopoly of Office and its file formats at the cost of slightly less incentive to choose Windows over Mac.
Making VS on Mac would earn them no money directly and would only encourage the creation of more Mac apps. At best, it might increase the takeup of .NET/Mono on Mac, which might mean more .NET apps, but no money since .NET runtime is free. I'm not seeing the incentive.
I primarily use Sublime, TextMate or Komodo on Mac for python dev but would love to also use VS. I do run windows and do most dev on that under VS. Maybe one day VS will come to Mac, I know that doesn't follow the platform mission but would get some good traction for Visual Studio going forward and a little fire under Xcode for C/C++ dev on Mac.
At this point both XCode and VS are pretty equal but XCode I also like and have no problem with. Both are unique to the OS though. Both are also extremely bloated but needed for C/C++ dev. Eclipse is also a bit cludgy. That python to native screenshot on the site looks intruiging.
I do use MonoDevelop on Mac for Unity dev and it does support debugging but would love to use VS on Mac one day.
All in all when I do python dev I like less in my IDE at times, just a good autocomplete/intellisense and I usually despise integrated source control into IDEs preferring to do it with outside tools such as terminal/cmd, sourcetree or tortoises. SCM integration in IDEs always seems to kill performance and gets out of sync, especially in the latest MonoDevelop (startup indexing kills the usefulness - http://answers.unity3d.com/questions/356129/monodevelop-perf...).
Haven't tried it yet, might give it a try. The debugging looks cool and even Guido seems to think it has some benefits: https://profiles.google.com/115212051037621986145/buzz/CGh9M... - note he mentions painful SCM integration, as usual in IDEs that just doesn't work well. SCM support I usually turn off as it adds iteration lag typically. Prefer the scm tools directly almost always.
I keep SourceTree, by the same company, running while I'm working in PyCharm, and it picks up all the changes nicely. It has been my crutch in becoming competent using Git.
One thing that drives me nuts in Xcode as opposed to VS is that the autocomplete only completes when you hit tab. I want it to compete when I hit a period or a space too like it does in VS! Considering you find them both basically equal, have you found a workaround for this or is it just not frustrating to you?
Unfortunately no, just have to deal. Some use "CTRL + SPACE" or ESC or "CTRL + ," but it still doesn't do it very smart. VS autocomplete is still smarter and quicker it seems. I do like the greying auto complete of XCode as you type as sometimes the drop down gets in the way.
VS 2013 now comes with way more editing options than Xcode. It always drive me nut that I couldn't make IDE automatically insert space around function parameters, because it is not a popular style.
I love Visual Studio but after having worked with python quite a lot and being involved in the local developer community (IN NEOhio, NYC, and starting into Southern Maine) I think I've only ever meet two python developers who used windows as there development Os. I'm not holding my breath but if MS would port VS to OS X/Linux it would be really cool. I don't know that a good business case could be made for it though.
On the other hand perhaps something could be done about Python so that we who are forced to develop Python on Windows stop being second-class citizens in the Python world?
ButI agree. VS is an awesome IDE and the more operating systems it would be available on the better.
You are fighting various other teams in Redmond/power users that have issues with OSS and technology that's cross platform and not from the Mothership. Python/Iron Python would have been a great default language for administrative scripting , but nope, they had to reinvent the wheel with PowerShell.
(I've had MVPs yell at me for discussing data analysis with Python, even on Windows.)
I run a couple of medium sized intranet projects with Django on Windows Server 2008/SQL Server 2008. Not ideal but if you want to use Django, it's sometimes a necessity in corporate MS only environments.
I currently maintain and run a big ol' Django project running on Apache/Windows/MSSQL (and some Oracle) here (university of Arizona). It's not that bad although myself and the other developer both use mac's so its annoying having to RDP in to do anything in a python shell.
How is that relevant? One of the nice features of a language like Python is that it's very easy to write cross-platform code with it. You really have to do effort to code a python web app on Windows that breaks on Linux. The same holds for e.g. Ruby, Node.js and Java.
I prefer Windows for a dev platform (really, I do), but I've only once written a webapp that was hosted on Windows. I'd much rather prefer unixy servers.
Does anyone have experience with the free VS Shell mentioned in the article as the foundation for putting together a free of cost installation?
How does it compare to VS Express? Why would there be two different free Visual Studio offerings...just to keep things locked down and rule out support for add-ins?
I think the idea of the visual studio shell is to have sort of a blank slate of an IDE for people to write their own plugins for. There's no language support, just the blank canvas.
Anyway microsoft doesn't provide support for their core languages (C#/C++/VB) for the shell, so the main consequence is that, in the shell you basically get all the languages microsoft /doesn't/ directly support in visual studio, but nothing else. Whereas in the express editions you have an IDE you can't extend, but each edition supports one of microsoft's core languages.
Our PTVS + integrated/isolated shell basically gives you a virtual "Python Express". However recently msft has moved away from the "Express" model to "Scenario" models. ie, VS for Phone, VS for Desktop, VS for Web, etc. and each includes all the tools and multiple languages you might need for that workload. We're hoping to include PTVS into the desktop & Web scenarios in the future.
That would be cool. I've been enjoying how much I can accomplish using VS Express for Web and Desktop. It is a little annoying having to install both of these, but beggars can't be choosers, right?
Yup, try PyCharm, PyDev, Wing, Komodo, Spyder, ... I did a comparison last year (which I can't unfortunately share :( I can ask) -- bottom line, all pretty darn good, each has its strengths and weaknesses. Take away: it's a great time to be a Python dev on Windows (finally?).
WRT to PTVS itself, the key feature is being VS based; the mixed-mode debug for example takes advantage of support in VS. But at the same time, if you're looking for a cross-platform, very very very lightweight tool, this isn't the IDE you're looking for.
It really varies from area to area, and each has something that others don't. E.g. PyCharm is unique in supporting Cython, PTVS is now the only one with mixed-mode debugging (don't you wish those two were married in one IDE? ~) etc.
In other areas like code editing, the differences are often qualitative. For example all Python IDEs have code completion, but try entering this in your favorite one:
def f(x):
def g(y):
return x + y
return g
a = f(1)(2)
b = f(3.0)(a)
c = f(u'a')(str(b))
d = (a, b, c)[input()]
And then see what completions it gives you for a., b. etc.
It would be interesting if some independent third party would do a detailed point by point study and published it.
Not really, the blog is my side gig. I talk about lots of stuff, but since I'm in the MS dev space I lean in that direction. I work in Azure and ASP.NET as a PM, I'm not in marketing.
Just Vi or Vim for me. Used VS, VB, Eclips years back, but now back to Vi/Vim for embedded and server environment. Have not missed any of IDE features at all.
What languages do you work with? Simple things like being able to jump to the definition of a function with a press of a button (esp. when working with a large unfamiliar code base) are indispensable for me.
grep is nice. its gnarly in template heavy c++, but so are all the tools. intellisense can't reliably provide navigation among all of the possible instantiations in your project.
(esc;qgrep -rn thing .) is faster for me than reaching for the mouse.
>> its gnarly in template heavy c++, but so are all the tools. intellisense can't reliably provide navigation among all of the possible instantiations in your project.
Have you tried it in VS 2010+? You might be surprised. I've seen it correctly handle polymorphic Boost lambdas, and that's a rather impressive feat of TMP. Also, I've just tried the scenario that you've described (if I understand it correctly - "Find all references" on a class template), and it does list all the explicit instantiations in the project.
I have to second this. I hear VS>=2010 uses the compiler infrastructure to generate the intellisense data, rather than doing it (as VS<=2008) by simple text processing, and it's made a huge difference in terms of reliability. As well as improved support for templates, it also does a good job of handling code generated by macros. Newer Visual Studios might prove that the question "OMFG what could POSSIBLY be worse than the VS2008 C++ build system?" isn't actually rhetorical after all, but the code completion is much improved.
(On another note, Xcode. I'm normally pretty negative about Xcode, because it's mostly awful. But I believe its code navigation and code completion is done in a similar way - only using LLVM, of course - and that part does work extremely well. If anything, it's actually slightly better than Visual Studio, because its navigation shortcut is much better about giving you a popup list of all possible reasonable destinations, e.g., if you try to go from a member function call to its definition when that function is virtual.)
>> I hear VS>=2010 uses the compiler infrastructure to generate the intellisense data, rather than doing it (as VS<=2008) by simple text processing, and it's made a huge difference in terms of reliability.
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:
The nastiness here is that the line of code inside main() should be parsed differently depending on pointer size on the target architecture. If it uses foo<4>, then it is a declaration of a local variable named baz, of type foo<4>::bar<123>. If it uses foo<8>, then it's an expression involving two comparison operators: ((foo<>::bar < 123) > baz) - referencing the global float 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.
Thanks for the suggestion. Actually, I already knew about webmatrix but it's missing a lot of features from VS and is IIS oriented. It's been a while since I last checked it, though. I'll have a fresh look.
It's cool until you see the price tag for Visual Studio Profi/Prem/Ultimate (I assume you can't use Python tools with Express versions).
In that case I will stick to my old copy of Visual J++...
You can't use it with VS Express, but you can use it with VS Shell (also free) - and we have a single-file installer that will install both Shell and PTVS for you.
The article mentions that Visual Studio is not required to use this, but all of the downloads I tried from that page tell me to install Visual Studio..
Which is made by the same developers as ReSharper, a popular add-on for Visual Studio.
Using RubyMine now as a Rails dev, after years of Visual Studio use as a ASP.NET dev, and having the familiar ReSharper-like tools and interface in RubyMine is awesome.
RubyMine is an incredibly powerful IDE (like most of the JetBrains IDEs), with lots of Ruby specific goodness.
Disclaimer: I used to work on IronPython.