Interpreters and Dynamically Typed Languages
为什么具有动态类型语言的程序通常被解释而不是编译？
In short: They go together like peas and carrots.
Compiling vs. interpreting and language typing are fundamentally separate concerns in that you can have all possible permutations. On the other hand, the "reason" for picking compiling and not picking dynamic typing for a language design are usually the same: performance. The "reason" for picking dynamic typing and interpretation are also somewhat related.
It's not a hard and fast rule. You can always mix 'em up. You can compile Perl and Lisp for example and interpret C.
You are observing a non-causal correlation:
Compilers are usually retrofitted onto dynamically-typed languages in an attempt to improve performance (because performance is often very poor). For example, here's how long some major dynamically-typed languages were interpreted for before their first compiler was written: Lisp (1958-1962), Mathematica (1988-2004), Lua (1993-2004), Python (1991-2002) and Javascript (1995-2009). In contrast, languages like OCaml (1996) and F# (2001) were released first as compilers.
As noted by others, languages are neither compiled or interpreted. They're just rules that need translating and most have interpreted and compiled implementations. Even then, it's hard to talk about interpretation versus compilation when many "interpreters" are jitting all over the place and some "compilers" are happy to compile-on-demand if a source file changes.
Maybe it's better to categorize implementations as fully pre-compiled or compiled-on-demand . If we use these categories, the one thing that breaks full pre-compilation is an eval function. This probably has more of an effect on the implementation than dynamic types. If you have an eval function, you're required to support compile-on-demand.
链接地址: http://www.djcxy.com/p/72320.html下一篇: 口译员和动态类型语言