could you clarify a little bit more how it was for you, what you had to change. Maybe you could point me in the right direction by providing some links to the information you used.

My first source were actually the tools' man pages. Just type

$ man toolname

on the command line ( $ here is part of the prompt, not the input).

Depending on the platform, they're quite well-written and can also be found on the internet. In the case of make , I actually read the complete documentation which took a few hours. Actually, I don't think this is necessary or helpful in most cases but I had a few special requirements in my first assignments under Linux that required a sophisticated makefile. After writing the makefile I gave it to an experienced colleague who did some minor tweaks and corrections. After that, I pretty much knew make .

I used GVIM because I had some (but not much) prior experience there, I can't say anything at all about Emacs or alternatives. I find it really helps to read other peoples' .gvimrc config file. Many people put it on the web. Here's mine.

Don't try to master all binutils at once, there are too many functions. But get a general overview so you'll know where to search when needing something in the future. You should, however, know all the important parameters for g++ and ld (the GCC linker tool that's invoked automatically except when explicitly prevented).

Also I'm curious, do you have code completion and syntax highlighting when you code?

Syntax highlighting: yes, and a much better one than Visual Studio. Code completion: yes-ish. First, I have to admit that I didn't use C++ code completion even in Visual Studio because (compared to VB and C#) it wasn't good enough. I don't use it often now but nevertheless, GVIM has native code completion support for C++. Combined with the ctags library and a plug-in like taglist this is almost an IDE.

Actually, what got me started was an article by Armin Ronacher. Before reading the text, look at the screenshots at the end of it!

do you have to compile first before getting (syntax) errors?

Yes. But this is the same for Visual Studio, isn't it (I've never used Whole Tomato)? Of course, the syntax highlighting will show you non-matching brackets but that's about all.

and how do you debug (again think breakpoints etc)?

I use gdb which is a command-line tool. There's also a graphical frontend called DDD . gdb is a modern debugging tool and can do everything you can do in an IDE. The only thing that really annoys me is reading a stack trace because lines aren't indented or formatted so it's really hard to scan the information when you're using a lot of templates (which I do). But those also clutter the stack trace in IDEs.

Like I said, I had the 'pleasure' to set my first steps in the Java programming language using windows notepad and the command line java compiler in high school, and it was, .. wel a nightmare! certainly when I could compare it with other programming courses I had back then where we had decent IDE's

You shouldn't even try to compare a modern, full-feature editor like Emacs or GVIM to Notepad. Notepad is an embellished TextBox control, and this really makes all the difference. Additionally, working on the command line is a very different experience in Linux and Windows. The Windows cmd.exe is severely crippled. PowerShell is much better.