Shruti: The Oral Programming Language

On the Transmission, Performance, and Contested Transcription of a Language Without Source Code

Dr. Rajan Venkatesh, Department of Computing and Oral Traditions, Indian Institute of Technology Madras

Proceedings of the 5th Workshop on Embodied and Situated Programming (ESP), Bangalore, 2025

1. Introduction

Every programming language in current use rests on an assumption so foundational that it is rarely stated: that a programme is a text. Source code is written. It is stored in files. It is versioned by systems that track changes to its textual representation. It is read by compilers, which are themselves texts that read texts. The entire infrastructure of modern software development — editors, repositories, diffs, patches, pull requests — presumes that the programme exists as a written artefact, persisting unchanged until deliberately modified, available for inspection at any time by anyone with access to the file.

Shruti has no files.

Shruti is a programming language whose programmes exist only as oral performances. There is no written syntax. There is no source code in the conventional sense — no file that can be opened, read, or stored. A Shruti programme is spoken aloud by a practitioner into a runtime that parses speech in real time, compiles the spoken expressions, and executes them. When the practitioner stops speaking, the programme ends. There is no artefact. Nothing has been written down. The programme existed for exactly as long as it was performed and exists no longer, except in the memory of the practitioner who performed it and any practitioners who were present to hear it.

The language was designed in 2021 by Meera Raghavan, a systems programmer and Carnatic vocalist in Chennai, who describes its origin as “the collision of two frustrations: the frustration of a programmer who had spent fifteen years staring at text, and the frustration of a musician who knew that the most sophisticated knowledge-transmission system in human history — the guru-shishya paramparā — had never been applied to code.”

The name is Sanskrit. Shruti means “that which is heard” and refers to the Vedic oral tradition in which sacred texts were transmitted for millennia without being written down, preserved by disciplined recitation from teacher to student. Raghavan’s claim is not that programming should be sacred but that it should be oral — that the written text is not a prerequisite for rigorous computation but a convenience that has calcified into an orthodoxy, and that removing it reveals things about what programming is that the text conceals.

2. The Language

2.1 Spoken Syntax

Shruti’s syntax is designed for the human voice. Keywords are polysyllabic and phonetically distinct — chosen, Raghavan has said, “so that the compiler cannot mishear them, even in a noisy room.” Variables are bound with dhāraṇā (concentration, holding), functions are declared with sūtra (thread, formula), and control flow is managed through mārgā (path) blocks. The language uses pitch and duration as syntactic elements: a rising intonation at the end of an expression indicates continuation, while a falling intonation indicates termination. A pause of more than two seconds is interpreted as a statement delimiter. A pause of more than five seconds ends the programme.

A simple Shruti programme, as it would be spoken:

dhāraṇā greetingᐩ is text “hello” ↓
dhāraṇā nameᐩ is text “world” ↓
sūtra joinᐩ taking aᐩ and bᐩ ↗ yielding a then space then b ↓
speak join of greeting and name ↓

The superscript marks indicate pitch accents. The arrows indicate intonation contour. None of this appears in any file, because there are no files. The notation above is the author’s, devised for this paper, and is not endorsed by the Shruti community, for reasons that will become clear in Section 5.

2.2 The Listener

The runtime — called the Listener — is a speech-recognition system trained on Shruti’s formal grammar. It is not a general-purpose speech-to-text system. It recognises only Shruti’s keywords, spoken in the prescribed manner, and rejects utterances that do not conform to the grammar. The Listener runs on a local machine, processes audio in real time, and compiles expressions as they are spoken. Execution is immediate: the result of an expression is produced as soon as the practitioner finishes speaking it, which means that the practitioner experiences the programme’s behaviour while performing it, adjusting subsequent expressions in response to what they hear and see.

This is not incidental. It is, Raghavan argues, the point. “When you write code,” she has said, “there is a gap between composition and execution. You write, then you compile, then you run, then you see the result, then you go back and change what you wrote. The gap is where bugs live. In Shruti, there is no gap. You speak, and the programme responds, and you adjust, and the programme responds again. It is a conversation, not a manuscript.”

