>> what's so wrong with Windows as a development environment?

Command line.

When you're doing a task on a computer, some paradigms are better suited than others depending on the task.

E.g. imagine delicately touching up pixels in a photo, guided by your artistic eye yet instructing the computer by laboriously typing many commands into a command line. There's no reason this couldn't work, it's just way more natural to use a pen & digtiser, or a mouse.

When we're developing we're editing text and invoking commands. Editing text is covered by any major platform just fine, a lot of popular editors & IDEs are even cross platform.

Invoking commands are sometimes covered by the IDE, sometimes the commands covered are pretty comprehensive (i'm thinking of Tom Christiansen's quip "Emacs is a nice operating system, but I prefer UNIX").

There's a limit to what tasks your IDE can cover, even though some do try really hard to cover all your needs (Eclipse has a web browser in it!) and when you hit that limit as we so often do in development, you need a command line.

At that point, Windows kind of whistles while sheepishly looking off to one side.

There's a related point about development dependencies, some libraries are hard and / or time consuming to build. A great package manager is a brilliant productivity booster. Mostly though, it's the point about the command line.

(just to be clear, i have given powershell a good shot, i estimate i've authored almost 1k lines of it).

Thanks for the reply.

What sort of command line tasks are you trying to invoke on both systems that are easier to invoke on unix? I can't think of any commands off the top of my head that I've had to invoke recently, other than IIS commands. Maybe it's just the fact that the C# developer's workflow is so heavily IDE based. I can imagine that if you were having to manually invoke the compiler etc, then a useful command line would be a must.

No problem at all!

Searching is a big one, looking through my shell history i frequently use egrep although I think egrep is a bad example here since I could use the IDE to do a search. The problem is that I frequently want to do something with the results - maybe make a substitution in each of the result files, or compress the files, or copy them to another host.

I overuse the find command, locate would run faster in many cases but find is just a reflex. E.g. answering:

    find data/ -type f -mtime -1 # get me the working dataset from today

I see a lot of source control commands, This is something all the IDEs do but in my experience it's much more robust from the command line than an IDE.

There's a few 3 or 4 line scripts for various tasks I was doing manually. To give an example one is to kick off a rebuild of my KVM virtual machine (I currently write a lot of CFEngine code so this is a frequent thing when the unit tests of the cfengine code don't go to plan and leave the KVM borked!)

The biggest use case in my shell history is simple navigation to look at or operate on various files. Fuzzy search in ST2 is slowly winning my heart here right enough but it doesn't work on remote hosts or even local dirs not in my project.

Very interesting, thanks for the in-depth explanation.

I think that this does appear to be a fundamental difference between Windows devs and Unix devs. All of the things you've listed there, I'd do through the GUI on Windows.

Searching, obviously, I'd Windows+E (or Super + E in OS non-specific keyboard terms) to open up the explorer, then tab+tab to navigate to find, then type the query. I can't think of an easy way to pipe a set of files into some sort of function (e.g. for substitutions) outside of F#, maybe something exists for that in PowerShell, but I find PowerShell to be a bit of a poorly-documented mess.

Source control, again, I'd do through the GUI. With TortoiseHG, I've got my hg commands available for me with the right click of a file/folder under a repository. I see that it seems that this'd be significantly slower than doing it through command line, but the windows shortcuts actually make it pretty snappy to navigate through the file system in the GUI.

For kicking off a VM, I'd usually attempt to shortcut the command I'm looking to execute regularly and then Windows+D my way to the desktop to execute it.

Windows does seem to have made the decision early on (i.e. back in '95, when I first started using it) to provide a clean and concise GUI first and foremost, and then to add programmer/automation-friendly terminal APIs as an afterthought. I wonder if the issues that Unix users on windows have are caused by the fact that Unix systems seemed to go the other way, and that attempting to replicate a Unix experience on Windows would just lead to frustration?

This is interesting, because I rarely get a chance to use Unix at work, nor do I get much of a chance to speak to Unix devs (we're a Microsoft shop -- WPF, ASP.NET MVC, and SharePoint if we're feeling masochistic). Thanks again for an interesting snapshot into your workflow.

Likewise, ive just realised that I dont make effective use of the desktop on windows but when you mention win+d to get to a screen worth of cherry picked shortcuts, it makes sense.

I never really put anything on my desktop, I do use the win7 taskbar a lot but I reckon ill start using the desktop too.

EDIT: meant to add for piping in windows, someone showed me something similarly useful, if you drag a bunch of selected files onto a program icon, the program can often make use of those files. E.g. drag some files onto the outlook icon and it'll compose a new email with them attached.

With regards to piping, yes this can sometimes be true. It's very dependent on the actual program. Programs on windows take a string array as the argument to their main function, so if the program is written in such a way that it iterates across every element of the string array argument and then does something with them, then this'd work. Most of the Microsoft programs behave sensibly with this, and execute an Open command against each of the files dragged onto them, but this isn't guaranteed to be true.

I'd still like a nicer, general purpose way of manipulating multiple files in Windows. That does seem to be one place where it's definitely lacking, but it could just be that I don't know how to do it.

In my (anecdotal) experience: A lot of tools (everything from editors to compilers, etc.) that are open source are from the Unix world. They're designed to work in a POSIX way and the ports to Windows (if they exist, or you're forced to use Cygwin) are a bit cludgy: You might just as well have used some kind of Unix in the first place. Windows dev tools are available, of course, but you often have to pay quite a lot for them. Good OSS exists for Windows, but it's a subset of what's readily available under nix, which doesn't encourage the hacker/hobbyist spirit.

Thanks for the reply.

That does make sense. As a C# developer, I haven't really had call to use OSS IDEs, so I can't really comment, but I do remember having an ugly time trying to use an OSS interactive disassembler on Windows.