Là gõ tĩnh có giá trị đánh đổi?

Tôi bắt đầu viết mã bằng Python chủ yếu ở nơi không có loại an toàn, sau đó chuyển sang C # và Java ở đó. Tôi thấy rằng tôi có thể làm việc nhanh hơn một chút và ít đau đầu hơn với Python, nhưng một lần nữa, các ứng dụng C # và Java của tôi ở mức độ phức tạp cao hơn nhiều nên tôi chưa bao giờ cho Python kiểm tra căng thẳng thực sự.

Các trại Java và C # làm cho nó có vẻ như không có loại an toàn tại chỗ, hầu hết mọi người sẽ gặp phải tất cả các loại lỗi khủng khiếp bên trái và nó sẽ rắc rối hơn giá trị của nó.

Đây không phải là một so sánh ngôn ngữ, vì vậy xin vui lòng không giải quyết các vấn đề như được biên dịch so với giải thích. Là loại an toàn có giá trị đánh vào tốc độ phát triển và linh hoạt? TẠI SAO?

cho những người muốn có một ví dụ về ý kiến ​​rằng gõ động nhanh hơn:

"Sử dụng ngôn ngữ được gõ động trong quá trình phát triển. Nó cho bạn phản hồi nhanh hơn, thời gian quay vòng và tốc độ phát triển." - http://blog.jayway.com/2010/04/14/static-typing-is-the-root-of-all-evil/

Đó là một huyền thoại mà các lập trình viên không phải lo lắng về các loại trong các ngôn ngữ được gõ động.

Trong các ngôn ngữ được gõ động:

• Bạn vẫn phải biết nếu bạn đang làm việc với một mảng, số nguyên, chuỗi, bảng băm, tham chiếu hàm, từ điển, đối tượng hoặc bất cứ điều gì.

• Nếu đó là một đối tượng, bạn phải biết nó thuộc về lớp nào.

• Việc gán một trong các loại này cho một biến hoặc tham số hàm dự kiến ​​là một loại khác hầu như luôn luôn là một lỗi.

• Ở mức thấp hơn, những thứ như số bit hoặc được ký so với không dấu thường xuyên vẫn phải được tính nếu bạn đang điền một gói TCP, chẳng hạn.

• Bạn có thể gặp vấn đề khi bạn nhận được số 0 trong đó bạn thực sự muốn một chuỗi rỗng. Nói cách khác, bạn vẫn đang gỡ lỗi các lỗi không khớp. Sự khác biệt thực sự duy nhất là trình biên dịch không bắt lỗi.

• Tôi cho rằng bạn thậm chí không tiết kiệm nhiều thao tác gõ - bởi vì bạn có xu hướng muốn ghi lại trong các bình luận loại tham số chức năng của bạn thay vì ghi lại nó trong mã của bạn. Đây là lý do tại sao các khối nhận xét kiểu doxygen phổ biến hơn nhiều trong thực tế trong toàn bộ mã được gõ động, trong đó trong các ngôn ngữ được nhập tĩnh, bạn hầu như chỉ nhìn thấy chúng cho các thư viện.

Điều đó không có nghĩa là lập trình bằng các ngôn ngữ được gõ động không cảm thấy dễ chịu hơn vì trình biên dịch không phải lúc nào cũng nằm trên lưng bạn và các lập trình viên có kinh nghiệm không có xu hướng gặp khó khăn trong việc tìm và sửa các loại lỗi mà gõ tĩnh sẽ mắc phải. , nhưng đó là một vấn đề hoàn toàn tách biệt với sự gia tăng hiệu quả hoặc giảm tỷ lệ lỗi, trong đó gõ động là tốt nhất ngay cả với gõ tĩnh.

Khi các loại mạnh hơn, chúng có thể giúp bạn nhiều hơn - nếu bạn sử dụng chúng đúng cách thay vì chiến đấu với chúng. Thiết kế các loại của bạn để phản ánh không gian vấn đề của bạn và các lỗi logic có nhiều khả năng trở thành không khớp kiểu thời gian biên dịch thay vì các sự cố thời gian chạy hoặc kết quả vô nghĩa.

Tuyên bố miễn trừ trách nhiệm: Tôi là người yêu kiểu;)

Câu hỏi của bạn rất khó trả lời: Những sự đánh đổi đó là gì?

Tôi sẽ lấy một ví dụ cực đoan: Haskell , nó được gõ tĩnh. Có lẽ một trong những ngôn ngữ được gõ mạnh nhất tồn tại, trên thực tế.

Tuy nhiên, Haskell hỗ trợ Lập trình chung , theo nghĩa là bạn viết các phương thức hoạt động với bất kỳ loại nào tuân theo một khái niệm (hoặc giao diện) nhất định.

Hơn nữa, Haskell sử dụng Kiểu suy luận , do đó bạn không bao giờ phải khai báo loại biến của mình. Chúng được tính toán tĩnh trong quá trình biên dịch, giống như một Trình thông dịch Python sẽ tính toán chúng chạy chương trình.

Tôi đã phát hiện ra rằng hầu hết mọi người đều đánh máy bằng cách gõ tĩnh, thực sự phàn nàn về điều gì khác (tính dài dòng, nỗi đau của việc chuyển đổi một loại có lợi cho loại khác), nhưng Haskell không có vấn đề gì trong khi gõ ...

Ví dụ về sự ngắn gọn:

-- type
factorial :: Integer -> Integer

-- using recursion
factorial 0 = 1
factorial n = n * factorial (n - 1)

Ngoài hỗ trợ tích hợp, thật khó để có được nhiều hơn.

Ví dụ về lập trình chung:

> reverse "hell­o" -- Strings are list of Char in Haskell
=> "olleh"
> reverse [1, 2, 3, 4, 5]
=> [5,4,3,2,1]

Ví dụ về suy luận kiểu:

> :t rever­se "hell­o"
:: [Char]

có thể được tính toán đơn giản:

• "hello"là một danh sách Char(thể hiện dưới dạng [Char])
• reverseáp dụng cho một loại [A]trả về một loại[A]

Dùng thử trong trình duyệt của bạn

Tôi thích cả hai ngôn ngữ gõ tĩnh và gõ động. Hai ưu điểm lớn nhất của loại an toàn đối với tôi là:

1) Bạn thường có thể suy luận khá nhiều những gì một chức năng hoàn toàn từ chữ ký loại của nó (điều này đặc biệt đúng trong các ngôn ngữ chức năng như Haskell).

2) Khi bạn thực hiện tái cấu trúc đáng kể, trình biên dịch sẽ tự động cho bạn biết mọi thứ bạn phải làm để giữ mọi thứ hoạt động. Khi tôi cấu trúc lại một cái gì đó trong C ++, quy trình của tôi thường chỉ đơn giản là a) thay đổi một phần tôi biết tôi muốn thay đổi, sau đó b) sửa mọi lỗi biên dịch.

Cá nhân, tôi thấy rằng loại an toàn giúp tôi phát triển nhanh hơn trong công việc hiện tại của tôi. Trình biên dịch thực hiện rất nhiều việc kiểm tra sự tỉnh táo đối với tôi gần như khi tôi gõ, cho phép tôi tập trung hơn vào logic kinh doanh mà tôi đang triển khai.

Điểm mấu chốt đối với tôi là mặc dù tôi mất một chút linh hoạt, tôi vẫn có được một chút thời gian để theo dõi các vấn đề về loại hình.

Có rất nhiều ý kiến ​​mạnh mẽ xung quanh cuộc tranh luận nhưng rõ ràng đây không thực sự là vấn đề quan điểm, đó là vấn đề thực tế . Vì vậy, chúng ta nên nhìn vào nghiên cứu thực nghiệm . Và bằng chứng từ đó là rõ ràng:

Có , gõ tĩnh là giá trị thương mại-offs - và không chỉ bởi một chút, nhưng trên thực tế đáng kể . Trên thực tế, bằng chứng vững chắc cho thấy việc gõ tĩnh có thể giảm ít nhất 15% lỗi trong mã (và đây là ước tính thấp, tỷ lệ thực tế gần như chắc chắn lớn hơn). Đó là một con số cao đáng kinh ngạc : Tôi nghĩ rằng ngay cả hầu hết những người đề xuất kiểu gõ tĩnh sẽ không nghĩ rằng nó tạo ra sự khác biệt lớn như vậy.

Hãy xem xét điều này: nếu ai đó nói với bạn rằng có một cách đơn giản để giảm 15% lỗi trong dự án của bạn chỉ sau một đêm, thì đó là một việc không có trí tuệ. ¹ Nó gần như là viên đạn bạc tục ngữ.

Bằng chứng được trình bày trong bài báo Loại hay không gõ: Định lượng lỗi phát hiện trong JavaScript của Zheng Gao, Christian Bird và Earl T. Barr. Tôi khuyến khích mọi người đọc nó, đó là một bài viết tốt trình bày nghiên cứu mẫu mực.

Thật khó để tóm tắt ngắn gọn về việc các tác giả đã thực hiện phân tích chặt chẽ như thế nào nhưng đây là một phác thảo (rất thô sơ):

TypeScript và Flow là hai ngôn ngữ lập trình dựa trên JavaScript, trong khi vẫn tương thích với nhau, thêm gợi ý kiểu và kiểm tra kiểu tĩnh. Điều này cho phép tăng mã hiện có theo loại và sau đó gõ kiểm tra nó.

Các nhà nghiên cứu đã thu thập các dự án nguồn mở được viết bằng JavaScript từ GitHub, xem xét các báo cáo lỗi đã giải quyết và cố gắng giảm từng lỗi được báo cáo thành một đoạn mã sẽ bị trình kiểm tra loại tĩnh của TypeScript hoặc Flow bắt được. Điều này cho phép họ ước tính giới hạn thấp hơn về tỷ lệ lỗi có thể được sửa bằng cách sử dụng kiểu gõ tĩnh.

Các nhà nghiên cứu đã thực hiện các biện pháp phòng ngừa nghiêm ngặt để đảm bảo rằng phân tích của họ sẽ không coi một lỗi không liên quan đến loại là có liên quan đến các loại. ²

So với các nghiên cứu trước đây, nghiên cứu mới này có những điểm mạnh đặc biệt:

