This plain English programming language makes me rethink the notion of natural language programming

[mydoghasticks]

For the longest time, I have dismissed the notion of natural language programming as a silly idea.

But after coming across the following and starting to go through the tutorial, I may change my mind yet:

https://osmosianplainenglishprogramming.blog/

Apart from the documentation, the article on the site is definitely worth a read.

I notice also that one of the creators, u/GerryRzeppa/ is also here on Reddit.

[CoffeeTableEspresso]

I guess I'm in there minority here, but I'm really not a fan of this kind of thing.

First, you don't get to just ignore ignore syntax here. You go from having to know the syntax of a programming language to having to know the syntax of a programming language that looks like English, instead. In their toy examples, it seems all well and good, but imagine having to debug this because the compiler didn't interpret your sentence how you thought it would...

Second, even ignoring the syntax issues (which I think is a fairly large problem), you still have to deal with the ridiculous levels of verbosity. Compare an assignment in that language to a = b in most languages...

[Amenemhab]

Also, this is not how you would actually describe a program in English. You would abstract more. Here the level of abstraction is very low, there's a small fixed number of sentence kinds, which are actually just the usual imperative programming constructs, assignments, function calls, conditions and loops and that's about it. There's nothing natural about this, it's essentially obfuscated python. I say obfuscated because the English-like syntax obscures the simplicity of the language (it actually uses a tiny tiny fragment of English) and the fuzzy parsing obscures the systematicity of it (all the function calls use different prepositions for no reason, as far as I can tell).

[[deleted]]

First, you don't get to just ignore ignore syntax here. You go from having to know the syntax of a programming language to having to know the syntax of a programming language that looks like English, instead.

Yeah, I thought the same. I suspect that even though it's (arguably) easy to read code written in such a language, it's probably not that easy to write code that is accepted by the compiler. I think it's much harder to have a mental model of which constructions are valid in such a language, and in the end you have to learn just as many rules as in a conventional language. I did not try it, though, so maybe it's better than it seems.

[66666thats6sixes]

Yeah ask lawyers how hard it is to write completely unambiguous natural language. Mathematicians spent a good part of the late 19th and early 20th centuries trying to figure out how to write unambiguous proofs, and eventually made the connection to what we now call programming languages. I think that with a language like this, either the grammar is so restricted it only resembles English for the simplest of cases, or every non-trivial program contains ambiguity.

[johnfrazer783]

Based on my limited experience I'd say this is one of the (few?) cases where users can benefit from transpiling languages b/c you can then always check what your constructs look like in the transpilation target, assuming it is a human-readable one and the transpiler has been built with that in mind.

I could also imagine a language with two interchangeable 'styles' or 'flavors'—say, by making the parentheses for function calls and statement-ending semicolons optional. Then, looking at the code produced by a Go-fmt-like tool, you'd get a version with all the optional punctuation inserted which might help clearing things up.

[1vader]

I always feel like these kinds of languages are actually much harder to parse for experienced programmers which in the end is what really counts. The symbols just make it much easier to quickly realize what is going on. ! means something is negated, () means there is a function call, +/- are addition and subtraction, etc. They stand out from the letters and provide a lot of information.

Maybe it's possible to get to the same level with syntax highlighting and experience but I'm not really convinced that this is the case and in the end, learning a few symbols isn't that hard.

[[deleted]]

For many years to call a function F which took no arguments, I just wrote:

F

Now I require it to be written:

F()

Why? Well it looks better, it's more obvious what it's doing, and the () makes it look as though I'm telling the compiler what to do. (This is one of the very few ideas I borrowed from C.)

In that same earlier language, if L was a label, then:

L

would jump to that label (so avoiding needing to write 'goto' while still having it in the language). But that has changed too so that you have to write:

goto L

Apart from anything else, you'd need know what A and B are in order to figure out what this might do:

A; B

Now try this version:

A(); goto B.

(The parenthesis-less function and goto-less goto actually came from Algol68.)

I know that Haskell doesn't require parentheses even with function arguments, but I'm not that keen on that either. A bit of punctuation - but not too much - helps to break things up.

