So what is a language?
If the solution is to create a language (not a program, not a module, not a command) than I need to know, what is a language, what is it composed from, when do I know I completed my language, what feature do I need filled to have a complete language.
Many ppl repeat those words about writing your own mini language or high level language ... so something good must be in it, specially since, that at an abstract level this thought is supported, that any program can be viewed as a language, any library, can be thought of as a language
Correct; the difference between a "program" and a "language" is one of perspective. You write a program to walk 100m, turn right, walk 110m, turn right, walk 100m, turn right, walk 110m, and maybe turn right. You write a language to go around the block, instead.
What is missing is, how can this way of thinking, help me create a better program (language) or better module (language)
I think we can start by having a better or a more specific definition of a 'language'
Short answer: [link|http://en.wikipedia.org/wiki/Formal_language|read up on "formal languages"].
A little language possesses a vocabulary of functions, classes, modules, and packages which map to concepts in the problem domain. The elements of the vocabulary interact according to a formal grammar. The concepts are determined by self-declaration of human stakeholders, subject to systematic analysis and organization in order to produce a formal system.
Also, I want to mention, that read in a few article about Ruby, that ruby makes it very easy to write your own mini language, what a tease, as if every body is doin it, yet, when I search, I can't find any book or article who tell u how to create ur own language, the school of "make it a language", is far from ...
being an everyday thing! It's really not that popular, or elaborated upon.
As Ben pointed out, you don't start from scratch when writing a "little language". You start with a generic language (like Ruby or Python or LISP), make up some new primitives (like go_around_the_block()), ignore any primitives which you don't need, and end up with a slang dialect which fits your problem space. It's called "little" because it's embedded within another, larger language.
Ruby "makes it easy" because you can override almost any primitive (even builtin types) to create the behavior that you want. Python doesn't allow you to override builtin types; you have to subclass them.
Cameron Laird [link|http://groups.google.com/groups?th=6c6790175731d644&seekm=m66s52-91c.ln1%40lairds.us#link8|made this point] nicely just this morning on c.l.p.:
Next, Python thumps Java on readability and maintainability. While I don't yet know how to make an iron-clad objective case for this briefly, I'm utterly convinced that Python programs are significantly easier to read "six months later". This matters: much of teamwork is dealing with source code that one doesn't understand. Traditionalists promote Java as a statically-typed language, but this is just a distraction; Python's more graceful expressiveness leads to relatively more focus on correct algorithms and unit tests, while Java is relatively mired in syntax. Programming in Java feels too often like dealing with Java, whereas Python is a leader in letting developers think they're dealing with the application.