In an effort to understand computer workings, I dreamed up a fictitious machine that executes instructions. Here, the program writer simply writes out a recipe, a line of instructions, in plain English language. Like:

Recipe for Victoria sponge cake mix.

Line #1: Go to bowl number 3.
Line #2: Pick out an egg.
Line#3: Place the egg in bowl number 6.
Line#4: Go to bowl number 3.
Line#4: Pick out an egg.
Line~5: Place the egg in bowl number 6......

Of course, a human can read and execute this program.

In the fictitiuos machine, the operator feeds in the sheet of paper and it is read by the machine (OCR'ed).
I'm not sure how much I can appreciate by dreaming up this fictitious machine, maybe not much. But I have these questions:

#1 Would the lines written in plain English amount to source code and that is adequate? Why not?
#2 What kind of things would need to be done, or put in place, in order for a robotic arm to follow the instructions and produce a mix? (Say, Victoria spong cake). Thanks.

 

What are your thoughts on the subject?

 

Any language is adequate as long as you have interpreter or compiler for it.

But ...

One need to be mindful of needed resources. That is the key premise of any design.

Using machine oriented languages, one can do things with far less resources. A small MCU with just handful of bytes of memory could do the job. It can be powered by battery.

An alternative to that is an AI that runs on a much larger system, perhaps computer farm. Far greater demands on resources (Cpu,RAM, space, electricity) but it can understand and process instructions understood by average human.

 

It's called COBOL.

 

Complexity and capabilities of computational hardware can be described in different ways. One crude way is to simply count the number of logic elements.. gates. Or transistors.

System with 1000 elements is inferior to system with 1000000 elements. Size of the elements does not matter.
System with 1000 elements can be designed using elements of different size but complexity is still the same.

Early elements ( relays, tubes) ware huge... Thumb or fist sized.

Modern element are much much much smaller, allowing packaging huge number in small volume.

Btw, the same goes with brains. Some scientist ended taking brain tissue of different species, run it through blender, then count number of neurons. Size of neurons does not matter. The number of them does. Turs out that bird brains use rather small ones (and densely packed).

 

This is not new. The robot game ChipWits introduced in 1984 used natural language instructions such as:

move forward
turn right
look for bomb
zap bomb
flip coin

 

All programming languages are plain English (all of them are English, even though you might have expected Pascal to be French). It is just a stripped down version of English (more like George Orwell's Newspeak) using a small number of words, which is entirely in the imperative mood with occasional use of the conditional tense.

 

All programming languages are plain English (all of them are English, even though you might have expected Pascal to be French). It is just a stripped down version of English (more like George Orwell's Newspeak) using a small number of words, which is entirely in the imperative mood with occasional use of the conditional tense.

Good point. To the uninitiated, APL looks weird. But since it is an extensible language, it can easily be turned into readable code.

 

And then we have Forth. The 'write-only' programming language without syntax that writes itself and can be anything.

 

And then we have Forth. The 'write-only' programming language without syntax that writes itself and can be anything.

Correct. ChipWits was written in Forth.

 

And then we have Forth. The 'write-only' programming language without syntax that writes itself and can be anything.

The very few words Forth does have are English!

 

We have that, just ask ChatGPT, in Plain English to write a program for you.

 

Correct. ChipWits was written in Forth.

I still have critical motion controller software written in Forth using specialized Forth processors.
https://forum.allaboutcircuits.com/...s-that-are-still-running.132038/#post-1092256

 

The very few words Forth does have are English!

Piker English, Yes.

CAKE DUP HAVE EAT

Spoiler

 

#1 Would the lines written in plain English amount to source code and that is adequate? Why not?

If you used a structured variation of "plain English".

DEC wrote a database management system in the 1970's that used structured English as its language:
https://en.wikipedia.org/wiki/DATATRIEVE

 

In an effort to understand computer workings, I dreamed up a fictitious machine that executes instructions. Here, the program writer simply writes out a recipe, a line of instructions, in plain English language. Like:

Recipe for Victoria sponge cake mix.

Line #1: Go to bowl number 3.
Line #2: Pick out an egg.
Line#3: Place the egg in bowl number 6.
Line#4: Go to bowl number 3.
Line#4: Pick out an egg.
Line~5: Place the egg in bowl number 6......

Of course, a human can read and execute this program.

In the fictitiuos machine, the operator feeds in the sheet of paper and it is read by the machine (OCR'ed).
I'm not sure how much I can appreciate by dreaming up this fictitious machine, maybe not much. But I have these questions:

#1 Would the lines written in plain English amount to source code and that is adequate? Why not?
#2 What kind of things would need to be done, or put in place, in order for a robotic arm to follow the instructions and produce a mix? (Say, Victoria spong cake). Thanks.

This raises some interesting questions. My first reaction is to emphasize that programming languages have no ambiguities, the grammars never permit ambiguous statements to go unnoticed, they are not allowed. So any language that has that property (and human languages do not) can in principle serve as a programming language.

You can read about the Chomsky Hierarchy from a paper on algebraic linguistics here. Most programming languages are variants of Type 1.

As for physical machines, there was a fascinating robot project carried out in the late 60s named "Shakey" it was truly incredible. In that system the designers developed a system whereby the robot could plan how to achieve some physical goal. This worked by having a system that could prove whether some state was actually reachable from some other state by working backwards from the future state and if it was proven true, the proof was inverted and executed as a plan.

 

Synonymous Homonym to the rescue.

 

On thing, I probably should have said conversational English, rather than plain English, in the title question. I'll come back to this thread, but I'm going on a vacation for a few days and may not come back for a few days. There will be reasons why conversational English is not employed in the source code. In my example program, for the Victoria mix, it did seem appropriate or intuitive to have some thought about what to write, having in mind it's a machine that is executing the instructions, not a human being.

 

In an effort to understand computer workings, I dreamed up a fictitious machine that executes instructions. Here, the program writer simply writes out a recipe, a line of instructions, in plain English language. Like:

Recipe for Victoria sponge cake mix.

Line #1: Go to bowl number 3.
Line #2: Pick out an egg.
Line#3: Place the egg in bowl number 6.
Line#4: Go to bowl number 3.
Line#4: Pick out an egg.
Line~5: Place the egg in bowl number 6......

Of course, a human can read and execute this program.

In the fictitiuos machine, the operator feeds in the sheet of paper and it is read by the machine (OCR'ed).
I'm not sure how much I can appreciate by dreaming up this fictitious machine, maybe not much. But I have these questions:

#1 Would the lines written in plain English amount to source code and that is adequate? Why not?
#2 What kind of things would need to be done, or put in place, in order for a robotic arm to follow the instructions and produce a mix? (Say, Victoria spong cake). Thanks.

The problem with using "plain English" -- by which I interpret you to mean essentially the English as used in everyday conversation -- is that plain English relies heavily on side-channel communication in order to accurately convey information. For instance, we rely on the listener to understand what a particular word means based on the context of its usage. If I tell someone that I lost my car keys, I expect them to interpret that as meaning that I don't currently know where my car keys are located. If I tell them that I lost my house, I do NOT expect them to conclude that I don't know where the house is, but rather that I mean that I no longer have ownership of the house. But if I tell them that I lost my car, then either of those interpretations is possible, but the context of the broader discussion will almost certainly result in the correct interpretation being used. Now suppose you walk by a couple of people engaged in a conversation and all you hear is one of them say, "I lost my shirt"? Does the possibility that they either don't know where their shirt current is, or that they no longer own the shirt, come to mind as a likely interpretation? Human languages are all this way, because all of them evolved as a means for humans to communicate ideas to other human beings and humans are extremely good at pattern matching, inference, and contextual appreciation. Even then, misunderstandings can and do arise on a regular basis. So until you come up with a machine that can not only apply the same level of reasoning that a human brings to the table, but also enough more so that those remaining misunderstandings don't happen, you are spinning your wheels (and how would 'spinning your wheels' be interpreted by this machine?).

Even your very simple example reveals this ambiguity. What does line #2 really tell the machine to do? The machine has somehow travelled to the vicinity of Bowl #3. Fine. But what if there are eggs in a container in front of Bowl #3 as well as eggs in Bowl #3? Perhaps the eggs in the bowl were previously taken from the carton of eggs near it and hard boiled. Why should the machine infer that you want it to pick an egg only from Bowl #3, and not from the carton that is actually closer to it? Then, what does it mean to "pick" and egg. Does it mean to physically pick on up? Or just to make a note about one of them (along the lines of "pick a door")?

Then in Line #3, why should the machine infer that "the egg" refers to the same egg as "an egg" from the prior step, as opposed to, perhaps, some egg from some previous instruction?

Then there are all of the words and phrases and techniques that humans use that are specialized within various fields, including cooking. What does it mean to "saute" something? Or to "sear" something? Even if you have previously defined a subroutine for "saute", is that going to apply exactly the same way to everything -- do you "saute" mushrooms exactly the same way that you saute beef?

 

Thinking about a program written in plain English. . .
You might use the word "times" to mean "multiply" as in "3 times 7".
You might also say "repeat three times".
How does your interpreter or compiler know which meaning of "times" to use?

If you said "I go to town on Tuesdays AND Thursdays" then your compiler would be confused, because you actully mean "I go to town if the day is Tuesday OR the day is Thursday". No day can be both Tuesday AND Thursday. Just think of how often in writing English, you use AND and OR in the opposite of the strict Boolean sense.