Tại sao các ngôn ngữ được nhập động không cho phép nhà phát triển chỉ định loại?


14

Các ngôn ngữ được gõ động mà tôi biết không bao giờ để các nhà phát triển chỉ định các loại biến hoặc ít nhất có hỗ trợ rất hạn chế cho điều đó.

JavaScript, chẳng hạn, không cung cấp bất kỳ cơ chế nào để thực thi các loại biến khi thuận tiện để làm như vậy. PHP cho phép bạn chỉ định một số loại đối số phương pháp, nhưng không có cách nào để sử dụng các loại có nguồn gốc ( int, string, vv) cho các đối số, và không có cách nào để thực thi các loại cho bất cứ điều gì khác hơn là đối số.

Đồng thời, sẽ thuận tiện khi có lựa chọn chỉ định trong một số trường hợp loại biến trong ngôn ngữ được nhập động, thay vì thực hiện kiểm tra loại thủ công.

Tại sao có giới hạn như vậy? Là vì ​​lý do kỹ thuật / hiệu suất (tôi cho rằng đó là trong trường hợp của JavaScript), hoặc chỉ vì lý do chính trị (đó là, tôi tin rằng, trường hợp của PHP)? Đây có phải là trường hợp đối với các ngôn ngữ được gõ động khác mà tôi không quen thuộc không?


Chỉnh sửa: theo dõi các câu trả lời và các ý kiến, đây là một ví dụ để làm rõ: giả sử chúng ta có phương pháp sau trong PHP đơn giản:

public function CreateProduct($name, $description, $price, $quantity)
{
    // Check the arguments.
    if (!is_string($name)) throw new Exception('The name argument is expected to be a string.');
    if (!is_string($description)) throw new Exception('The description argument is expected to be a string.');
    if (!is_float($price) || is_double($price)) throw new Exception('The price argument is expected to be a float or a double.');
    if (!is_int($quantity)) throw new Exception('The quantity argument is expected to be an integer.');

    if (!$name) throw new Exception('The name argument cannot be an empty string.');
    if ($price <= 0) throw new Exception('The price argument cannot be less or equal to zero.');
    if ($price < 0) throw new Exception('The price argument cannot be less than zero.');

    // We can finally begin to write the actual code.
    // TODO: Implement the method here.
}

Với một số nỗ lực, điều này có thể được viết lại thành (cũng xem Lập trình theo hợp đồng trong PHP ):

public function CreateProduct($name, $description, $price, $quantity)
{
    Component::CheckArguments(__FILE__, __LINE__, array(
        'name' => array('value' => $name, 'type' => VTYPE_STRING),
        'description' => array('value' => $description, 'type' => VTYPE_STRING),
        'price' => array('value' => $price, 'type' => VTYPE_FLOAT_OR_DOUBLE),
        'quantity' => array('value' => $quantity, 'type' => VTYPE_INT)
    ));

    if (!$name) throw new Exception('The name argument cannot be an empty string.');
    if ($price <= 0) throw new Exception('The price argument cannot be less or equal to zero.');
    if ($price < 0) throw new Exception('The price argument cannot be less than zero.');

    // We can finally begin to write the actual code.
    // TODO: Implement the method here.
}

Nhưng phương thức tương tự sẽ được viết như sau nếu PHP tùy ý chấp nhận các kiểu gốc cho các đối số:

public function CreateProduct(string $name, string $description, double $price, int $quantity)
{
    // Check the arguments.
    if (!$name) throw new Exception('The name argument cannot be an empty string.');
    if ($price <= 0) throw new Exception('The price argument cannot be less or equal to zero.');
    if ($price < 0) throw new Exception('The price argument cannot be less than zero.');

    // We can finally begin to write the actual code.
    // TODO: Implement the method here.
}

Cái nào ngắn hơn để viết? Cái nào dễ đọc hơn?


1
Bạn có thể tùy ý chỉ định các loại trong một số ngôn ngữ được nhập động - ví dụ: trong Common Lisp.
SK-logic

Khá nhiều ngôn ngữ được gõ động sử dụng phôi để ép một loại ...
Trezoid

Một số làm. Ví dụ, Objective-C được gõ động, nhưng bạn có thể khai báo một loại cho các biến và trình biên dịch sẽ đưa ra cảnh báo nếu bạn không nhận được loại bạn đang mong đợi.
mipadi

