Python和其他人使用import获取外部功能的技术。
C和其他人使用include（例如C ++，伴随着namespace头痛）。
在设计语言时，选择其中一个（或使用Objective-C之类的内容）的原因是什么？
我看到Apple正在通过一篇论文向LLVM提出一些更新/更改，并想知道为什么存在差异。
鉴于有多种方法可以实现import（我的答案之前我还没有意识到），!include与include的整体好处是什么？ import技术似乎只 根据给定的路径找到单个子组件（至少在Python中 - 其[明显]方法是我所知道的唯一方法。）
import方法的其他用途与此有何不同？何时使用“旧式”include方法在现代语言设计和实现中有意义（如果有的话）？
答案 0 :(得分：9)
C的方法，C ++和Objective C简单地继承，定义和实现非常简单（简而言之，“当遇到#include时，将其替换为文件的内容，并继续” ），但有严重的问题。其中一些问题在您看过的演示文稿（以及其他地方）中有所说明。有成语和最佳实践（也在该演示文稿和其他地方讨论过）和次要扩展（#pragma once，预编译标题），可以缓解一些问题，但最终，这种方法基本上只限于处理软件工程师对模块系统的期望。假装它可以做更近期的替代方案（见下文）是一个非常漏洞的抽象。
如今，每个对语言设计有意见的人似乎都同意，如果你能提供帮助，你就不应该这样做。由于需要向后兼容性，C ++和Objective C没有这个选择（尽管两者都有并且仍然可以选择添加另一种机制，而Objective C就是这样做的）。这对于它来说是“公平的”，因为这是一个相当不错的决定（当它有效时，它仍然有效，如果你有纪律），但世界已经转向并采取更好的方式将代码拆分为模块，然后将其重新组合在一起。 （请注意，这种方式早在C日就已经存在，但显然它们并没有流行一段时间。）
您所描述的“{”import技术实际上是一个非常大的设计空间。许多模块系统几乎（但并不完全）彼此完全不同 - 其余模块系统仍有足够的细微差别来毁掉你的一天。它可以是任何东西，从在新范围（Python，PHP）中执行导入的文件到完全成熟的ML风格的仿函数。有一些相似之处，因为所有这些模块系统都给每个“模块”（无论在相应系统中意味着什么）它们自己的范围/命名空间，（通常）允许单独编译模块，并且通常会不经意地修复它们。 C风格文本的问题包括（或者创作者用替代方案看到的任何其他问题）。这一般与人们可以说的一样多。