I'm slowly convincing myself that the future of programming includes verbalizability (and thus, natural language). The ubiquity and utility of natural language is well known: almost all of the information we read, write/type, speak and hear every day is communicated via a natural language, not a specially-crafted one. Natural language is our primary means of understanding the world and interacting with other humans, especially in the absence of supplementary tools such as pen-and-paper (e.g. in face-to-face conversation). When was the last time you described a cause-and-effect phenomenon (a story, event, or task instructions) to someone without extensive use of natural language? At best, we use other artifacts (diagrams, formal models) as aids. Despite the ubiquity and utility of natural language, if one person tries to "speak" a Java/C/JS/Rust program to another person, they have to go through an extremely complicated and lossy translation process from code to words. Based on some of my recent design work (not shared yet), I'm beginning to believe we could actually design programming languages whose "source code" consists solely of terse natural language sentences/structures with very specific syntax restrictions (to deny multiple interpretations / ambiguities). The language would not be accompanied by any supplementary symbols (!@#$%^&]/->) with domain-specific meaning, since those would inhibit verbalization. Writing code in this language still requires careful deliberation (to develop the logic), but reading and discussing code with full verbalization becomes trivial: no translation is required at all! Yes, I'm not the first person to think about putting natural language in PLs. Someone might bring up COBOL, HyperTalk, SQL, or similar. I'm not saying verbalizability is "the solution" to programming alone, but along with a well-crafted semantics (information model etc.), it could lead to something extraordinary. If anyone wants to think further about this, Felienne Hermans (video is timestamped to that bit). Quote: "how does code sound?" I searched this Slack's archives, and I was surprised to discover the word "verbalization" has never been used.

@opeispo mentioned it before: https://futureofcoding.slack.com/archives/C5T9GPWFL/p1593728981205800?thread_ts=1593726809.181800&cid=C5T9GPWFL. There may be others using different words.

Sounds interesting! I'm looking forward to learning more.

Our latest work on a front-end revolves pretty much entirely around this idea. 🙂 The big shift for us came from moving our focus away from “simple” to “simple to understand.” The results have been encouraging so far. Here’s the obligatory “incrementer button”

an incrementer is a button with a count of 0
    the text is bound to its count

when an incrementer is clicked
    increment the count

None of that is builtin, e.g. here’s how increment is defined:

to increment a number
    set the number to the number + 1

And here’s a button:

a button is an element that has a text string
    its tag is "button"
    always set "textContent" of the button to its text

Verbalizability (I'm going to go with pronounceability) is an entirely different prospect from natural language. Pronounceability is definitely a great thing, for accessibility if nothing else. I still can't imagine a system of "terse natural language sentences" that isn't hostile to at least one of precision or concision. I'd love to be convinced otherwise. Can you give a napkin-example of what you have in mind? For pronounceability I would still follow the lead of mathematics as pronounced, e.g. "f of x equals forall y in d g of x and y". Whatever approach you take needs to have enough expressive power to balance out the bandwidth limit of at least speech, if not word-based notation (I like the idea of a conventional-looking system with operators that happen to all have reasonable pronunciations, which would keep the written syntax relatively compact). OTOH: if you can just avoid the trap of phrases that look like multiple words but parse like a single token (in that they always have to be together in the same order), if you just let words be independently composable, you'll be head and shoulders above COBOL et al.

@Kartik Agaram ah, good work! I searched for “verbal-” and “vocal-“ but not “pronounce”.

It's interesting to compare operator-heavy languages like Haskell with math notation. The latter has always been a shorthand notation for a highly codified jargon. It is pronounceable because mathematicians have communicated orally all the time. Occasional excesses into unpronounceable notations have been made, but never made it into mainstream. This mechanism hasn't worked for digital notations because people don't communicate about them orally. A cultural practice of the Lisp community (in the widest sense, including Scheme etc.) that I have always appreciated is to value pronounceability of names. Which may seem surprising to all those who never take a closer look at Lisp because of all those parentheses. For me, Lisps are the PLs closest to natural language (but I have never used Cobol), and that's their strong point.

To buttress your point @Konrad Hinsen I miss being able to name variables ‘open?’ . This is an interesting example actually because when said out loud it is the same word as ‘open’ but with a different tone or maybe ‘open?’ should be pronounced ‘is open’ . Is that a strike against using variable names like this 🤔.

@opeispo Indeed, the question mark was one of the main innovations coming from Scheme. Once you have seen it, you can't help but consider the

-p

prefix from earlier Lisp days incredibly clumsy. I read the question mark with a different tone (to myself, I hardly speak Lisp to others), and that sounds very natural to me.

Obligatory mention of The Osmosian Order of Plain English Programmers

When trying to use natural language as a basis for programming, I suppose a lot of effort needs to go into dealing with ambiguity. I'm all for this, because I think problems with complexity and with understandability come from the level of precision that is required to do programming today, which caters to logic and math types, and is far beyond what non-programmers are used to from their daily lives. I wonder, @ibdknox, can you talk more about how you explicitly deal with ambiguities in that prototype, or is that not a concern at all?

There was a good useR keynote last month on some of this by Amelia McNamara called "Speaking R" (, slides).

@Nick Smith Nothing is builtin, so drawing to HTML in this instance has no implications on the semantics of the language itself. You could just as easily replace the definition of element with something that draws to GL. This is all you need for the def of element:

an element is a thing with a tag "div"

to create an element
    dom.elem(the element, its tag)

It’s just an FFI call. The language was designed to be able to go all the way down to bare metal if desired. The full semantics of the model is probably best left for another discussion 🙂

@ibdknox I love hearing some much about where things are going. Definitely can't wait till you can share more 🙂 I am interested to know, who is we? Is this work you are doing in your spare time or at a company?

Josh (from Eve) and I left our jobs and are doing this off of savings at the moment. Our goal is to try to put something impactful enough together that we can create a sustainable small business around it. 🙂

do you know about https://www.storyscript.com/ I discovered it in this slack, but I haven’t played with it

@Konrad Hinsen your comment "operator-heavy languages like Haskell with math notation" makes me ponder whether scenarios where operators feel best might be those where a diagram would do better. 🤔

@elbear Oh, I did see Storyscript at one point! I should probably look at it more closely.

This isn't a critique, just a stray thought about visual representation: The transition from rhetorical algebra (verbal descriptions of relationships) to symbolic language is commonly lauded as a large improvement in the UI for maths. Do you disagree with this in general/think it only applies to "low-level" concerns/think it only applies to symbolically-inclined individuals? The inverse approach might be to try to extend mathematical notation to better represent the "high-level" concepts end-users want to manipulate. Can this be done without being immediately off-putting to people who aren't big fans of maths? (i.e. normal people!) 😄

@Andrew Reece I think symbolic representations are useful when you need to do algebra (symbolic manipulation/evaluation). But programmers don’t want to do this: they simply want to write something down, and be able to easily read it later. We make the computer do the algebra when we hit “Run”.