1
Clojure là một ví dụ về ngôn ngữ thường được gõ động nhưng bạn có thể tùy ý đưa ra các loại biến thông qua "gợi ý loại" (điều này thường chỉ được thực hiện khi cần để có được lợi ích hiệu suất của thông tin loại thời gian biên dịch)
mikera

1
Groovy là một ví dụ khác về ngôn ngữ được gõ động cho phép một loại được chỉ định.
Eric Wilson

Câu trả lời:


17

Điểm có kiểu gõ tĩnh là khả năng chứng minh tĩnh rằng chương trình của bạn đúng với các loại (lưu ý: không hoàn toàn chính xác trong tất cả các giác quan). Nếu bạn có một hệ thống loại tĩnh trong suốt, bạn có thể phát hiện lỗi loại hầu hết thời gian.

Nếu bạn chỉ có thông tin loại một phần, bạn chỉ có thể kiểm tra các phần nhỏ của biểu đồ cuộc gọi nơi thông tin loại xảy ra hoàn tất. Nhưng bạn đã dành thời gian và nỗ lực để chỉ định thông tin loại cho các phần không hoàn chỉnh, nơi nó không thể giúp bạn nhưng có thể mang lại cảm giác an toàn sai lầm.

Để diễn đạt thông tin loại, bạn cần một phần ngôn ngữ không thể quá đơn giản. Bạn sẽ sớm nhận ra rằng thông tin như thế intlà không đủ; bạn sẽ muốn một cái gì đó như List<Pair<Int, String>>, sau đó là các loại tham số, v.v. Nó có thể gây nhầm lẫn đủ ngay cả trong trường hợp khá đơn giản của Java.

Sau đó, bạn sẽ cần xử lý thông tin này trong giai đoạn dịch giai đoạn thực hiện, bởi vì thật ngớ ngẩn khi chỉ kiểm tra các lỗi tĩnh; người dùng sẽ mong đợi rằng các ràng buộc kiểu luôn luôn giữ nếu được chỉ định ở tất cả. Các ngôn ngữ động không quá nhanh như vậy và các kiểm tra như vậy sẽ làm chậm hiệu suất hơn nữa. Một ngôn ngữ tĩnh có thể dành nhiều nỗ lực nghiêm túc để kiểm tra các loại vì nó chỉ thực hiện một lần; một ngôn ngữ năng động không thể.

Bây giờ hãy tưởng tượng việc thêm và duy trì tất cả những điều này chỉ để mọi người đôi khi tùy ý sử dụng các tính năng này, chỉ phát hiện một phần nhỏ lỗi loại. Tôi không nghĩ rằng nó đáng để nỗ lực.

Điểm chính của các ngôn ngữ động là có một khung rất nhỏ và rất dễ uốn, trong đó bạn có thể dễ dàng thực hiện những việc liên quan nhiều hơn khi thực hiện bằng ngôn ngữ tĩnh: nhiều hình thức vá khỉ được sử dụng để lập trình, chế giễu và thử nghiệm, thay thế mã động, v.v., Smalltalk và Lisp, cả hai đều rất năng động, đã đưa nó đến mức cực đoan để gửi hình ảnh môi trường thay vì xây dựng từ nguồn. Nhưng khi bạn muốn đảm bảo rằng các đường dẫn dữ liệu cụ thể là an toàn kiểu, hãy thêm các xác nhận và viết thêm các bài kiểm tra đơn vị.


1
+1, mặc dù các bài kiểm tra chỉ có thể cho thấy rằng các lỗi không xảy ra trong một số tình huống nhất định. Chúng là một sự thay thế kém cho một bằng chứng rằng lỗi (loại) là không thể.
Ingo

1
@Ingo: chắc chắn rồi. Nhưng ngôn ngữ động rất tốt cho việc mày mò và tạo mẫu nhanh, nơi bạn thể hiện những ý tưởng tương đối đơn giản rất nhanh. Nếu bạn muốn mã sản xuất chống đạn, bạn có thể chuyển sang ngôn ngữ tĩnh sau đó, khi bạn đã trích xuất một số thành phần cốt lõi ổn định.
9000

1
@ 9000, tôi không nghi ngờ rằng chúng là tuyệt vời. Muốn chỉ ra rằng viết 3 hoặc 4 bài kiểm tra khập khiễng là không, và không thể đảm bảo loại saftey .
Ingo