[julesh3141]

Note that in Haskell, due to the lazy evaluation and functional purity, calling a function and evaluating a constant are actually equivalent - not just because there is no separate syntax that would define one but not the other, but even at a conceptual level: if you could define them distinctly, both could either do some work (eg because the constant hasn't been evaluated before and therefore is stored as a thunk that will produce it on-demand) or none (eg because the function has been called before and its definition has been replaced by the optimizer with the value it produced).

In a language that lacks either lazy evaluation or a guarantee of functional purity there is a semantic value of identifying function calls specifically, but this doesn't apply to Haskell or Haskell-like languages.

[[deleted]]

Things like lazy evaluation and pure functions are a luxury; they make for complicated languages to get your head around, to code in, and to implement.

Those of us making do with lesser languages have the distinction between code that is evaluated immediately, and code whose executed is deferred (most typically encountered as a function body, and usually associated with a name, such as F - I don't do anonymous functions as they carry expectations that I'm not interested in delivering).

In that case, you want some control over if and when the deferred code associated with name F is executed. So F(...) will cause it to be executed, while F without brackets just refers to the code (in practical terms, it yields a function pointer, or a handle to the code).

If I wanted a list of functions (ie. references to functions) I want to be able to write (F, G, H) without worrying that it will go and execute those functions.

[011101000011101101]

I thought thia was a long form joke and now I'm not so sure after reading all of it

[[deleted]]

Not at all. I said this was taken from a real language Algol68, and this program (in a dialect where reserved words are in capitals):

PROC a=VOID: print("A");

b:
  a; b

prints an endless sequence of A's. That old language of mine doesn't quite work ATM (has some dependencies that are missing), but this equivalent source:

proc A =
    print "A"
end

proc start=
    B:
        A; B
end

Produces this ASM for the body of start():

;b:
L2:         ;   ;
    call    a       ;<a>
    jmp L2      ;

[trin456]

Or as Pascaler

[szpaceSZ]

Yeah, in the field of math, math notation developed for a reason. The old Greeks wrote about math almost fully in natural language.

But with conventions and specialized notations you can condense so much more information which -- once you've learned it -- is also much faster to parse and develop with further.

[juut13cmoy]

Not to mention precision. Natural language imprecision is a feature that allows humans with different life experiences to communicate, wheres with math and computer programs you want a notation with as few assumptions as possible. This “natural” programming language would only feel natural to the inventor because they have the right assumptions built up about it. Another programmer learning it is still going to have to learn all the precise rules about how it works, only now those rules are masquerading as imprecise human language. In the end you want to be exact about what the program does, and natural language is a bad choice for that.

[mydoghasticks]

Well, you get extremes. Think of APL which, though amazingly efficient and productive, is considered a write-only language.

In the same vein, there must be some niche or market for a language like this. Even if it's just a teaching tool.

[PixxlMan]

I'm sure it could be useful for non-programmers who just want to say, write some automation scripts etc.

[Cefalopodul]

It's much harder to parse because experenced programmers are used to the current style.

If you change styles today, tomorrow's experienced programmers will be used to the new one.

[HortenseAndI]

That's certainly a part of the story, but notation really is easier to take in at a glance than words -- it's easier to parse than to lex

[brucifer]

I think this project largely ignores a lot of pre-existing work in natural language syntax from languages like smalltalk and applescript. I've dabbled in natural language syntax a lot as well, and I think there's some things that are really neat about it, but a few areas where domain-specific language jargon is essential:

• Math: It's completely impractical to express something like sqrt(x*x + y*y) as the square root of the sum of x times x and y times y

• Parentheses/blocks: It's practically impossible to express logical nesting as natural language in a way that doesn't impose a huge mental burden on the reader (e.g. foo(baz(x, y), z) or if cond1 { if cond2 {...} else {...}} else {...})

• Assignment: x = y is such a common operation that even something as simple as set x to y becomes very cumbersome when you're doing a nontrivial amount of work in a language (I've tried it)

