Technique, or, Modern Adventures in NOT Designing a Programming Language
Room A | Thu 22 Jan 3:45 p.m.–4:30 p.m.
Presented by
-
Andrew Cowie
https://istathar.space/
Andrew Cowie was cursed as a child by a Unix sysadmin who doomed him to fix other people's build systems for the rest of his days. He has since gathered an extensive background of software development, systems operations, production infrastructure, and engineering leadership experience—but somewhat unusually started his career as an infantry officer in the Canadian army, having graduated from Royal Military College with a degree in engineering physics. He later ran operations for a new media company in Manhattan and was a part of recovering the firm after the Sept 11 attacks. Since then he has consulted on crisis resolution, change management, robust architectures, and (more interestingly) leveraging Open Source to achieve these ends. Andrew has been working in and around systems engineering and functional programming for many years; his most recent work has been to re-engineer observability into analytics pipelines and deployment machinery.
Andrew Cowie
https://istathar.space/
Andrew Cowie was cursed as a child by a Unix sysadmin who doomed him to fix other people's build systems for the rest of his days. He has since gathered an extensive background of software development, systems operations, production infrastructure, and engineering leadership experience—but somewhat unusually started his career as an infantry officer in the Canadian army, having graduated from Royal Military College with a degree in engineering physics. He later ran operations for a new media company in Manhattan and was a part of recovering the firm after the Sept 11 attacks. Since then he has consulted on crisis resolution, change management, robust architectures, and (more interestingly) leveraging Open Source to achieve these ends. Andrew has been working in and around systems engineering and functional programming for many years; his most recent work has been to re-engineer observability into analytics pipelines and deployment machinery.
Abstract
I bet you started a project once and you aren't quite finished yet. My
project isn't done yet either, but the difference is I started on mine over 20
years ago. Don't be hasty, young Hobbits, but I want to tell you all about the
journey that got us here.
This talk is the story of the Technique Procedures Language, a programming
language for describing procedures in a structured but human-readable form.
The language has evolved over a long period, starting with on-paper procedures
for systems operations tasks, and then going through different iterations of
approach. The paper documents were great, but I wanted a program to help me
run the events they described. It began as a GUI written in GTK and Java, but
how to express the code of these procedures? That led to an abusive
relationship with XML, strong embeddings in general purpose languages,
misadventures with various scripting tools, and even attempts to figure out if
any enterprise software would suit. Nothing really worked. Finally, I threw my
hands and said "why don't we just create our own language that does what we
want?".
Cool! So I wrote a parser in Haskell and was well on my way to an evaluator to
interpret the programs ... and realized that this language, now called
Technique v0, had entirely missed the point. It was unpleasant to write,
cumbersome to extend, and worst of all, the original theoretical analysis that
underpinned the work had been left behind.
Instructions written by humans to be read by by humans just don't look
like programming code. All we want is to be able to write down the steps we
need to do. So I went back to the drawing board and crafted something that
would actually be usable, by people.
This second attempt at a custom language, Technique v1, is a complete rework,
this time in Rust. It is not a programming language. It has returned to the
roots of what a procedure is and is truly domain-specific. Perhaps it is a
procedures language.
Technique features a compiler, code formatter, and rendering to PDFs. Syntax
highlighting is available for Vim, the Zed Editor, Sublime Text, and the Typst
typesetter. There's a language server, and an extension for Zed, with VS Code
and NeoVim on the way.
In a way everything I have done in my engineering career has been building to
being able to do this. Together we will go through some of the lessons learned
along the way: things that seemed like good ideas at the time; the temptations
of Not Invented Here; learning by doing. But the most interesting part has
been the past few months. What does it take to get the infrastructure for a
new language in place? A peek under the covers of how this one came to be
might encourage you—or scare you—to keep working away at your own projects,
too.
I bet you started a project once and you aren't quite finished yet. My project isn't done yet either, but the difference is I started on mine over 20 years ago. Don't be hasty, young Hobbits, but I want to tell you all about the journey that got us here.
This talk is the story of the Technique Procedures Language, a programming language for describing procedures in a structured but human-readable form.
The language has evolved over a long period, starting with on-paper procedures for systems operations tasks, and then going through different iterations of approach. The paper documents were great, but I wanted a program to help me run the events they described. It began as a GUI written in GTK and Java, but how to express the code of these procedures? That led to an abusive relationship with XML, strong embeddings in general purpose languages, misadventures with various scripting tools, and even attempts to figure out if any enterprise software would suit. Nothing really worked. Finally, I threw my hands and said "why don't we just create our own language that does what we want?".
Cool! So I wrote a parser in Haskell and was well on my way to an evaluator to interpret the programs ... and realized that this language, now called Technique v0, had entirely missed the point. It was unpleasant to write, cumbersome to extend, and worst of all, the original theoretical analysis that underpinned the work had been left behind.
Instructions written by humans to be read by by humans just don't look like programming code. All we want is to be able to write down the steps we need to do. So I went back to the drawing board and crafted something that would actually be usable, by people.
This second attempt at a custom language, Technique v1, is a complete rework, this time in Rust. It is not a programming language. It has returned to the roots of what a procedure is and is truly domain-specific. Perhaps it is a procedures language.
Technique features a compiler, code formatter, and rendering to PDFs. Syntax highlighting is available for Vim, the Zed Editor, Sublime Text, and the Typst typesetter. There's a language server, and an extension for Zed, with VS Code and NeoVim on the way.
In a way everything I have done in my engineering career has been building to being able to do this. Together we will go through some of the lessons learned along the way: things that seemed like good ideas at the time; the temptations of Not Invented Here; learning by doing. But the most interesting part has been the past few months. What does it take to get the infrastructure for a new language in place? A peek under the covers of how this one came to be might encourage you—or scare you—to keep working away at your own projects, too.