2
@ 9000, Đúng, và tin xấu là ngay cả khi đó, thực tế là không thể. Ngay cả mã Haskell hoặc Agda cũng dựa vào giả định, ví dụ như thư viện được sử dụng trong thời gian chạy là chính xác. Điều đó đang được nói, trong một dự án với khoảng 1000 LỘC trải rộng trên vài chục tệp mã nguồn, thật tuyệt vời khi bạn có thể thay đổi một cái gì đó và bạn biết rằng trình biên dịch sẽ chỉ ra ở mỗi dòng mà sự thay đổi có tác động.
Ingo

4
Các bài kiểm tra viết kém không phải là sự thay thế cho kiểm tra kiểu tĩnh: chúng kém hơn. Các bài kiểm tra viết tốt cũng không phải là sự thay thế cho kiểm tra kiểu tĩnh: chúng vượt trội.
Rein Henrichs

8

Trong hầu hết các ngôn ngữ động, ít nhất bạn có thể kiểm tra động loại đối tượng hoặc giá trị.

Và có các loại suy ra, kiểm tra và / hoặc thi hành tĩnh đối với một số ngôn ngữ động: vd

Và Perl 6 sẽ hỗ trợ một hệ thống loại tùy chọn với kiểu gõ tĩnh.


Nhưng tôi đoán rằng điểm mấu chốt là rất nhiều người sử dụng ngôn ngữ động chúng được gõ động và đối với họ, việc gõ tĩnh tùy chọn là rất "ho hum". Và rất nhiều người khác sử dụng chúng bởi vì chúng "dễ dàng cho những người không lập trình sử dụng", phần lớn là kết quả của kiểu gõ động tự nhiên dễ tha thứ. Đối với họ, gõ tùy chọn là thứ họ sẽ không hiểu hoặc sẽ không bị làm phiền khi sử dụng.

Nếu bạn là người hoài nghi, bạn có thể nói rằng gõ tĩnh tùy chọn cung cấp điều tồi tệ nhất của cả hai thế giới. Đối với zealot kiểu tĩnh, nó không ngăn chặn tất cả các lỗi kiểu động. Đối với một loại quạt năng động, nó vẫn là một chiếc áo khoác thẳng ... mặc dù dây đai không được buộc chặt.


2
Cần lưu ý rằng việc kiểm tra các loại bản thân được hầu hết các cộng đồng trong hầu hết các trường hợp. Sử dụng tính đa hình (cụ thể là "gõ vịt") khi xử lý các ký tự đối tượng, ép buộc với loại dự kiến ​​nếu có thể / hợp lý. Một vài trường hợp vẫn không hợp lý khi cho phép bất kỳ loại nào, nhưng trong nhiều ngôn ngữ, bạn vẫn có ngoại lệ trong hầu hết các trường hợp này, vì vậy việc kiểm tra loại hiếm khi hữu ích.

4
"Mọi người thường sử dụng ngôn ngữ động vì chúng được gõ động" : JavaScript được sử dụng vì đây là ngôn ngữ duy nhất được hầu hết các trình duyệt hỗ trợ. PHP được sử dụng vì nó phổ biến.
Arseni Mourzenko

2

Javascript đã lên kế hoạch bao gồm một số kiểu gõ tĩnh tùy chọn và dường như nhiều ngôn ngữ động trưởng thành đang đi theo hướng đó-

Lý do là khi bạn mã đầu tiên, bạn muốn được gõ nhanh và linh hoạt. Khi mã của bạn ổn định, hoạt động và có nhiều (r) sử dụng, bạn muốn khóa thiết kế để giảm lỗi. (điều này có lợi cho cả người dùng và nhà phát triển, vì người trước sẽ gặp lỗi khi kiểm tra cuộc gọi của họ và người sau sẽ không vô tình phá vỡ mọi thứ.

Điều này có ý nghĩa với tôi, vì tôi thường thấy có quá nhiều kiểu kiểm tra khi bắt đầu dự án, quá ít khi kết thúc thời gian sống, bất kể tôi sử dụng ngôn ngữ nào;).


Tôi không biết về những kế hoạch bao gồm gõ tĩnh tùy chọn trong JavaScript; nhưng hy vọng họ không quá tàn bạo như trong ActiveScript. tồi tệ nhất của cả JavaScript và Java.
Javier