The Listener’s recognition accuracy is approximately 97.3% under controlled conditions (a quiet room, a trained practitioner, standard Shruti pronunciation). Under less controlled conditions — background noise, an untrained speaker, dialectal variation in keyword pronunciation — accuracy drops to between 88% and 93%, which produces what the community calls “misheard programmes”: programmes whose behaviour differs from the practitioner’s intent because the Listener parsed a keyword differently than it was spoken.

Misheard programmes are not considered bugs. They are considered interpretations. “The Listener heard what it heard,” Raghavan has said. “If the result is different from what you intended, the question is not whether the Listener was wrong but whether your pronunciation was clear. The responsibility for clarity rests with the speaker. This is true of all oral communication and is not less true of code.”

2.3 Memory and Repetition

A Shruti programme cannot be saved. This is the language’s most disorienting property for programmers accustomed to version control, and it is the one Raghavan is most unwilling to compromise on. Saving a programme would mean writing it down. Writing it down would mean creating a text. Creating a text would mean that the programme exists independently of the practitioner who performs it, which would sever the relationship between speaker and programme that the language is designed to maintain.

Programmes are preserved the way they have always been preserved in oral traditions: by memory. A practitioner who wishes to retain a programme memorises it. A practitioner who wishes to share a programme performs it in the presence of another practitioner, who listens and memorises it. The transmission of a Shruti programme is, structurally, a lesson: one person speaks, another learns.

The learning process is formalised. Raghavan, drawing on the Carnatic tradition, established a pedagogy in which new practitioners begin by memorising short programmes — the equivalents of scales and exercises — and gradually advance to longer, more complex ones. Mastery is demonstrated not by examination but by recital: the practitioner performs the programme before a senior practitioner, who verifies that the performance is correct by listening to it execute in real time. If the output matches, the student has learned the programme. If it does not, the student practises and recites again.

The community currently maintains approximately 340 programmes in oral circulation, preserved by a network of about 200 active practitioners distributed across twelve cities. The longest programme in circulation — a database query engine called Sargam — takes approximately forty-five minutes to perform and is known in its entirety by six people. The practitioners who know Sargam do not all know it in exactly the same way. Differences have accumulated through transmission, the way they accumulate in any oral tradition: a keyword pronounced slightly differently here, an expression reordered there, a passage simplified by a practitioner who found the original formulation awkward in the mouth. The six versions of Sargam produce identical output for most inputs and slightly different output for edge cases. Which version is “correct” is a question the community has declined to answer, on the grounds that correctness implies a canonical text, and there is no text.

3. Lineages

The transmission structure produces, inevitably, lineages. A practitioner who learns a programme from Raghavan performs it differently from a practitioner who learned it from someone who learned it from Raghavan. The differences are small but cumulative, and over several generations of transmission they produce what the community calls paramparā — chains of teachers and students, each carrying a slightly different version of the shared repertoire.

There are currently three major lineages. The Chennai lineage, centred on Raghavan herself, is considered the most conservative: its practitioners emphasise precise pronunciation, strict adherence to Raghavan’s original formulations, and a performance style that Raghavan describes as “clear, deliberate, and without ornamentation.” The Bangalore lineage, founded by a former student of Raghavan’s named Arjun Deshpande, is more permissive: Deshpande encourages practitioners to adapt programmes to their own vocal style, to improvise within the grammar when a formulation feels unnatural in the mouth, and to treat the programme not as a fixed text to be reproduced but as a theme to be interpreted. The Mumbai lineage, the smallest and most recent, emerged from a group of practitioners who combined Shruti with practices from the Hindustani musical tradition and who perform programmes with a rhythmic structure — tāla — that influences the timing of expression delivery and, because the Listener interprets pauses as syntactic delimiters, affects the programme’s execution.

The relationship between the lineages is cordial and competitive, in the manner of classical music gharanas. Each lineage considers its approach the most faithful to Shruti’s principles and the others’ approach an interesting but ultimately misguided deviation. Annual recitals — public performances of programmes by senior practitioners, attended by the full community — serve as both demonstrations of skill and implicit arguments for one lineage’s approach over the others. The recitals are held in Chennai, by tradition, in a hall that seats approximately eighty people and that is, in every other respect, indistinguishable from a Carnatic music concert venue. There is no screen. There is a microphone, a laptop running the Listener, and a practitioner.