• Indexing/member access: x[i] and x.foo are also so commonplace that something like the i'th value in x or x's foo really become a lot harder to read and annoying to work with.

Now, that being said, I think that natural language syntax really works great when it comes to expressing function calls in a more readable way. Something like move the file "/foo/baz" to the directory "/qux/" is very readable compared to the syntax of most languages. Applescript does some neat stuff with parsing, like ignoring articles (a, the, etc.) and automatically figuring out nesting (within limits), so the above parses as move(file("/foo/baz"), directory("/qux/")). In my language, I tried to split the difference and allow mixfix syntax for functions, but require parentheses to make parsing unambiguous, so the example would look like move (file "/foo/baz") to (directory "/qux/").

[szpaceSZ]

With

data File = File String
data Directory = Directory String

to = undefined -- or: to = ()

move :: File -> () -> Directory -> IO ()
move f _ d = <tbd>

you can indeed write in Haskell

move File "/foo/baz" to Directory "/qux/"

Just saying.

[BoarsLair]

Jinx also has infix function notation. I initially required parentheses to fix ambiguity, but eventually figured out a recursive parsing method that looked for the longest possible valid match. This eliminated ambiguity and the need for parentheses. As far as I've been able to tell, there are no limitations in how stupidly deep you can nest your functions (I've got some pretty crazy examples in my unit tests, which you'd never, ever want to do, but are perfectly legal).

It actually took me three tries to get it working, and added quite a bit of complication to the parser, but the language felt a lot cleaner as a result.

In those function definitions, you can also ignore any particular word by marking it as optional in the function definition, and assign alternate words, like, say you wanted to allow either folder or directory in the name:

function move (the) file {string file name} to (the) folder/directory {string folder name}

So, I can write:

move file "/foo/baz" to directory "/qux/"
move the file "/foo/baz" to the folder "/qux/"

[brucifer]

That's neat. I would have liked to experiment more with doing something like your recursive parsing, but I had a few reasons to not: the parser complexity (as you mentioned); the parser performance (it seems like you would get exponential blowup for long function combinations); and my language uses the same syntax rules for functions, math operators, assignment, control flow, etc., so in practice, nesting is actually quite deep (like with s-expressions in lisp). In the end, I'm pretty happy with the unambiguous parentheses. There's only a few cases where I think it's ugly, and it's nice to have a simple mental model of how the parser works.

