Ngôn ngữ loại động so với ngôn ngữ loại tĩnh

Những lợi thế và hạn chế của ngôn ngữ loại động so với ngôn ngữ loại tĩnh là gì?

Xem thêm : whats với tình yêu của ngôn ngữ động (một chủ đề tranh luận hơn nhiều ...)

Khả năng trình thông dịch suy ra các chuyển đổi loại và loại làm cho thời gian phát triển nhanh hơn, nhưng nó cũng có thể gây ra lỗi trong thời gian chạy mà bạn không thể có được bằng ngôn ngữ gõ tĩnh nơi bạn bắt chúng vào thời gian biên dịch. Nhưng cái nào tốt hơn (hoặc thậm chí nếu điều đó luôn luôn đúng) được thảo luận sôi nổi trong cộng đồng những ngày này (và từ rất lâu).

Một vấn đề tốt là từ việc gõ tĩnh ở những nơi có thể, gõ động khi cần thiết: Sự kết thúc của cuộc chiến tranh lạnh giữa các ngôn ngữ lập trình của Erik Meijer và Peter Drayton tại Microsoft:

Những người ủng hộ việc gõ tĩnh cho rằng các ưu điểm của gõ tĩnh bao gồm phát hiện sớm các lỗi lập trình (ví dụ: ngăn thêm số nguyên vào boolean), tài liệu tốt hơn ở dạng chữ ký loại (ví dụ: kết hợp số và loại đối số khi giải quyết tên), hơn nữa cơ hội tối ưu hóa trình biên dịch (ví dụ: thay thế các cuộc gọi ảo bằng các cuộc gọi trực tiếp khi loại chính xác của máy thu được biết tĩnh), tăng hiệu quả thời gian chạy (ví dụ: không phải tất cả các giá trị cần mang theo kiểu động) và trải nghiệm nhà phát triển thời gian thiết kế tốt hơn (ví dụ: biết loại máy thu, IDE có thể trình bày menu thả xuống của tất cả các thành viên hiện hành). Những kẻ cuồng đánh máy tĩnh cố gắng làm cho chúng tôi tin rằng các chương trình được gõ tốt không thể sai. Trong khi điều này chắc chắn nghe có vẻ ấn tượng, đó là một tuyên bố khá trống rỗng. Kiểm tra kiểu tĩnh là sự trừu tượng hóa thời gian biên dịch của hành vi thời gian chạy của chương trình của bạn và do đó, nó nhất thiết chỉ là một phần âm thanh và không đầy đủ. Điều này có nghĩa là các chương trình vẫn có thể bị lỗi do các thuộc tính không được theo dõi bởi trình kiểm tra loại và có những chương trình trong khi chúng không thể bị lỗi thì không thể kiểm tra kiểu. Sự thúc đẩy của việc gõ tĩnh ít một phần và hoàn chỉnh hơn khiến cho các hệ thống kiểu trở nên quá phức tạp và kỳ lạ như được chứng kiến ​​bởi các khái niệm như kiểu ảo phật giả [11] và kiểu wobbly kiểu [10]. Điều này giống như cố gắng chạy marathon với một quả bóng và dây xích buộc vào chân của bạn và hét lên một cách đắc thắng rằng bạn gần như đã làm được điều đó mặc dù bạn đã thoát ra sau dặm đầu tiên. Kiểm tra kiểu tĩnh là sự trừu tượng hóa thời gian biên dịch của hành vi thời gian chạy của chương trình của bạn và do đó, nó nhất thiết chỉ là một phần âm thanh và không đầy đủ. Điều này có nghĩa là các chương trình vẫn có thể bị lỗi do các thuộc tính không được theo dõi bởi trình kiểm tra loại và có những chương trình trong khi chúng không thể bị lỗi thì không thể kiểm tra kiểu. Sự thúc đẩy của việc gõ tĩnh ít một phần và hoàn chỉnh hơn khiến cho các hệ thống kiểu trở nên quá phức tạp và kỳ lạ như được chứng kiến ​​bởi các khái niệm như kiểu ảo phật giả [11] và kiểu wobbly kiểu [10]. Điều này giống như cố gắng chạy marathon với một quả bóng và dây xích buộc vào chân của bạn và hét lên một cách đắc thắng rằng bạn gần như đã làm được điều đó mặc dù bạn đã thoát ra sau dặm đầu tiên. Kiểm tra kiểu tĩnh là sự trừu tượng hóa thời gian biên dịch của hành vi thời gian chạy của chương trình của bạn và do đó, nó nhất thiết chỉ là một phần âm thanh và không đầy đủ. Điều này có nghĩa là các chương trình vẫn có thể bị lỗi do các thuộc tính không được theo dõi bởi trình kiểm tra loại và có những chương trình trong khi chúng không thể bị lỗi thì không thể kiểm tra kiểu. Sự thúc đẩy của việc gõ tĩnh ít một phần và hoàn chỉnh hơn khiến cho các hệ thống kiểu trở nên quá phức tạp và kỳ lạ như được chứng kiến ​​bởi các khái niệm như kiểu ảo phật giả [11] và kiểu wobbly kiểu [10]. Điều này giống như cố gắng chạy marathon với một quả bóng và dây xích buộc vào chân của bạn và hét lên một cách đắc thắng rằng bạn gần như đã làm được điều đó mặc dù bạn đã thoát ra sau dặm đầu tiên. và do đó nó nhất thiết chỉ là một phần âm thanh và không đầy đủ. Điều này có nghĩa là các chương trình vẫn có thể bị lỗi do các thuộc tính không được theo dõi bởi trình kiểm tra loại và có những chương trình trong khi chúng không thể bị lỗi thì không thể kiểm tra kiểu. Sự thúc đẩy của việc gõ tĩnh ít một phần và hoàn chỉnh hơn khiến cho các hệ thống kiểu trở nên quá phức tạp và kỳ lạ như được chứng kiến ​​bởi các khái niệm như kiểu ảo phật giả [11] và kiểu wobbly kiểu [10]. Điều này giống như cố gắng chạy marathon với một quả bóng và dây xích buộc vào chân của bạn và hét lên một cách đắc thắng rằng bạn gần như đã làm được điều đó mặc dù bạn đã thoát ra sau dặm đầu tiên. và do đó nó nhất thiết chỉ là một phần âm thanh và không đầy đủ. Điều này có nghĩa là các chương trình vẫn có thể bị lỗi do các thuộc tính không được theo dõi bởi trình kiểm tra loại và có những chương trình trong khi chúng không thể bị lỗi thì không thể kiểm tra kiểu. Sự thúc đẩy của việc gõ tĩnh ít một phần và hoàn chỉnh hơn khiến cho các hệ thống kiểu trở nên quá phức tạp và kỳ lạ như được chứng kiến ​​bởi các khái niệm như kiểu ảo phật giả [11] và kiểu wobbly kiểu [10]. Điều này giống như cố gắng chạy marathon với một quả bóng và dây xích buộc vào chân của bạn và hét lên một cách đắc thắng rằng bạn gần như đã làm được điều đó mặc dù bạn đã thoát ra sau dặm đầu tiên. và có những chương trình mà trong khi chúng không thể sai thì không thể kiểm tra kiểu. Sự thúc đẩy của việc gõ tĩnh ít một phần và hoàn chỉnh hơn khiến cho các hệ thống kiểu trở nên quá phức tạp và kỳ lạ như được chứng kiến ​​bởi các khái niệm như kiểu ảo phật giả [11] và kiểu wobbly kiểu [10]. Điều này giống như cố gắng chạy marathon với một quả bóng và dây xích buộc vào chân của bạn và hét lên một cách đắc thắng rằng bạn gần như đã làm được điều đó mặc dù bạn đã thoát ra sau dặm đầu tiên. và có những chương trình mà trong khi chúng không thể sai thì không thể kiểm tra kiểu. Sự thúc đẩy của việc gõ tĩnh ít một phần và hoàn chỉnh hơn khiến cho các hệ thống kiểu trở nên quá phức tạp và kỳ lạ như được chứng kiến ​​bởi các khái niệm như kiểu ảo phật giả [11] và kiểu wobbly kiểu [10]. Điều này giống như cố gắng chạy marathon với một quả bóng và dây xích buộc vào chân của bạn và hét lên một cách đắc thắng rằng bạn gần như đã làm được điều đó mặc dù bạn đã thoát ra sau dặm đầu tiên.