• Có một so sánh trực tiếp giữa gõ tĩnh và gõ động, với một vài yếu tố gây nhiễu (nếu có), vì sự khác biệt duy nhất giữa JavaScript và TypeScript / Flow là cách gõ.
• Chúng thực hiện sao chép trên nhiều thứ nguyên bằng cách kiểm tra cả TypeScript và Flow (tức là các hệ thống loại khác nhau) và bằng cách cho những người khác nhau tái tạo chú thích loại (thủ công) để sửa lỗi. Và họ thực hiện điều này trên một số lượng lớn các cơ sở mã từ các dự án khác nhau.
• Bài viết đo lường tác động trực tiếp của việc gõ tĩnh lên các lỗi có thể sửa chữa (thay vì một số chất lượng mơ hồ hơn).
• Các tác giả định nghĩa một mô hình nghiêm ngặt về những gì cần đo, và làm thế nào, lên phía trước. Hơn nữa, mô tả của họ cực kỳ rõ ràng và giúp dễ dàng phân tích các sai sót (thật tốt khi một bài nghiên cứu mở ra các cuộc tấn công: nếu không có cuộc tấn công nào có thể làm xáo trộn lập luận của nó, thì nó còn mạnh hơn nữa). ³
• Họ thực hiện phân tích công suất phù hợp để kích thước mẫu của họ là đủ, và phân tích thống kê tiếp theo của họ là kín khí.
• Họ quá bảo thủ để loại trừ những giải thích gây nhiễu, và chỉ đo một phần chuyển động duy nhất. Hơn nữa, họ hạn chế phân tích của họ đối với các lỗi có thể sửa được ngay lập tức bằng cách bao gồm các loại và loại trừ mọi thứ có thể yêu cầu tái cấu trúc nâng cao hơn để phù hợp với việc gõ. Vì vậy, trong thực tế, hiệu ứng lớn hơn rất nhiều, nhưng chắc chắn không nhỏ hơn những gì họ báo cáo.
• Và cuối cùng, họ không tìm thấy một hiệu ứng nhỏ nhưng sự khác biệt đáng kinh ngạc . Mặc dù thủ tục bảo thủ quá mức của họ, ngay cả ở mức thấp của khoảng tin cậy 95%, họ thấy rằng có ít nhất 10% lỗi sẽ biến mất chỉ với các kiểm tra loại được thêm tối thiểu.

Trừ khi có một lỗ hổng cơ bản trong bài báo mà chưa ai phát hiện ra, bài báo cho thấy một lợi ích lớn của việc gõ tĩnh, gần như không mất phí. ⁴

Trên một ghi chú lịch sử, nghiên cứu về việc gõ các môn học trong lập trình đã có một khởi đầu mạnh mẽ bởi vì, trong một thời gian dài, bằng chứng không rõ ràng. Lý do cho điều này là vì thực hiện các thử nghiệm có hệ thống để kiểm tra hiệu quả của việc gõ tĩnh so với gõ động không dễ dàng: một thử nghiệm có hệ thống phải cô lập hiệu ứng mà chúng tôi đang nghiên cứu. Và thật không may, chúng tôi không thể cô lập hiệu ứng của môn học đánh máy, vì nó gắn liền với các ngôn ngữ lập trình.

Thực tế đã có các ngôn ngữ lập trình cho phép gõ cả tĩnh và động trong các phương ngữ khác nhau (ví dụ VB có Option Strict Onhoặc Off, hoặc gõ tĩnh Lisp). Tuy nhiên, những điều này không phù hợp để so sánh trực tiếp, quan trọng nhất là vì không có cơ sở mã đủ lớn hiện có cho phép so sánh trực tiếp. Tốt nhất chúng ta có thể so sánh chúng trong các thiết lập trong phòng thí nghiệm của Cameron, trong đó các đối tượng thử nghiệm giải quyết ngẫu nhiên một nhiệm vụ trong biến thể gõ tĩnh hoặc động của ngôn ngữ.

Thật không may, các bài tập lập trình nhân tạo này không mô hình hóa việc sử dụng trong thế giới thực. Cụ thể, nhiều trong số chúng có phạm vi nhỏ và giải quyết một vấn đề được xác định rõ có thể tóm tắt trên nửa trang văn bản.

May mắn thay, trong quá khứ, bởi vì TypeScript, Flow và JavaScript thực sự là cùng một ngôn ngữ ngoại trừ việc gõ tĩnh và vì có một bộ dữ liệu mã và lỗi trong thế giới thực rộng lớn để lấy mẫu.

_{¹ Lấy cảm hứng từ một trích dẫn từ bài báo gốc.}

_{² Tôi không hoàn toàn hài lòng với điều này: một trong những thế mạnh chính của các ngôn ngữ được gõ tĩnh là các vấn đề không liên quan đến kiểu có thể được xử lý theo cách có thể được kiểm tra kiểu tĩnh. Điều này biến đổi nhiều lỗi logic thành lỗi loại, làm tăng đáng kể tỷ lệ lỗi có thể bị bắt bằng cách gõ tĩnh. Trên thực tế, bài báo phân loại một cách thô sơ các lỗi không liên quan đến loại và tôi cho rằng một tỷ lệ lớn trong số đó thực tế có thể bị bắt bằng cách gõ tĩnh.}

_{³ Tôi mời bất cứ ai, đặc biệt là những người ủng hộ việc gõ động, cố gắng tìm ra những sai sót không được giải quyết trong phân tích. Tôi không nghĩ có nhiều (nếu có), và tôi tin rằng không có lỗ hổng tiềm năng nào làm thay đổi nghiêm trọng kết quả.}

_{⁴ Tôi nghi ngờ rằng chi phí thực tế của việc gõ tĩnh trong các dự án thực tế, quy mô lớn là không có, vì sau đó nó trở thành một phần tự nhiên của kiến ​​trúc và thậm chí có thể đơn giản hóa việc lập kế hoạch. Sửa lỗi loại tĩnh cần có thời gian, nhưng ít hơn nhiều so với lỗi được phát hiện sau này. Điều này đã được nghiên cứu rộng rãi theo kinh nghiệm và đã được biết đến trong nhiều thập kỷ (xem ví dụ Code Complete ).}

Là loại an toàn có giá trị đánh vào tốc độ phát triển và linh hoạt?

Vì vậy, thực sự điều này đi xuống với những gì bạn đang làm. Nếu bạn đang lập trình nói, các hệ thống dự phòng cho máy bay, loại an toàn có lẽ là cách để đi.