Nó đã được lên kế hoạch cho JS 4 (hoặc ECMAscript 4) nhưng phiên bản đó đã bị hủy do tranh cãi. Tôi chắc chắn một cái gì đó tương tự sẽ xuất hiện trong tương lai, trong một số ngôn ngữ. (Trong Python, bạn có thể sắp xếp việc đó với trang trí, btw.)
Macke

1
Trang trí thêm kiểm tra loại động , một loại xác nhận. Bạn không thể kiểm tra kiểu tĩnh toàn diện trong Python, tuy nhiên bạn rất cố gắng, do tính năng động cực cao của ngôn ngữ.
9000

@ 9000: Đúng vậy. Tuy nhiên, tôi không nghĩ rằng kiểm tra kiểu động là xấu mặc dù (nhưng tôi thích so sánh kiểu vịt hơn ala JS4), đặc biệt là khi kết hợp với kiểm tra đơn vị và các trình trang trí đánh máy có thể hỗ trợ các trình kiểm tra IDE / lint hữu ích hơn nếu chúng ở đâu chuẩn hóa.
Macke

Tất nhiên là không tệ! Đây không phải là vấn đề đạo đức. Tại một số điểm, loại phải được "kiểm tra" bằng cách này hay cách khác. Nếu bạn viết * ((double *) 0x98765E) trong C, CPU sẽ thực hiện và kiểm tra xem 0x98765E có thực sự là một con trỏ thành gấp đôi không.
Ingo

2

Đối tượng Python làm có một loại.

Bạn chỉ định loại khi bạn tạo đối tượng.

Đồng thời, sẽ thuận tiện khi có lựa chọn chỉ định trong một số trường hợp loại biến trong ngôn ngữ được nhập động, thay vì thực hiện kiểm tra loại thủ công.

Trên thực tế, kiểm tra loại thủ công trong Python hầu như luôn lãng phí thời gian và mã.

Nó đơn giản là một cách thực hành tồi để viết mã kiểm tra kiểu trong Python.

Nếu một loại không phù hợp được sử dụng bởi một số sociopath độc hại, các phương thức thông thường của Python sẽ đưa ra một ngoại lệ thông thường khi loại không phù hợp.

Bạn viết không có mã, chương trình của bạn vẫn thất bại với a TypeError.

Có những trường hợp rất hiếm khi bạn phải xác định loại trong thời gian chạy.

Tại sao có giới hạn như vậy?

Vì nó không phải là "giới hạn", nên câu hỏi không phải là một câu hỏi thực sự.


2
"Các đối tượng Python có một loại." - ồ thật sao? Cũng như các đối tượng perl, các đối tượng PHP và mọi mục dữ liệu khác trên thế giới. Sự khác biệt giữa gõ tĩnh và gõ động chỉ khi loại sẽ được kiểm tra, tức là khi lỗi loại biểu hiện. Nếu chúng xuất hiện dưới dạng lỗi trình biên dịch, thì đó là kiểu gõ tĩnh, nếu chúng xuất hiện dưới dạng lỗi thời gian chạy, thì đó là động.
Ingo

@Ingo: Cảm ơn đã làm rõ. Vấn đề là các đối tượng C ++ và Java có thể được truyền từ loại này sang loại khác, làm cho loại đối tượng hơi mờ và do đó làm cho "kiểm tra kiểu" trong các trình biên dịch đó cũng hơi âm u. Trường hợp kiểm tra kiểu Python - ngay cả khi đang trong thời gian chạy - thì ít âm u hơn. Ngoài ra, câu hỏi gần giống với việc nói các ngôn ngữ được gõ động không có loại. Tin tốt là nó không phạm phải sai lầm phổ biến đó.
S.Lott

1
Bạn đã đúng, nhập phôi (trái ngược với chuyển đổi loại, tức là ((gấp đôi) 42)) lật đổ kiểu gõ tĩnh. Chúng là cần thiết khi hệ thống loại không đủ mạnh. Trước Java 5, Java không có kiểu parmeterized, bạn không thể sống mà không có kiểu phôi. Ngày nay nó tốt hơn nhiều, nhưng hệ thống loại vẫn thiếu các loại được phân loại cao hơn, không nói đến tính đa hình được xếp hạng cao hơn. Tôi nghĩ rằng rất có thể các ngôn ngữ gõ động được hưởng chính xác nhiều người theo dõi vì họ giải phóng một ngôn ngữ khỏi các hệ thống loại quá hẹp.
Ingo

2

