静态/动态类型及类型注解相关技术问题咨询

Let's start with a quick recap from Turbak's Design Concepts in Programming Languages to set the context:

尽管部分动态类型语言带有简单类型标记（例如Perl变量名以特定字符开头表示值类型：$表示标量值，@表示数组值，%表示哈希值（键值对）），但动态类型语言通常无显式类型注解。静态类型语言则相反，显式类型注解是常态。多数源自Algol 68的语言，如Ada、C/C++、Java、Pascal，要求为所有变量、数据结构组件、函数/过程/方法参数及返回值显式声明类型。不过，部分语言（如ML、Haskell、FX、Miranda）通过type reconstruction或type inference技术实现静态类型，无需显式类型声明。

Nope, dynamic languages don’t need type reconstruction or inference the way static languages do—and the reason boils down to when type checking happens.

Static languages use type inference/reconstruction at compile time to figure out types before the program runs, so they can catch type errors early. Dynamic languages, on the other hand, do all their type checking at runtime. Every value carries its type information with it as the program executes, so the language always knows exactly what type a variable holds at any given moment—no need to "infer" it ahead of time.

For example, in Python (a dynamic language with optional type hints), you can write:

x = 42
x = "hello"

When you run this code, the interpreter knows x is an integer the first time you use it, and a string the second. There’s no compile step where it needs to guess what x’s type should be; it just checks types as it goes. Type inference in static languages is a tool for enforcing type safety before execution, which dynamic languages don’t prioritize in the same way.

Absolutely not—static vs. dynamic typing is highly visible to developers, and it’s way more than just whether you write type annotations. Let’s break this down:

First, the core difference between static and dynamic typing is when type errors are caught:

• Static languages (even those with type inference, like Haskell or ML) catch type errors at compile time. If you try to add a string to an integer, your code won’t even run until you fix it.
• Dynamic languages catch type errors at runtime. Your code will run until it hits the problematic line, then crash (or throw an error).

This alone makes the developer experience drastically different. Now, let’s address the annotation-specific parts:

Explicit type annotations: Static vs. dynamic languages don’t look or behave the same #

• Static languages with explicit annotations (like Java or C++) enforce those annotations strictly. If you declare a variable as int x and try to assign a string to it, the compiler will reject your code immediately. The annotations aren’t just documentation—they’re part of the language’s type system that’s enforced before execution.
• Some dynamic languages support optional type annotations (like Python’s x: int). But these annotations are usually not enforced at runtime by default. You can write x: int = "hello" and the code will still run (unless you use a linter or type checker like mypy). The annotations here are hints, not hard rules.

So even with explicit annotations, the developer experience is night and day: static languages block you from running bad code, dynamic languages let you run it until it breaks.

No explicit type annotations: Static vs. dynamic languages are still distinct #

• Static languages without annotations (like Haskell or OCaml) use type inference to figure out types at compile time. If you write a function that adds two values, the compiler will infer that both inputs must be numbers—and if you try to pass a string later, it’ll throw a compile error. You don’t write annotations, but you still get the safety of compile-time type checking.
• Dynamic languages without annotations (like Python or Ruby) have no compile-time checks. You can write a function that adds two values, pass a string and a number, and the code will run until it tries to execute the addition, then fail.

Again, the difference is obvious: with static inference, you get early feedback; with dynamic typing, you only find issues when the code runs.

In short, static vs. dynamic typing isn’t just an implementation detail—it shapes how you write, test, and debug code every day. Annotations are just one visible feature; the timing of type checking is the real, tangible difference developers feel.

内容的提问来源于stack exchange，提问作者Tim