Programs are a prison: Rethinking the fundamental building blocks of computing interfaces
我们经常听到，苹果的应用程序生态系统（或微软的，或谷歌的）是 "围墙花园"。但单个应用本身呢？
事实上，单个程序甚至是更有害的围墙花园--对真正的表现力、生产力、自由度和计算体验的一致性构成了窒息性的障碍。
想想在表格结构中把一些数字加起来。这在大多数编程语言中都是直接的。但如果同样的表格出现在网页、移动应用或PDF中呢？它就在屏幕上，它可能在标记中被编码为一个表格。所以数据就在那里。然而，我们无法查询它。
也许如果我们复制和粘贴它，我们可以查询它。或者我们可以下载页面，保存到磁盘上，写代码加载页面，解析表格，然后将数据转储到数据库中。
但为什么我们需要做这些事情呢？为什么我们不能直接查询呢？
每个程序周围都有一堵墙，阻止了这种事情的发生。一个个程序挡住了我们的路，挡住了我们的表达能力和计算自由。就像伟大的国家一样，伟大的软件应该建立桥梁，而不是墙。
除了独立的应用程序，软件会是什么样子？没有墙的软件会是什么样子？
面向对象编程的概念由来已久，耳熟能详。在OO的全盛时期，人们寄予厚望，认为OO将允许更高层次的表现力和封装，以及随之而来的更大程度的代码重用和重新组合。
但这绝对没有实现--问题又一次出现在应用程序上。Photoshop的代码库和Instagram的代码库无疑都定义了复杂的Image对象，但每一个都只存在于其封闭的监狱中。
一个真正有表现力的系统会让我们无缝地将任何滤镜应用到任何图像上，但这目前还不可能。
每个人对Image的含义和能做的事情都有一个完全独立的概念--每个应用基本上都是从头开始重建一个对象的意义。如果我们对互操作性、重用性和一致性感兴趣，这是一个糟糕的情况。
我们需要计算环境，其中的构件是固有的可互操作的对象--直接与之交互，根本没有应用的概念出现。
目前，最引人注目的软件是将最多的功能锁定在其中的软件--在对象的环境中，最引人注目的软件将是将最多的可互操作的可再组合的功能暴露给周围的对象。
这绝不是一个新的或原创的想法--Alan Kay和Smalltalk领域的朋友们已经用Squeak这样的东西玩了几十年了。类似的想法在业务系统的实现中也得到了很好的应用，比如裸露的对象，也就是用户界面应该由它所代表的对象直接生成的概念。