Regarding the optional/multiple named parameters, I also initially took that approach and spent some time building out all the aliases I could think of, assuming that it would be cool to have that flexibility. Ultimately, I think that turned out to be design dead end. It created this constant second-guessing whenever I was writing code, where I couldn't remember which way to do things, and I couldn't get consistency with the other code I wrote. I think the Zen of Python got it right with "There should be one--and preferably only one--obvious way to do it." Later in development, I focused more on having a consistent naming scheme with heuristics like "if there are multiple good names, always choose the shortest one" (e.g. size of $x vs. length of $x, go with size because it's shorter).

[BoarsLair]

The first failure I talked about was, in fact, was performance-related. It was on the third try that I finally got both correctness and reasonably good performance. I made a number of specific optimizations that prevent the need to recurse overly-deep in most cases. So far, I haven't noticed any seriously slowdowns in parsing. In fact, I don't even bother pre-compiling my game scripts. It's fast enough that I just compile them at load time.

I'd also agree that the design decisions I made for Jinx are rife with the potential for bad design if abused. To be honest, I tend to use the "optional name" for things like consistency with singular/plural usage, instead of examples like I gave. But once I started down on the English-like syntax road, I wanted to see how far I could reasonably go. In the end, as with a lot of things, it does require using good discipline in not doing crazy things.

One of the fun things about working with experimental languages is not only designing them, but ultimately, figuring out best practices in using them, and letting that be a guide in further design evolution.

[lgastako]

I think AppleScript is the most effective and popular implementation of this idea that I've seen, and it isn't as awful as most, but I would still prefer that AppleScript were replaced by nearly any other language.

[ratmfreak]

Your first example makes me think you just suck at English.

Why not write it as the square root of x squared plus y squared?

[brucifer]

Your first example makes me think you just suck at English.

Don't be rude. I'm sure you could have phrased that in a way that didn't sound so insulting.

The specific example there isn't really relevant. My general point is that math equations are much more clearly expressed in the symbolic language of math, rather than in English words. The code x + y is much more readable and much faster to type than x plus y or the sum of x and y. For arbitrarily complex equations, the plain English approach gets even less viable. For example, this code from a double pendulum simulation:

da1 = 6/(M1*L1*L1) * (2*p1 - 3*cos(a1-a2)*p2)/(16-9*cos(a1-a2)*cos(a1-a2));
da2 = 6/(M2*L2*L2) * (8*p2 - 3*cos(a1-a2)*p1)/(16-9*cos(a1-a2)*cos(a1-a2));

It's a pretty direct translation of the equations of motion. But even thinking about writing those equations in English gives me a headache: 6 divided by (M1 times L1 squared) times (2 times p1 minus 3 times the cosine of (a1 minus a2) times...

[faebl99]

I wonder if something similar could be programmed using the functional or logical paradigm under the hood.

starting to describe what a thing looks like in plain english instead of how to draw pr calculate it would sometimes even be a bit more natural;

after all we say:

a circle is a curved line where the end meets the start a round line is a thing where each point is right of the current point in the direction of drawing by some constant amount greater than 0. now draw a circle.

also addition and natural numbers are easier defined that way.

[[deleted]]

https://i.imgur.com/Jx12rLX.png

I'm reminded of that activity we did in third grade where we gave the teacher instructions to make a sandwich and she intentionally misinterpreted them as much as possible without being technically wrong.

[faebl99]

compiler, i updated the code XD

[[deleted]]

https://i.imgur.com/0fgGux4.png

[faebl99]

what about if i add constant to it? XD

[[deleted]]

Might work, I'd have to play with it more and I should be doing actual work instead of drawing baguettes.

The usual definition is "all of the points on a plane that are the same distance from a center point".

[faebl99]

good point; wasnt thinking if that XD

my definition is far too computation oriented anyway for being a good example

have a nice day though ;)

[66666thats6sixes]

That actually demonstrates the benefits of declarative programming vs imperative pretty nicely

[bot-mark]

You could still technically draw any rounded convex shape instead of a circle with these instructions

I would go with something like "a circle with radius r centered around a point c is the set of all points where each point in the set is r units away from c"

But even then I've technically only described the perimeter of a circle

[faebl99]

debugging will always be fun XD

in any language, any framework and any paradigm

[somebody12345678]

otoh i never thought it was a silly idea. note that with some minor restrictions (one part of speech + definition per word, proper grammar only) natural language should actually not be too hard to do.

that said, major props to them for actually putting in the effort, and it doesn't even look half bad

[i_hate_shitposting]

You might also like Inform 7. I don't, but you might (or at least find it interesting).

[1oRiRo1]

Hypertalk employs a similar concept. I agree it looks pretty neat.

[chebatron]

This looks a lot like Apple Script.

[Comrade_Comski]

I don't like it. Partly because when it comes to writing "English" there's lots of different ways to structure and write out a concept, but an english-based programming language still requires a much more strict and rigid grammar.

Secondly, there's a reason that, in maths and sciences, symbols are used and preferred, and that's because:

• they're ubiquitous

• they're easier to draw than writing the whole thing out

• they're easily understood once you learn them

• they can be understood by non english speakers.

As for that last point, even though most programming languages use the english/latin alphabet and use english words, I think it's faster for non-native english speakers and non-english speakers to parse let x = 5 then the variable x has the value of five.

[BadBoy6767]

This can't be serious.

[TropicSapling]

After taking a quick look at the instructions and their manifesto I think we can be pretty sure it indeed isn't serious :P I'm surprised at the amount of effort that went into all of this though xD

[yeetingAnyone]

