Awesome. Now I can do my robotics programming in the best IDE in existence. Sorry, Eclipse, I love you and we're great together, but you're no Visual Studio.
This is quite an awesome tool that MSFT has released. But the top N comments are about the merits of IDE's vs vi then devolves into a pissing match about coding discipline.
I'm sure this was meant as a joke, but, the downmods still make me sad. I used VS for some classes in school and at my first job and it made me a worse programmer. It took years to undo the damage. In my opinion, as a developer, and in my experience in working with a lot of other developers, terminal + vim + build tools (gcc/javac/python, etc) is far superior compared to VS.
I'd be curious as to what 'damage' you needed to have undone. I've written in just about every IDE available (including vim) and quite frankly my opinion is that, well, tools can make things easier but they won't make anyone a good programmer.
The debugger is a big one. I had a terrible habit of not thinking through the code but just running through the debugger until I got it working.
Not thinking about how code looks (especially to other people) since I could just resize the window to whatever.
A lot of the build complexities were hidden, which was fine as long as everything worked, but, as soon as something small broke, I spent days reading documentation and uselessly searching MSDN and the web trying to get the project to build (so, not understanding my build environment is something else I had to fix).
There are lots more (source control, collaboration, etc). I know that switching my tools and my development environment made me a better programmer.
I do most of my development in Eclipse or VS, because frankly my time is worth more than screwing around with Vim for more than basic text editing. Funnily enough, I only break out the debugger when something's really nasty--maybe once a week, for half an hour or so. I certainly don't practice debugger-driven development, and I don't know anyone who does. Personal problem, not a tooling problem.
"Not thinking about how the code looks"--personal and cultural problem, not that of the tools; whether I'm in Vim or Coda or VS2010, I run a guideline at 100 characters (because 80 character lines is dumb in the age of the smallest dev monitor being 1280 pixels wide) and wrap to it. Never heard a complaint from anyone I work with.
Build complexity--here, you have something of a point, but MSBuild or Maven or whatever isn't appreciably different than tooling with makefiles (except that MSBuild probably has better documentation and there's some semblance of a standard way to do things).
Source control? I use Hg and Git, seamlessly, from within VS2010 or Eclipse. Not a problem at all. Collaboration? I've used VSTS for it before, but I just hang a Chrome window in my second monitor and keep Redmine (at home--Bugzilla, at work) and an IRC channel open. None of this is appreciably easier in the Land of the Holy Terminal--it's just different.
I've used both heavily IDE-driven stuff and the stone knives and bearskins that vi-land suggests, and my practices do not fundamental change from one to the other--because I understand what I am doing and how and why to do it. Changing your environment doesn't help you become a better programmer unless you understand why you did what you did and have developed the discipline to not do it regardless of tooling. Your problem existed between keyboard and chair, and it doesn't sound like you've fixed it--just hid it away.
My understanding of the comment is that the commenter makes the point that VS is almost too comfortable (sorry if I'm mis-reading this), and that comfort is actually a hindrance to learning things.
I see it where I teach, the students that come in are most comfortable with windows + VS and they are productive in this environment. However, after just one course in C programming using vim, the students have a much greater appreciation of the process of producing software. They gain an understanding of compiling and linking, Makefiles and automated builds. (I'm not sure all of them like vim + make, but they see where VS is automating stuff for them and I think this is a valuable thing to learn).
Do you need this understanding to be a productive programmer? Of course not and indeed learning it is a bit of a timesink compared to getting your features finished.
Eventually like most things it is horses for courses (it doesn't make sense to me to develop C# code using vim as you have the worlds best(tm) IDE to help you), but personally I feel that IDEs have become too much of a crutch, they help so much that you can be productive without knowing what you are doing and, this maybe elitist, I feel this harms the industry a little.
Good programmers will always be good programmers, bad programmers can hide with an IDE, they have to learn what they are doing when dropped into vim + make (or other lo-fi tools of choice).
I have coworkers who use Eclipse (for Java). It's a CPU hog; often it locks up entirely, crashes are infrequent but, happen. I've tried it; I know I'm much faster with vim. For me, my time is worth more than putting up with Eclipse.
I use 80 characters per line because if I am at a larger monitor, I can have 2 or 3 split windows side by side. If I'm at a smaller terminal, everything's still readable. I find narrower code is more readable anyway. Most developers I admire write like that. In any case, this is a major flame war topic; if you don't like it, I'm glad that your system works for you.
As far as build systems, I'll take autotools and its learning curve and pain over VS any day. I can fix it when it breaks.
What are you trying to accomplish by saying that my problem is not the tools but that I'm bad at programming? Why is it that because you think you can write decent code in VS, that means that I didn't learn anything new when I switched from it? I know I certainly did; in fact, if I could give myself any advice back when I started any sort of formal programming, it would be: get off VS and Windows immediately! I would be three years ahead of where I am now.
I'm not saying you're bad at programming, I'm saying you're blaming the tools for your lack of discipline. Plenty of good programmers I know are undisciplined. But you can learn, and it's not the tools' fault that you didn't do so before. Hell, I'm a VS2010/Eclipse driver but I write MSBuild scripts by hand and I spent time the other day debugging the make/ant monstrosity. Limiting yourself because it's the only way to make yourself learn what you need to learn may work, but why not just learn it?
(And re: Eclipse--yeah, it's a bit of a hog, but hardware is cheap. Developer time isn't. And the features it provides have no equivalent in vim et al.--just look in the Source dropdown menu for a number of significant productivity enhancers. Those are some of the more minor ones, even; Open Type probably saves me half an hour a day in the monster of a codebase I have to work in. Eclipse is by no means perfect, but it's geared toward reducing boilerplate and stepping on the annoyances involved in Getting Things Done.)
Most of my peers in school used the same "compile, debug" approach as well. Most of them are still doing it and I can't see any serious software company ever hiring them (there is no shortage of positions for mediocre programmers though, so, they're doing just fine). I don't think this symptom is unique to me and my lack of discipline. As to why I didn't just "learn" to use VS or "learn" to program better? It wasn't for the lack of trying. MSDN was worthless, written documentation (yeah, it was that far back) was worthless and all of the code that other people wrote in VS that I had to interact with was absolutely terrible. It wasn't until I switched my environment until that I got any better. I got more from a man page in an hour than I did from a week of reading MSDN.
As far as Eclipse; I've worked with large codebases and I was faster with vim and knew my APIs better than any of my colleagues who used Eclipse. I heard them complain about Eclipse freezing pretty much daily (as well as doing something wrong when it came to interacting with perforce, often in a devastating way). I know that I Got more things Done than any of them.
That's an interesting take. You do have to have tools that adapt to your personal style, and it sounds like you felt that you needed to push yourself into different habits, which is commendable.
I've found that many programmers who come from a Java background over to .NET have a bad habit of writing their code and deploying it without debugging it even once. It's so much trouble to debug for them, they just wait until it blows up and takes down the server. Or their error handling is just throwing a stack trace to a screen instead of actually handling the error.
Heh, yeah, that approach sounds pretty terrible to deal with. What I do is extensive unit tests and useful logging. Unit tests catch most of the stupid stuff and plenty of the sophisticated stuff (and are a useful thing to have for a lot of other reasons anyway). Logging lets me track down what slips through the cracks. Most of the bugs that resulted in serous production issues for me were a result of rather complex interactions between complex components, not something a debugger would have helped anyone with.
That said, I have no doubt that there are a plenty of people who are amazing at writing code in VS and are much better developers than I am.
I haven't used IntelliJIDEA, but I do use Jetbrains' Resharper, which transforms VS into a much better IDE. If that's anything to go by, IntelliJIDEA's intellisense will be better than VS's intellisense.
Having said that, I just watched the screencast[1] of Python intellisense in VS, very impressive.
IDEA's Python support seems very poor compared to VS. I installed the IDEA Python plugin and when I typed "import " it said "no suggestions". Same thing when I typed "sys." and when I created a new Python project, it couldn't find any interpreters installed on my system.
Meanwhile in VS, after installing the Python plugin all of that stuff just worked the first time.
When you start up a new Pycharm project or add a new interpreter, you have to let the index processes run (there's an indicator in the lower toolbar which will tell you when background processes are running...click it). When those index processes are finished, Pycharm will definitely autocomplete import statements: http://imgur.com/JRsfH
What version of IDEA do you have? The latest version 10.5 works with the new version of the python plugin (which is basicaly pycharm) and auto completes right away when you start typing.
I really don't like having to configure the interpreters but it's also nice when you're using project based virtual environments.
You're asking that like it's special. Why is that? I mean, Python works great on Windows. Has an installer and all that; next next next finish. Package management is something of a hell (esp if you're used to ruby gems) but all in all it works fine.
I for one, prefer win as a dev platform, no matter the deployment platform. That means if the language of choice is Python, I use Python on Windows. I always assumed that this is rather common..
Most of the pythonistas I know are more or less evenly divided between Mac and various flavors of Unix. Windows users are somewhat rare, but present. I was curious if other groups have different profiles.
"Pythonistas" might not use windows, but a lot of programmers who work on Windows use python. Python on windows has been actively used at every place I've ever worked.
I was mainly just replying to the person claiming the pythonistas don't use windows. I've never met anyone claiming to be a pythonista so I don't know. I have however met lots of people who program on and for windows and who use python.
I never said pythonistas don't use Windows. I said few of the ones I know do and wondered if other people had different perceptions. Before moving to Linux, I did most of my Python programming using Windows.
Why would any programmer who isn't actually programming for Windows use Windows? Unless you're writing .net applications in VS, Windows isn't a developer-friendly operating environment.
This is what I do, Win7 for games, debian for work.
I like the dualboot nature as when in debian I have no excuse to startup a game and get distracted, when in windows I know I'm off work and I can relax.
Also having access to good command line tools is priceless - I'm not conversant with powershell, so maybe windows is good for this now, but being able to quickly grep/sed/awk/vi/etc is so useful.
I used to do that, but booting between two OS's was always kind of a pain and really Windows 7 generally just kind of works. I haven't booted into my Linux partition for month. For the times I need Linux there's vmware, but there are relatively few things that I can't get done on windows.
Server side on the other hand I'm all *nix all the time.
I also used to do that, but I landed on the other side - Linux generally just kind of works, and I dropped my Windows partition a couple of years ago. For the times I need Windows there's Virtualbox, but there are relatively few things that I can't get done on Linux. :)
<prejudice> I think that, these days, uniquely identifying oneself with just a single programming language is a bit like identifying yourself with a particular OS or computer. Most Windows users don't care much about this. They use Windows because it works best for them, not because they have t-shirts with Windows logos (or vice versa). The same holds for the choice of programming language. </prejudice>
Or more likely those Windows programmers don't know anything else but Windows and are unwilling to invest time to dig themselves out of the pit and see the light. To me a developer using Windows willingly has always been like an IQ test.
> Package management is something of a hell (esp if you're used to ruby gems) but all in all it works fine.
Wow. Ruby must have come a long way. Of course I gave up on it a long time ago when I couldn't find a good decompression library (only one that I could get to work was documented in Japanese).
I've found most python stuff "just works" or can be made to work.
Of course my use of Ruby dates to 2006 or so, as you can see that dates me quite a bit. I'm sure things have improved greatly over the years.
What about it? There's a few packages (mostly C extensions) that don't always build right, but the only problems I've had using pip and virtualenv on Windows have been related to corporate proxies/DNS.
Well, for Ruby, if your program complains that it needs "somelib", i do "gem install somelib" and it works. In my experience, this holds 100% of the time, on Windows.
For Python, I have, afaik, 3 (and a half) options:
1) Use something called "easy_install". Installing "easy_install" is not at all easy, which means that the entire experience is somewhat, well, ironic.
1b) Something with "egg files". I never quite understood what these are or how to use them, but I believe they are somehow related.
2) Use something called "pip". If "pip" knows your lib, then all is fine, but if not, things are bad. Also, there are different versions of pip for different "builds" of Python, and I do not know which to use. Tools seem not to be able to figure this out for me. In at least one case I ended up having multiple versions of pip, installed through different means, because the one that came with Python (which afair is the case) was not the right pip version.
3) Google for the library to discover that there is an installer for it, instead of using one of the package manager thingos mentioned above.
Trying to install trac on windows, I had to use all 3 of the above options (not 1b). I forgot what for what, but it wasn't trivial.
As you can see for my story, which is probably full of incorrect details, I'm not an expert. But I'm no expert of ruby gems either, and when I use Ubuntu I'm no expert at apt-get. Why do I need to be an expert of all the four-ish python library distributions to be able to install a single program?
Now see, I've had the same experience with rubygems on Windows (couldn't find the installer, gem directories weren't where they should be, missing dependencies, etc). It's all a matter of being familiar with your tools. :)
I've never had a problem using pip on windows for packages written in pure python. For packages with C components, http://www.lfd.uci.edu/~gohlke/pythonlibs/ almost always has the latest up to date version. But yea I agree, they should fix it so that it's easier to compile C based packages on Windows.
I use installers for things I deem to be key packages (numpy, scipy, stuff like that) and use virtualenv and pip to set up project specific sets of packages. I really don't know what to do with egg files, I've never had to use one directly.
virtualenv really is the key to getting this working well.
Honestly, as a long time windows python user, I think the main mechanism for package management on windows are installers. In that sense they're both easy and also kinda non optimal, but for popular packages it generally isn't that big of a deal.
At least on the *nix side, virtualenv and pip do almost everything you'd need. If you're using easy_install to install anything other than pip, you're likely doing it wrong.
Try Activestates's pypm. It is a binary package manager so anything that might fail a pip install where compilation is necessary is already compiled for you.
We develop trading software exclusively on Windows, and I use it for internal tools and our testing infrastructure. There are a few C extensions written to wrap our libraries, a lot of integration, regression, performance, and load libraries, and a bunch of dev tools to setup environments with our dependencies and such.
I introduced Python to the company in 2006 after writing a few very quick and dead simple test tools, and it seemed to pick up steam once our QA organization was looking for a way to beef up automation efforts.
tkinter. Python/tkinter is the fastest and easiest way I've found to create and distribute small[1] cross platform apps with GUIs. Python's batteries included philosophy makes it really great for cross platform uses, although it sometimes means constraining yourself to only the included batteries.
Average users can easily manage installing Python since it requires no admin privileges, and it works out of the box without hassle (and it's already there for linux workstations). Once they have it installed you can just email *.pyw scripts and they work for Windows users automagically and email filters that block .exe attachments let them through. In the super restricted government computing environment I did this in (a mix of Windows and Linux computers), the only other reasonable option would have been the JVM, which wouldn't have been nearly as fast to develop against.
[1] I'm talking super simple one-off tools that are written and distributed in an afternoon, not fully designed and developed products. Keep in mind, creating a button that simply runs a regex against a file and spits out a result is literally magic for most people, what I can do in 3 hours of effort can save a non-programmer hundreds of man-hours of work.
That site ranks the most vulgar English works released by Project Gutenberg. I calculated the ranking based on ~150k user ratings of the offensiveness of words listed on The Online Slang Dictionary.
A variety of tasks. To mention just a few: moving data between spreadheets and a database, with edits along the way; bashing a vendor's files into a usable form; rewriting AutoCad interchange files (.dxf files) to include new labels based on existing ones; providing mass upload into a document library where the original developers gave us only file-at-a-time.
In the *x world, I tend to use Perl, because I learned that first and know things in my fingers that I have to stop and think about with Python. In the Windows world, though Python for Windows just makes life so much easier.
Internal web applications at work. It's more clunky and cumbersome to install packages on Windows than *nix and the command line is underpowered and less integrated, but the benefits (and sheer joy) of programming in Python are worth the slight impedance mismatch.
I use Python on Windows for Django developement. Since I'm need to use other Win based software for work I use it also as my dev station. Can't complain, Windows does the job and Python doesn't care. One of the advantages of Python being x-platform. I find that most people that use Linux for dev, then emulate Windows for something, so I just stick to Win. This might change in Oct when Ubuntu 11.10 comes out, but probably now. Win has served me always very well.
If you go to PyCon, you'll see a _ton of Windows User, a ton of Mac users and a ton of Linux users. The Python community is impressively OS agnostic. The startup community less so.
I dev on Win because of the better multiple monitor support. I run using 3 large monitors on my Dev box, that I can rotate between landscape and portrait mode at will.
Python is my language of choice for WebDev, tools, etc...
A real POSIX shell that isn't slow.
A fast gcc and the like.
It is a pain to compile psycopg2 and lxml on windows compared to linux. Cygwin and virtual machines are unfortunately too slow when you are used to working in a non-virtualized Linux environment.
I'm heavily biased though because once you are addicted to the command line, it becomes very hard to live on Windows :-(
IPython doesn't get you POSIX, but it mitigates a lot of the pain. I run it inside console2 and the experience is pretty good. I have grep, gzip, plink, ffmpeg, and a bunch of other command line programs available from gnuwin32 and elsewhere. Given the choice I would use linux, but the most powerful machine I have access to is Win7 and I'm prohibited from changing this :(
Have you seen PowerShell? It has only shipped with the OS starting with Windows 7, but it's a surprisingly powerful shell--in some ways it looks way more powerful (and complicated) than bash and the like.
I do. We use python in our lab for simple scripts (backups and doing things our test SW isn't capable of, like HTTP comm), aggregating data, and some small web tools.
I'm at one of the big three, where getting a *nix machine on the network is next to impossible without piles of paperwork, and Windows is a requirement for our test machines. I'm all for better Windows tools :)
One of my coworkers had a whole setup script for getting an entire python development environment setup on Windows using Cygwin, including pip, virtualenv, mysql, gcc, ang cyg-get (like apt-get for Cygwin). All of the rest of us in the office use Macs or Linux (me), but he was able to checkout our projects from git, pip install the requirements files, and work just like the rest of us on his Windows machine. It required a lot of a figuring stuff out, but he kept great notes and can now go from a new install to a full environment by just following his notes.
I am. Developing 3D visualization applications. Mainly a desktop application using wxPython, but also a collection of web app front ends to those visualizations using cherrypy.
We do use py2exe to package up our application, but that is more for convenience and to act as an indicator that we don't want people to go hacking around in the source code. Also, even though python makes up the bulk of the app, measured in lines of code, that is not where the really interesting things happen, so we're not too bothered one way or the other.
Lots of AutoDesk products are extended with Python, like Maya and MotionBuilder
And in our studio, for good and bad, Windows is mostly deployed (audio guys might consider getting Macs again, as there was not proper support for ProTools on recent Windows versions)
I use Python on Windows for various things, primarily number crunching. Mostly I use it as a better (for me) Matlab, but it's also handy for random scripting tasks.
I do, although it's slowly being replaced with PowerShell (which is more convenient for integrating with windows applications, has better pipe semantics and better management stuff, particularly WMI, deployment etc). Plus it's built in and comes with a nice IDE on Win7 (PowerShell ISE).
At the moment though, I use Python for time management (using some scripts I wrote), a general purpose calculator, data munging on the fly, watching memcache stats, reporting and some other general bits of duct tape and string.
I really struggle with PowerShell - so many things don't work like I expect them to (e.g. passing arguments to the command line, which is surprisingly hard given that's one of the problems it was meant to solve; anything involving operators - these are different from any other language; different error condition semantics for the different built-in commands; default error handling behaviour; etc.)
Having the power of .Net in a scripting language is great, but it would have been even nicer if that language was consistent with the others on the platform (C#, JS, Ruby, Python for instance.) In fact I regularly think of converting our existing PS deployment scripts to Python, and better tooling support would definitely help.
I used to struggle with it too, until some time ago I think it all kind of clicked in place.
Don't try and think of it as similar to other shells like bash, but as an interactive console for objects. The operators, flow mechanisms and semantics make a lot of sense from that perspective, at least to me.
I've found that in that capacity, and as soon as I grokked the object pipeline, it's a wonderful tool with access to the entire .net ecosystem and a really hard push from Microsoft to have support for it on most of their tools
I've been automating several procedures with it and it's been working great.
That said, I also have some (iron)python scripts for some other tasks that don't involve as much glue between applications and services.
Kinda makes me wonder how easy it'd be to use them with c# and other .net languages, for anyone who was coming over from Python and already comfortable with those libs.
Our remote debugging solution depends on msvsmon to provide the attach-to-process functionality, so remote debugging doesn't work on linux out of the box. However, given a process attach infrastructure on linux you could reuse our debugger.py to talk back to Visual Studio, as that is a simple socket connection. If you wanted to implement that and contribute it back we'd definitely look at taking it.
The only complaint I have is that the installer hijacks the Python icons. I don't exactly care what program .py files open with since I usually drag/drop them into the appropriate editor and run Python apps from the command line. But I grew quite fond of CPython's file icons and they're much different after Python Tools installation.
The workaround is to reinstall Python after installing Python Tools.
Interesting, I guess this shows how popular python has become, tried a couple IDEs, so far pycharm, based on intellij, is one of the better ones if any one has a better one would love to try it ...
