A way of implementing parentheses would be to use “downstep” (or upstep), as in some African languages (or indeed, as in English parenthetical clauses or asides). Perhaps the language would have to be “musical” in a sense. Or perhaps recursion could be replaced with cataphora, e.g.: “If a, then do the following and end: if b, then do the following and end: if c,….and end.” This might be more convenient for the speaker. Siva > On 25 Feb 2016, at 6:31 PM, Logan Kearsley <[log in to unmask]> wrote: > > This is a topic that I realize may cause a good deal of confusion, so > to be very clear up front: I in no way mean to imply that programming > languages are the same kind of thing as human languages, nor am I > currently concerned with the construction of a system that could serve > in both capacities. > Programming language =/= Human language > > Now that that's out of the way.... > > There's a video from a few years back ("Using Python to Code by > Voice": https://youtu.be/8SkdfdXWYaI?t=544) by a programmer who could > not type anymore due to RSI about hacking voice recognition software > to replace the keyboard as an input method for editing source code and > doing various other programming & system administration tasks. > > That's cool, but it basically just comes down to coming up with > efficient voice commands to replace keystrokes, without actually > changing anything about the thing that you're editing to optimize for > editing by voice. If you aren't editing something on a screen, but > composing or reciting a purely oral program, typical programming > languages aren't really optimized for that, regardless of whether you > have pithy names for the punctuation. And of course for most > real-world usage, that doesn't matter- there are very few > circumstances where you need to dictate large chunks of code to > another person without feedback. > > But, I've started working on a fictional setting (which I started > blogging about here: > http://gliese1337.blogspot.com/2016/02/the-structure-interpretation-of-demonic.html) > in which that is a serious concern- magic is modelled on computer > science, and it is not uncommon to have to recite the "spells". > > Unlike many magic systems involving spoken spells, however, in this > case the language itself is not "built-in"; i.e., there is no > privileged "language of magic". Magic does what the magician tells it > to do in whatever language the magician prefers to use and > understands, but the level of detail required means that magicians > generally prefer to use highly formal languages that are more like > computer programming languages than they are like normal human > languages. That means that human magicians are free to design magical > languages that are convenient for their use. > > So, with all that background, I'm now wondering what a programming > language would look like that is optimized to take the best advantage > of the human language faculty in order to make it easier to memorize > and dictate code. > > I'd like to know what thoughts the other programmers on the list have > on the subject (and anybody else who cares to comment, really, though > I'd expect other programmers to be the most interested), but here's > what I've got so far: > > The major problem that I see needing to be solved is parenthesization; > one can't be expected to properly keep track of indentation levels in > speech, and explicit brackets around everything can get really hard to > keep track of even when you can look at what you're doing on a screen > (which is why we have special editors that keep track of > bracket-matching for us!) Ideally, one would want a language that did > not require explicit parenthesization anywhere, and in which other > "syntactic noise" is also minimized, so that every token of the > language carries as much semantic weight as possible, to make them > easier to memorize. This leads me to think that a concatenative, > combinator-based language (like FORTH, or the non-programming-language > conlang Fith) would be the best base, on top of which "idiomatic" > flourishes could be added. > > -l.