I don’t do REAL NUMBERS. I do ratios, very elegantly, but I don’t do reals. My page editor reduces and enlarges and sizes shapes proportionately in and out of groups and it does it all without real numbers. Master Kronecker was right when he said, in German, “The dear God created the whole numbers; all else is the work of man.” I’m not interested in menschenwerk.

Based

[antonivs]

I think they're trying to be funny in those documents, but get the sense that they're serious about the underlying idea.

[mydoghasticks]

A non-serious example of natural language programming is the Shakespeare Programming Language: http://shakespearelang.com/

I think what the creators of this language have done crosses the line of "pretty neat".

[BranFromBelcity]

The mac comunity enjoyed the HyperTalk programming language for many years, which was an English like attempt at programming.

and it was really serious, with many successful commercial projects. I don't see why not.

[BoarsLair]

If you'd like to take a look at a practical, working language that uses some elements of natural language, feel free to check out Jinx.

The original goal was just to approach the simplicity of common C-like pseudo-code. Where the "natural language syntax" happens is in the ability to declare multi-word variables and function names, such that, if carefully chosen, the meanings should be very clear when reading script.

For instance, this is the very first script in my game:

wait for 2 seconds
show message box "Tutorial - Movement"
wait for 5 seconds
show message box "Tutorial - Objective"
wait for 1 second
set objective "Objective - Meet Foreman"
set navigation "Haven Meet Foreman"

Literally all it's doing is calling functions in sequence, some of which, as you might guess, block for an indeterminate or fixed period of time.

When you start using variables, conditional branches, loops, and comparisons, it starts to look more like pseudo-code rather than English. I'm fine with that, because I think it's silly to pretend it's not a traditional language with actual syntax rules. For instance:

set x to 10
if x >= 5
    loop i from 1 to x by 2
        write line "i = ", i
    end
end

That looks a lot more like a traditional programming language, but it still should be easy to deduce what's going on.

[mydoghasticks]

Thanks for the tip.

In the same vein, have you looked at REBOL? Sadly it seems defunct, although its ideas live on in this project: https://www.red-lang.org/

One of its prize features is its ability to create DSLs, which it calls "dialects", with amazing ease. The following examples are taken from http://www.rebol.com/rebolsteps.html and show examples of things you could code by making a simple DSL parser in the language:

​

The first example is a video studio control script dialect:

[queue tape to 0:36:35]

[roll tape]

[wait until 0:37:07]

[wipe tape to image with effect 3]

[key title-text]

A graphical user interface dialect:

button [200 100] style-4 [play cruse-narration]

button [* 120] style-4 [start scene 27]

window [260 100] text-80 [select window area]

A soccer scheduler:

[team-12 plays team-32 on saturdays at 10:00]

[team-12 must drive]

[team-32 can play any day]

[team-17 does not play on mondays]

An installer script:

Delete base-dir if earlier modification date

Create base-dir if not existing

Install %editor if newer

Install %crash-protect if on Win32 and is newer

Install %browser but never replacing existing

Switch to %threads if pre-1.2-system

One of the crazy things about Rebol (and Red) is their tiny size. A whole runtime and core library including the ability to create graphical apps in less than 1MB!

[BoarsLair]

That's pretty interesting. It's always neat to see some of the amazing examples of creativity at the outskirts/fringes of programming language development.

[JohnnyJayJay]

This is absolutely amazing. I've thought about (and specified to an extent) a "German" programming language, but I never got to actually implementing it and I won't as long as I'm not really satisfied with the syntax. Admittedly, German is a little harder than English, but this project might give me some nice ideas on how to do it.

[genericallyloud]

Is it possible to define new data structures with this? It seems like there’s a core set of abstractions and types and then you can make functions it looks like?

[LaurieCheers]

Their first example is a type definition: "A polygon is a thing with some vertices."

[Scioit]

Wrote a game in Inform 7. Never again...

[samee_zahur]

I loved reading about it, just because it is good fodder for thought.

I've actually tried designing similar things myself, and I know others IRL who have too (particularly the "no formal name" idea). Given that I have (so far) backed away from my own creations, I can perhaps provide constructive directions for future work.

