The December 2022 issue of IEEE Spectrum is here!

Close bar

Meet Twist: MIT’s Quantum Programming Language

Keeping tabs on data entanglement keeps reins on buggy quantum code

3 min read
Code sits over a background photo of quantum computing hardware
Code: MIT; Quantum computer: Graham Carlow/IBM

A team of researchers at MIT’s Computer Science and Artificial Intelligence Laboratory (CSAIL) have created Twist, a new programming language for quantum computing. Twist is designed to make it easier for developers to identify which pieces of data are entangled, thereby allowing them to create quantum programs that have fewer errors and are easier to debug.

Twist’s foundations lie in identifying entanglement, a phenomenon wherein the states of two pieces of data inside a quantum computer are linked to each other. “Whenever you perform an action on one piece of an entangled piece of data, it may affect the other one. You can implement powerful quantum algorithms with it, but it also makes it unintuitive to reason about the programs you write and easy to introduce subtle bugs,” says Charles Yuan, a Ph.D. student in computer science at MIT CSAIL and lead author on the paper about Twist, published in the journal Proceedings of the ACM on Programming Languages.

“What Twist does is it provides features that allow a developer to say which pieces of data are entangled and which ones aren’t,” Yuan says. “By including information about entanglement inside a program, you can check that a quantum algorithm is implemented correctly.”

One of the language’s features is a type system that enables developers to specify which expressions and pieces of data within their programs are pure. A pure piece of data, according to Yuan, is free from entanglement, and thereby free from possible bugs and unintuitive effects caused by entanglement. Twist also has purity assertion operators to affirm that an expression lacks entanglement with any other piece of data, as well as static analyses and run-time checks to verify these assertions.

To evaluate the language, the team wrote programs in Twist for a set of well-known quantum algorithms and executed them on a quantum simulator. “We performed experiments that showed the overhead of running these runtime checks is no more than 3.5 percent over running the base program, which we believe is fairly low and a good trade-off for the safety guarantees the language gives you,” Yuan says.

The team also introduced small bugs to some of the programs and found that Twist can detect those bugs and reject the erroneous programs. “We hope that when people use our language or design new quantum languages for their specific use cases, they’ll be able to look at our work and say that the idea of purity and having entanglement as a feature is something they want because it will give them more confidence that their programs are correct without having to run a lot of expensive simulation and testing,” says Yuan.

While many researchers are focused on building efficient and optimized quantum hardware, Twist aims to fill the gap in quantum software. “Drawing some parallels to what we’re seeing with machine learning and other high-performance computing applications—where with every new phase of hardware development we get a new system and potentially new capabilities— there are perhaps many incredible opportunities to be had by harnessing the hardware. But it almost always is the software that stands in the way of people having access to that hardware and being able to deploy it and use it widely in different software systems,” says Michael Carbin, an associate professor at MIT and coauthor of the paper about Twist. “A lot of the work we’re doing is laying some of the foundations and trying to tease out what some of the core abstractions are that may make these types of devices more programmable.”

Yet one of the challenges the team faced in building Twist is the lack of a standard for what quantum programs should look like. “Over the years, people have developed core algorithms to solve individually complex tasks like factoring integers, but it’s less clear how we can build an entire ecosystem of software for it,” Yuan says. “With Twist, we were able to build the language around our best consensus of the tasks we want to perform on quantum computers and make it as expressive as possible for those tasks.”

In terms of limitations, Twist can only tell you whether or not a piece of data is entangled with other pieces of data, but not how they’re entangled. “The exact way they’re entangled is what will determine whether a quantum algorithm is correct, but there are an infinite number of ways in which data can be entangled,” says Yuan. “It’s a real challenge to be able to give that finer-grained detail, and it’s something we’ll need to do in the future.”

The team is now working on another language that builds upon Twist to tackle other quantum phenomena such as phase and superposition, but they hope Twist will pave the way for creating better quantum programs.

“For a developer trying to implement a quantum algorithm, they need the tools built into the language to tell them something is happening in their program that’s caused by entanglement,” Yuan says. “If we can build core language principles and features that allow a developer to reason about entanglement, we can make it so entanglement is less of a cognitive burden, and allow developers to write more intuitive programs.”

The Conversation (2)
Martin Smith21 Feb, 2022
INDV

Article says Twist was developed on a QC simulator. Is it expected that it would run on any QC hardware, or does it assume a particular architecture (trapped ions, or whatever?)

earningstone sangma21 Feb, 2022
GSM

This is much of a great leap towards something which would be cost effective and with possibilities to improve it further, we can hope it would surely enrich the quantum programming.

Why Functional Programming Should Be the Future of Software Development

It’s hard to learn, but your code will produce fewer nasty surprises

11 min read
Vertical
A plate of spaghetti made from code
Shira Inbar
DarkBlue1

You’d expectthe longest and most costly phase in the lifecycle of a software product to be the initial development of the system, when all those great features are first imagined and then created. In fact, the hardest part comes later, during the maintenance phase. That’s when programmers pay the price for the shortcuts they took during development.

So why did they take shortcuts? Maybe they didn’t realize that they were cutting any corners. Only when their code was deployed and exercised by a lot of users did its hidden flaws come to light. And maybe the developers were rushed. Time-to-market pressures would almost guarantee that their software will contain more bugs than it would otherwise.

Keep Reading ↓Show less
{"imageShortcodeIds":["31996907"]}