Những người ủng hộ các ngôn ngữ gõ động cho rằng gõ tĩnh quá cứng và tính mềm của ngôn ngữ động khiến chúng phù hợp lý tưởng cho các hệ thống tạo mẫu với các yêu cầu thay đổi hoặc không xác định hoặc tương tác với các hệ thống khác thay đổi không thể đoán trước (tích hợp dữ liệu và ứng dụng). Tất nhiên, các ngôn ngữ được gõ động là không thể thiếu để xử lý các hành vi chương trình thực sự năng động như chặn phương thức, tải động, mã di động, phản ánh thời gian chạy, v.v. Trong mẹ của tất cả các bài viết về kịch bản [16], John Ousterhout lập luận rằng các hệ thống gõ tĩnh ngôn ngữ lập trình làm cho mã ít sử dụng lại, dài dòng hơn, không an toàn hơn và ít biểu cảm hơn các ngôn ngữ kịch bản được gõ động. Lập luận này được đưa ra theo nghĩa đen bởi nhiều người đề xướng các ngôn ngữ kịch bản được gõ động. Chúng tôi lập luận rằng đây là một lời ngụy biện và rơi vào cùng loại với lập luận rằng bản chất của lập trình khai báo là loại bỏ sự phân công. Hay như John Hughes nói [8], việc không thể tạo ra một ngôn ngữ mạnh mẽ hơn bằng cách bỏ qua các tính năng là một điều không thể. Bảo vệ thực tế rằng trì hoãn tất cả các loại kiểm tra thời gian chạy là một điều tốt, đang chơi các chiến thuật đà điểu với thực tế là các lỗi nên được bắt càng sớm trong quá trình phát triển càng tốt. đó là một sự bất khả thi logic để làm cho một ngôn ngữ mạnh mẽ hơn bằng cách bỏ qua các tính năng. Bảo vệ thực tế rằng trì hoãn tất cả các loại kiểm tra thời gian chạy là một điều tốt, đang chơi các chiến thuật đà điểu với thực tế là các lỗi nên được bắt càng sớm trong quá trình phát triển càng tốt. đó là một sự bất khả thi logic để làm cho một ngôn ngữ mạnh mẽ hơn bằng cách bỏ qua các tính năng. Bảo vệ thực tế rằng trì hoãn tất cả các loại kiểm tra thời gian chạy là một điều tốt, đang chơi các chiến thuật đà điểu với thực tế là các lỗi nên được bắt càng sớm trong quá trình phát triển càng tốt.

