(本文独家发布在金蝶云社区上)
在Quora的帖子中，Alan Kay对程序员的工具状态感到遗憾。几乎每个另外的工程学科都建立了现代计算工具：用于计算机辅助设计，模拟和测试，以及用于制造。 但自20世纪70年代以来，编程并没有取得很大进展。我们为其他人建立了很好的工具，但我们自己却没有趁手的工具。 俗话说：鞋匠的孩子的鞋子上有洞。
Kay的观点并不完全正确，但在分析他观点的瑕疵之前，先看看Kay观点里合理的部分是十分重要的。但是如果我们不理解他观点合理的部分，我们当然不会明白接下来要构造什么，不确定的未来可能会盯着我们。
让我们从编程本身开始吧。目前我们仍在使用打卡编程，只是现在可以在高分辨率显示器上进行模拟传统编程。我们仍在使用字母数字字符集进行面向“行”的编程。我们仍在使用编程语言，这些编程语言在很大程度上表现得像C或类似LISP，编程社区中最大的争论是关于哪些史前范例更好。 我们有IDE可以更容易地生成这些虚拟打卡，但不会从根本上改变野兽的性质。我们有一些单元测试工具，但它们要求我们编写更多的穿孔卡（单元测试）。 我们有版本控制工具来管理这些针对穿孔卡的更改。 我们甚至拥有持续集成，持续部署和容器编排的工具 - 所有这些工具都可以通过创建更多的虚拟穿孔卡进行编程。
数据库开发人员的状况要好一些。像SQL这样的非过程语言更容易使用自己的可视化编程风格，产生像Tableau这样的工具，尽管如果你将企业应用程序连接到后端数据库，这些工具也无济于事。
我们离开这里的话(传统编程)，究竟可以到哪里？我一直以为真正的下一代编程语言不会重复LISP，C或Smalltalk语法。它根本不是基于字符的：它将是基于视觉的。代替我们之前的通过打字来编程，我们应该画出我们想要的东西。我还没有看到适合该规则的语言。不过像Alice和Scratch这样的教学平台倒是一个有趣的尝试，但它们并没有走得太远：他们只是采用我们已经知道的编程语言并应用一些视觉隐喻。 比如，用C型夹具来代替循环结构，用插件块代替关键字，看到了吧，貌似什么都没有改变。
我怀疑我们需要的可视化编程语言将会从我们所有的编程范例中借鉴思想：它可以传递消息，它也具有对象，它支持并发，等等。 但是它没有文字性表示; 它不会是像C这样的基础语言外加视觉糖衣。
我对这种语言的来源有一些想法。 我看到两种趋势可能有助于我们思考编程的未来。
首先，我看到越来越多的证据表明有两种程序员：通过将其他模块连接在一起来构建模块的程序员，以及创建模块用来给其他人连接的程序员。第一个种类是“蓝领”程序员群体;第二个是“学术”程序员群体 - 例如，目前在人工智能领域做出开拓性工作的人们。其实两组都没有比另一组更有价值或更重要。建筑交易领域提供了一个很好的比喻。如果我需要安装一个新的厨房水槽，我会打电话给水管工。他知道如何将水槽连接到管道的其他部分;但是他不知道如何设计水槽。在某个办公室里有一个水槽设计师，他们可能（以一种基本的方式）了解如何将水槽连接到管道，但他们在设计水槽方面的真正专业知识，而不是安装水槽。你也离不开它，尽管这个世界需要比设计师更多的管道工。软件行业也是如此：构建Web应用程序的人数远远大于构建像React这样的Web框架或者设计新算法并进行基础研究的人数。
计算管道工应该使用与算法设计人员相同的工具吗？ 我不这么认为; 我可以想象一种高度优化的语言，用于连接预先构建的操作，但不能用于构建操作本身。 您可以在将函数应用于列表的每个元素的语言中看到这一点：您不再需要循环。（Python的map（）将函数应用于列表的每个元素;有些语言的函数会自动运行。）您可以将PHP视为一种适用于将网页连接到数据库的语言，但实现加密算法却很糟糕。 也许这种连接语言可能是视觉的：如果我们只是连接一堆东西，为什么不使用行而不是代码行？ （Mel Conway正致力于“接线图”，允许消费者通过描述交互场景来构建应用程序。）
其次，人工智能中最有趣的研究领域之一是生成代码的能力。几年前，我们看到AI能够优化数据库查询。 Andrej Karpathy认为，这种能力使我们处于软件2.0的边缘，其中AI将生成我们需要的算法。如果将来AI系统能够编写我们的代码，我们需要什么样的语言来描述我们想要的代码？那种语言当然不会是一种带有循环和条件的语言;我也认为它不是一种基于函数给出的数学抽象的语言。Karpathy建议该语言的核心将是用于训练AI模型的标记数据集。我们将向计算机显示我们希望它执行的操作，而不是编写分步说明。如果您认为这样的编程范式过于激进，离制造可以帮我们编程的机器太远，请考虑20世纪50年代的机器语言程序员会想到现代优化编译器吗？
所以，虽然我还无法想象新的视觉语言会是什么样子，但我能感觉到我们已经处于能够构建它的边缘了。 事实上，我们已经在构建它。 Jeremy Howard在platform.ai的项目之一是一个允许主题专家在没有任何传统编程的情况下构建机器学习应用程序的系统。另外微软已经推出了一种可以拖放的机器学习工具，它提供了一个图形工具，用于组装训练数据，清理数据，并使用它来构建模型，而无需任何传统的编程。 我想有人可能认为这“不是真正的编程”，但这等于通过依赖古老工具来定义编程。
那么其他剩下的工具呢？用于构建，测试，部署和管理软件的工具是什么情况呢？
kay在这里低估了我们所拥有的东西。所以这一点我不敢苟同，因为这方面我们确实还是有一些范例的;这也说是我们的基础。我们拥有超过40年的构建工具经验（从1976年就出现的make工具），以及类似的自动配置经验（CFengine，Chef和Puppet的前身，他们可以追溯到90年代），网络监控（Nagios的历史可以追溯到2002年）和持续整合（Hudson，Jeeves的前身，可追溯到2005年）。处理容器编排的Kubernetes是“街区新生儿”。Kubernetes是分布式系统的机器人自动化工厂。它是管理和运行大型软件部署的工具，可以在多个节点上运行。这真的是一个完整的工具套件，从自动装配到自动化测试再到全自动化生产。我们唯一的工作就是，关灯！睡觉！其他的都交给让计算机区完成。
遗憾的是，这些工具的工作机制仍然是基于虚拟穿孔卡（文本文件，通常是XML，YAML，JSON或同样令人不愉快的东西），这是一个必须克服的问题。但是我认为这个问题并不困难 - 为这些工具创建视觉语言比创建视觉语言本身要容易得多 - 这是一种传统。
软件人员习惯于使用糟糕的工具。虽然我们讨厌被迫使用计算机上古时代的物理穿孔卡（我之前确实接触国，确实很不好玩），但是如果你将这些穿孔卡虚拟化，我们还能将就着使用。也许这是一种信息仪式，或者是一种工业欺诈。
Kay的这一点是对的，我们不应该对这种状况感到满意。使用20世纪60年代开发人员可以立即理解的工具构建软件的痛苦使我们不得不考虑这些位，而不是那些位的含义。作为一个行业，我们需要超越这一点。我们有一些我们需要的工具的原型。我们只需要完成这项工作。
我们需要为软件开发想象出一个不一样的未来。
推荐阅读