What do you mean by “closely related”? What problem is this langugae going to solve?

Do you believe that by making a programming language look like a human language, i.e. using many keywords and little interpunction in its syntax, programming will be easier? That is not hard to do at all, but futile. It has been tried many times, most prominently with SQL and COBOL. Such languages are often disliked by programmers for their verbosity, and they do not help people to learn programming more easily.

What makes programming difficult is not dealing with syntax consisting of weird symbols, but the task of translating the requirements into unambiguous, detailed instructions, and dealing what all the special cases that nobody thought of when formulating the requirements.

Or do you envision the ability to use free-form natural language to instruct a computer? That, too, has been tried for a long time, and it’s one of the hardest unsolved problems in artificial intelligence, because it would not be a programming language at all, lacking formal syntax and semantics. Basically, you need a compiler or interpreter that is as intelligent as a human. In fact, this is pretty much the job human programmers do.

Assuming I get the gist of your question (something to the effect of, “why aren’t programming languages more like natural languages”):

Yes, but that’s a very complicated subject, well beyond the scope of a one-line question.

But I’ll point you to:

• AppleScript
  (what happens when a programming language tries to be more “natural”).

And,

• Legalese (what happens when a natural language tries to be more “programmatic”).

Things like have been tried but the chances are that even if you solve the hard problem of parsing natural language and intepreting it into something meaningful (there’s a walth of reading out there on NLP – natural language processing), the you will have another problem whether it will be any good at programming with.

Natural language is intended to cover a very broad domain (all of human experience) while conveying subtlety of meaning. In order to do that, it relies heavily on context: shared points of reference between interlocutors, and logical leaps and resolutions of ambiguities which both parties are confident the other can make.

Consider the following exchange:

A: It’s French Onion soup today.

B: Oh, dear! Would you like one of my sandwiches?

Speaker B infers ‘It’ means “the soup on offer”, presumably at the one source of food nearby; B knows speaker A doesn’t like or can’t eat onion soup and knows that A will therefore be hungry, so expresses sympathy. B has and is willing to forego a sandwich in order to prevent A being hungry, and thinks it possible that A will appreciate this offer.

This works for conversational human language where we are trying to express our own contribution conversationally and listen to what the other side has to say, but for programming we want to be very specific. Programming is the art of giving detailed instructions which will in given circumstances result in known outputs. In this case, it’s harder to correct a computer conversationally at runtime. You don’t want your business-critical software to make the wrong decision because it made the wrong guess when resolving natural language. It’s also likely to be inefficient in terms of raw performance.

Basically, the problem domain of programming (as opposed to say, applications which accept user input like “Book a doctor’s appointment on Tuesday”) is a very specific problem which natural human language is relatively poor at addressing.

Humans are perfectly capable of writing in languages that machines can understand, at least now we have languages like C, Perl, etc. Computers are not good at understanding languages that come naturally to humans. Typically we come to a compromise on languages with parseable syntax and unambiguous meaning. Although we can use syntactic sugar (also known as DWIM or “Do what I mean”) to smoothe over the trickier aspects of a language, we need to be careful to ensure that this is governed by rules transparent to both the computer and the programmer. Language significantly more ‘human-like’ will just result in us spending time guessing “OK, but what will the computer DO with that information?”.

An excellent example of the border between the useful and the frustrating is this in JS. On the one hand this lets you get things done quickly without worrying too much about parameters. On the other, it’s a magnet for action at a distance bugs that are really hard to track down when you think this refers to one thing but in fact it refers to something else.

In fact, giving clear instructions can sometimes be hard among humans, and real words like “this” are often misinterpreted – we’re not good at communicating our expectations first time round and the discipline of translating it into unambiguous is a vital part of programming.

Not only would it be difficult to develop it, as doing so would basically require artificial intelligence, it would also be harder to use than current programming languages. A programming language today requires an investment of time to learn the syntax and available library functions, but in return for that investment you get a payoff in terms of a clear, unambiguous language that has a precisely defined and (usually) easy to understand meaning for well-formed programs. Human languages are imprecise and ambiguous, which makes them unsuitable for programing tasks.

Yes and No.

If all you mean is it’s like asking Siri to do stuff, you’re going to be disappointed.

After all, people have been trying to make computer languages human-like for a long time.
Just look at Cobol.

On the other hand, if you have something in your head, and you’re trying to teach the computer how to do it, there has to be a fairly good match-up between the concepts you are thinking about, and the nouns and verbs available in the programming language.

In fact, there’s no other way to write any program.
The first thing you do is define variables, data structures, functions/methods, which correspond to what you’re thinking about, so you can tell the computer what to do.
You’re no longer working in Java, Python, Fortran, or whatever you started in.
That’s just the base language.
You’re working in the particular language you taught it.

That doesn’t mean just any Joe Schmoe can walk up and understand your code.
Just as there was a learning curve on the machine’s part, there is a learning curve on his part too.
People who think they shouldn’t have to spend time learning (in order to get the reward of higher productivity) are just not being serious.

At the same time, you need to be a teacher.
Just as you taught the computer what you are talking about, you also need to teach other people.