Các hệ thống loại tĩnh tìm cách loại bỏ một số lỗi tĩnh, kiểm tra chương trình mà không chạy nó và cố gắng chứng minh tính đúng đắn ở một số khía cạnh nhất định. Một số hệ thống loại có thể bắt lỗi nhiều hơn những hệ thống khác. Ví dụ, C # có thể loại bỏ các ngoại lệ con trỏ null khi được sử dụng đúng cách, trong khi Java không có sức mạnh như vậy. Twelf có một hệ thống loại thực sự đảm bảo rằng bằng chứng sẽ chấm dứt , "giải quyết" vấn đề tạm dừng .

Tuy nhiên, không có hệ thống loại nào là hoàn hảo. Để loại bỏ một loại lỗi cụ thể, họ cũng phải từ chối một số chương trình hoàn toàn hợp lệ vi phạm các quy tắc. Đây là lý do tại sao Twelf không thực sự giải quyết vấn đề tạm dừng, họ chỉ tránh nó bằng cách đưa ra một số lượng lớn bằng chứng hoàn toàn hợp lệ xảy ra để chấm dứt theo những cách kỳ lạ. Tương tự, hệ thống kiểu của Java từ chối PersistentVectortriển khai Clojure do sử dụng các mảng không đồng nhất. Nó hoạt động trong thời gian chạy, nhưng hệ thống loại không thể xác minh nó.