Hầu hết thời gian, bạn không cần, ít nhất là không ở mức độ chi tiết mà bạn đề xuất. Trong PHP, các toán tử bạn sử dụng làm cho nó hoàn toàn rõ ràng những gì bạn mong đợi các đối số sẽ là; đó là một chút giám sát thiết kế mặc dù PHP sẽ truyền các giá trị của bạn nếu có thể, ngay cả khi bạn chuyển một mảng sang một hoạt động mong đợi một chuỗi và vì diễn viên không phải lúc nào cũng có ý nghĩa, đôi khi bạn nhận được kết quả lạ ( và đây chính là nơi loại kiểm tra hữu ích). Ngoài ra, điều đó không thành vấn đề nếu bạn thêm số nguyên 15hoặc chuỗi "1""5"- thực tế là bạn đang sử dụng+Toán tử báo hiệu cho PHP rằng bạn muốn coi các đối số là số và PHP sẽ tuân theo. Một tình huống thú vị là khi bạn nhận được kết quả truy vấn từ MySQL: Nhiều giá trị số được trả về đơn giản dưới dạng chuỗi, nhưng bạn sẽ không nhận thấy vì PHP đưa chúng cho bạn bất cứ khi nào bạn coi chúng là số.

Python nghiêm ngặt hơn một chút về các loại của nó, nhưng không giống như PHP, Python đã có ngoại lệ ngay từ đầu và sử dụng nó một cách nhất quán. Mô hình "dễ xin tha thứ hơn sự cho phép" đề nghị chỉ thực hiện thao tác mà không cần kiểm tra loại và dựa vào một ngoại lệ được nêu ra khi các loại không có ý nghĩa. Nhược điểm duy nhất của điều này mà tôi có thể nghĩ đến là đôi khi, bạn sẽ thấy rằng một nơi nào đó không phù hợp với những gì bạn mong đợi, nhưng việc tìm ra lý do có thể rất tẻ nhạt.

Và có một lý do khác để xem xét: Ngôn ngữ động không giai đoạn biên dịch. Ngay cả khi bạn có các ràng buộc kiểu, chúng chỉ có thể kích hoạt khi chạy, đơn giản vì không có thời gian biên dịch . Nếu kiểm tra của bạn dẫn đến lỗi thời gian chạy, thì việc mô hình hóa chúng phù hợp sẽ dễ dàng hơn nhiều: Như kiểm tra rõ ràng (như is_XXX()trong PHP hoặc typeoftrong javascript) hoặc bằng cách ném ngoại lệ (như Python làm). Về mặt chức năng, bạn có tác dụng tương tự (một lỗi được báo hiệu khi chạy khi kiểm tra kiểu không thành công), nhưng nó tích hợp tốt hơn với phần còn lại của ngữ nghĩa của ngôn ngữ. Đơn giản là không có ý nghĩa gì khi xử lý các lỗi loại về cơ bản khác với các lỗi thời gian chạy khác trong một ngôn ngữ động.


0

Bạn có thể quan tâm đến Haskell - đó là hệ thống loại nhập vào các loại từ mã và bạn cũng có thể chỉ định các loại.


5
Haskell là một ngôn ngữ tuyệt vời. Nó hoàn toàn trái ngược với các ngôn ngữ động: bạn dành nhiều thời gian để mô tả các loại và thông thường một khi bạn đã tìm ra các loại chương trình của mình hoạt động :)
9000

@ 9000: Thật vậy. Một khi nó biên dịch, nó thường hoạt động. :)
Macke

@Macke - cho các giá trị khác nhau của thường , tất nhiên. : - và trạng thái đột biến không tồn tại.
Ingo

0

Như các câu trả lời khác đã ám chỉ, có hai cách tiếp cận để gõ khi thực hiện ngôn ngữ lập trình.

  1. Yêu cầu lập trình viên cho bạn biết tất cả các biến và hàm sử dụng cho các loại. Lý tưởng nhất, bạn cũng xác minh rằng các thông số kỹ thuật loại là chính xác. Sau đó, vì bạn biết loại nào sẽ ở mỗi nơi, bạn có thể viết mã giả định rằng thứ thích hợp sẽ ở đó và sử dụng bất kỳ cấu trúc dữ liệu nào bạn sử dụng để thực hiện trực tiếp loại đó.
  2. Đính kèm một chỉ báo loại cho các giá trị sẽ được lưu trữ trong các biến và được chuyển đến và trả về từ các hàm. Điều này có nghĩa là lập trình viên sẽ không phải chỉ định bất kỳ loại nào cho các biến hoặc hàm, bởi vì các loại thực sự thuộc về các đối tượng mà các biến và hàm tham chiếu.

