量子运算开发套件Q#未来怎么走?

量子运算开发套件Q#在2017年底发布以来,已经满一年,微软也在今年初开源并新支持了macOS与Linux桌面平台,以扩大开发者人数,而在年末的时候,微软对外说明了Q#的设计理念与接下来的发展方向。

微软发布Q#的原因,除了要让量子开发更容易,同时也希望能满足特定场景的需求,像是微软预告添加的自动化功能,以自动化原本需要手动的工作,微软提到,量子比特布局和量子闸合成,通常仍需要针对每个程序和目标硬件逐一进行,而自动化作业可以加速这个过程。

另外,Q#也能解决开发人员经常会担心程序代码在硬件上执行时的错误纠正问题,以及由于量子比特现在仍是稀缺资源,微软认为,量子运算的长期目标应该是被用来解决,当前硬件还无法解决的计算密集行工作,微软也希望在开发工作上,大规模量子程序优化应该被当作优先事项。

因此微软选择开发自有的语言,以便对消息的表达方式拥有完全的控制力,使其富有弹性,以及在量子编译时期能够支持模块化与可扩展软件架构。微软提到,程序语言不仅代表一组方便用来表达算法的工具,也同时塑造了开发者思考问题的方法,以及拆解问题成小任务并构建解决方案的方式。

根据目的调整和组合这些工具,程序语言可以对理解现有方法产生极大的影响,更不用说用在全新领域上。微软想集合程序语言设计人员、编译器工程师、量子物理学家、算法和硬件专家以及各种软件开发者,为量子运算塑造一种新的运算架构。

2018年11月Q#发布了0.3版,官方现在已经着手准备下一个版本,并且说明了Q#发展的方向。微软提到,Q#中对数据结构的支持很少,虽然提供了许多高级语言功能来抽象经典概念以及量子控制流,但刻意省略了一些诸如类别等面向对象的机制。

微软未来会将重点放在修正量子态的转换,将其表完成Q#中的操作以及在未来的特性和关系。然而,数据的基本捆绑和这些操作为许多程序重要的部分,微软希望提供适当的机制来表达,以允许达到抽象、方便以及抵抗程序代码编写错误。

除了增加的类型安全性之外,当前设置中的用户定义类型的能力受限,目前以黑盒子的方式将类型参数化,因此限制了他们的用途。由于微软没有提供动态反射的机制,因此不可能将运算符或是其他类型特定功能,应用于每个单独调用解析其类型的参数项目。因此就这个设计的意义来说,这些项目只是个黑盒子,仅能用于传递。

由于量子设备调试非常困难,微软希望能以静态的方式,执行这些繁重的工作,微软提出了两种可能的机制,以来减轻这些负担,其中一是类型限制,这是一种的常见于热门语言的机制,可以被视为基于类型属性的专业化,另一种则是根据实际类型本身,追求更严格的专业化方向,以增加目前避免使用的重载的类型。而无论是哪一种方法,通过明确地将用户定义的类型,与类型系统中的元组分开,是跨出扩展其能力的第一步。

微软表示,Q#借助社群的力量不断发展,虽然量子运算创建在量子力学之上,一般人因为对于这领域不熟悉而却步,但是又因为量子运算创建在理想化量子系统的概念上,因此也符合部分容易学习的原则。微软通过Q#dev博客的文章传递这些原则,并促使开发人员进行交流。