Creating a programming language for your product requires a knowledge of your customer.  Years ago I had a job designing robots.  Now there are, or were, various languages and systems for programming of the robot to do its assigned task.  Most of those languages at the time required the person doing the robot programming to have computer programming skills. I had a great idea on how to program my robot.  I had just learned about the FORTH language and figured everyone would love to learn FORTH.  I wrote a FORTH interpreter. If you are familiar with FORTH you will know its designed around reverse polish notation.  I quickly found that not many people wanted to learn to program my robot because it required them to learn a language with this mental hurdle that only a few engineers were familiar with.

For my next robot we put in a BASIC interpreter.  BASIC at least was based on regular arithmetic expressions.  We sold quite a few of these motion control systems, but what generated more interest was when we put a GUI front end that looked like a spreadsheet.

You see, much more people are familiar with spreadsheets than programming languages.  It was the only motion controller for a robot at the time that was really easy to program by using a familiar metaphor.  What we did was to filter the technology to a wider audience.

I realized that the GUI I designed into the product had an impact on sales.  Imagine that.

My next project was another automation project aimed at a consumer with no programming experience.  To make the task more difficult the product only had a multi line LCD character display.  After our design team put our heads together we came up with what I think was a novel approach.  The use of Wizards.  Most product with LCD's, that I have seen, use menu's and setting that require the consumer to have some knowledge of where in the menu structure to find a particular setting.  Our concept was to first break down programming into TASKS.  We would have a wizard for each TASK.  Each wizard led the consumer by asking questions until a TASK was programming.   In addition, we created an underlying model that was similar to the existing products in the market.

It wasn't a perfect design, the small LCD was limiting, we were not able to customize the key layout, the consumer was led into fixed tasks, but it was an improvement over the existing products. 

You can always make the consumers programming task easier by limiting consumer choices.  Thats too easy.  You know your successful I think when you don't limit choices, but in fact have many ways to accomplish a task without making your customer think about how to accomplish their task.

Assume a consumer has never seen your product before or read the manual.  The consumer has pre-existing notions about how they might accomplish a task with your product based on their past experiences with other products, even those products that are quite different such as VCR's, iPods, Outlook, automobile cruise controls, ....  If you can determine those most appropriate notion(s) and make your design fit to create a metaphor the consumer might find your product easy to use because they already know what to do. 

A good underlying model, and a GUI metaphor, don't limit choices but expand the consumers uses.