I do not want to build a language as a simple exercise, I'll do almost anything it takes and can you elaborate by the purpose of looking at much simpler languages and what exactly do you mean by "simple"? I'll have a look if I can get or find the book.
I'll see if I can read dergueta's tutorial series too, if either of the book suggested by WingedPanther73 or dergueta's tutorial series covers this you don't have to answer, but if it doesn't or you haven't read either and know how to create a programming language, could you summarise the steps you would take from scratch to make your own programming language e.g.: what software you'd use, how would you use it and where did you learn how to use it and the kind?
ok so I don't really know how much of an experienced programmer you are or what projects you have worked on the past, but making a programming language is not an easy task.
You need to understand that there are two very discrete stages at creating a programming language. The first is creating a specification for you language. That is everything from the typesystem and your language's syntax to the communication protocol between your language and your computer.
The second is the development of a compiler or an interpreter software (depending on how you want your language to be executed) that takes text files which contain source code for your language, read the source and translate it for the computer to understand. In my engineering degree the Compilers course was the hardest of all and very few students ever chose it, so don't worry if you get discouraged after a while. The hardest part won't be the design of the language itself, since that's the fun part. It's going to be the humongous amount of knowledge that you have to know before you start developing your own language.
I respect that you have experience on other high level languages, but what these languages really do is provide you with an easy and abstract way to communicate with the computer without having to delve into stuff like asm or machine language. Understand that just because you're very good at a programming language doesn't mean that you know how the computer works. That's hardly ever the case (unless you know a lot of C, and even then C just gives you a tiny idea).
I'll give you a very brief and extremely incomplete review of what a general compiler might look like.
A software that compiles source code to machine language might seem in most cases very convoluted, but that's really only if you don't know what you're doing. A compiler program is usually divided into other programs, or stages, that your source code has to run through before reaching the final stage of an ELF (executable file).
For example the first program (or stage) your source code might go through is a lexer, which performs lexical analysis on your program and basically turns every single token (look for the definition of token to understand what it really is) into a string. A lexer usually works together with a parser which is the program that reads your file and converts it to data structures which are usually implemented in the form of an abstract syntax tree (you can use any other d.s. you prefer, but I wouldn't recommend using linked lists for this).
See this image from Wikipedia to understand it a bit more:
After that you run your data structure through the main compiler program which might optimize code away (that means that it finds better ways to implement your code on instructions for the CPU, to either save space or make it faster) or do other things you want it to do, but the final product has to be the creation of an executable program by the PC.
Now all this is extremely overly-simplified (euphemism is on purpose) and it doesn't even come close to describing the very complex art of compiling. There's a million stuff you can learn about compilers, or interpreters or anything really as long as it turns your program into something that can be read by the computer, should that be an executable (eg an .exe file) or a script that is interpreted line by line while it is running.
The thing is, I might have messed some stuff up or sounded confusing while describing this (since I described it the way I thought about it), but nowadays noone writes a compiler or an interpreter on machine code or even assembly. A compiler for your language is usually written in another language, which is then compiled to that language's compiler and the output is a compiler to your own language's program. If your language reaches a very advanced level you can then write the compiler for your language, using your own language in a process known as bootstrapping (see: https://en.wikipedia...ing_(compilers)). This is simpler than it sounds actually.
After you specify the rules surrounding your language (syntax, type-system etc) you can use your knowledge in one of the languages you are already good at, and write a simple compiler to see how it works. Most modern languages began that way (Java, Python etc). Of course it doesn't just take knowing another programming language's syntax in order to implement this. For example if you want to have your language support threading, you really have to know OS-level system calls for your compiler.
Usually most languages are written in C due to its low-level and inline assembly capabilities, with ready-made lexer and parser libraries such as gnu flex, yacc and bison (see: http://aquamentus.com/flex_bison.html). If you already have knowledge in C++ then you might be familiar with pointers and pointer arithmetic so C will be a piece of cake for you. Also you really need to have knowledge of a symbolic language to understand how the computer thinks and works, which isn't that easy (see: http://www.drpaulcarter.com/pcasm/).