11

非类型化的Python:曾经的 Python

 9 months ago
source link: https://www.techug.com/post/untyped-python-the-python-that-was/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

非类型化的Python:曾经的 Python

关于 Python 类型化,人们已经说了很多。如果你一直在 Twitter 上关注我(或者你有幸与我共事),你可能知道我对 Python 类型化持怀疑态度。这源于语法的复杂性、mypy 的迟缓、其实现的整体繁琐性以及与之交互时的尴尬。今天我就不再赘述这些细节了,而是想带大家回顾一下我早期使用 Python 的经历。为什么呢?因为我相信 Python 的内在哲学与类型概念之间的冲突是根本而深刻的,但也并不新鲜。

类型化编程语言的概念远远早于 2015 年。它们不是现在才发明的。关于类型化必要性的争论也不是最近才出现的。当你想启动一个新的软件项目,尤其是类似于网络服务的项目时,你总是可以选择编程语言。早在 2004 年,当我开始涉足编程时,就有很多语言可供选择。传统的选择不是 Python,显而易见的选择甚至不是 PHP,而是 Java。鉴于其类型系统和企业级功能,Java 是严肃网络应用项目的首选。PHP 是玩具,Python 则无处可寻。PHP 很流行,但在我的圈子里,它总是被视为一个完全荒谬的概念,而有人会在它的基础上建立业务的想法更是如此。我记得在大学一年级的时候,流行的观点是现实世界是在 .NET、Java 和 C++ 的基础上运行的。PHP 被嘲笑,Python 和 Ruby 没有出现在对话中,服务器上的 JavaScript 也不存在。

然而,我却在这里用 PHP 和 Python 构建东西。我之所以选择这两种语言,并不是因为懒惰而厌恶静态类型化,而是因为这两种语言提供了卓越的开发体验,其中很大一部分原因就是缺少类型。开发者的体验非常出色。是的,它没有智能感知,但我所做的所有改动都会立即出现在网页上。我还记得通过 FTP 直接实时修改实时网站。后来在生产服务器上直接用 vim 编辑网站。这是不是很可怕?当然。但该死的是,它很有成效。我从中学到了很多。他们教会了我关于取舍的宝贵经验。不仅是我,使用这些语言的整整一代开发人员都认识到,我们最大的弱点(没有类型化,也没有编译)也是我们最大的优势。这需要一点克制,也需要一种略有不同的编程方式,但它却能带来令人难以置信的成果。

那是 XPath 的世界,那是 DTD 的世界,那是 SOAP 和 WSDL 的世界。在这个世界里,系统的固有复杂性是如此之高,以至于你绝对需要一个集成开发环境、代码生成和编译工具。与之形成鲜明对比的是我的世界。我的世界里有 Vim、CVS、SVN 和一个基本的 Linux 操作系统,我可以构建出让我引以为豪的东西。我最终把 PHP 换成了 Python,因为它对我来说有更好的优势。但我永远不会忘记 PHP 带给我的一切:我从它身上学到,并不是所有东西都必须漂亮,它必须能解决问题。它确实做到了。

但与 PHP 一样,我和 Python 语言运行时之间的接触面也很小。我写的代码会被解释器转换成字节码指令(你甚至可以看一下!),并由解释器中的一个小循环进行评估。解释器是开源的,易于阅读,最重要的是,我可以在解释器中四处探索。通过这种方式,我不仅能够学习到更多的计算机知识,而且还能非常容易地理解到底发生了什么。毫无疑问,我能够理解我编写的代码和运行的代码之间的一切。

是的,当时还没有静态类型检查,intellisense 基本上也不存在。微软等公司甚至还不认为 Python 是一种语言。但是,去他的,我们是有生产力的!不仅如此,我们还构建了大型软件项目。我们知道如何取舍。在生产过程中,由于传递了错误的类型,我们的运行时错误频发,但我们也有相应的工具来处理这些错误!我清楚地记得,当我向一位来自 .NET 界的同事展示我所拥有的一些工具时,他是多么的震惊。在我部署了糟糕的代码,结果却让人大吃一惊后,我收到的电子邮件不仅显示了完全可读的堆栈跟踪,还显示了框架的源代码。当我向他展示我有一个模块可以远程连接到正在运行的解释器,并在运行中执行 Python 代码进行调试时,他更是大吃一惊。

但请听我说:所有反对动态语言和动态类型系统的论点都已经存在!没有什么新发明,也没有什么真正的改变。我们都知道类型化的价值,我们也都集体说:去它的。我们不需要这个,我们需要鸭子duck类型。让我们好好利用这一点吧。

现在的变化是:我们不再那么信任开发人员,我们正在重新引入我们曾经反对的复杂性。现代 Python 有时会让开发人员无法理解。在某些方面,我们正在创造新的 Java。我们变成了最初被我们取代的人。只是一不小心,我们就会走上世界上最糟糕的 Java 的道路。我们在一种不支持类型化的语言中加入了类型化,我们的解释器很慢,它有一个 GIL。我们需要小心,不要忘记我们的根在别处。我们不应该共同抛弃我们曾经拥有的优势。

风向变了,这是不可否认的。其他语言已经证明,类型能以令人兴奋的新方式增加价值。我最初与人争论 Python 与 Java 的类型问题时,Java 甚至还没有泛型。JavaScript 当时还在与 “令人难以忍受的玩具 “的名声作斗争。TypeScript 离诞生还有好几年的时间。虽然没有发明什么新东西,但有些东西却得到了普及。抽象数据类型不再是研究人员的玩具。.NET 开始混合使用静态和动态类型,TypeScript 则在后来普及了为原本没有类型的语言添加类型。我们的社区中也有更多的开发人员不太可能理解这些语言最初的魅力所在。

我们该何去何从?这是一个脾气暴躁的我在抱怨逝去的时代,抱怨类型是如何毁掉一切的吗?很难说。类型化有其不可否认的作用,也有可能提高整体工作效率。然而,固有的利弊权衡并没有改变,选择或反对类型化应该是一种没有污名的选择。这一决定的核心原则并没有改变:类型化会增加价值,也会增加成本。

本文文字及图片出自 Untyped Python: The Python That Was


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK