在编写解释型语言时，打字弱或打字能力强吗？
我想知道这一点，因为通常是那里更快的动态类型解释语言（Lua，Javascript），事实上大多数解释语言都使用弱类型。
但另一方面，强类型可以保证弱类型不会，因此，优化技术是否可能与另一个不可能的优化技术？
强类型我的意思是类型之间没有隐式转换。例如，这在强类型语言中是非法的，但在弱类型语言中可能是合法的："5" * 2 == 10。特别是Javascript因这些类型的转换而臭名昭着。
答案 0 :(得分：2)
在我看来，由于缺乏“强类型解释语言”（使用我在问题评论中理解的定义），这个问题很难用明确的例子来回答。
我想不出任何被解释的语言，也没有隐含的转换。我认为这有两个原因：
解释型语言往往不是静态类型。我认为这是因为如果你要实现一种静态类型的语言，那么从历史上看，编译相对容易，并且会给你带来显着的性能优势。
如果语言没有静态类型，则强制进行隐式转换。替代方案会给程序员带来太多困难（他们必须跟踪类型，在源代码中不可见，以避免运行时错误）。
因此，在实践中，所有解释型语言都是弱类型。但是性能增加或减少的问题意味着与一些没有增加或减少的问题进行比较。至少，如果我们想要讨论不同的，现有的实施策略，它就会这样做。
现在你可以回复“好吧，想象一个”。好。那么你要求在运行时检测到需要转换的代码与程序员明确添加转换的代码之间的性能差异。在这种情况下，您要比较动态检测转换需求和调用程序员指定的显式函数之间的区别。
从表面看来，检测总是会增加一些开销（用[后期]编译的语言可以通过jit改进，但是你要问的是解释器）。但如果你想要快速失败的行为（类型错误），那么即使是显式转换也必须检查类型。所以在实践中我想象差异相对较小。这反馈到原点 - 因为弱类型的性能成本很低（考虑到问题中的所有其他约束/假设），并且备选方案的可用性成本很高，大多数（全部？）解释语言支持隐式转换。
[对不起，如果我仍然不理解。我担心我错过了一些东西，因为问题 - 这个答案 - 看起来并不有趣......]
[编辑：也许是一种更好的方式来问同一个（？）的东西会是什么样的“动态（后期绑定？）语言处理类型转换的各种方式的比较优势/劣势是什么？”因为我认为你可以说python的方法特别强大（表达性），同时与其他解释语言有相似的成本（而且这个问题避免了必须争论python或任何其他语言是否是“弱类型”）。
答案 1 :(得分：0)
对于强类型，我的意思是类型之间没有隐式转换。
"5" * 2 == 10
问题是“弱打字”并不是一个定义明确的术语，因为有两种截然不同的方式可能会发生“隐式转换”，这对性能产生相反的影响：