Defining your own programming language is an interesting challenge and test of creativity. A question you should consider is the extent to which you want the "language" to operate as something that completely analyzes a program before trying to execute anything, something that interprets commands in context-free fashion as it's going along, or something like Forth or PostScript in which commands are processed as they come from an input stream, but which has the ability to append input to a list, or to read commands from a list as though they were coming from an input stream, this allowing one to effectively define procedures by reading all the instructions into a list, and then later executing all the instructions in the list.
Another related question is whether you want your language to be practical for large-scale application development. If an application won't need more than 26 variables, for example, using a fixed mapping of the letters a-z to 26 variables may be simpler than trying to implement a symbol table or allocate space for variables. Local variables and parameter passing can be somewhat complicated; having all variable be in one global scope and requiring that code pass parameters using those global variables will simplify the language design, but writing code in such a language can easily become unmanageable especially if one wants to avoid defining an excessive number of single-use variables [e.g. because there are only 26 variables available].
I've used a fair number of domain-specific languages, including some I've designed; I've liked some and disliked others. The most important thing in designing a language is to decide one's objectives. That's not to suggest that defining the objectives will make everything else fall into place, but if you don't have a sense of your objectives you'll have no way of knowing which design ideas will let you meet those objectives and should be followed, and which design ideas would be incompatible with your objectives and should be abandoned.
