Programming in plain English: https://osmosianplainenglishprogramming.blog/

In the article, it is answered "yes" to the question "can natural languages be parsed in a relatively “sloppy” manner?". But I wonder what are the edge cases, and if this "sloppy" parsing can lead to errors that are very subtle to debug where a formal syntax might have help to better grasp what is happening.

I like this. I’m very unlikely to use it anytime soon, but seeing those programs expressed in a more clear and succinct way breaks a lot of my intuition about this topic.

Very thought-provoking, thanks!

I tried to download "The Prototype" file (www.osmosian.com/cal-4700.zip) from this blogpost, but Windows antivirus said this file contained a trojan. Update: now it downloads without any warning.

Wow, this is super cool! I bet @Steve would be interested

@Chet Corcos very much so! Very long read 🤣 but a scroll through suggests that it’s more about visual design and drawing than business logic is is very much more my interest. Each domain has quite different requirements and constraints.

Well they built a compiler with it as well as a WYSIWYG text editor and a filesystem browser... so it much be pretty flexible.

@ibdknox If I may be candid: I don’t understand why you would apply NLP like this to drawing… strange result to use when art is is not language.

I get what you mean -- this is definitely a different use-case and lacks a lot of the usability stuff that I think you're going for. But that said, its always good to have a solid foundation...

If this “plain english programming” is compiled than it will have the same limitations as the other hundreds of languages before it: you have to represent the entire programs state in text.

Hmm. I think I see what you mean.

I think this is where Eve also failed: being compiled and to broad of scope.

Interested to hear more on your thinking behind "if it’s “compiled” than the foundation is flawed by design."

Let’s DM

Are you saying, drop everything and write AGI?

The world is not black and white. I order things on Amazon but they still need to be built by real people in a factory. Drop everything? Heck no! But creating software still remains out of reach for most the worlds population.

Ok, “state” was the wrong word to choose. Maybe “the source of truth” is better. Same issue: plain-text compilation requires that the full truth is represented in the plain text which has significant limitations.

It's exactly how we talk to anyone that requires step by step instructions. A chef teaching a new line cook, an art teacher walking you through how to paint your first watercolor sky...

“Language itself is exceedingly general” is this not the problem of Eve? Why be general when you can be more pragmatic to scope to a domain. For example (not to plug it again, but it’s good example) Storyscript is not for gaming or drawing. It’s for business-logic QA and workflows. That scope makes our “language” (which it’s not really) can be designed differently.

It makes your language easier to design and easier to be business-wise successful, but it's not somehow fundamentally better. Generality isn't a problem to be solved, it's a thing to strive for. Language, math, art, kinesthetics, and so on are ridiculously general and have taken us from quite literally nothing to the civilization we have now. Narrower things fill in the details, but they don't expand the canvas. So no. I don't see generality as "the problem of Eve." 🙂

I admit that my perspective of Eve is my own. Regardless, the demos shows how to make frontend and games which are domains that have better tools to achieve these problems, not to mention they are quite different (especially the users). I do think it was the lack of focus and to broad of scope.

It's sad that we see Python and Excel withering away in their generality 😛

I mostly agree too.

It might be worth actually reading the article rather than skimming it. It's presenting a different perspective on how english might be a better python than python is.

It seems like the conversation in thread might be talking about several different (and mostly orthogonal!) things at once. How general a language's capabilities are, what it's input methods are, and even where on the spectrum of implicitness (draw an eye) to explicitness (start an arc at X100Y50, ...) it falls are all completely separable decisions.

☝️ that is what the new thing we're working on is trying to cover: how do you create an environment that lets you seamlessly flow between high level implicit statements to low-level explicit refinement?

With previous Eves you’ve published reading lists of related tech. Do you have a reading list for this one yet? Holes and project templates are the extent of what I’ve seen for being able to refine software into existence.

In the programming world, Self and the Alternate Reality Toolkit are the closest things I know of. Entity Component System engines are related as well. As Ivan mentioned in another thread, 3d software definitely has this feel and there are lots of games to really dive into: Minecraft, Factorio, Dreams, Little Big Planet, etc.

I have to say I'm impressed with how well this natural language system appears to work. I share some of the earlier concerns in this thread that it might be very difficult to tell what's going on when things aren't working as intended— not just in terms of how the syntax is being parsed, but what the compiler and resultant program are actually doing. The most difficult part of programming— mental simulation of invisible processes— is not really fixed by making the program into plain English. I'd hypothesize that an unambiguous notation is actually an aid to mental simulation, not a hindrance (it removes some guessing/degrees of freedom about what the computer might be thinking). Of course the use of a symbolic notation itself requires more complex mental simulation (i.e. of a parser/lexer/compiler), and this "bootstrapping problem" adds yet another layer of difficulty that makes even getting started with programming so hard for many beginners. But I think it's a big fallacy to think that removing this initial barrier is what will open up programming. It's just the first hurdle; after that comes a lifetime of mentally emulating every program you work with. It's my thesis that the future of programming will not come about until the need for mental simulation is largely removed. But this is a really interesting and unexpected peek into perhaps another, new niche of programming.