Ngôn ngữ động và lập trình ngôn ngữ tĩnh thực sự là hai động vật khác nhau. Cả hai đều đòi hỏi một cách tiếp cận cơ bản khác nhau. Bạn chủ yếu có thể chuyển một phương pháp tiếp cận giữa tĩnh và động, nhưng bạn sẽ mất đi những lợi thế của phương pháp khác.

Đó là một suy nghĩ thực sự. Cái này tốt hơn những cái khác phải không? Điều đó thực sự phụ thuộc vào bạn là ai và bạn nghĩ như thế nào. Hầu hết những người tôi làm việc cùng sẽ không bao giờ chạm vào ngôn ngữ động nếu họ không phải làm thế, vì họ cảm thấy có quá nhiều chỗ cho lỗi. Họ có sai khi nghĩ điều này? Tất nhiên là không, nhưng điều đó có nghĩa là họ đã nhận ra rằng cách tiếp cận áp dụng phong cách mã hóa của họ sẽ không hoạt động trong một môi trường năng động. Những người khác tôi đi đến nhóm người dùng hoàn toàn ngược lại. Họ thấy việc gõ tĩnh quá cồng kềnh, bởi vì nó giới hạn cách tiếp cận của họ để giải quyết các loại vấn đề nhất định.

Tôi có thể thành thật mà nói, tôi nhảy giữa JavaScript và C # rất nhiều. Bây giờ, biết và làm việc trong cả hai ngôn ngữ sẽ ảnh hưởng đến ngôn ngữ kia ở một mức độ nào đó, nhưng trên thực tế, mã tôi viết trong mỗi giao diện hoàn toàn khác với ngôn ngữ kia. Họ đòi hỏi một cách tiếp cận khác, bởi vì về cơ bản chúng khác nhau. Những gì tôi đã tìm thấy là nếu bạn thấy mình suy nghĩ, "Đàn ông điều này khó hơn nhiều để làm điều này bằng ngôn ngữ X", cách tiếp cận của bạn có lẽ hơi lạc hậu. Dưới đây là một ví dụ, mọi người nói về cách làm việc "Pythonic". Điều đó có nghĩa là có một cách mà ngôn ngữ Python hoạt động để làm cho vấn đề trở nên dễ dàng hơn. Làm một số cách khác thường khó hơn và cồng kềnh hơn. Bạn phải vượt qua cái bướu để biết cách ngôn ngữ hoạt động để thực sự nó phù hợp với bạn. Nó '

Có một câu hỏi tương tự vừa được hỏi gần đây: Ngôn ngữ động và gõ tĩnh cho các trang web

Để phục hồi cốt lõi câu trả lời của tôi:

Khi các hệ thống phát triển lớn hơn, các ngôn ngữ được nhập tĩnh đảm bảo sự mạnh mẽ ở cấp thành phần và do đó linh hoạt ở cấp hệ thống.

Vâng, Java được gõ đúng và vâng, Java rất tệ (không vi phạm. Thật khủng khiếp. Nền tảng & hệ sinh thái tuyệt vời, nhưng là một trong những ngôn ngữ tồi tệ nhất (thực sự đang được sử dụng)).
Nhưng suy ra từ đó, việc đánh máy nghiêm ngặt đó chỉ là một lời ngụy biện. Nó giống như chỉ vào PHP và suy ra các kiểu gõ động (một lần nữa, không vi phạm. Nó đang dần cải thiện, tôi cung cấp cho bạn điều đó).

Cá nhân, tôi thực hiện hầu hết sự phát triển của mình trong haXe , có một hệ thống kiểu tĩnh. Nó không chỉ biểu cảm rõ rệt hơn so với Java và nó đòi hỏi ít nỗ lực hơn do suy luận kiểu, mà còn là tùy chọn. Nếu nó cản trở bạn, bạn chỉ cần bỏ qua nó.

Loại an toàn là một tính năng (đây là điều mà nhiều ngôn ngữ được cho là cấp cao không đúng) để giúp bạn ngăn chặn việc tự bắn vào chân mình .
Và về bất kỳ thành công nào, ngôn ngữ được gõ động sẽ đơn giản tốt hơn, nếu bạn có tùy chọn kiểm tra loại mã của mình theo ý muốn.
Ví dụ, tôi chắc chắn rất thích thử nghiệm Ruby, nhưng điều đó chủ yếu là do Ruby hoàn toàn hướng đối tượng, hoàn toàn trực giao với sự hiện diện của hệ thống loại thời gian biên dịch.

Tôi nghĩ rằng tuyên bố, rằng các hệ thống loại tĩnh là khó hiểu chỉ đơn thuần dựa trên sự thiếu kiến ​​thức về các hệ thống loại tĩnh tốt. Có một số ngôn ngữ làm đúng, haXe là một trong số đó, và được cho là thậm chí không phải là ngôn ngữ tốt nhất trong vấn đề đó.

Ví dụ mã haXe:

class Car {
    public function new();
    public function wroom() trace('wroooooooom!')
}
class Duck {
    public function new();
    public function quack(at) trace('quackquack, ' + at + '!')
}

function letQuack(o) o.quack();
letQuack(new Car());
letQuack(new Duck());

Điều này sẽ tạo ra một lỗi thời gian biên dịch:

Car should be { quack : Void -> Unknown<0> }
Car has no field quack
For function argument 'o'
Duck should be { quack : Void -> Unknown<0> }
Invalid type for field quack :
to : String -> Void should be Void -> Unknown<0>
For function argument 'o'

Bạn thực sự không thể khẳng định tôi đã phải nỗ lực rất nhiều vào loại an toàn.

