当我们说一种语言是动态类型和静态类型时,这意味着什么?


当前回答

静态类型:在编译时执行的类型检查。

静态类型语言的真正含义是:

必须指定变量的类型 变量只能引用特定类型的对象* 值的类型检查将在编译时执行,任何类型检查都将在此时报告 将在编译时分配内存来存储该特定类型的值

静态类型语言的例子有C、c++、Java。

动态类型:在运行时执行的类型检查。

动态类型语言的真正含义是:

不需要指定变量的类型 同一个变量可以引用不同类型的对象

Python、Ruby都是动态类型语言的例子。


*一些对象可以通过类型转换分配给不同类型的变量(在C和c++等语言中非常常见的做法)

其他回答

静态类型语言在编译时进行类型检查,并且类型不能更改。(不要用类型转换注释,会创建一个新的变量/引用)。

动态类型语言在运行时进行类型检查,变量的类型可以在运行时更改。

简单地说:在静态类型语言中,变量的类型是静态的,这意味着一旦将变量设置为类型,就不能更改它。这是因为类型是与变量而不是它所引用的值相关联的。

例如,在Java中:

String str = "Hello";  // variable str statically typed as string
str = 5;               // would throw an error since str is
                       // supposed to be a string only

另一方面:在动态类型语言中,变量的类型是动态的,这意味着在你将变量设置为类型后,你可以更改它。这是因为输入与它假设的值相关,而不是变量本身。

例如,在Python中:

some_str = "Hello"  # variable some_str is linked to a string value
some_str = 5        # now it is linked to an integer value; perfectly OK

因此,最好将动态类型语言中的变量视为指向类型值的泛型指针。

总而言之,类型描述(或应该描述)语言中的变量,而不是语言本身。恕我直言,它本可以更好地用作带有静态类型变量的语言,而不是带有动态类型变量的语言。

静态类型语言通常是编译语言,因此,编译器检查类型(这很有意义,对吧?因为类型不允许稍后在运行时更改)。

动态类型语言通常是解释型的,因此类型检查(如果有的话)发生在使用它们时的运行时。这当然会带来一些性能损失,也是动态语言(例如python、ruby、php)伸缩性不如类型化语言(java、c#等)的原因之一。从另一个角度来看,静态类型语言的启动成本更高:通常会让你编写更多、更难的代码。但这在以后是有回报的。

好在双方都在借鉴对方的特点。类型语言融合了更多的动态特性,例如c#中的泛型和动态库,而动态语言则包含了更多的类型检查,例如python中的类型注释,或PHP的HACK变体,这些通常不是语言的核心,可按需使用。

在技术选择方面,任何一方都没有内在的优势。这只是一个偏好的问题,你想要更多的控制或灵活性。只要为工作选择合适的工具,并确保在考虑转换之前检查相反的可用工具。

甜蜜和简单的定义,但符合需求: 静态类型语言将类型绑定到整个作用域的变量(Seg: SCALA) 动态类型语言将类型绑定到变量引用的实际值。

http://en.wikipedia.org/wiki/Type_system

Static typing A programming language is said to use static typing when type checking is performed during compile-time as opposed to run-time. In static typing, types are associated with variables not values. Statically typed languages include Ada, C, C++, C#, JADE, Java, Fortran, Haskell, ML, Pascal, Perl (with respect to distinguishing scalars, arrays, hashes and subroutines) and Scala. Static typing is a limited form of program verification (see type safety): accordingly, it allows many type errors to be caught early in the development cycle. Static type checkers evaluate only the type information that can be determined at compile time, but are able to verify that the checked conditions hold for all possible executions of the program, which eliminates the need to repeat type checks every time the program is executed. Program execution may also be made more efficient (i.e. faster or taking reduced memory) by omitting runtime type checks and enabling other optimizations. Because they evaluate type information during compilation, and therefore lack type information that is only available at run-time, static type checkers are conservative. They will reject some programs that may be well-behaved at run-time, but that cannot be statically determined to be well-typed. For example, even if an expression always evaluates to true at run-time, a program containing the code if <complex test> then 42 else <type error> will be rejected as ill-typed, because a static analysis cannot determine that the else branch won't be taken.[1] The conservative behaviour of static type checkers is advantageous when evaluates to false infrequently: A static type checker can detect type errors in rarely used code paths. Without static type checking, even code coverage tests with 100% code coverage may be unable to find such type errors. Code coverage tests may fail to detect such type errors because the combination of all places where values are created and all places where a certain value is used must be taken into account. The most widely used statically typed languages are not formally type safe. They have "loopholes" in the programming language specification enabling programmers to write code that circumvents the verification performed by a static type checker and so address a wider range of problems. For example, Java and most C-style languages have type punning, and Haskell has such features as unsafePerformIO: such operations may be unsafe at runtime, in that they can cause unwanted behaviour due to incorrect typing of values when the program runs. Dynamic typing A programming language is said to be dynamically typed, or just 'dynamic', when the majority of its type checking is performed at run-time as opposed to at compile-time. In dynamic typing, types are associated with values not variables. Dynamically typed languages include Groovy, JavaScript, Lisp, Lua, Objective-C, Perl (with respect to user-defined types but not built-in types), PHP, Prolog, Python, Ruby, Smalltalk and Tcl. Compared to static typing, dynamic typing can be more flexible (e.g. by allowing programs to generate types and functionality based on run-time data), though at the expense of fewer a priori guarantees. This is because a dynamically typed language accepts and attempts to execute some programs which may be ruled as invalid by a static type checker. Dynamic typing may result in runtime type errors—that is, at runtime, a value may have an unexpected type, and an operation nonsensical for that type is applied. This operation may occur long after the place where the programming mistake was made—that is, the place where the wrong type of data passed into a place it should not have. This makes the bug difficult to locate. Dynamically typed language systems, compared to their statically typed cousins, make fewer "compile-time" checks on the source code (but will check, for example, that the program is syntactically correct). Run-time checks can potentially be more sophisticated, since they can use dynamic information as well as any information that was present during compilation. On the other hand, runtime checks only assert that conditions hold in a particular execution of the program, and these checks are repeated for every execution of the program. Development in dynamically typed languages is often supported by programming practices such as unit testing. Testing is a key practice in professional software development, and is particularly important in dynamically typed languages. In practice, the testing done to ensure correct program operation can detect a much wider range of errors than static type-checking, but conversely cannot search as comprehensively for the errors that both testing and static type checking are able to detect. Testing can be incorporated into the software build cycle, in which case it can be thought of as a "compile-time" check, in that the program user will not have to manually run such tests. References Pierce, Benjamin (2002). Types and Programming Languages. MIT Press. ISBN 0-262-16209-1.

静态类型:在编译时执行的类型检查。

静态类型语言的真正含义是:

必须指定变量的类型 变量只能引用特定类型的对象* 值的类型检查将在编译时执行,任何类型检查都将在此时报告 将在编译时分配内存来存储该特定类型的值

静态类型语言的例子有C、c++、Java。

动态类型:在运行时执行的类型检查。

动态类型语言的真正含义是:

不需要指定变量的类型 同一个变量可以引用不同类型的对象

Python、Ruby都是动态类型语言的例子。


*一些对象可以通过类型转换分配给不同类型的变量(在C和c++等语言中非常常见的做法)