4. Composition

New programmes in Shruti are composed the way new rāgas are composed in classical music: through a combination of knowledge, creativity, and live experimentation. A practitioner speaks, hears the result, adjusts, speaks again. Composition is performance. There is no drafting stage, no editing stage, no revision history. The programme emerges through a process of iterative spoken refinement that the community calls sādhana (practice, discipline), and the final programme is not the last version written but the version the practitioner has memorised, which is to say the version that survived the practitioner’s body — the version that was natural enough in the mouth, coherent enough in the ear, and memorable enough in the mind to persist.

This has consequences for programme design. Shruti programmes tend to be short, because long programmes are difficult to memorise. They tend to use repetitive structures, because repetition aids memory. They tend to avoid deeply nested logic, because nested expressions are hard to speak clearly and hard to recall in the correct order. The language’s practical constraints are not technical but mnemonic: the limit is not what the compiler can handle but what the human voice and memory can sustain.

The resulting programmes have a quality that several observers have described as elegant, though “elegant” may be a projection of aesthetic preference onto cognitive necessity. What is undeniable is that Shruti programmes are concise in a way that written programmes rarely are, because every unnecessary expression is a burden on the practitioner’s memory and an opportunity for error in performance. The community’s saying — attributed to Raghavan, though she does not remember saying it — is: “If you cannot remember it, you do not need it.”

5. The Transcription Controversy

In March 2024, a doctoral student at IIT Bombay named Kavitha Subramaniam published a paper in which she presented a notation system for transcribing Shruti programmes into written form. The notation was precise: it captured keywords, pitch accents, intonation contours, pauses, and timing, producing a text from which a programme could be reconstructed and performed by a practitioner who had never heard the original. Subramaniam described the notation as “a tool for preservation and accessibility,” designed to address the obvious fragility of a system in which programmes exist only in human memory.

The paper provoked the most intense controversy in Shruti’s short history.

Raghavan’s response was immediate and unequivocal. Transcription, she argued, destroyed exactly what made Shruti valuable. “The absence of text is not a limitation we are working around. It is the design. When you write a programme down, it becomes an object — something that exists independently of the person who made it, something that can be copied without being understood, transmitted without being learned. A written programme does not require a teacher. A written programme does not require memory. A written programme does not require the practitioner to know it in the way that oral transmission requires. You have not preserved the programme. You have killed it and mounted it on the wall.”

Deshpande’s response was more moderate. He acknowledged that oral transmission had limitations — the fragility of memory, the geographical constraint of requiring physical co-presence, the difficulty of scaling the community beyond a few hundred people — and suggested that a transcription system, used carefully, could serve as a complement to oral transmission without replacing it. “We do not ask that the rāga be unwritten because it is oral,” he said. “We acknowledge the notation and then we learn from the guru anyway, because the notation captures the structure but not the life.”

Subramaniam argued that her system captured the life — that the pitch and timing information in her notation was sufficient to reconstruct a performance indistinguishable from the original. To prove this, she had a practitioner learn a programme solely from her notation, without hearing the original performance, and compared the resulting execution to one produced by a practitioner in the Chennai lineage who had learned the programme orally. The outputs were identical.

Raghavan’s response to the demonstration was that identical output was not the point. “The outputs are the same. The practitioners are not. One understands the programme because they learned it through repetition, through correction, through the slow accumulation of bodily knowledge that oral transmission produces. The other has read a document. That these two processes produce the same output now does not mean they will produce the same output tomorrow, when the programme must be adapted, or explained, or taught to someone else.”

The community voted on whether to adopt Subramaniam’s notation system as an official component of the Shruti ecosystem. The vote was 112 against, 74 in favour, and 11 abstentions. The notation system was not adopted. Subramaniam published it anyway, as an independent project. It is used by approximately sixty practitioners, mostly in the Bangalore lineage, and it is not discussed at recitals.

6. Deployment