Nói rằng bạn không cần loại an toàn, bởi vì bạn có các bài kiểm tra thậm chí còn ngu ngốc hơn. Bài kiểm tra viết là nhàm chán và lặp đi lặp lại. Và tôi thực sự không muốn viết một bài kiểm tra, chỉ để tìm hiểu rằng một ví dụ về Xe sẽ không quấy rối và một con Vịt cần ai đó quậy phá.

Vào cuối ngày, bạn sẽ thấy, bất kể chi phí an toàn cho loại trên không là bao nhiêu, cuối cùng nó cũng bị đạn dược (ngay cả trong Java - mặc dù có thể không sớm như vậy).

Vì bất kỳ lý do gì, tôi không mắc lỗi liên quan đến loại đối tượng thường xuyên nữa. Trong các ngôn ngữ như C #, tôi có nhiều khả năng mắc lỗi liên quan đến phôi thời gian chạy hơn là tôi có thể mắc lỗi an toàn loại trình biên dịch, mà tôi cấp, thường là do nhu cầu thỉnh thoảng phải xử lý tĩnh của tĩnh đánh máy ngôn ngữ. Khi tôi viết ruby, mã có xu hướng gợi ý khá mạnh về loại đối tượng và tính khả dụng của REPL có nghĩa là tôi đã xác minh bằng thực nghiệm rằng phương thức / thuộc tính mong muốn tồn tại hoặc tôi sẽ có một bài kiểm tra đơn vị thực hiện về cơ bản là điều tương tự, vì vậy tôi cũng hiếm khi gặp vấn đề về an toàn trong ruby.

Nhưng điều đó không có nghĩa là các hệ thống gõ tĩnh không thể tốt hơn chúng.

Trong các ngôn ngữ gõ tĩnh, hệ thống loại thực sự cũng rất quan trọng. Ví dụ, với một cái gì đó giống như một số đơn nguyên trong các ngôn ngữ chức năng (loại <Một số>: = có x | không), bạn có được kiểm tra thời gian biên dịch mà về cơ bản ngăn chặn NullReferenceException đáng sợ trong hầu hết các hệ thống loại; khi mã khớp mẫu chạy, bạn nhận được các lỗi thời gian biên dịch cho bạn biết rằng bạn không thể xử lý điều kiện null (nếu bạn sử dụng cơ chế đó để khai báo kiểu). Bạn cũng giảm các loại lỗi tương tự khi bạn sử dụng những thứ như |> toán tử đường ống trong F #.

Theo truyền thống gõ tĩnh của Hindley, Milner, bạn có thể xây dựng những thứ mang lại cho bạn nhiều hơn một sự đảm bảo rằng một loại yêu cầu hỗ trợ giao diện X, và một khi bạn có những thứ đó, tôi sẽ nói rằng hệ thống gõ tĩnh trở nên rất nhiều có giá trị hơn.

Khi đó không phải là một tùy chọn, các tiện ích mở rộng Design By Contract cho C # có thể thêm một bộ cơ chế khác làm tăng giá trị của hệ thống loại tĩnh, nhưng chúng vẫn đòi hỏi nhiều kỷ luật hơn một số mô hình chức năng đó.

Nó phụ thuộc.

Chế độ thất bại của con người thường được thống kê. Kiểm tra loại mạnh làm giảm khả năng một số loại thất bại nhất định của con người (gây ra mã lỗi). Nhưng chỉ vì bạn có thể thất bại không phải lúc nào cũng có nghĩa là bạn sẽ (Murphy không chịu được).

Việc giảm tỷ lệ thất bại tiềm năng này có đáng giá hay không.

Nếu bạn đang viết mã cho một nhà máy điện hạt nhân hoặc hệ thống ATC, bất kỳ việc giảm chế độ thất bại nào của con người có thể cực kỳ quan trọng. Nếu bạn đang tạo mẫu nhanh một số ý tưởng trang web không có thông số kỹ thuật và với hậu quả thất bại gần như bằng không, thì việc giảm các chế độ thất bại hoặc xác suất có thể hoặc không mua cho bạn bất cứ thứ gì, nhưng có thể khiến bạn mất thời gian phát triển (nhiều lần nhấn phím hơn, v.v.), và trong các tế bào não bị phân tâm bằng cách ghi nhớ (các) loại hiện tại cần thiết.

Đã có rất nhiều hệ thống rất phức tạp được viết bằng Lisp và tôi không nghe thấy bất kỳ Lisper nào phàn nàn rằng họ muốn gõ tĩnh. Khi tôi làm việc với nó, tôi không nhớ bất kỳ vấn đề nào làm tôi chậm đi nhiều mà hệ thống kiểu tĩnh (và bạn có thể chỉ định các loại tĩnh trong Common Lisp) sẽ gặp phải.

Ngoài ra, các ngôn ngữ được nhập tĩnh chính dường như không phù hợp để bắt lỗi. Trong việc thiết kế bố trí, có chuyện gì quan trọng là một số lượng nhất định là một phép đo dọc trên trang, không cho dù đó là int, unsigned, float, hoặc double. Mặt khác, trình biên dịch sẽ thường gắn cờ các chuyển đổi loại mà nó cho là không an toàn và vui vẻ cho tôi thêm phép đo dọc và số lượng ký tự trong một chuỗi. Điểm yếu này của hệ thống loại tĩnh là ý tưởng ban đầu đằng sau ký hiệu Hungary của Simony, trước khi nó bị biến thành vô dụng xấu xí.

Các loại là các ràng buộc trên các giao diện, vì vậy chúng là một tập hợp con của những gì bạn có thể muốn kiểm tra với các bài kiểm tra đơn vị, và vì vậy rất nhiều sự đánh đổi là tương tự nhau:

• Các loại tĩnh cung cấp phản hồi trước đó về việc liệu mã có đáp ứng các yêu cầu có thể được biểu thị bởi hệ thống loại hay không, đổi lại việc trì hoãn phản hồi từ việc xây dựng một cái gì đó có chức năng tối thiểu (như phản hồi của khách hàng hoặc kiểm tra mức cao hơn).
• Biết rằng mã đáp ứng các yêu cầu nhất định có thể dễ dàng tái cấu trúc và gỡ lỗi, nhưng nó cũng bổ sung thêm chi phí để thay đổi giao diện và thay đổi yêu cầu.
• Đặc biệt, nếu một ngôn ngữ gõ tĩnh thiếu sự ép buộc, nó cung cấp bảo mật bổ sung chống lại việc sử dụng mã trên dữ liệu sẽ gây ra lỗi (giảm nhu cầu về điều kiện và xác nhận), nhưng các ràng buộc hạn chế quá mức yêu cầu người dùng viết thêm mã để xoa bóp dữ liệu của họ hình thức chấp nhận được (chẳng hạn như đúc loại rõ ràng).
• Chú thích loại rõ ràng có thể hỗ trợ sự hiểu biết khi đọc mã, hoặc nó có thể làm lộn xộn mã với thông tin dư thừa hoặc không cần thiết.
• Tùy thuộc vào việc thực hiện, nó có thể làm mất đi sự căng thẳng. Điều này phụ thuộc vào những thứ như chú thích loại được yêu cầu hoặc suy ra, hệ thống loại có thể biểu thị các kiểu / giao diện chung, cú pháp như thế nào và bạn có định kiểm tra các ràng buộc có thể được biểu thị bởi hệ thống loại không (ví dụ: kiểm tra tương tự có khả năng ngắn gọn hơn như một tính năng ngôn ngữ hơn là kiểm tra đơn vị, nhưng bạn có thể không có ý định kiểm tra nó).
• Ngoài ra (nhưng không liên quan đến TDD), các loại tĩnh có thể hỗ trợ tối ưu hóa thời gian biên dịch, với chi phí yêu cầu kiểm tra các loại đó (và dành thời gian để kiểm tra chúng và thực hiện tối ưu hóa), và tối ưu hóa tốt hơn có thể được thực hiện nếu dữ liệu bị hạn chế đối với các loại Bản đồ đó tốt cho phần cứng. Điều này giúp giảm bớt sự phát triển về mã với các yêu cầu về hiệu năng, nhưng có thể gây rắc rối cho mã không phù hợp với các ràng buộc này (theo điểm 3).

Tóm lại, tôi cho rằng các ngôn ngữ động đặc biệt hữu ích cho việc tạo mẫu, trong khi nếu bạn cần chắc chắn rằng mã của mình là chính xác, bạn nên ưu tiên một hệ thống loại mạnh.

Vâng chắc chắn. Một điều bạn sẽ thấy khi bạn sử dụng cả hai ngôn ngữ được gõ mạnh và Python (Python được gõ mạnh) hơn nữa là hầu hết các mã được viết tốt trong các ngôn ngữ động có xu hướng tuân theo rất nhiều quy ước giống như mã được gõ mạnh. Gõ động rất hữu ích cho việc tuần tự hóa và giải tuần tự hóa, nhưng đối với hầu hết những thứ khác, nó thực sự không đóng góp nhiều lợi thế. Và trừ khi hầu hết các mã của bạn liên quan đến tuần tự hóa, tại sao lại bỏ qua việc kiểm tra lỗi miễn phí?

Morgan, tôi có một ý tưởng thú vị để bạn thử: gõ tĩnh + động. Bạn đã đề cập đến Python, C # và Java. Bạn có biết rằng có một số cổng Python khá tốt cho cả .NET và Java không? Trong cả hai trường hợp, các cổng cho phép bạn sử dụng các thư viện của các nền tảng đó và / hoặc tương tác với mã hiện có. Điều này cung cấp cho bạn một số khả năng:

1. Giữ mã kế thừa trong ngôn ngữ tĩnh, không linh hoạt. Sử dụng Python cho công cụ mới.
2. Sử dụng Python để tạo nguyên mẫu công cụ mới trên nền tảng trưởng thành. Mã lại các thành phần bạn muốn giữ bằng ngôn ngữ trưởng thành hơn.
3. Sử dụng ngôn ngữ động cho các phần bạn thay đổi thường xuyên.
4. Có thể sử dụng ngôn ngữ động để chơi với các ý tưởng như sửa đổi mã đang chạy.
5. Làm mọi thứ bằng ngôn ngữ động ngoại trừ những phần quan trọng mà bạn sử dụng ngôn ngữ được gõ mạnh.

Tôi đã sử dụng những cách tiếp cận này từ cuối những năm 90 để vượt qua nỗi đau phát triển trong C / C ++. Tôi cần các thư viện bản địa và đôi khi hiệu suất. Tuy nhiên, tôi muốn cú pháp tốt hơn, linh hoạt, an toàn, v.v. Vì vậy, mánh khóe đã cẩn thận kết hợp chúng để có được sự đánh đổi đúng đắn. Nó thường tốt hơn trong thực tế hơn là ném toàn bộ ngôn ngữ và mã kế thừa cho một ngôn ngữ / nền tảng khác.

