Closed NoamWhy closed 6 years ago
I suggest you take a look at C compiler preprocessors, which essentially did what you are suggesting.
They were generally considered a terrible idea, albeit were necessary in C for various reasons. Their usage where not necessary is frowned upon quite strongly.
The issues are twofold.
Firstly they have quite odd behaviour since they are text editors, not functions, which can lead to surprising behaviour. I suggest you read up about that.
Secondly, it makes it impossible to read anyone elses code, since you don't know what any piece of syntax you mean. It is extremely important for C# to have a limited variety of expression, so that everyone understands just from seeing some code what it means. If every developer uses their own domain specific language, development in teams becomes impossible.
I would also point out, that the entire reasoning behind your idea is in my opinion misplaced.
The language is not the problem!
Programming is hard because programming is hard. Languages are easy to learn, and the syntax just stops being an issue pretty quickly.
Thanks Yair,
Well, the old C days are long gone, and in today's C# the user would be able to easily toggle between the natural and the formal representations, so there is never a concern that the code would be miss-understood. This will also prevent any "odd behavior", since the natural code will be unambiguously translated to formal one, and by a click of a button you can see that translation, and verify that it's OK. So there is absolutely no problem here.
I believe such a feature will be highly welcomed by big organisations which have to manage massively large and complicated business logic.
Consider the following example:
using "double (x)" = x+x;
using increment (x) = x++;
var y = 5;
double (increment (y));
You would expect this to result in 12 since 5+1 is 6, and 6 + 6 is 12.
Not so, it's 11!
Also y isn't 6 at the end of this. It's 7!
Why?
The code gets converted to:
var y = 5;
y++ + y++;
but y++ returns the original value of y before its incremented. Thus y++ returns 5 and, turns y into 6. Then the next y++ returns 6 and turns y into 7. We add 5 and 6, resulting in 11.
Similarly
using "(x) equals itself" = x == x;
(new(object)) equals itself;
That will return false!
Why?
That gets converted into:
new(object) == new(object);
Which is false.
Your first example is wrong, since you should define:
using "increment (x)" = ++x; using "take (x) and then increment it" = x++;
Also, the compiler has to make sure that all instances of the same variable are passed the same value. No big deal. This will solve both of the problems you have presented above.
Nice try though :-)
What is your actual specification for how this would work? It sounds a lot like some sort of macro expansion system. But it's entirely underspecified right now, so i don't actually know what is being requested.
Hi Cyrus,
The big Idea is to move closer towards programming using natural language. Surely, I don't have a fully detailed specification, since this is merely an initial discussion about a possible direction in which programming may develop.
in today's C# the user would be able to easily toggle between the natural and the formal representations, so there is never a concern that the code would be miss-understood. This will also prevent any "odd behavior", since the natural code will be unambiguously translated to formal one, and by a click of a button you can see that translation, and verify that it's OK.
This sounds more like an IDE feature than a language one.
It would be interesting to see an IDE that translates between natural languages and programming languages, though.
Also, why do you need C# to be involved in tihs at all? It sounds simply like you are just preprocessing your code before handing it to C#. But that can be done today already using existing preprocessing solutions.
Thanks Khm1600,
Indeed I believe we would all want to see an increase use of natural language in programming, and this can be an excellent first (and simple) step.
I also believe that a good implementation of the above would require a smart cooperation between the IDE and the compiler.
Surely, I don't have a fully detailed specification, since this is merely an initial discussion about a possible direction in which programming may develop.
Without a specification, i would side with the "this sounds like a very bad idea". Effectively, it's the same as many other systems that have come before, which have had numerous problems in the past. There's a reason these types of approaches are not popular, and without clarity on how this would actually work, i'm going to presume that this would have the same problems and concerns.
Indeed I believe we would all want to see an increase use of natural language in programming, and this can be an excellent first (and simple) step.
Why do you need C# involved then? Why not just write a tool that does this?
Also, why do you need C# to be involved in tihs at all? It sounds simply like you are just preprocessing your code before handing it to C#. But that can be done today already using existing preprocessing solutions.
Not quite. The use of spaced words, with scattered variables between them is not supported. And besides, the whole thing should be managed properly.
I also believe that a good implementation of the above would require a smart cooperation between the IDE and the compiler.
Why? There is no specification on what's going on. Right now it seems like a fairly basic matching/substitution system. Why not just write that up, work with it a while, and then if good things come out from it, come back with a more detailed proposal?
Not quite. The use of spaced words, with scattered variables between them is not supported.
Why not? Just write a preprocessor that supports that. :)
And besides, the whole thing should be managed properly.
I don't know what that means :). Right now you've just given a couple of basic examples. It seems extremely trivial for you to just write a tool to look for the patterns you've mentioned and to convert them. Try it out for a while. write some programs in this style. Come back with some realistic examples demonstrating the improvements this brings. :)
Indeed I believe we would all want to see an increase use of natural language in programming,
How would your system parse: Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo
?
Or, less cutesy, how does your system deal with: https://en.wikipedia.org/wiki/Ambiguity? Especially: https://en.wikipedia.org/wiki/Syntactic_ambiguity?
I also believe that a good implementation of the above would require a smart cooperation between the IDE and the compiler.
Why? There is no specification on what's going on. Right now it seems like a fairly basic matching/substitution system. Why not just write that up, work with it a while, and then if good things come out from it, come back with a more detailed proposal?
I'll be happy to specify and develop this, if someone would be willing to finance this project. I am simply expressing a general idea. Now, the C# team may decide to pick up this glove and lead the natural language revolution, or alternatively ignore it for now... until this feature will be available in Jave and Python.
Indeed I believe we would all want to see an increase use of natural language in programming,
How would your system parse:
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo
?
If this expression was not defined, the compiler would show an error.
If this expression was not defined, the compiler would show an error.
The expression is defined :) It's just hugely ambiguous. How do you anticipate your system being able to deal with this? Here's the general way it needs to be parsed for it to have a reasonable meaning:
I'll be happy to specify and develop this,
That would be great. Please go do that and come back with some sort of specification on how you envision this working. I can use that to try to give an accurate costing to how expensive the IDE side of this would be.
and lead the natural language revolution, or alternatively ignore it for now...
Natural programming languages have been worked on for decades. It's not a new idea. Heck, i used AppleScript for ages and had their form of natural language support. But, unsurprisingly, they've never really taken off given that the sorts of problems you get with natural language are exactly the sorts of problems you do not want to have in when programming.
until this feature will be available in Jave and Python.
Can you point to the efforts by the java or python communities to add such features to their respective languages? That would likely help out here as that would then provide examples of the sorts of language specifications outlining how they think this could work. That would save you a lot of time and effort of having to figure all that out for C# :)
@NoamWhy I can guarantee you that this feature will never be implemented in C# or any other mainstream language. As such, my interest here is not to put you down, but to explain to you why the idea is not as attractive as it may seem at first, and in fact is pretty terrible idea.
I believe you're thinking about programming in the wrong way. You look at a line of C# code, see that it looks confusing, and say "Hey, this is really confusing, lets use natural language".
Languages like COBOL and AppleScript already allow you to use natural language. They are universally hated languages precisely for that reason!
The reason why they are hated, is because what's difficult about programming is not the syntax, it's not the symbols. It's that specifying a programme precisely to a computer is very difficult, whichever language you use. Natural language just means that on top of that you've got to type more words, and it's harder to see the structure of the programme at a glance.
You claim that
I believe such a feature will be highly welcomed by big organisations which have to manage massively large and complicated business logic.
On the contrary, if this feature was introduced, almost every single organisation would forbid it's use, especially large ones.
Large organisations want to be able to manage their large and complicated business logic. To do that, they don't want developers wasting time understanding what every line of code means. They want exactly one syntax, which everybody uses, not to have everybody invent their own syntax.
If this expression was not defined, the compiler would show an error.
The expression is defined :) It's just hugely ambiguous. How do you anticipate your system being able to deal with this? Here's the general way it needs to be parsed for it to have a reasonable meaning:
The use of parenthesis eliminates all ambiguity. Can you provide me an expression with parenthesis whose parsing is ambiguous?
The use of parenthesis eliminates all ambiguity.
That's not even true in C# today :D
For example:
(Foo)-Bar
From the grammar itself, this could either be:
:)
and lead the natural language revolution, or alternatively ignore it for now...
Natural programming languages have been worked on for decades. It's not a new idea. Heck, i used AppleScript for ages and had their form of natural language support. But, unsurprisingly, they've never really taken off given that the sorts of problems you get with natural language are exactly the sorts of problems you do not want to have in when programming.
until this feature will be available in Jave and Python.
Can you point to the efforts by the java or python communities to add such features to their respective languages? That would likely help out here as that would then provide examples of the sorts of language specifications outlining how they think this could work. That would save you a lot of time and effort of having to figure all that out for C# :)
This would also turn C# into a follower rather then a leader. Come on guys, where is your spirit of creativity and innovation?
(You) certainly ((do) not) (speak (English)) (using (a lot of (parenthesis))), (do (you))? :)
This would also turn C# into a follower rather then a leader.
C# has constantly followed for most of it's lifetime. It initially started following Java (which was hte basis of much of the language and the runtime system), and then moved on from them.
Over its lifetime, it has taken great ideas pioneered in many other languages, and incorporated them pragmatically into the core of it. For example, lambdas predated C# by decades. Generics have been studied and implemented elsewhere for ages. List comprehensions are super common in functional languages. Pattern matching is available in many other languages. Dynamic programming as well. Tuples as well. Asynchronous programming was pushed heavily by other systems (esp. F#). And so on and so forth.
The value in C# is the effective way it pragmatically marries many valuable features together, while trying to avoid many of hte problems and mistakes that came before it. It often does this well. It sometimes does not :)
Come on guys, where is your spirit of creativity and innovation?
Adding features for the sake of 'creativity' or 'innovation' is not a driving force for C#. It's not a research vehicle. it's intended to help people solve problems over a huge number of domains.
--
Now, as i said above, i'm not against this idea. But it's simply underspecified and incomplete currently. It's equivalent to coming in and saying: wouldn't it be great if i could just switch over time python half-way through my C# code, then switch to F#, then switch to C++ and have that all work?! It would be amazing.
As the great Ian Malcolm said:
:)
(You) certainly ((do) not) (speak (English)) (using (a lot of (parenthesis))), (do (you))? :)
Come on, don't be such short sighted, think big. In the next version of the implementation, we could integrate machine learning to teach it how to place parenthesis. And if an ambiguity emerges, the computer will point that out to you and you will work out this thing together.
Not to mention there may be multiple aliases for one construct in one code base. Just imagine running into a code base where "x++", "take the value and then increment (x)", "take (x) and then increment it" and "自增 (x) 然后返回原值" mean the same thing.
Not to mention there may be multiple aliases for one construct in one code base. Just imagine running into a code base where "x++", "take the value and then increment (x)", "take (x) and then increment it" and "自增 (x) 然后返回原值" mean the same thing.
I get it, there are challenges, but this does not mean we have to give up on natural language altogether.
This would also turn C# into a follower rather then a leader.
C# has constantly followed for most of it's lifetime. It initially started following Java (which was hte basis of much of the language and the runtime system).
Over its lifetime, it has taken great ideas pioneered in many other languages, and incorporated them pragmatically into the core of it. For example, lambdas predated C# by decades. Generics have been studied and implemented elsewhere for ages. List comprehensions are super common in functional languages. Pattern matching is available in many other languages. Dynamic programming as well. Tuples as well. Asynchronous programming was pushed heavily by other systems (esp. F#). And so on and so forth.
:)
The value in C# is the effective way it pragmatically marries many valuable features together, while trying to avoid many of hte problems and mistakes that came before it. It often does this well. It sometimes does not :)
Come on guys, where is your spirit of creativity and innovation?
Adding features for the sake of 'creativity' or 'innovation' is not a driving force for C#. It's not a research vehicle. it's intended to help people solve problems over a huge number of domains.
--
Now, as i said above, i'm not against this idea. But it's simply underspecified and incomplete currently. It's equivalent to coming in and saying: wouldn't it be great if i could just switch over time python half-way through my C# code, then switch to F#, then switch to C++ and have that all work?! It would be amazing.
As the great Ian Malcolm said:
:)
Now I understand why C# has such a small users base compared to Java and Python. This is so sad...
And if an ambiguity emerges, the computer will point that out to you and you will work out this thing together
The point is: In natural languages, there is ambiguity everywhere. That's the problem. That's why people don't use them for programming languages. Because now it gets super hard to actually ensure that you even understand what you're saying to the computer.
We could integrate machine learning to teach it how to place parenthesis.
And what happens if we then reteach the machine learning, and it changes its mind, and now existing programs change meaning?
--
Think about it this way: if natural language understanding was easy, we would have computers understanding people already and it would be trivial to get them to perform tasks for us. As it is, i can only command my computer to do the most trivial sort of things. And then things break down almost immediately the moment i want to do something slightly complex. This is true whether working with speech, or written text.
Think about Cortana. It has probably millions of man hours poured into it. Can i get it to do more than the most basic tasks? Can i get it to even perform a basic understanding of natural language? Nope. And that's with tons of incredibly smart minds trying to actually get it to handle htat.
Terms like 'machine learning' aren't silver bullets that just solve problems for you. They're incredibly fuzzy tools for very fuzzy problems. But, as has been mentioned above, you do not want that sort of fuzzyness for programming languages. That goes against a primary goal of ensuring that the computer is actually performing the task i want, and that i can tell that it is doing that :)
Come on, don't be such short sighted, think big.
Ok. I have a bigger thought. I should just be able to say to the computer the problem i want it to solve, and it should solve it for me. For example, i should be able to just say somethign like:
"Computer, write me a programming language that accepts natural language input and figures out what it means" and it should then take that and do the right thing :)
I get it, there are challenges, but this does not mean we have to give up on natural language altogether.
The onus is on you to demonstrate why this would be valuable and how you would actually address these significant concerns. :)
Now I understand why C# has such a small users base compared to Java and Python.
Neither Java nor Python support these features. So i cannot fathom why you think the absence of natural language support matters here... :)
Cyrus, I am listening to what you are saying, and all I hear is "this is impossible" "this is difficult" "I have no idea how to do that".
To this I say - Yep! You are right! Yet, I invite you all to stop filling this page with "No we can't" stuff (this is easy and boring, anyone can do that), and to start presenting your brilliant innovative side, and have a positive "Yes we can" discussion on how we might over come these difficulties together. This will be so much more interesting to read (even if we eventually fail).
@NoamWhy
You are suggesting a feature which a) has very little positive value b) has a lot of negative value c) is extremely difficult to do well d) would require vast resources to implement
You have not even provided a speciation, and you are wondering why the csharp team, which is extremely busy, is not planning to investigate it?
I would say that implementing it as an IDE feature targeting multiple programming languages would be a way better idea.
This way, user can configure what becomes what easily without having to worry about multiple aliases. Undefined and ambiguous constructs simply throws an error. And everything is saved in the form of the target language. Basically, a natural language like programming language that transpiles between other programming languages. It requires experienced programmers to define those natural language aliases for ALL possible constructs in a language, though.
Not everything should become a feature of a language, especially when that language has already existed for years, you know.
and have a positive "Yes we can" discussion on how we might over come these difficulties together.
My position is not that we can't do this. It's that we shouldn't do this. The very nature of natural languages makes them highly unsuitable to the domains where we want computers to work.
Natural languages are full of ambiguity and interpretations. That's not waht you want in a programming language. And, if you solve the issue by removing the ambiguity... you know what you end up with? A programming language :D
this is easy and boring, anyone can do that. start presenting your brilliant innovative side...
Alright, let's actually attempt this, and let's try to solve the first problem we encounter. Precedence and associativity.
Say i have the following "foo bar baz". How should the system figure out what that means. Is it equivalent to foo(bar(baz))
? is it (foo bar)(baz)
? is it (foo) bar (baz)
? Is 'bar' an binary operator between 'foo' and 'baz'? Is 'foo' a unary operator applied to the rest? What process is used to even go about figuring out what this should become and how it should translate?
Say i have the following "foo bar baz". How should the system...
First I am glad you have shifted gear in to "Let's think about it". Second, my original proposal suggests the use of parenthesis to prevent ambiguity. So you would have to write either: foo(bar(baz)), or: (foo bar)(baz), or: (foo) bar (baz). The compiler would simply look for definition of such a pattern, and if it doesn't find any, or finds too many, it issues an error. Done.
So you would have to write either: foo(bar(baz))
So how is that an improvement on C#? :)
The compiler would simply look for definition of such a pattern
how does it do that? how would you define your patterns such that teh compiler would even know how to consider them? You say 'simply', but you've also indicated that is a large and complex problem that would need adequate funding :D
and if it doesn't find any, or finds too many, it issues an error. Done.
You make this sound as if it would be extremely simple. Would you be willing ot create a PR showing how to do this? :)
If it really is just a matter of the compiler looking for patterns and then just trying to find the right one, then it hsould be able to demonstrate this working pretty simply. It would also then allow people to see examples of how a 'natural language' .net app would look like. Would you be willing to go do that and come back in a day or so to show the results?
Note: wrt to the example, you don't even have to do anythign complex. Just use an existing parser generator system (like antlr or any of the numerous parser generators out there) and write a system that takes your rules, and generates parser rules that a parser is then generated from. That parser can then just spit out hte C# code you want.
It would help the conversation out a lot as right now many things are far too vague, and when trying to get more details the response is simply "the compiler will handle it". But this is rather unsatisfying in terms of discussion, because i'm trying to find out how the compiler would do such a thing. If you can provide a proof of concept that would help clear things up and avoid this communication ambiguity :)
Would you be willing to go do that and come back in a day or so to show the results?
Sure, but to make it more effective, give me a small piece of code that you would like to see in natural language. I will then work out a specification how this should be done.
A good example we generally use is something like the C# parser itself: https://github.com/dotnet/roslyn/blob/master/src/Compilers/CSharp/Portable/Parser/LanguageParser.cs
I'd be super interested to see what that would look like, in an unambiguous form, in natural language form.
Another approach that can help here is to use the Roslyn API itself to parse this file. You'll then have hte actual parse tree in memory that Roslyn creates. You can then walk that and spit out a natural language form for people to look at.
I'd be super interested to see what that would look like...
Now you are talking 👍 Give me a day or two, I'll see what I can do.
Here's a walkthrough on getting started with Roslyn: https://docs.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/get-started/syntax-analysis
Also, you can use Roslyn Quoter: https://roslynquoter.azurewebsites.net/ to go from C# to a full in-memory tree. For example, here's just the constructor of that type:
Consider this example:
using System;
using System.IO;
using System.Net;
using System.Text;
using "let (x) be (y)" = var x = y;
using "set (x) to (y)" = x=y;
using "a new web request from URL (string X)" = WebRequest.Create (X);
using "the UTF8 bytes encoding of (string x)" = Encoding.UTF8.GetBytes(x);
using "set the request method of (x) to (y)" = x.Method = y;
using "set the content type of (WebRequest x) to (string y)" = x.ContentType = y;
using "set the content length of (WebRequest x) to (string y)" = x.ContentLength = y;
using "the length of (x)" = x.length;
using "the reqest stream of (WebRequest x)" = x.GetRequestStream();
using "the response stream of (WebResponse x)" = x.GetResponseStream();
using "write to (Stream x) all the bytes in (bytes[] b)" = x.Write(b, 0, b.Length);
using "close (Stream x)" = x.Close();
using "the responce from (WebRequest x)" = x.GetResponse();
using "a new stream reader from (stream x)" = new StreamReader(x);
using "the whole string in (StreamReader x)" = x.ReadToEnd();
namespace Examples.System.Net
{
public class WebRequestPostExample
{
public static void Main_Natural ()
{
let (web_request) be (a new web request from URL ("http://www.microsoft.com"));
set the request method of (web_request) to ("POST");
let (posted_data) be ("This is a test that posts this string to a Web server.");
let (posted_bytes) be (the UTF8 bytes encoding of (posted_data));
set the content type of (web_request) to ("application/x-www-form-urlencoded");
set the content length of (web_request) to (the length of (posted_bytes));
let (data_stream) be (the reqest stream of (web_request));
write to (data_stream) all the bytes in (posted_bytes)
close (data_stream);
let (web_response) be (the responce from (web_request));
set (data_stream) to (the response stream of (web_response));
let (stream_reader) be (a new stream reader from (data_stream));
let (server_response) be (the whole string in (stream_reader));
close (stream_reader);
close (data_stream );
close (web_response );
}
public static void Main_Formal ()
{
var request = WebRequest.Create ("http://www.contoso.com/PostAccepter.aspx ");
request.Method = "POST";
var postData = "This is a test that posts this string to a Web server.";
var byteArray = Encoding.UTF8.GetBytes (postData);
request.ContentType = "application/x-www-form-urlencoded";
request.ContentLength = byteArray.Length;
var dataStream = request.GetRequestStream ();
dataStream.Write (byteArray, 0, byteArray.Length);
dataStream.Close ();
var response = request.GetResponse ();
dataStream = response.GetResponseStream ();
var reader = new StreamReader (dataStream);
var responseFromServer = reader.ReadToEnd ();
reader.Close ();
dataStream.Close ();
response.Close ();
}
}
}
@NoamWhy,
That is an excellent example … that highlights why I don't think this a good idea. When reading your "natural language" version, I had to keep referring to the aliases to work out what the code actually did. It's wordy and hides the actual code. Plus you have had to define a new alias for almost every line of code, save for variable declarations. So it doubles the code size and obfuscates what the code does.
To understand what happens when people try to use natural language to describe things in a precise and unambiguous fashion, have a read of a typical end user agreement and other legal document. They are impenetrable to all but legal experts. And they are extremely verbose. Programming languages are actually easier to learn to read and write and are far more succinct. Which is why we use symbolic notations in all modern languages, rather than eg COBOL , which is probably the nearest we ever got to trying to use natural language.
@NoamWhy It really appears that the thing you want is not specific to the C# language and I'm a little confused why it's proposed here. There are other languages that are better-positioned for creating custom DSLs. An example of such a .NET language is Boo.
@DavidArno
Agreed. Most of the aliases wouldn't really be that reusable, and combining them in any meaningful way would likely result in gobbledygook. That would result in writing aliases over the aliases just to make them read properly.
English is an awfully nuanced language where context and intonation can completely change the meaning of a word or a sentence. Much of that context is culturally dependent yet many development teams are multi-cultural. Those little subtleties could easily be lost or misinterpreted. In short, most "natural language", and especially English, would make for exceptionally awful programming languages.
@NoamWhy I'm starting to think that you're trolling us 😝
In all serious though, there's a very good reason that programming languages were not modelled on human speech: a new and better language for giving instructions, writing recipes or describing calculations was simply necessary. After all, look at mathematics:
With a bit of learning
x⁴ = x
is much easier to understand and quicker to read than
There exists a number that, when multiplied by itself three more times, will produce a result equal to the original number
Having said that, there is some place for natural language somewhere. I suggest you take a look at projects like Cucumber or Specflow which are used for specifying tests:
[Given("A a url (.*)")]
void GivenAUrl(string url)
{
....
}
[When("I make a (.*) request to the url")]
void GivenAWebRequestToUrl(string method)
{
....
}
[Then("I get a response with status (.*) and content (.*)")]
void GivenAWebRequestToUrl(int statusCode, string content)
{
....
}
You can then have a .feature
file containing the following:
Given a url "http://github.com"
When I make a GET request to the url
Then I get a response with status 200 and content "Some content"
Natural Aliases
Consider the following simple function:
To use this function anywhere in our code, we may write:
var z = Add(x,y);
Now, imagine we could write the following statement:
using "the sum of (x) and (y)" = Add(x,y);
Where such a statement simply indicates to the compiler that wherever it sees a pattern of the form "the sum of (x) and (y)", it should translate it to Add(x,y).
This would then allow us to write:
var z = the sum of (x) and (y);
we may further define:
using "let (x) be (y)" = var x=y;
And then write:
let (z) be (the sum of (x) and (y));
Our code now is plain natural English, and can be read and understood by anyone.
Surely, developers could still be free to type the shorter formal version "Add(x,y)", and have the editor automatically suggest/replace that with the natural representation, if they want to. Also, the editor would allow developers to easily toggle between formal and natural representations of the code.
There is no fear of any conflict between the formal C# grammar and the natural one, since prior to parsing the code as formal C#, the compiler first tries to translate any statement from natural to formal, and only then compiles the result as formal C#.
Here is another cool example. Suppose we have a class called Account, which allows us to write:
var A = new Account (UserName, UserPass);
Using natural aliases, we can define:
using "a newly created account with username (UN) and password (PS)" = new Account(UN,PS);
This would then allow us to write:
let (A) be (a newly created account with username (UN) and password (PS));
This is 100% natural language, and the code is crystal clear to anyone who can read English. And for those who prefer, say Spanish, we can define (using google translate) a Spanish version, as follows:
using "establecer (x) para ser (y)" = var x=y;
using "una cuenta recién creada con nombre de usuario (UN) y contraseña (PS)" = new Account(UN,PS);
And BOOM! Our code now speaks natural Spanish:
establecer (A) para ser (una cuenta recién creada con nombre de usuario (UN) y contraseña (Pass));
How cool is that!!!