Cả hai phương pháp đều hợp lệ và việc sử dụng phụ thuộc một phần vào các cân nhắc kỹ thuật như hiệu suất và một phần dựa trên các lý do chính trị như thị trường mục tiêu cho ngôn ngữ.


0

Trước hết, các ngôn ngữ động được tạo ra chủ yếu để dễ sử dụng. Như bạn đã đề cập, thực sự tốt khi thực hiện chuyển đổi loại tự động và cung cấp cho chúng tôi ít chi phí hơn. Nhưng đồng thời nó thiếu các vấn đề hiệu suất.

Bạn có thể gắn bó với các ngôn ngữ động, trong trường hợp bạn không lo lắng về hiệu suất. Ví dụ, JavaScript chạy chậm hơn khi cần thực hiện nhiều chuyển đổi loại trong chương trình của bạn, nhưng nó giúp giảm số lượng dòng trong mã của bạn.

Và phải kể đến, có những ngôn ngữ động khác thậm chí cho phép lập trình viên chỉ định loại. Ví dụ Groovy là một trong những ngôn ngữ động nổi tiếng chạy trên JVM. Và nó đã rất nổi tiếng trong những ngày gần đây. Lưu ý rằng hiệu suất của Groovy giống như Java.

Hy vọng nó sẽ giúp bạn.


-1

Nó chỉ đơn giản là không có ý nghĩa để làm như vậy.

Tại sao?

Bởi vì hệ thống loại DTL chính xác đến mức các loại không thể được xác định tại thời điểm biên dịch. Do đó, trình biên dịch thậm chí không thể kiểm tra xem loại được chỉ định sẽ có ý nghĩa hay không.


1
Tại sao? Nó là một ý nghĩa hoàn hảo để gợi ý một trình biên dịch về những loại mong đợi. Nó sẽ không mâu thuẫn với bất kỳ ràng buộc hệ thống loại nào.
SK-logic

1
SK-logic: Nếu được gõ động có nghĩa là mọi chức năng / phương thức / hoạt động đều lấy các đối tượng thuộc loại "Động", "Bất kỳ" hoặc bất cứ thứ gì và trả về "Động", "Bất kỳ", nói chung, không có cách nào để nói rằng một giá trị nhất định sẽ luôn luôn là một số nguyên, ví dụ. Do đó, mã thời gian chạy phải kiểm tra các số nguyên không phải là số nguyên, giống như kiểu đầu tiên là "Động". Đây chỉ là những gì một hệ thống kiểu tĩnh thực hiện: nó cho phép có thể đưa ra rằng một biến, trường hoặc phương thức trả về nhất định sẽ luôn thuộc một kiểu nhất định.
Ingo

@Ingo, không, có một cách. Xem cách nó được thực hiện trong Common Lisp, ví dụ. Nó đặc biệt hữu ích cho các biến cục bộ - bạn có thể tăng hiệu suất đáng kể bằng cách giới thiệu tất cả các gợi ý gõ.
SK-logic

@ SK-logic: Có lẽ bạn có thể cho tôi biết khi nào và cách phát hiện lỗi loại trong CL? Dù sao, @MainMa đã tóm tắt hiện trạng khá độc đáo trong câu hỏi của anh ấy / cô ấy: Đó chỉ là những gì người ta có thể mong đợi từ các ngôn ngữ động "thuần túy".
Ingo

@Ingo, điều gì khiến bạn nghĩ rằng các loại chỉ hữu ích cho việc chứng minh chính xác tĩnh? Điều này không đúng đối với các ngôn ngữ như C, nơi bạn đã chọn kiểu truyền không được kiểm tra. Chú thích kiểu trong các ngôn ngữ động hầu hết hữu ích vì gợi ý trình biên dịch giúp cải thiện hiệu suất hoặc chỉ định biểu diễn số cụ thể. Tôi đồng ý rằng trong hầu hết các trường hợp, các chú thích không nên thay đổi ngữ nghĩa của mã.
SK-logic

-1

Hãy nhìn vào Go, trên bề mặt nó được gõ tĩnh, nhưng những kiểu đó có thể là các giao diện về cơ bản là động.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.