Basically, your question is "how are languages, libraries, operating systems and applications designed and implemented?"  That's a multi-billion dollar worldwide industry employing millions of people. You might want to focus your question a bit more.

That said, I can take a crack at:

> I can't understand how people create programming languages and devise compilers for it.

It is surprising to me, but lots of people do look at programming languages as magical. When I meet people at parties or whatever, if they ask me what I do I tell them that I design programming languages and implement the compilers and tools, and it is surprising the number of times people -- professional programmers, mind you -- say "wow, I never thought about it, but yeah, someone has to design those things".  It's like they thought that languages just spring up wholly formed with tool infrastructures around them already.

They don't just appear. Languages are designed like any other product, and their compilers and tools are built like any other software product: one line of code at a time.

Language design is a huge topic. If you're interested in designing a language, a good place to start is by thinking about what the deficiencies are in a language that you already know. Design decisions often arise from considering a design defect in another product.

Alternatively, consider a domain that you are interested in, and then consider designing a domain-specific language (DSL) that specifies solutions to problems in that domain. You mentioned LOGO; that's a great example of a DSL for the "line drawing" domain. 

Once you have sketched out what you want your language to look like, try to write down *precisely* what the rules are for determining what is a legal and illegal program. Typically you'll want to do this at three levels: 

1. *lexical*: what are the rules for words in the language, what characters are legal, what do numbers look like, and so on.
2. *syntactic*: how do words of the language combine into larger units? In C# larger units are things like expressions, statements, methods, classes, and so on.
3. *semantic*: given a syntactically legal program, how do you figure out what the program *does*?

Write down these rules *as precisely as you possibly can*. If you do a good job of that then you can use that as the basis for writing a compiler or interpreter.

I write a blog about the design of C#, VB, VBScript, JavaScript and other languages and tools; if this subject interests you, check it out. http://blogs.msdn.com/ericlippert

And if you're looking for a job doing this stuff when you're older, consider coming to Microsoft as a college intern and trying to get into the developer division. That's how I ended up with my job today!