Vì lý do đó, hầu hết các hệ thống loại cung cấp "thoát", các cách để ghi đè trình kiểm tra tĩnh. Đối với hầu hết các ngôn ngữ, những ngôn ngữ này có hình thức truyền, mặc dù một số ngôn ngữ (như C # và Haskell) có toàn bộ chế độ được đánh dấu là "không an toàn".

Chủ quan, tôi thích gõ tĩnh. Được triển khai đúng cách (gợi ý: không phải Java), một hệ thống kiểu tĩnh có thể giúp ích rất nhiều trong việc loại bỏ các lỗi trước khi chúng làm sập hệ thống sản xuất. Các ngôn ngữ được gõ động có xu hướng yêu cầu kiểm tra đơn vị nhiều hơn, điều này rất tẻ nhạt vào thời điểm tốt nhất. Ngoài ra, các ngôn ngữ được nhập tĩnh có thể có một số tính năng nhất định không thể hoặc không an toàn trong các hệ thống loại động ( chuyển đổi ngầm định xuất hiện trong tâm trí). Đó là tất cả một câu hỏi về yêu cầu và hương vị chủ quan. Tôi sẽ không xây dựng Eclipse tiếp theo trong Ruby hơn là tôi sẽ cố gắng viết một tập lệnh sao lưu trong hội hoặc vá một kernel bằng Java.

Ồ, và những người nói rằng " x gõ có năng suất gấp 10 lần so với gõ y " chỉ đơn giản là thổi khói. Gõ động có thể "cảm thấy" nhanh hơn trong nhiều trường hợp, nhưng nó sẽ mất đi một khi bạn thực sự cố gắng làm cho ứng dụng ưa thích của mình chạy . Tương tự như vậy, gõ tĩnh có vẻ như là mạng an toàn hoàn hảo, nhưng người ta nhìn vào một số định nghĩa kiểu chung phức tạp hơn trong Java sẽ khiến hầu hết các nhà phát triển bàn tán xôn xao vì bịt mắt. Ngay cả với hệ thống loại và năng suất, không có viên đạn bạc.

Lưu ý cuối cùng: đừng lo lắng về hiệu suất khi so sánh tĩnh với gõ động. Các JIT hiện đại như V8 và TraceMonkey đang đến gần nguy hiểm với hiệu suất ngôn ngữ tĩnh. Ngoài ra, việc Java thực sự biên dịch thành ngôn ngữ trung gian động vốn có nên là một gợi ý rằng trong hầu hết các trường hợp, gõ động không phải là kẻ giết người hiệu năng lớn mà một số người nghĩ ra.

Vâng, cả hai đều rất, rất rất rất hiểu lầm và cũng là hai điều hoàn toàn khác nhau. không loại trừ lẫn nhau .

Các loại tĩnh là một hạn chế về ngữ pháp của ngôn ngữ. Langauges gõ tĩnh có thể nói là không có ngữ cảnh. Sự thật đơn giản là nó trở nên bất tiện khi diễn đạt một ngôn ngữ hoàn toàn trong ngữ pháp không ngữ cảnh không xử lý tất cả dữ liệu của nó đơn giản như các vectơ bit. Các hệ thống kiểu tĩnh là một phần của ngữ pháp của ngôn ngữ nếu có, chúng chỉ đơn giản hạn chế nó hơn một ngữ pháp tự do ngữ cảnh có thể, do đó kiểm tra ngữ pháp xảy ra trong hai lần đi qua nguồn thực sự. Các loại tĩnh tương ứng với khái niệm toán học của lý thuyết loại, lý thuyết loại trong toán học chỉ đơn giản là hạn chế tính hợp pháp của một số biểu thức. Giống như, tôi không thể nói 3 + [4,7]trong toán học, điều này là do lý thuyết loại của nó.

Do đó, các loại tĩnh không phải là một cách để 'ngăn ngừa lỗi' từ góc độ lý thuyết, chúng là một hạn chế của ngữ pháp. Thật vậy, với điều kiện là +, 3 và các khoảng có các định nghĩa lý thuyết tập hợp thông thường, nếu chúng ta loại bỏ hệ thống loại 3 + [4,7]có kết quả được xác định khá rõ đó là một tập hợp. "Lỗi về kiểu thời gian chạy" về mặt lý thuyết không tồn tại, sử dụng thực tế của hệ thống loại này là để ngăn chặn các hoạt động mà con người không có ý nghĩa. Tất nhiên, hoạt động vẫn chỉ là sự dịch chuyển và thao tác của các bit.

Điều đáng chú ý ở đây là một hệ thống loại không thể quyết định liệu các hoạt động đó có xảy ra hay không nếu nó được phép chạy. Như trong, phân vùng chính xác tập hợp tất cả các chương trình có thể có trong những chương trình sẽ có 'lỗi loại' và những chương trình không có. Nó chỉ có thể làm hai điều:

1: chứng minh rằng lỗi loại sẽ xảy ra trong chương trình
2: chứng minh rằng chúng sẽ không xảy ra trong chương trình

Điều này có vẻ như tôi đang mâu thuẫn với chính mình. Nhưng những gì trình kiểm tra loại C hoặc Java thực hiện là nó từ chối một chương trình là 'không theo quy tắc' hoặc vì nó gọi đó là 'lỗi loại' nếu nó không thể thành công ở mức 2. Nó không thể chứng minh rằng chúng sẽ không xảy ra, điều đó không có nghĩa là chúng sẽ không xảy ra, nó chỉ có nghĩa là nó không thể chứng minh điều đó. Rất có thể là một chương trình sẽ không có lỗi loại bị từ chối đơn giản vì nó không thể được trình biên dịch chứng minh. Một ví dụ đơn giản làif(1) a = 3; else a = "string";, chắc chắn vì nó luôn luôn đúng, nhánh khác sẽ không bao giờ được thực thi trong chương trình và không xảy ra lỗi loại nào. Nhưng nó không thể chứng minh những trường hợp này một cách chung chung, vì vậy nó đã bị từ chối. Đây là điểm yếu lớn của rất nhiều ngôn ngữ được nhập tĩnh, trong việc bảo vệ bạn chống lại chính mình, bạn nhất thiết cũng được bảo vệ trong trường hợp bạn không cần đến nó.

Nhưng, trái với niềm tin phổ biến, cũng có những ngôn ngữ được gõ tĩnh hoạt động theo nguyên tắc 1. Họ chỉ từ chối tất cả các chương trình mà họ có thể chứng minh rằng nó sẽ gây ra lỗi loại và vượt qua tất cả các chương trình mà họ không thể. Vì vậy, có thể họ cho phép các chương trình có lỗi loại, một ví dụ điển hình là Gõ vợt, đó là sự kết hợp giữa gõ động và gõ tĩnh. Và một số người sẽ tranh luận rằng bạn có được điều tốt nhất của cả hai thế giới trong hệ thống này.

Một ưu điểm khác của gõ tĩnh là các kiểu được biết tại thời gian biên dịch, và do đó trình biên dịch có thể sử dụng điều này. Nếu chúng ta trong Java làm "string" + "string"hoặc 3 + 3, cả hai +mã thông báo trong văn bản cuối cùng đại diện cho một hoạt động và mốc thời gian hoàn toàn khác nhau, trình biên dịch sẽ biết nên chọn loại nào trong số các loại một mình.

Bây giờ, tôi sẽ đưa ra một tuyên bố rất gây tranh cãi ở đây nhưng hãy đồng ý với tôi: 'kiểu gõ động' không tồn tại .

Nghe có vẻ rất gây tranh cãi, nhưng đó là sự thật, các ngôn ngữ được gõ động từ góc độ lý thuyết được tháo gỡ . Chúng chỉ là các ngôn ngữ gõ tĩnh chỉ với một loại. Hay nói một cách đơn giản, chúng là những ngôn ngữ thực sự được tạo ra bởi ngữ pháp bởi một ngữ pháp tự do ngữ cảnh trong thực tế.

Tại sao họ không có loại? Bởi vì mọi hoạt động được xác định và cho phép trên mọi toán tử, "lỗi loại thời gian chạy" chính xác là gì? Đó là từ một ví dụ lý thuyết hoàn toàn là một tác dụng phụ . Nếu thực hiện print("string")in chuỗi là một thao tác, thì cái length(3)trước có tác dụng phụ là ghi stringvào đầu ra tiêu chuẩn, đơn giản là cái sau error: function 'length' expects array as argument., đó là cái đó. Từ góc độ lý thuyết, không có thứ gọi là ngôn ngữ gõ động. Họ được tháo gỡ

Được rồi, lợi thế rõ ràng của ngôn ngữ 'gõ động' là sức mạnh biểu cảm, một hệ thống loại không có gì ngoài giới hạn của sức mạnh biểu cảm. Và nói chung, các ngôn ngữ có hệ thống loại thực sự sẽ có kết quả xác định cho tất cả các hoạt động không được phép nếu hệ thống loại chỉ bị bỏ qua, kết quả sẽ không có ý nghĩa với con người. Nhiều ngôn ngữ mất tính hoàn chỉnh Turing sau khi áp dụng một hệ thống loại.

Nhược điểm rõ ràng là thực tế là các hoạt động có thể xảy ra sẽ tạo ra kết quả vô nghĩa với con người. Để bảo vệ chống lại điều này, các ngôn ngữ được gõ động thường xác định lại các hoạt động đó, thay vì tạo ra kết quả vô nghĩa đó, chúng xác định lại nó có tác dụng phụ là viết ra một lỗi và có thể tạm dừng chương trình. Trên thực tế, đây không phải là một "lỗi", đặc điểm kỹ thuật ngôn ngữ thường bao hàm điều này, đây là hành vi của ngôn ngữ nhiều như in một chuỗi từ góc độ lý thuyết. Loại hệ thống do đó buộc người lập trình phải suy luận về dòng mã để đảm bảo rằng điều này không xảy ra. Hoặc thực sự, lý do để nó làmxảy ra cũng có thể có ích trong một số điểm để gỡ lỗi, cho thấy rằng đó hoàn toàn không phải là "lỗi" mà là một thuộc tính được xác định rõ của ngôn ngữ. Trên thực tế, phần còn lại của 'kiểu gõ động' mà hầu hết các ngôn ngữ có đang bảo vệ chống lại sự phân chia bằng 0. Đây là kiểu gõ động, không có kiểu nào, không có nhiều kiểu hơn số 0 là một kiểu khác với tất cả các số khác. Cái mà mọi người gọi là 'loại' chỉ là một thuộc tính khác của mốc thời gian, như độ dài của một mảng hoặc ký tự đầu tiên của chuỗi. Và nhiều ngôn ngữ được gõ động cũng cho phép bạn viết ra những thứ như thế "error: the first character of this string should be a 'z'".

Một điều nữa là các ngôn ngữ được gõ động có loại có sẵn trong thời gian chạy và thường có thể kiểm tra nó và xử lý nó và quyết định từ đó. Tất nhiên, về mặt lý thuyết, nó không khác gì việc truy cập char đầu tiên của một mảng và xem nó là gì. Trong thực tế, bạn có thể tạo C động của riêng mình, chỉ cần sử dụng một loại như int dài dài và sử dụng 8 bit đầu tiên của nó để lưu trữ 'loại' của bạn và viết các hàm phù hợp để kiểm tra nó và thực hiện phép cộng hoặc số nguyên. Bạn có một ngôn ngữ gõ tĩnh với một loại hoặc ngôn ngữ động.

Trong thực tế tất cả các chương trình này, các ngôn ngữ gõ tĩnh thường được sử dụng trong bối cảnh viết phần mềm thương mại, trong khi các ngôn ngữ gõ động có xu hướng được sử dụng trong bối cảnh giải quyết một số vấn đề và tự động hóa một số tác vụ. Viết mã bằng các ngôn ngữ được nhập tĩnh đơn giản chỉ mất nhiều thời gian và cồng kềnh vì bạn không thể làm những việc mà bạn biết sẽ không ổn nhưng hệ thống loại vẫn bảo vệ bạn trước những lỗi bạn không mắc phải. Nhiều lập trình viên thậm chí không nhận ra rằng họ làm điều này bởi vì nó nằm trong hệ thống của họ nhưng khi bạn viết mã bằng các ngôn ngữ tĩnh, bạn thường làm việc xung quanh thực tế là hệ thống loại sẽ không cho phép bạn làm những điều không thể sai, bởi vì nó không thể chứng minh rằng nó sẽ không đi sai.

Như tôi đã lưu ý, 'gõ tĩnh' nói chung có nghĩa là trường hợp 2, có tội cho đến khi được chứng minh vô tội. Nhưng một số ngôn ngữ, không xuất phát từ hệ thống loại của chúng từ lý thuyết loại tất cả đều sử dụng quy tắc 1: Vô tội cho đến khi được chứng minh là có tội, có thể là sự lai ghép lý tưởng. Vì vậy, có lẽ Typed Vợt là dành cho bạn.

Ngoài ra, đối với một ví dụ vô lý và cực đoan hơn, tôi hiện đang triển khai một ngôn ngữ trong đó 'loại' thực sự là ký tự đầu tiên của mảng, chúng là dữ liệu, dữ liệu của 'loại', 'loại', chính là một loại và mốc thời gian, mốc dữ liệu duy nhất có chính nó là một loại. Các loại không hữu hạn hoặc giới hạn tĩnh nhưng các loại mới có thể được tạo dựa trên thông tin thời gian chạy.

Có lẽ "lợi ích" lớn nhất của việc gõ động là đường cong học tập nông hơn. Không có hệ thống loại để tìm hiểu và không có cú pháp không tầm thường cho các trường hợp góc như ràng buộc kiểu. Điều đó làm cho việc gõ động có thể tiếp cận được với nhiều người hơn và khả thi đối với nhiều người mà các hệ thống kiểu tĩnh tinh vi nằm ngoài tầm với. Do đó, việc gõ động đã bắt kịp trong bối cảnh giáo dục (ví dụ Scheme / Python tại MIT) và các ngôn ngữ dành riêng cho tên miền dành cho những người không lập trình (ví dụ Mathicala ). Các ngôn ngữ động cũng đã bị cuốn vào những ngóc ngách nơi chúng có ít hoặc không có cạnh tranh (ví dụ Javascript).

Các ngôn ngữ được gõ động ngắn gọn nhất (ví dụ: Perl, APL, J, K, Mathicala ) là các miền cụ thể và có thể ngắn gọn hơn đáng kể so với các ngôn ngữ được nhập tĩnh có mục đích chung ngắn gọn nhất (ví dụ OCaml ) trong các hốc mà chúng được thiết kế cho .

Những nhược điểm chính của gõ động là:

• Lỗi loại thời gian chạy.

• Có thể rất khó hoặc thậm chí thực tế không thể đạt được cùng một mức độ chính xác và đòi hỏi phải thử nghiệm nhiều hơn nữa.

• Không có tài liệu xác minh trình biên dịch.

• Hiệu suất kém (thường là vào thời gian chạy nhưng đôi khi vào thời gian biên dịch thay vào đó, ví dụ Steme Scheme) và hiệu suất không thể đoán trước do phụ thuộc vào tối ưu hóa tinh vi.

Cá nhân, tôi lớn lên trên các ngôn ngữ động nhưng sẽ không chạm vào chúng với cực 40 'như một chuyên gia trừ khi không có lựa chọn khả thi nào khác.

Từ đánh máy của Artima : Bài viết mạnh so với yếu, tĩnh so với động :

gõ mạnh ngăn chặn các hoạt động trộn giữa các loại không khớp. Để trộn các loại, bạn phải sử dụng một chuyển đổi rõ ràng

gõ yếu có nghĩa là bạn có thể trộn các loại mà không cần chuyển đổi rõ ràng

Trong bài báo của Pascal Costanza, Đánh máy động so với gõ tĩnh - Phân tích dựa trên mẫu (PDF), ông tuyên bố rằng trong một số trường hợp, gõ tĩnh dễ bị lỗi hơn so với gõ động. Một số ngôn ngữ được nhập tĩnh buộc bạn phải mô phỏng thủ công gõ động để thực hiện "Điều đúng". Nó được thảo luận tại Lambda the Ultimate .

Nó phụ thuộc vào bối cảnh. Có rất nhiều lợi ích phù hợp với hệ thống gõ động cũng như cho kiểu gõ mạnh. Tôi cho rằng dòng ngôn ngữ kiểu động nhanh hơn. Các ngôn ngữ động không bị hạn chế với các thuộc tính lớp và trình biên dịch nghĩ về những gì đang diễn ra trong mã. Bạn có một chút tự do. Hơn nữa, ngôn ngữ động thường biểu cảm hơn và dẫn đến ít mã hơn là tốt. Mặc dù vậy, nó dễ bị lỗi hơn và cũng đáng nghi ngờ và phụ thuộc nhiều hơn vào độ bao phủ của bài kiểm tra đơn vị. Đó là nguyên mẫu dễ dàng với lang động nhưng bảo trì có thể trở thành ác mộng.

Lợi ích chính của hệ thống gõ tĩnh là hỗ trợ IDE và phân tích mã chắc chắn. Bạn trở nên tự tin hơn về mã sau mỗi thay đổi mã. Việc bảo trì là hòa bình của bánh với các công cụ như vậy.

Có rất nhiều điều khác nhau về ngôn ngữ tĩnh và động. Đối với tôi, sự khác biệt chính là trong các ngôn ngữ động, các biến không có kiểu cố định; thay vào đó, các loại được gắn với các giá trị. Bởi vì điều này, mã chính xác được thực thi là không xác định cho đến khi thời gian chạy.

Trong các triển khai sớm hoặc ngây thơ, đây là một lực cản hiệu suất rất lớn, nhưng các JIT hiện đại đã tiến gần đến mức tốt nhất bạn có thể có được với việc tối ưu hóa các trình biên dịch tĩnh. (trong một số trường hợp rìa, thậm chí tốt hơn thế).

Đó là tất cả về công cụ phù hợp cho công việc. Không phải là tốt hơn 100% thời gian. Cả hai hệ thống được tạo ra bởi con người và có sai sót. Xin lỗi, nhưng chúng tôi hút và làm cho công cụ hoàn hảo.

Tôi thích gõ động vì nó không theo cách của tôi, nhưng có lỗi thời gian chạy có thể xuất hiện mà tôi không có kế hoạch. Khi gõ tĩnh có thể sửa các lỗi đã nói ở trên, nhưng điều khiển một lập trình viên mới (bằng ngôn ngữ đã gõ) đang cố gắng tạo ra một chuỗi char và chuỗi không đổi.

Nhập tĩnh: Các ngôn ngữ như Java và Scala được gõ tĩnh.

Các biến phải được xác định và khởi tạo trước khi chúng được sử dụng trong mã.

cho người cũ int x; x = 10;

System.out.println (x);

Gõ động: Perl là một ngôn ngữ gõ động.

Các biến không cần phải được khởi tạo trước khi chúng được sử dụng trong mã.

y = 10; sử dụng biến này trong phần sau của mã