Silq and QUA vie for Quantum computing language

Posted on by Ray in Quantum Computing, System effectiveness, System quality

Read a couple of articles this past week on new Quantum computing programing languages. Specifically, one in ScienceDaily on Silq, (The 1st intuitive programming language for quantum computers) and another in TechCrunch (Quantum Machines announces QUA, its universal lang. for quantum computing). The Silq discussion is based on an ACM SIGPLAN paper (Silq: A High-Level Quantum Language with Safe Uncomputation and Intuitive Semantics). programing

Up until this point there have been a couple of SDK’s for various quantum computers, most notably QASM for IBM’s, Q# for Microsoft’s and ? for Google’s Quantum Computers. We have discussed QASM in a prior post (see: Quantum Computer Programming post).

But both QUA and Silq are steps up the stack from QASM and Q#, both of which are more realistically likened to machine microcode thanassembly code. For example, with QASM you are talking directly to mechanisms to cohere qubits, electronics needed to connect qubits, electronics to excite qubit states, etc.


QUA and Silqs seem to take different tacks to providing their services.

Silq control flow
  • Silq is trying to abstract itself above the hardware layer and to provide some underlying logical constructs and services that any quantum programmer would want to use. Most notably, Silq mentions that they provide automatic erasure of intermediate calculations results which can impact future quantum calculations if they are not erased. They call this “specific uncomputation“. Silq also offers types, loops, conditionals, superposition (the adding together of two quantum states) and diffusion (spreading of quantum states out).
  • QUA on the other hand is Quantum Machines full stack implementation for quantum computer orchestration. QUA is only a one component of this stack (the highest level) but underneath this is a compiler and a Quantum Machine OPX box, a hardware appliance that interfaces with quantum computers of various types. There’s not much detail about QUA other than it offers conditionals and looping constructs and internal error detection.

From what I see, we are a long ways away from having a true programming language for quantum computers. Quantum Machines sees the problem with today’s quantum computers as the lack of a stack problem.

The Silq group see the problem with today’s quantum computers as a lack of any useful abstraction problem. Silq is trying to provide simpler semantics and control structures that maybe someday could become the foundation of a true quantum computing programming language.

Silq has compared itself to Q#, used in Microsoft’s Quantum Computing solution. So our guess is it works only with Microsoft’s quantum computer.

In contrast, QUA offers an orchestration solution for many different quantum computers but you have to buy into their orchestration hardware and stack.

Who will win out in the end is anyone’s guess. There’s a great need for something that can abstract the quantum hardware from the quantum algorithms being implemented. At the moment I like what I see in Silq just wish it was applied more generically.

At press time there were not many details available on Quantum Machines QUA language. Their stack approach may be better in the long run, but having to use their hardware appliance to run it seems counter productive.

~~~~

However, if the programming gods were to ask my opinion as to where a new programming language was really needed, I’d have to say neuromorphic computing (see Our neuromorphic chips a dead end? post). Neuromorphic computing really needs abstraction help. Without some form of suitable abstraction layer, neuromorphic computing seems dead as it stands.

Comments.

Picture Credit(s):

Published by Ray