1 类型的效率和安全

语言的类型安全很少有绝对的。安全通常为程序员提供“逃生口”，例如对用其他语言编写的代码的外部函数调用，可能是不安全的语言。

事实上，这种逃生口有时会在语言本身内以受控形式提供——OCaml 中的 Obj.magic(Leroy, 2000), Unsafe.cast 在新泽西州执行标准ML 等 Modula-3 (Cardelli et al., 1989; Nelson, 1991) 和 C] (Wille, 2000)。

更进一步，提供一种旨在实施的“不安全的子语言”低级运行时设施，例如垃圾收集器。

特殊功能这种子语言的一部分只能在明确标记为不安全的模块中使用。
Cardelli (1996) 阐述了一种不同的语言安全性观点，区分所谓的捕获和未捕获的运行时错误。

捕获的错误会导致计算立即停止（或引发可以在程序中干净地处理的异常），而未被捕获错误可能允许计算继续（至少一段时间）。

未捕获错误的示例可能是访问超出末尾的数据像 C 这样的语言中的数组。在这种情况下，一种安全的语言可以防止运行时未捕获的错误。

还有一种观点侧重于可移植性。它可以表示为口号，“安全的语言完全由其程序员手册定义。”
让语言的定义成为程序员需要的一组东西理解以预测语言中每个程序的行为。

那么像C这样的语言的手册并不构成定义，由于某些程序的行为(例如，涉及未经检查的数组如果不知道特定 C 编译器如何在内存中布局结构等细节，则无法预测访问或指针算术），并且同一个程序在被不同的编译器执行时可能会有完全不同的行为。

相比之下，用于/和指定的手册（具有不同的严格程度）语言中所有程序的确切行为。一个类型良好的程序在任何正确的实现下都会产生相同的结果这些语言中。

1.1 效率

计算机科学中的第一类系统，从 1950 年代开始使用 Fortran (Backus, 1981) 等语言，被引入以提高效率。

通过区分整数值来提高数值计算的效率算术表达式和实值表达式；这允许编译器使用不同的表示并生成适当的机器指令原始操作。

在安全语言中，进一步的效率改进是通过消除许多需要的动态检查来获得保证安全（通过静态证明他们将永远得到满足）。

今天，大多数高性能编译器严重依赖收集到的信息在优化和代码生成阶段由类型检查器执行。甚至本身没有类型系统的语言的编译器努力恢复此类型信息的近似值。依赖类型信息的效率改进可能来自于一些令人惊讶的地方。

例如，最近已经表明，不仅代码使用类型分析生成的信息可以改进并行科学程序中的生成决策以及指针表示。在Titanium 语言 (Yelick et al., 1998) 使用类型推断技术来分析指针的范围，并能够做出明显更好的决策在此基础上，程序员显式地手动调整他们的程序。

在ML Kit Compiler中 使用了更强大的区域推断算法（Gifford、Jou velot、Lucassen 和 Sheldon，1987；Jouvelot 和 Gifford，1991；Talpin 和朱维洛，1992；托夫特和塔尔平，1994，1997； Tofte 和 Birkedal，1998 年）到将垃圾收集的大部分（在某些程序中，全部）替换为基于堆栈的内存管理。

1.2 类型系统和语言设计

记住将类型系统改造成未设计类型检查的语言可能很棘手；理想情况下，语言设计应该与类型系统一起设计。

---Alf (Magnusson and Nordström, 1994) 直接基于类型论。Constable (1998) 和 Pfenning (1999) 讨论了这些系统的历史。

数据库社区对类型系统的兴趣也在增加，随着以文档类型定义（XML 1998）和其他类型的模式（例如新的 XML-Schema标准 [XS 2000]) 用于描述 XML 中的结构化数据。

新语言查询和操作 XML 提供了强大的基于静态类型系统直接针对这些模式语言

---（Hosoya 和 Pierce，2000；Hosoya、Vouil lon 和 Pierce，2001；Hosoya 和 Pierce，2001；Relax，2000；Shields，2001）。

类型系统的一个完全不同的应用出现在计算语言学领域，其中类型化的 lambda 演算构成了形式主义的基础例如分类语法

---（van Benthem，1995；van Benthem 和 Meulen，1997；兰塔，1995；等等。）。

造成这种情况的一个原因是，没有类型系统的语言——即使是安全的、动态检查的语言——往往会提供使类型检查变得困难或不可行的特性或鼓励编程习惯用法。

确实，在键入语言类型系统本身通常被视为设计和组织原则的基础，根据它的其他方面设计被考虑。

另一个因素是类型语言的具体语法往往是比无类型语言更复杂，因为类型注释必须考虑在内。做好清洁设计工作更容易当所有问题都可以一起解决时，语法可以理解。

类型应该是编程语言的一个组成部分的断言与程序员必须在哪里物理写下类型注释以及它们可以在哪里推断的问题是分开的由编译器。

设计良好的静态类型语言永远不需要由程序员显式且繁琐地维护大量类型信息。但是，对于多少有一些分歧显式类型信息太多。

ML 中的语言设计者努力将注释保持在最低限度，使用类型推理方法来恢复必要的信息。 C语言家族，包括 Java，都选择了更加冗长的风格。

2 小结

每个语言和应用程序在安全性方面都有不同的要求。
例如，与医疗保健相关的应用程序可能需要 HIPAA 合规性，或者金融应用程序可能需要 PCI 合规性。
在选择正确的堆栈时，我们还考虑了更一般的安全建议，例如 OWASP Top 10。
密切关注所选堆栈的安全公告将有助于应用程序更加健壮。

需要注意的是，在后单体软件世界中，技术决策在应用程序生态系统中并不相互排斥。
我们越来越多地实现微服务架构，因此我们可以运行基于不同编程语言和框架构建的单个服务。

通过这种方式，我们可以确保每个特定任务都由最佳平台提供服务。
凭借我们广泛的经验和专业知识，并坚持良好代码的标志 - 可维护性，简单性，YAGNI，干燥，固体和可测试性 - 我们能够始终如一地指导我们的客户找到最有效的技术解决方案。