简单的问题:我用编译语言(如C++/Java )和解释语言(如Python/Javascript )进行了大量的编程(专业的和个人的)。我个人发现,当我用静态类型语言编程时,我的代码几乎总是更健壮。但是,我遇到的几乎每种解释语言都使用动态类型(PHP、Perl、Python等)。我知道为什么编译语言使用静态类型(大多数时候),但我不明白在解释语言设计中对静态类型的反感。
为什么会出现这种陡峭的脱节?这是解释型语言的一部分吗?OOP?
发布于 2009-09-11 22:27:47
这个问题很有趣。顺便说一句,我是phc (PHP编译器)的作者/维护者,我正在做动态语言编译器的PhD工作,所以我希望我能提供一些见解。
我认为这里有一个错误的假设。PHP、Perl、Python、Ruby、Lua等的作者并没有设计“解释型语言”,他们设计了动态语言,并使用解释器来实现它们。他们这样做是因为解释器比编译器更容易编写。
Java的第一个实现是解释的,它是一种静态类型的语言。静态语言的解释器确实存在: Haskell和OCaml都有解释器,曾经有一个流行的C解释器,但那是很久以前的事了。它们之所以流行,是因为它们允许使用REPL,这可以使开发变得更容易。
也就是说,正如您所预期的那样,在动态语言社区中存在对静态类型的反感。他们认为由C,C++和Java提供的静态类型系统是冗长的,不值得努力。我想我在一定程度上同意这一点。用Python编程要比用C++有趣得多。
要解决其他人的观点:
eval语句,它在Javascript和Ruby中被广泛使用。phc提前编译PHP,但我们仍然需要一个运行时解释器来处理eval。eval也不能在优化编译器中进行静态分析,尽管如果你不需要健壮性,有一个cool technique。ghci所做的。我希望函数式语言中使用的解释器风格需要这样做。dlamblin说分析不是interpretation.发布于 2009-09-08 14:34:27
我认为这是因为解释型语言的本质,他们希望是动态的,这样你就可以在运行时改变事情。因此,在执行完下一行代码后,编译器永远不会确切地知道程序的状态。
想象一下以下场景(在Python中):
import random
foo = 1
def doSomeStuffWithFoo():
global foo
foo = random.randint(0, 1)
def asign():
global foo
if foo == 1:
return 20
else:
return "Test"
def toBeStaticallyAnalyzed():
myValue = asign()
# A "Compiler" may throw an error here because foo == 0, but at runtime foo maybe 1, so the compiler would be wrong with its assumption
myValue += 20
doSomeStuffWithFoo() # Foo could be 1 or 0 now... or 4 ;)
toBeStaticallyAnalyzed()正如您希望看到的,编译器在这种情况下不会有任何意义。实际上,它可能会警告您"myValue“可能不是数字。但在JavaScript中,这将失败,因为如果"myValue“是一个字符串,20也会隐式地转换为字符串,因此不会发生错误。所以你可能会收到成千上万的无用的警告,我不认为这是一个编译器的意图。
灵活性总是要付出代价的,你需要更深入地研究你的程序,或者更仔细地对它进行编程,换句话说,在上述情况下,你就是编译器。
那么你作为编译器的解决方案呢?-用"try: except“来修复它:)
发布于 2009-09-08 13:04:56
解释语言使用动态类型,因为没有编译步骤来执行静态分析。编译语言在编译时进行静态分析,这意味着任何类型错误都会在开发人员工作时报告给开发人员。
如果您认为静态类型语言具有在执行上下文之外强制执行类型规则的编译器,则更容易理解。解释型语言从来不是静态分析的,因此类型规则必须由解释器在执行上下文中强制执行。
https://stackoverflow.com/questions/1393883
复制相似问题