Lakota

Lakota was a proprietary scripting language created by Richard Harter at SMDS, Inc. (Software Maintenance and Development Systems), the small Massachusetts software house behind the Aide-de-Camp configuration management system. Its design premise was unusual and pragmatic: rather than replacing the operating system’s command language, Lakota extended it. A Lakota script could freely intermix Lakota statements with ordinary Unix shell commands on Unix, or with DCL commands on VMS, because the language deliberately claimed no characters that were special to the host shells. It was, in its creator’s framing, something close to an anti-Perl.

Lakota was never released, never sold, and never documented publicly, and on the usual definitions it should have vanished without a trace. It nearly did. What makes it worth an encyclopedia entry is that - unlike most in-house languages - its author was a prolific and quotable Usenet essayist, so the language’s design philosophy, several concrete features, and even its creator’s own verdict on one design mistake all survive in his words, scattered across catalog entries, newsgroup archives, and his personal website.

What the record says

The catalog record under which this encyclopedia carries Lakota reads: year 2006, paradigm object-oriented, category research, status dormant. Checking that record against primary sources was instructive, because most of it does not hold up:

The one-line catalog description, however, is solid, and every other source echoes it: “Scripting language, extends existing OS commands.” That sentence, preserved in Bill Kinnersley’s Language List and in FOLDOC (where the entry survives to this day), is the seed from which the rest of this page grows.

Richard Harter

Richard Harter (June 29, 1935 - April 20, 2012) had one of those pre-standardized careers that early software was full of. Born in Hyde County, South Dakota, he grew up on a cattle ranch, attended a one-room country school, served in the U.S. Marine Corps from 1954 to 1957, and finished a mathematics degree at South Dakota State University in 1965 after what he called “a very irregular college career.” He spent his working life in the Boston area - by his own summary he “hacked the internet, started companies, and tracked some missiles” - and was a principal of SMDS, Inc.

Beyond his day job he was a fixture of Usenet from its earliest years: a long-time contributor to comp.lang.misc’s language-design debates, a founding-era participant in talk.origins, a science-fiction fandom regular, and the author of a sprawling personal website of essays on mathematics, computing, and South Dakota life. On retirement he moved back to Highmore, South Dakota, and he died in 2012. It is exactly this paper trail - unusual for the author of an unreleased in-house language - that makes Lakota partially recoverable.

SMDS and Aide-de-Camp

SMDS’s flagship product, Aide-de-Camp (ADC), earns its own footnote in software engineering history. It appears in Susan Dart’s influential Software Engineering Institute surveys of configuration management systems (1990-1991) as an early example of change-set-based version control - organizing history around logical sets of changes rather than file versions, an idea that mainstream tools took years to catch up with.

That is the environment Lakota served: a small vendor whose product and customers spanned Unix and VMS, with all the scripting friction that implies. The Bourne shell and DCL agree on almost nothing - syntax, quoting, wildcards, control flow - so a company supporting both either wrote everything twice or found a portable layer. Lakota was, on the evidence of Harter’s descriptions, that layer. Whether Lakota also shipped inside ADC itself as a customer-facing scripting facility is not documented anywhere that could be located, so no such claim is made here; what is documented is internal use, with Harter noting that SMDS had considered marketing the language.

Design philosophy: the anti-Perl

The clearest statement of Lakota’s design comes from a comp.lang.misc thread that asked, half-seriously, what an anti-Perl would look like. Perl’s design absorbs notation greedily - sigils, punctuation operators, quoting forms - and assumes it owns the whole script. Harter offered Lakota as the opposite pole:

• OS commands are legal Lakota commands. A script is not written in Lakota instead of the shell; it is written in the shell’s world with Lakota’s constructs available. Under Unix a script could mix Lakota and shell commands; under VMS, Lakota and DCL.
• No character theft. To make that mixing unambiguous, Lakota avoided attaching special meaning to any character that was already special in the command languages of interest. Where Perl bristles with notation, Lakota renounced it - the syntactic footprint had to be nearly invisible so the host language’s own syntax could pass through untouched.
• Portability as the point. Since the language carried its own semantics and borrowed the host’s, the same approach adapted across operating systems whose native shells were mutually unintelligible.

This is a genuinely distinctive position in language design space. Embedded extension languages of the era (Tcl most famously) invited applications into the language; Lakota instead moved itself into whatever command environment already existed. The closest modern echoes are tools that overlay rather than replace a host notation.

Documented features

No manual, grammar, or code sample survives publicly, and this page will not invent one. But Harter’s Usenet posts preserve several concrete facts about the language’s shape:

• Indentation-based blocks. Lakota delimited blocks by indentation - the design Python later made famous - and, like early Python, permitted mixing tabs and spaces with a tab counted as eight spaces. Harter’s retrospective verdict, posted in June 2004 when Python’s own developers were wrestling with the same issue: “I used the same scheme in Lakota and concluded that it was a serious mistake.” He added, ruefully, that he “realized it was a mistake, talked about fixing it, and never did anything about it.”
• PL/I-style multiway branching. Lakota used the select ... case construct in the manner of PL/I, as Harter confirmed in a December 2004 discussion of case-statement keywords across languages - one of the few individual constructs of the language that can be named with certainty.
• Proprietary and unreleasable. In his September 2001 RSL design notes Harter was explicit: “this language is proprietary and I cannot release it; however I am drawing on lessons learned from usage of that language.”

The name

Nothing in the surviving record states why the language was called Lakota. The natural reading - and it is offered here strictly as an inference - is that Harter named it for the Lakota people of the northern Great Plains. He was born and raised in Hyde County, South Dakota, in the heart of Lakota and Dakota country, returned there in retirement, and wrote about the history of the Sioux nation on his website. For a South Dakota rancher’s son naming a language at a Boston software company, the name looks like a deliberate piece of home.

Legacy

Lakota’s most traceable legacy is in Harter’s own later designs, both of which were published as design notes rather than released software. In 2001 he began public design notes for RSL (“Richard’s Scripting Language”), a language he intended to place in the public domain, explicitly mining Lakota for lessons - among them a planned embeddable interpreter, interactive shell, and portability across Windows, Linux, and other systems he knew from Lakota’s world. By 2004 he was posting about a successor design he called San, where the tab-and-space lesson resurfaced as a rule that a source file must declare its layout style explicitly, use it consistently, and follow rules simple enough for automatic translation between styles. Neither language appears to have shipped, which gives Lakota the odd distinction of being the only language in this lineage that ever actually ran.

Its other legacy is as a specimen. The overwhelming majority of programming languages ever created were like Lakota: in-house tools, proprietary, undocumented outside the building, dead with their company or their author. Almost none of them can be described at all. Lakota can - not because SMDS preserved it, but because its author argued about language design in public for thirty years. The half-recovered portrait in this page is roughly the best case for what an unreleased language leaves behind.

Why it matters

Lakota is a reminder that the history of programming languages is mostly invisible. Catalogs like the Language List, FOLDOC, and HOPL preserved one-line entries for thousands of languages; behind a large fraction of those lines stood real, running systems - with design philosophies, regretted decisions, and users - that left no other public trace. Lakota’s line happened to be attached to a man who wrote everything down somewhere. The 2006 date and OOP label in the modern catalog record also show how such thin records decay as they are copied between lists: with no primary source to check against, errors accrete silently. This page exists partly to push back on that - to pin the entry to what its creator actually said, while any of it can still be found.

If you have primary material on Lakota - an SMDS manual, a script, correspondence, or first-hand memory of the language in use - it would be genuinely welcome; this is a page that a single surviving document could substantially rewrite.