(Lưu ý: Một câu trả lời đã được nói rồi, nhưng tôi cũng muốn nhấn mạnh lại cách gõ động đó! = Không / gõ yếu. Nhiều hệ thống kiểu động sử dụng kiểu gõ mạnh ở bên trong. một loại biến được xác định trong thời gian chạy, không cần chú thích kiểu và / hoặc có thể thay đổi khi chạy.

Bạn sẽ không nhận được câu trả lời thực sự khách quan cho vấn đề đó, nhưng kinh nghiệm của tôi là loại an toàn là vô giá cho đến khi bạn thành thạo TDD. Khi bạn có phạm vi kiểm tra đơn vị nặng, trong đó các bài kiểm tra đã được viết trước mã, kiểm tra trình biên dịch trở thành một nỗi đau và thực sự bắt đầu cản trở bạn.

Tôi thấy câu hỏi này xuất hiện rất nhiều và tôi nghĩ rằng chất lượng phần mềm của bạn (và thiếu lỗi) có liên quan nhiều đến quá trình phát triển của bạn, cách hệ thống của bạn được kiến ​​trúc và sự cam kết của bạn và đồng nghiệp về chất lượng mã.

Công việc cuối cùng của tôi chủ yếu là phát triển trăn. Tôi đã làm việc cho một công ty lưu trữ web quốc tế lớn và chúng tôi có các nhóm phát triển ở Mỹ, Canada và Hàn Quốc. Khung web python tùy chỉnh cho ứng dụng khách hàng mặt trước cho phép người dùng quản lý tên miền và tài khoản lưu trữ web của họ. Cuối cùng: tất cả trăn quá. Dịch vụ web Python để nói chuyện với các máy chủ riêng lẻ để thực hiện những việc như cung cấp trang web lưu trữ web mới, tạo blog mới, tạo các mục dns trong hệ thống dịch vụ tên của chúng tôi; vv, vv Trong công việc hiện tại của tôi, ứng dụng khách tất cả của chúng tôi trong java; sản phẩm chính của chúng tôi là một hỗn hợp của java và flash. Khung web java tùy chỉnh cho các ứng dụng cũ hơn, wicket cho các công cụ nội bộ mới hơn của chúng tôi.

Đã làm việc trong cả hai, tôi phải nói câu hỏi này làm phiền tôi mỗi khi tôi nhìn thấy nó. Nếu bạn đang sử dụng một ngôn ngữ được gõ động và thực sự kiểm tra mã của bạn, bạn sẽ ổn thôi. Nếu hệ thống được thiết kế tốt, và bạn tuân theo các tiêu chuẩn, bạn sẽ ổn. Không bao giờ có nhiều lỗi xuất hiện do thiếu các loại kiểm tra trình biên dịch. Hầu hết các lỗi là lỗi logic, giống như công việc java của tôi ngày nay.

Là loại an toàn có giá trị đánh vào tốc độ phát triển và linh hoạt? TẠI SAO?

Gõ tĩnh là sự gia tăng ròng về tốc độ và tính linh hoạt của sự phát triển trong suốt vòng đời của phần mềm. Nó làm giảm toàn bộ nỗ lực và sự bất tiện, nhưng di chuyển rất nhiều nỗ lực và sự bất tiện lên phía trước, nơi nó đáng chú ý hơn. Rào cản đầu vào để có mã làm việc cao hơn, nhưng một khi bạn vượt qua rào cản đó (bằng cách thỏa mãn trình kiểm tra loại), việc mở rộng và duy trì mã đó sẽ tốn ít công sức hơn.

Sẽ luôn có một số vấn đề đau đầu trong phát triển phần mềm vì:

• Sự phức tạp vốn có của những gì bạn đang cố gắng thực hiện

• Khả năng sai lầm vốn có của con người, đặc biệt là xem xét rằng chúng ta phạm nhiều sai lầm hơn khi chúng ta cố gắng làm điều gì đó phức tạp hơn

Sớm hay muộn, bạn cần dành chút thời gian để giải quyết những thách thức này. Không có nhận được xung quanh đó. Gõ tĩnh chỉ đơn giản là giải quyết những thách thức này sớm hơn là sau này. Sớm hơn là tốt hơn sau này, bởi vì bạn càng phát hiện ra một sai lầm (không phải là câu hỏi nếu , nhưng khi nào ), thì chi phí để sửa chữa sai lầm đó càng nhiều.

Chi phí ít hơn nhiều để sửa một lỗi được kiểm tra bởi trình kiểm tra loại so với chi phí để gỡ lỗi một ngoại lệ liên quan đến loại được nêu trong thời gian chạy. Trì hoãn việc kiểm tra kiểu cho thời gian chạy chỉ là quét vấn đề dưới tấm thảm.

Đây chỉ là ý kiến ​​của riêng tôi, nhưng không, tôi không nghĩ rằng loại an toàn là xứng đáng. Chưa một giây nào cả.

Tôi đã là một nhà phát triển trong một thời gian dài. Bắt đầu với c ++, c #, sau đó chuyển sang javascript (frontend và backend thông qua node.js). Vì tôi đã phát triển javascript, năng suất của tôi đã tăng vọt, đến mức tôi thực sự trở nên trầm trọng hơn khi sử dụng các ngôn ngữ dựa trên loại. Tôi cũng chống lại việc biên dịch, tôi muốn mọi thứ sẽ hoạt động ngay bây giờ. Các ngôn ngữ được giải thích thực sự là nơi tôi tìm thấy tình yêu của mình đối với lập trình.

Theo như các loại, tôi chỉ không thấy bất kỳ lợi ích. Tôi thấy các loại bây giờ giống như cách tôi thấy quản lý bộ nhớ. Hoàn toàn không cần thiết. Các ngôn ngữ của ngày mai sẽ hoàn toàn bảo vệ nhà phát triển biết bất cứ điều gì về các loại. Máy tính nên hiểu các loại và loại bỏ nhà phát triển ra khỏi nó.

Đây là một ví dụ. Tôi chỉ sử dụng Swift (ngôn ngữ mới của Apple) với hy vọng nó thực sự sống đúng với tên của nó một ngày trước và đã cố gắng thực hiện: var n = 1/2 không hoạt động. Tôi giống như, những gì đang xảy ra ở đây. và rồi buồn bã nhận ra tôi phải làm var n: Float = 1/2. Điều này nhắc nhở tôi rằng tôi ghét các hệ thống loại bao nhiêu và mức độ tăng nặng không cần thiết của chúng.

Tôi thậm chí còn đi thêm một dặm nữa để nói rằng tôi thậm chí không muốn các loại do người dùng xác định (chẳng hạn như Lớp học). Tôi không muốn loại nào cả. Tất cả tôi muốn là var và các đối tượng. Trong đó bất kỳ đối tượng có thể được sử dụng như bất kỳ đối tượng. Và các đối tượng là năng động và liên tục thay đổi. Trường hợp nó trở thành một vấn đề thời gian chạy như những gì hoạt động và những gì không.

Các nhà phát triển thích nói rằng các ngôn ngữ được gõ lỏng lẻo không tốt cho các dự án lớn. Nhưng tôi muốn nói điều đó ngược lại. Ngôn ngữ được gõ mạnh là khủng khiếp cho các dự án lớn. Và nếu bạn nói javascript không hoạt động cho các dự án lớn, hãy hỏi Uber một công ty trị giá 40 tỷ đồng chạy tất cả phụ trợ trên node.js / javascript hoặc Facebook bắt đầu bằng PHP.

Theo như các ngôn ngữ gõ tĩnh, nó không tốt cho các lần lặp nhanh ngày nay. Đây là một ví dụ đơn giản, bạn có 10 nhà phát triển làm việc trong dự án .net với máy chủ tích hợp liên tục, một nhà phát triển gửi lỗi và toàn bộ quá trình xây dựng bị hỏng, mặc dù 10 nhà phát triển đang làm việc trên những thứ khác nhau mà giờ họ đã dừng lại và chờ đợi cho các nhà phát triển vi phạm để sửa chữa sai lầm của mình. Nói về hiệu quả hả? Nhập hệ thống / ngôn ngữ tĩnh phụ thuộc lẫn nhau theo cách đó và làm cho mã của bạn phụ thuộc lẫn nhau. Tuy nhiên, tập tin script không bao giờ phụ thuộc lẫn nhau. Nếu có một vấn đề với một trong các tập lệnh thì nó không dừng sản xuất, tất cả các vấn đề bạn thấy đều được để lại cho bộ thực thi. Và thời gian chạy không bao giờ dừng lại. Nó không bao giờ phá vỡ. Nó có thể tạo ra đầu ra sai nhưng nó không '

ĐÚNG.

Tôi đã làm việc trong các ứng dụng PHP, trong đó các kiểu không "mạnh" như trong Java hoặc C #. Thông thường tôi đã hoàn thành "các loại mô phỏng", bởi vì, để tránh chuyển đổi tự động xấu hoặc xác thực dữ liệu.

Ngôn ngữ loại động rất tốt cho các tập lệnh hệ điều hành và các ứng dụng nhỏ nhanh., Không phải các ứng dụng phức tạp.

Tóm tắt: Nếu tôi phải chọn giữa ngôn ngữ lập trình "Loại yếu" hoặc "Loại động" hoặc Ngôn ngữ lập trình "Loại mạnh" cho một ứng dụng kinh doanh phức tạp, tôi chọn Ngôn ngữ lập trình "Loại mạnh" .

Tôi nghĩ rằng nó trả tiền để lùi lại một bước và xem xét khi nào việc gõ động gây ra vấn đề.

Một trường hợp là một nhánh mã hoàn toàn không được kiểm tra, nhưng thẳng thắn mã không bao giờ được kiểm tra có khả năng bị lỗi cho dù kiểu gõ động đang được sử dụng hay không.

Một vấn đề khác tinh tế hơn là sự thay thế không hoàn hảo.

Nếu một loại hoàn toàn sai thì trừ khi một đường dẫn mã cụ thể không bao giờ được sử dụng mà có khả năng được phát hiện nhanh chóng.

Mặt khác, nếu một loại là một thay thế không hoàn hảo thì mã có thể hoạt động chủ yếu nhưng phá vỡ theo những cách tinh tế sẽ không được phát hiện cho đến sau này.

Hai trong số các loại phổ biến nhất trong lập trình là số và chuỗi. Trong nhiều langau động, chúng là sự thay thế không hoàn hảo cho nhau. Nói như javascript hoặc php nếu bạn cung cấp một số trong đó một chuỗi được mong đợi hoặc ngược lại chương trình của bạn chạy mà không gây ra lỗi nhưng có thể hoạt động sai theo những cách khá tinh vi.

Python tránh vấn đề cụ thể đó, các số và chuỗi không có cách nào thay thế cho nhau và cố gắng sử dụng một cái mà người khác dự kiến ​​sẽ thường dẫn đến thất bại nhanh chóng.

Tuy nhiên, nó đã không tránh được hoàn toàn vấn đề nhạy cảm không hoàn hảo. Các loại số khác nhau có thể là sự thay thế không hoàn hảo cho nhau, do đó có thể các loại trình tự khác nhau.

Những gì tôi nhận được ở đây là tôi không nghĩ có thể so sánh lợi ích và chi phí của việc gõ tĩnh và động theo cách chung, bởi vì tôi nghĩ cả lợi ích và chi phí đều phụ thuộc vào sự biến đổi cụ thể của việc gõ ngôn ngữ tĩnh hoặc động sử dụng.