my case:

regularly.

most often:

compiling code;

invoking command-line tools.

sometimes for launching programs, but more often I do this in Visual Studio, though I don't usually develop from within Visual Studio (apart from things like simple GUI tools), mostly using it as a debugger.

personally, I find Windows Explorer + a dedicated text editor to be more usable, though I am left sometimes wishing the Windows taskbar could deal nicer with lots of open editor windows, and maybe support faster scrolling through the list (via the scroll wheel), though luckily the editor I am using avoids opening multiple windows, so it amounts to using a stack of open Explorer windows, each in a different directory, then switching to the directory I want and pulling up the file I want if I can't quickly see it in the list, and periodically closing all the open editors if "too much stuff is open" (and finding anything would require excessive slow scrolling).

so, at the moment:

~ 2 or 3 screens worth of open text editors;

15 Explorer windows (previously, it was more, but recently Windows was getting sluggish, so I did a bulk close);

4 Command Prompt windows (*1);

4 instances of Visual Studio (for debugging 4 different programs);

2 instances of Cygwin;

1 instance of CodeXL (AMD's Profiler);

...

*1:

two currently set to build things in two different locations;

one for periodically reinstalling a driver (every time I need to force-feed the new version into Windows, after I verify it probably isn't going to blow up, *2);

another to run some basic tests and benchmark the logic for the driver;

...

*2: though luckily, it is a ring-3 / user-mode driver, so crashes are merely rather annoying, rather than resulting in a blue-screen.

the command-prompt in question basically contains an arcane-looking command spanning multiple lines used to cause Windows to reload the driver using an INF file (could be moved into a BAT file or something).

so, "a fairly typical day...".

I work on Linux, so I use terminal a lot. Mainly for updating my system, git, ssh, mc.

I mostly use it for admin/management where I have to, but prefer to avoid it where possible, and this is despite - or perhaps because of? - having a DOS/Unix/VMS/etc background. Also some work on older versions of Oracle (as a DBA), Lotus Notes (spit) and Cisco routers. Yeah, I've seen some dreadful (and some really good) CLIs.

I view the GUI as a tool to make my job easier, and I also view it as being more robust as I can double-check options before comitting, and be more immune to typos (the latter applies more to one-off tasks rather than anything you'd script or automate, of course). It just makes sense to me to use the GUI if one is available for these reasons.

I've no technical difficulties with having to use a CLI, and no technical difficulties with needing to drop into one for some things which a GUI can't handle (or doesn't handle as well as it should) but always wish that I didn't have to. I've long since lost what I consider to be a kind of "programmer arrogance", I don't necessarily feel more in control with a CLI, and don't feel that using a tool designed to make my job easier is in any way "lazy" (quite the opposite; it can be more productive so I end up getting more done).

I see a lot of people who use command line text editors for their coding. Is that really faster than, say, Eclipse, or Code::Blocks?

The windows command prompt is a piece of trash, you're much faster with the GUI they provide.

Linux on the other hand is far easier and more powerful to use over the command line. I use it for version control, folder management, scripts, and quick text edits to config files.

I see a lot of people who use command line text editors for their coding. Is that really faster than, say, Eclipse, or Code::Blocks?

The windows command prompt is a piece of trash, you're much faster with the GUI they provide.

Linux on the other hand is far easier and more powerful to use over the command line. I use it for version control, folder management, scripts, and quick text edits to config files.

I actually see it as being the case that most of what you're talking about here - version control, etc - is actually accomplished by separate programs rather than by any native command-line functionality. Your text editor is a separate program, your VCS is a separate program, and these programs just happen to provide a command-line interface. That on it's own doesn't make the command-line better; it just means you've got a bunch of separate programs that exploit the command-line.

The point here is that there's often no real reason why these separate programs should have their primary interface via a command-line, other than person preference of their authors or historical inertia. Remove the fact that you're talking about separate programs from the equation and what are you left with?

The point here is that there's often no real reason why these separate programs should have their primary interface via a command-line, other than person preference of their authors or historical inertia.

Sure there's a real reason other than personal preference and historical inertia.

• Speed. For simple things such as version control, text editing, seeing what's in a folder, removing/creating/renaming files, or running scripts, I don't want a huge front-end loading into memory every time I have to edit a line in a text file, or push some changes to a repository. These are simple tasks and don't need to be in a window.
• Screen space and switching windows. The command line requires very little screen space, and yet gives you the ability to work with multiple programs in parallel without having to switch between screens (ALT+TAB for example, and then you have to press that multiple times before you reach the window you want...).

is actually accomplished by separate programs rather than by any native command-line functionality.

I'm pretty sure when the OP said "command line" he's including all command line front-ends into the equation, or he would have explicitly stated so.

Besides, what are you left with if you only mean native command line commands? Even "ls" is a program...

I use it all the time (mostly at work). I generally use it to launch build scripts and run command line tools.

I see a lot of people who use command line text editors for their coding. Is that really faster than, say, Eclipse, or Code::Blocks?

It's not faster by virtue of being a command-line editor--you can definitely make a horrible interface with or without a GUI--but that such software tends to put more emphasis on ease of use via the keyboard because that's how you're going to interact. When the physical labor of my job is mostly typing, something that makes that typing as painless and efficient as possible is much more noticeable to me than, say, an easy-to-use wizard I will use less frequently. Even in a modern IDE attention paid to how easy it is to work in the editor (or the rest of the interface, really) without having to touch the mouse would pay off.

That being said, Eclipse, Visual Studio, and Code::Blocks are not equivalent to, say, vim. vim is a fantastic editor, but at the end of the day it's only an editor (ignoring the scripting bits!). There are plenty of places where an IDE can provide productivity boosts that an editor can't because the features are unrelated to handling text. For my side of things, I just find that I spend somewhere around 5~10% of my time using something that requires a mouse or special visualization. I'd rather optimize my 90% use case and vim just clicks with me more than most other editors. Your digital mileage may vary. And I still use Eclipse and Visual Studio in addition to vim! Not like I shun a tool when it would make more sense.

There's this somewhat lengthy presentation if you want a more in-depth coverage of the thinking behind vim.

I see a lot of people who use command line text editors for their coding. Is that really faster than, say, Eclipse, or Code::Blocks?

It's not faster by virtue of being a command-line editor--you can definitely make a horrible interface with or without a GUI--but that such software tends to put more emphasis on ease of use via the keyboard because that's how you're going to interact. When the physical labor of my job is mostly typing, something that makes that typing as painless and efficient as possible is much more noticeable to me than, say, an easy-to-use wizard I will use less frequently. Even in a modern IDE attention paid to how easy it is to work in the editor (or the rest of the interface, really) without having to touch the mouse would pay off.

That being said, Eclipse, Visual Studio, and Code::Blocks are not equivalent to, say, vim. vim is a fantastic editor, but at the end of the day it's only an editor (ignoring the scripting bits!). There are plenty of places where an IDE can provide productivity boosts that an editor can't because the features are unrelated to handling text. For my side of things, I just find that I spend somewhere around 5~10% of my time using something that requires a mouse or special visualization. I'd rather optimize my 90% use case and vim just clicks with me more than most other editors. Your digital mileage may vary. And I still use Eclipse and Visual Studio in addition to vim! Not like I shun a tool when it would make more sense.

There's this somewhat lengthy presentation if you want a more in-depth coverage of the thinking behind vim.

yeah.

I personally use a mix of Notepad2 (mostly), Notepad++ (sometimes), and Vim (sometimes), in addition to using Visual Studio (mostly as a debugger), ...

cases where a person might use Notepad++ are *not* those where one would use Vim, and cases where a person may use Vim are not those where they might use Notepad2 or Notepad++.

also, a CLI is nice in that it is much easier to quickly throw together powerful interfaces in command-line tools, whereas it is considerably more work to make a GUI where someone can get much done (without it turning into an awful-looking mess in the process, *).

*: a big mess of buttons, check-boxes, drop-lists, ...

This CLI is better, no GUI is better, no...

... it gets a bit old. Often they are both not ideal.

If I start with a GUI program and they did not implement everything needed and I have to use the command line the GUI program is bad.

If I start with the command line and then have to try different ways to even get a list of available commands, because its so long it doesnt even list all with --help and it gets impossible to remember all, its also bad.

If I have to have the GUI program and the command line open to do everything, because both are lacking, its worse.

For example vim, when I had to use it it was near impossible to find out all commands and I felt like I would love typing my stuff into Notepad, although thats clearly lacking functionality.

Or source control, I could use hg easily from command line, but a click at Turtoise HG may still be faster sometimes. The problem is you can not do everything with the GUI.

Then git, everything thats 5 characters and a space for hg is one or two arcane commands with switches in git and the GUIs for it were much worse than Turtoise HG. The good/bad(depending on circumstances) thing is you are not blocked from doing things that hg doesnt want you to do (like merging 2 times from a bookmark to another when you dont want a branch that lives forever), the bad thing is both the CLI and the GUI are worse in git, not just one of them. Meanwhile I remembered the arcane commands and only use gitk to look at the tree/diff.