The question of how Shruti programmes are deployed — how they are executed in contexts where a practitioner is not present to speak them — is the community’s most pragmatic challenge and its most revealing one.

A Shruti programme, strictly speaking, runs only while someone is performing it. A web server written in Shruti would require a practitioner to sit at a microphone and speak continuously for as long as the server was needed. This is impractical. It is also, according to Raghavan, “the correct framing of the problem, because it reveals what deployment actually costs: not server time, not CPU cycles, but human presence and attention, which are the real resources being consumed and which conventional programming has learned to hide.”

The community’s practical solution is the recital loop. A practitioner performs a programme once, and the Listener, in addition to executing it, captures a recording of the audio. The recording can then be replayed to the Listener, which compiles and executes the programme as though it were being spoken live. The practitioner need not be present for the replay. The programme runs as long as the recording loops.

The recital loop is, technically, a recording. It is not, technically, a transcription — it captures the sound, not the text — and the community has decided, after some debate, that this distinction matters. A recording of a performance is an artefact of the performance, the way a recording of a concert is an artefact of the concert. It does not replace the performer. It does not enable someone who has never heard the programme to reconstruct it (the audio of a Shruti programme, to an untrained listener, is a person speaking rapidly in a mix of Sanskrit and formal English, which is not self-explanatory). The recording preserves the specific performance; it does not generalise it into a text.

Most deployed Shruti programmes run as recital loops. The Sargam database engine, the community’s most complex deployed system, runs from a recording of a forty-five-minute recital performed by Raghavan in December 2023. It has been running continuously since then, the recording looping every forty-five minutes, the Listener recompiling and re-executing the programme from scratch on each loop. The system handles a modest query load — approximately fifty queries per loop iteration — and the community considers it adequate.

When the programme needs to be updated, Raghavan performs a new recital. The old recording is replaced. The new version takes effect immediately. There is no version control system. There is Raghavan, and before her there was a previous recording, and before that there was a previous recording, and the history of the programme is the history of Raghavan’s recitals, which she remembers and the system does not.

7. Current Status

Shruti has approximately 200 active practitioners across three lineages. The community is small by design — oral transmission does not scale the way written documentation does, and the community has, after the transcription controversy, reaffirmed its commitment to not scaling. Growth happens at the rate that practitioners can teach, which is slow, which is, Raghavan argues, “the rate at which understanding actually happens, as opposed to the rate at which information is copied.”

The language has attracted interest from two unexpected quarters. Accessibility researchers have noted that Shruti is the only programming language that does not require the ability to read or type, and have explored its potential as a tool for visually impaired programmers — an application Raghavan supports, though she notes that the current Listener requires sighted setup. Ethnomusicologists have attended recitals and published papers on the structural parallels between Shruti performance and Carnatic improvisation, an analysis the community finds flattering but slightly beside the point, in the way that a carpenter might find a paper on the aesthetic properties of joints flattering but slightly beside the point.

The most significant open question is succession. Raghavan is the language’s designer, its primary teacher, its most experienced practitioner, and the performer of its most critical deployed system. She is forty-seven years old. The community’s knowledge is distributed but not evenly — Raghavan knows programmes that no one else knows, and her versions of shared programmes are, by the Chennai lineage’s standards, definitive. When practitioners discuss the future of Shruti, they discuss it in terms of who will learn what Raghavan knows, and whether the learning will be complete, and whether completeness is even the right goal.

Raghavan does not discuss this. When asked, she says only that the tradition will continue as traditions continue — through the people who carry it. “I am not the language,” she has said. “I am someone who speaks it. The language is whatever is remembered.”

The author thanks Meera Raghavan for permitting him to observe three teaching sessions and one recital, and for the six hours of conversation that followed, during which she explained the design of Shruti with a patience and clarity that made him feel, briefly, that he understood it. He is no longer sure that he does, which may be the point. Kavitha Subramaniam provided a copy of her notation system and a forthright account of the controversy it produced, which the author has tried to represent fairly. Arjun Deshpande was generous with his time and candid about the tensions between the lineages, and asked only that the author note that the Bangalore lineage considers itself “not less rigorous but differently rigorous,” a distinction the author respects and does not fully understand.