当 CORBA 和 Java 还都很重要的时候，设计 CORBA 的 OMG 鼓吹所有编程语言都应该围绕 CORBA 的接口定义语言 (IDL) 进行面向对象设计；而 Sun Microsystems 则宣扬所有系统都要映射为 Java 的对象模式，数据库要用 Enterprise JavaBean，CORBA 也该被封装为 RMI over IIOP。这是本质一样而方向相反的两支传教队伍抢夺同一群开发者的口角。值得注意的是，这场博弈的每一方依然需要对方去做自己无法胜任的工作（尽管不是唯一的选择），基于 CORBA 的开发不能离开具体编程语言，Java 也需要远程调用实现，但都坚持宣称对方应该照自己的思维模式行事。
CORBA, EJB, RMI 都已被开发者忘记，但类似的博弈永远存在。 主流的硬件图形接口中，Direct3D 继承了 Windows 95 时代一切封装为 COM 的文化遗产（尽管 Microsoft 自己现在也对这个文化有点心虚），macOS/iOS 秉承采用动态语言的传统实现 Metal（尽管 Apple 在 Objective-C 和 Swift 之间如何分配资源还略难取舍），Vulkan 为了跨平台采用 plain-C 接口。
现在的游戏或者专业图形软件很少直接用硬件图形接口开发，而是通过封装抽象层支持多个具体的硬件图形接口。如此一来避免了选择支持何种接口的非此即彼的问题。所以「思维模式」的博弈远离了关于选择操作系统特有接口还是 Vulkan 的问题。影响开发者思维模式主要体现在抽象层设计上。硬件图形接口本身的影响力决定了大多数抽象层接口要如何设计，是否会向某个具体接口的设计靠拢。每个抽象层的设计和传播都会影响具体图形接口在开发者中的口碑和初学者的选择。
暂时不谈如何影响抽象层设计，Vulkan 在 macOS/iOS 上面临的首要问题是 Apple 并不支持它，压根儿不能用也就谈不上思维方式的传播了。但有热心的第三方做出 MoltenVK，用 Metal 实现 Vulkan APIs，绕过了 Apple 不允许硬件厂商直接发布驱动程序的限制。但作为 Metal 的 thin-wrapper，它没法实现完整的 Vulkan。其开发者解释为了性能和实现简单只实现 Vulkan 中可以比较直接地对应到 Metal 的部分，即便如此移植个 Dota 级别的游戏并不在话下。这样终于把 Vulkan 推广到了 macOS/iOS 上。
但操纵思维模式并不是件直截了当的事情，其作用和反作用往往难以预料。MoltenVK 恰恰证明 Metal 已经直接体现了 Vulkan 中大部分概念，至于剩下的那些不能被直接体现的部分有多重要也许见仁见智。但 MoltenVK 本身就在向开发者发出不建议使用这部分的信号。你想想，只要 Vulkan-based 代码能忍住不去用几个少数 MoltenVK 不支持的 Vulkan 独门概念，就能无痛移植到 macOS/iOS 上，岂不美哉！如此反而给 Metal 的思维方式加了一道吸引开发者的筹码。推广跨平台思维方式的努力，经常还是被操作系统本身的优势消散于无形。
当然还有一种可能：除了 Unity 和 Unreal 引擎的维护者，压根没有别人再会去用 Metal/Vulkan 这样的硬件图形接口。就像 CORBA, Java, RMI，它们试图影响开发者的思维方式，最终被另一个层次的替代者掩埋在记忆中。
技术奇异点 