Thanks, Chris!

@Steve @ibdknox One problem with "Programming in plain English" is the exceptions problem. This is just not solvable unless you can solve the exceptions problem. Ripple Down Rules explains the problem, and describes a good human solution. The issues relates to rules. Rules typically have exceptions. This was made clear by some guy trying to create an expert system in a hospital. Experts would come to him with new rules for the expert system. He would code them in. Then they would come with a new rule than was an exception to the old rule. And so he invented Ripple Down Rules. This is a problem for coding, because, you need to uncover the exceptions. When given a text description of a problem, a lot of what a programmer does is look for the exceptions to the rule, the edge cases. Then they make a judgement call of if to include code that handles the exception or not. If you look at a program, sometimes it is mostly exceptions. It required a human to extract all the exceptions and then code them. Until a computer can work through a text description of a problem, and some how uncover the exceptions, I don't think we will see this kind of thing working.

@alltom There is ambiguity in English, so certainly! The compiler will make some choice in the face of ambiguity (including possibly to error; I don't know what this system does), but the human will still be faced with the problem of predicting what disambiguating choice the computer will make. It seems like the compiler is doing a sort of "fuzzy match" (?), so not being an AGI, it will certainly not guess correctly what the programmer meant in all cases. So when that happens, the human will be tasked with figuring out what the computer thought they meant.

@tbabb I though we had good solutions to the ambiguity in English problem already. Systems like https://donotpay.com/ can already handle ambiguity. I have not tested one, but I understand they do work successfully.

@Eddy Parkinson English (and pretty much all spoken language) is known to not be unambiguously parseable. Ex: "The boy lured the duck with a loaf of bread." Who had the bread, the boy or the duck? We humans know from world knowledge about ducks and loaves and animal behavior that one interpretation is more likely to be true; but either interpretation is a valid grammatical parsing. You basically couldn't solve this kind of problem in general without having a fully world-educated AGI. Even then, we can construct grammatical sentences that intelligent humans can't disambiguate with more information.

In PEP, you'd write one of those parses as

Put 3 into the variable

and the other as something like (guessing)

Find a variable with the value 3

. I don't think its goal is to let you write whatever you want, just to ensure you don't ever have to write

var = 3

or

variables.select { |v| v == 3 }

.

a.foo()

is ambiguous in JavaScript, and we've put a lot of engineering effort into being able to tell you which

foo

it will be. PEP seems simple enough that you could probably do it easily, maybe statically.

What would happen if the programmer wrote the sentence that I did?

In PEP, I dunno. I don’t have Windows. :( In mine, you’d have an ordered list of likely parses to choose from.

love this in particular:

>>Note that formal names (proper nouns) are not required for parameters and variables. This, we believe, is a major insight. A real-world chair or table is never (in normal conversation) called “c” or “myTable” — we refer to such things simply as “the chair” or “the table”. Likewise here: “the vertex” and “the polygon” are the most natural names for these variables.

I see the trick with articles and pronouns is to have interactive disambiguation, else you end up with the most nuanced scope and shadowing problems. (In one of my silly lisp phases I had

(the whatever)

,

it

,

him

, and

her

. The last two were bound when you used comparison operators, like, I don't know

(def (min-f f x y) (if (< (f x) (f y)) him her))

. So this returns the minium of

(f x)

and

(f y)

.

I really liked Chris's comment "We just want to make an environment that we actually want to live in". I actually think that before we think of making our tools for others, we have to make sure we love them ourselves! If we do that then we have already succeeded!

@tbabb said:

The most difficult part of programming— mental simulation of invisible processes— is not really fixed by making the program into plain English. I'd hypothesize that an unambiguous notation is actually an aid to mental simulation, not a hindrance (it removes some guessing/degrees of freedom about what the computer might be thinking).

I totally agree. With ambiguous systems based on natural language programming, there is a new source of complexity: for some task it can be tricky to find/guess the sentence that will make the compiler produce the behavior that you want. And maybe one compiler will "choose" one behavior that will be different than the one chosen by an other compiler. We only have this kind of problem with "unambiguous" languages where some compilers/interpreters behave differently on some parts of some standard (like C or JavaScript).

I think that's true to an extent. I occasionally "resort" to mathematical style notation when English is getting clumsy - i.e. added brackets or using set notation. This is most common in reading legalese. I genuinely believe laws would be more approachable if written in pseudo-code. I think this is rare though. Natural language is normally unambiguous. It's more common to see, for example, natural language comments elucidating a piece of code. These two sentences convey essentially exactly the same semantic information; 1. Copy the value of the 'eax' register into the 'eab' register 2. mov ebx eax But #1 is much easier to understand. There's no reason that assembly code should necessarily be written like #2 and not like #1

@tbabb looks like my comment was too ambiguous 🙂 ... donotpay solves the ambiguously problem by having a conversation. It asks you questions to resolve ambiguously. ... I am not sure how else you could do it, because, as you say, many English statements are ambiguous. donotpay uses the IBM Watson software - there are quite a few podcasts about it https://www.listennotes.com/podcasts/415-stories/e7-joshua-browder-of-DL2dXgmfvPr/