7 ms·

Twist: MIT’s Quantum Programming Language

88 points by georgehill 5y ago

prophesi 5y ago
I think this made the top of HN a few days ago: https://ionq.com/posts/june-24-2021-hello-many-worlds https://ionq.com/posts/june-24-2021-hello-many-worlds I was disappointed that all of them were Python libraries (besides Microsoft's Q#, but I don't find a C#-like language attractive either), so I'm definitely interested in what it looks like coding in Twist.
- Redimo 5y ago
  I feel you. I write mostly Java code, but I've worked heavily with python + qiskit for quantum ML the past 3 months, and it's excellent. Qiskit is "low" level enough to give me the freedom I want, and with Jupyter Notebooks it's just so much easier to quickly construct something and evaluate, as well as extract it in a way I can put it in a paper.
  - throw1234651234 5y ago
    C# and Java feels exactly the same to me now that Java has lambda/stream collection methods to match LINQ. Not sure how you feel there is any difference between the two. The only difficulty I have is when I have to work with Java Frameworks, even though I "never" use Java until I have to jump into a specific feature for other teams.
    - Redimo 5y ago
      I never said there is a difference? I'm talking about Java <-> Python/qiskit/jupyter. Its a very different way of doing things, but just as enjoyable, and I'd say it's the currently best solution for any r&d and prototyping
krastanov 5y ago
This seems like the first "quantum programming language" that actually contributes something interesting, besides being yet another way to write low-level commands to your quantum simulator (or experiment). I am very excited to see a language where the type system and the rest of the construct actually contributes something useful, as opposed to yet another useless SDK.
Strilanc 5y ago
It's very concerning that the type system can't understand quantum teleportation without adding manual assertions verified by a state vector simulator (exponentially costly in number of qubits) [1]. Similarly, teleportation takes 13 lines to specify, instead of 13 characters [1]. For context, teleportation is like the swiss army knife of quantum computing. You're gonna be using variations of it everywhere so it'd better be easy to write and fast to check. As an analogy... imagine if declaring a local variable required you to manually request a runtime check that its address wasn't the same as the address of another local variable. It's ridiculous overhead for something that should be transparently correct. More fundamentally, as someone who has done some compiling of quantum algorithms down into gates, I don't see how it would have been useful to me to solve the problem that this language's type system solves (are two quantum states separable or entangled). In basically any algorithm I can picture, the qubits are all immediately entangled, and they stay entangled until they are measured. Almost any situation where a state goes from entangled to separable (without a measurement) is an opportunity to optimize that state out of the algorithm. The main exception I'm aware of is catalysis, where the catalyst state should be restored by the end. To me this language looks like I pay a huge boilerplate tax to receive a benefit I can't really use. I think they need to iterate more on how the type system can be helpful and on reducing boilerplate before I'd download it. [1] Fig 4 of https://dl.acm.org/doi/pdf/10.1145/3498691 https://dl.acm.org/doi/pdf/10.1145/3498691
- krastanov 5y ago
  From my superficial understanding, your goals (e.g. compilation into realistic gates) are very different from the goals of these language designers (study of abstract structure of quantum algorithms). Also, I tend to strongly disagree with your first paragraph: if teleportation was "built-in" for the language, then the language would be useless for anything but "numerics" - it would be a Fortran instead of being a Lisp. When you study abstract algorithmic structures, you want to be able to access such low-level implementations. And once they have defined their `teleport` function (in something like a standard library), they can reuse it wherever they want (hence addressing your worry).
  - Strilanc 5y ago
adamnemecek 5y ago
Here’s the GitHub repo https://github.com/psg-mit/twist-popl22 https://github.com/psg-mit/twist-popl22
go_elmo 5y ago
Still prefer silq [0]. [0] https://silq.ethz.ch/ https://silq.ethz.ch/

88 points by georgehill 5y ago

I think this made the top of HN a few days ago: https://ionq.com/posts/june-24-2021-hello-many-worlds https://ionq.com/posts/june-24-2021-hello-many-worlds I was disappointed that all of them were Python libraries (besides Microsoft's Q#, but I don't find a C#-like language attractive either), so I'm definitely interested in what it looks like coding in Twist.

Redimo 5y ago
I feel you. I write mostly Java code, but I've worked heavily with python + qiskit for quantum ML the past 3 months, and it's excellent. Qiskit is "low" level enough to give me the freedom I want, and with Jupyter Notebooks it's just so much easier to quickly construct something and evaluate, as well as extract it in a way I can put it in a paper.
- throw1234651234 5y ago
  C# and Java feels exactly the same to me now that Java has lambda/stream collection methods to match LINQ. Not sure how you feel there is any difference between the two. The only difficulty I have is when I have to work with Java Frameworks, even though I "never" use Java until I have to jump into a specific feature for other teams.
  - Redimo 5y ago
    I never said there is a difference? I'm talking about Java <-> Python/qiskit/jupyter. Its a very different way of doing things, but just as enjoyable, and I'd say it's the currently best solution for any r&d and prototyping

krastanov 5y ago

This seems like the first "quantum programming language" that actually contributes something interesting, besides being yet another way to write low-level commands to your quantum simulator (or experiment). I am very excited to see a language where the type system and the rest of the construct actually contributes something useful, as opposed to yet another useless SDK.

Strilanc 5y ago

It's very concerning that the type system can't understand quantum teleportation without adding manual assertions verified by a state vector simulator (exponentially costly in number of qubits) [1]. Similarly, teleportation takes 13 lines to specify, instead of 13 characters [1]. For context, teleportation is like the swiss army knife of quantum computing. You're gonna be using variations of it everywhere so it'd better be easy to write and fast to check. As an analogy... imagine if declaring a local variable required you to manually request a runtime check that its address wasn't the same as the address of another local variable. It's ridiculous overhead for something that should be transparently correct. More fundamentally, as someone who has done some compiling of quantum algorithms down into gates, I don't see how it would have been useful to me to solve the problem that this language's type system solves (are two quantum states separable or entangled). In basically any algorithm I can picture, the qubits are all immediately entangled, and they stay entangled until they are measured. Almost any situation where a state goes from entangled to separable (without a measurement) is an opportunity to optimize that state out of the algorithm. The main exception I'm aware of is catalysis, where the catalyst state should be restored by the end. To me this language looks like I pay a huge boilerplate tax to receive a benefit I can't really use. I think they need to iterate more on how the type system can be helpful and on reducing boilerplate before I'd download it. [1] Fig 4 of https://dl.acm.org/doi/pdf/10.1145/3498691 https://dl.acm.org/doi/pdf/10.1145/3498691

krastanov 5y ago
From my superficial understanding, your goals (e.g. compilation into realistic gates) are very different from the goals of these language designers (study of abstract structure of quantum algorithms). Also, I tend to strongly disagree with your first paragraph: if teleportation was "built-in" for the language, then the language would be useless for anything but "numerics" - it would be a Fortran instead of being a Lisp. When you study abstract algorithmic structures, you want to be able to access such low-level implementations. And once they have defined their `teleport` function (in something like a standard library), they can reuse it wherever they want (hence addressing your worry).
- Strilanc 5y ago

adamnemecek 5y ago

Here’s the GitHub repo https://github.com/psg-mit/twist-popl22 https://github.com/psg-mit/twist-popl22

go_elmo 5y ago

Still prefer silq [0]. [0] https://silq.ethz.ch/ https://silq.ethz.ch/