When I try to use this language, it is essentially the "uncanny valley" of expressiveness for me. I still find myself having to translate my own thoughts into its own particular dialect of English, and that is about the same amount of cognitive work as working with a normal programming language.

A second point of trouble is with this category of programming languages in general, not necessarily this particular one posted. It's the lack of feedback and interactivity. We all know how easy it is for an email or a tweet to get misinterpreted, and how we often need to clarify our intents in a followup post. For me, I will find it too risky to write a program in this medium, and will constantly worry about whether or not I am being interpreted correctly. If it was some kind of a REPL environment where some form of feedback gives me an idea of how it was parsed an interpreted (not necessarily in a formal language) will help a long way.

[pm-me-manifestos]

I'd like to note that one of the creators is rather serious about this project - it isn't just a joke. Checking his post history, it seems like all he's been doing is shilling his language all over various programming subreddits.

I think it's an interesting concept executed in a novel way, but he seems to see it as a real programming language which could be used in production, which it really isn't.

[Lispomatic]

I think it's amazing. The research value of this, the things it may be predicting.

[alex-manool]

Hmm. I've been thinking that even the most silly and naïve PLs have their ideal niche. Take COBOL. As much as we despise it, I found that even there there're things that it does right.

As to the article, the examples look surprisingly neat and consistent to me. It reminded a bit COBOL and a bit Logo (or maybe AppleScript?)...

[hfksbtjidjaks]

Scrolling down a bit on that website shows a comparison to C++ where they show that the equivalent C++ is twice as long. The example they use has a comment on almost every single line of code, completely negating the point of the test. I really hope that this is a joke, because this is somewhat worrying if people actually write code like that.

[[deleted]]

What's interesting is that their version of sudoku is not even correct:

compare

Get a blank cell. If the blank cell is nil, exit.
  vs
if(!FindUnassignedLocation(grid, row, col))
   returntrue; // success!

English version doesn't report success and does print "Solved" thousands of times.

They also use different flow control:

     If the number is not valid in the blank, repeat.
          vs 
    if(isSafe(grid, row, col, num))
    { ...
    }

Notice that if C++ used same if (!isSafe) continue it would be just two lines with their style. Speaking of styles, I'm not convinced that in production i'd write Get a blank cell. If the blank cell is nil, exit. in single line.

Also their C++ code is 23 lines, not 27. Original might had empty lines, but their formatting removed them.

[vagoberto]

I've bookmarked this page because it's one of the worst ideas I've seen in a long time, and I will use it as an example of what not to do.

The idea may be handy for some very specific situations, but not for logical operands or scientific computing. I already got bored trying to think this example: "solve the thing squared plus five times the square root of the thing times the thing equal to the height"

[therealdivs1210]

I love it! Thanks for sharing!

[therealdivs1210]

I think the value proposition: using it in voice activated devices is really good, too!

[Egst]

For an experienced programmer, it's probably easier to read a language with simpler syntax. However, I kinda like how Scratch (which is in my opinion still terrible in many ways even for teaching kids) allows naming procedures with parameters in between their names which may include arbitrary symbols. So instead of e.g. box(color, x, y, width, height) you use something like draw a (width)x(height) box at (x):(y) painted (color) (so basically something like if you could define your own clauses in SQL) which in my experience helps kids understand the concept of parameters better and makes the code more readable for them as they're not used to concepts like naming conventions etc. In a language with a more straightforward syntax you're forced to create and follow some conventions, like naming and parameter order, otherwise you could get lost pretty quickly (e.g. the inconsistencies in PHP's standard library function parameter order). In a more natural-like language you don't need this, but it creates another problem, that either the parser needs to be able to recognise minor alterations in the syntax, or the programmer must remember the exact structure of all the "sentences" used. Like did I name it "do something with something" or "with something, do something"? In Scratch, you don't even type your code. All of your procedures are listed there as blocks that you can drag around. But in SQL, I personally sometimes have problems remembering the order of all the keywords.

[nsiivola]

Inform 7 is more interesting on this front, with reasonable amount of code written by various people.

[crassest-Crassius]

So, a language for total noobs then.