Three aspects of programming language design: mentation mysteries, metaphysical mathematical momentum, and "the shortcut"

Programming language design is something that humans do. 

One could examine biologically the effects of notations on the human mind, and try to create a working model of what might be called the "mentation mysteries" behind programming languages. And use that to set some kinds of criteria for future programming languages.

That's hard work. That's why it's called hard science. So people don't do this, when they design programming languages. They obviously don't need to, because plenty of programming languages exist, even though this research is still on the starting block.

So, instead of biological research, what other tools do people use to create new programming languages? 

Two tools: metaphysics and feeling.

By metaphysics I mean metaphysical mathematical momentum. 

Someone has a theory of what might be useful. It's based on some 'computational model' that they respect: Haskell programmers prefer functions that don't act on named state variables, Grogix programmers believe the world could be defined by operational grammars, LISP programmers believe that our world can be defined as ramified lists, SNOBOL programmers believe that ultimately everything is a string, etc. This is not just the ontology of their world ... made of lists, strings, grammars, monads, etc. ... there's also a metaphysics, a model of what lies hidden behind programming, in a fantasy computational system which acts as the programmer's substitute for the "real world". These language designers then develop mathematics and achieve momentum which can trample many other considerations for their tool, such as usability.

Well, there's only so much an engineer has time for ... So most aspects of most programming languages did not emerge from either biologically confirmed results or theoretical imperatives.

They emerged because they felt right. 

All those open questions about the mind, and those potentially useful metaphysical systems, might yield something useful later. But good engineering (and that's what good programming language design is) needs to work now. So, we use our sensitivity, we try things out, we keep the good stuff, we throw out the bad stuff, and we try to keep the result feeling coherent, while we maintain some kind of logical consistency and pragmatism.

It's the shortcut. 

You can't prove that your "answer to the crisis of programming" is right. But, using your gut, you can build something good, something perhaps a touch idiosyncratic, and see if it works for you, your friends, and some members of the public.

That said, it's really important to do a post-mortem. Be explicit about which of the three criteria above are being used in different parts of your language design. Because, most likely, you are using these three, separately or in combination, for different aspects of your language. And the poor engineer learning this language should be able to know what was going on, in your analysis, when you invented this language feature, or that one ... It's simple transparency. To a certain degree, you could sidestep analysis by just answering "I used my feeling" for all of it, but that would be silly. We tend to think about something and use our feeling to judge something. If you can't analyze your own language in this way, I think people would be quite right in not taking the effort to understand your programming language. They may be wrong, and they may be missing out, but the onus is on the inventor to explain what's been done, and why.

If you think your programming language is so simple and pure that it requires no explanation, I beg to differ, from experience. I created a programming language (grogix) which only has one kind of statement. But it takes a great deal of work to know whether you can use that simple statement to do all the things you want to do, and do them in a way that is easier than some existing way. So an explanation and demonstration is required.

So, look at your creation, and ask yourself to rank the drive behind any given feature:

1. cognitive science
2. metaphysical imperative
3. feeling