So hurricane Sandy was you?

But if you've got Linux already, why use Windows as the development environment?

This is a problem, I agree. I'm always uninstalling things when I visit my mother. Too many of these installers add extra junk in the mix, and most users who aren't paranoid just click "next" whenever it pops up instead of reading all of the stuff that gets installed (is there anyone on the planet who thinks a google or yahoo helper bar is actually helpful?). I'm also seeing updated versions of firefox messing things up, it's just too hard to train her to not click "ok" everytime the computer asks for something.

I agree. I have Avast on my mother's XP and it doesn't seem to slow things down. Granted it's a slow computer to start with, but most application use is only with Firefox and Thunderbird, and internet is slow enough that scanning web pages won't be noticeable.

"Had to" program with vi? Why is that? There were no other alternatives whatsoever?

IDEs really seem oriented to a project only if they're used from the beginning of the project. Too many of them insist on their own directory structure, like all files in a directory always being linked together or put into the same library, or each directory having its own separate project, etc.. It is hard to adapt a lot of IDEs to existing projects. They also tend to think that they're the only tool in the mix; ie, the IDE for an embedded chip thinks that it is the only chip in the entire system.

Make is very simple really. And it's portable. Even if you're only going to compile a Windows app you will not necessarily be tied to exactly one IDE forever. There are multiple IDEs for Windows and their projects formats are incompatible (and inevitably they require a project before you can use them). Whereas a lot of them do allow the use of an external Makefile. Thus the Makefile is a step at more portability, even on Windows.

Also the Makefile is great for automated builds. No need to have the build engineer pull up yet another IDE just to kick off a build rather than have it all scripted.

(As for Visual Studio, last time I used it I did edit its project files by hand because they kept getting screwed up if modified using the UI only.)

Problem is that GCC is far more portable and in wide use, so support for GCC is important. LLVM is probably great if you're on x86 only stuff or don't have to deal with a mixture of languages or systems.

Hey, time for graham crackers and milk, so stop using your ipad during kindergarten.

One can certainly use vi and then pull up the IDE on the side for the occasions when they have to use some extra tools. I worked in an environment like that once, the project was tied to Visual Studio, despite not being a Windows application even. So most people except the boss used external editors and then built using VS (and were forced to use an external debugger anyway since it wasn't Windows). It's clumsy but doable, even more clumsy in ways than just have a set of independent tools (editor plus gcc plus make plus gdb plus source code control plus...).

It often comes down to two groups of people; those who know the command line and are extremely fluent and fast in it, versus those who always want a graphical tool to do everything. That seems to be somewhat generational, as in those who learned to develop when there were only text or mostly text environments versus those who first developed when everything was windowed.

Everyone should use the tools that they themselves are most comfortable with; maybe with years of training they will be slightly faster in something else, but speed should not be the goal here. Better is to try and combine those two types of environments in some way. However whereas text tools tend to be good at being combined with other stuff, most IDEs tend to be very inflexible except for a limited plugin scheme.

A lot of programmers tend to only do a narrow range of operations on suitable components.

The thing is, once you know vi or emacs or a lot of other editors, they are stuck in your muscle memory. Some people can edit in vi much faster than others can do the same operation in an IDE. Now add in the ability to customize and add scripts and the utility goes up greatly. It's naive to think that this sort of person is going to somehow be more productive when presented with a point-and-click interface.

Sort of like going to a machine shop and announcing that everyone must stop using their own tools and only use company provided toolkits, the workers are not going to end up happy or productive.

Fired? That's ridiculous. Let the developers use the tools they are comfortable with.

If you're doing a 3 second refactor with a tool then that means you are not cross checking to be sure that the tool did it right or the way you wanted it done, so add at least an hour to do that to do it right. Never trust a tool to do the right thing, unless you're in the sort of dysfunctional environment where fast code is more important than correct code.

I don't know, great editor but lacking a bit to make a good IDE. I don't like IDEs though so I don't mind that. The whole concept of having a single window to view code in that is surrounded by auxillary rarely used windows just seems backwards, and yet that seems to be the dominant design. Also the idea that all tools must be a part of the same overarching tool seems wrong, since it prevents you from mixing and matching the best tools. Ie, if you have an IDE with a great editor but its debugger is mediocre, then the entire IDE becomes mediocre; in some cases I have seen some developers use several IDEs in parallel to get the best of each, which also defeats the idea of "integrated".

Emacs does what is important with an IDE, lets you edit, lets you run a debugger and present the data within it, lets you start a build and present the results within it, and lets you manage the source code control. Basically it has a way to integrate other text based tools. It doesn't need to be a Windows style MDI application to do that.

First IDE I used was in 1981, UCSD Pascal. Edit/compile/debug in a straight forward tool. Things do not seem to have improved that much since then. Maybe they're prettier though.

I don't think the skilled developer is going to be very productive on Visual Studio for Linux.