強打字弱打字的優點

Question

因此，我已經閱讀了堆棧溢出有關此問題的一堆類似問題，並且我認爲我很好地理解了兩者之間的區別。我的問題是，除了有些操作對程序員來說更簡單這種事實之外，是否還有弱打字相對於強打字的優勢。儘管我同意類型之間的某些操作被強類型語言不必要地複雜化，但似乎所有弱類型語言仍然可以用強類型語言來完成，並帶有一些額外的行李。個人而言，我可能更喜歡強類型的額外安全性，並處理某些操作的輕微煩惱，但除此之外還有弱類型的優點嗎？有沒有強大的打字永遠不會以同樣的方式？

Answer 1

某些語言提供了在運行時改變對象或類的行爲的概念：一個沒有實現方法的對象可能會決定找到一種方法來響應方法調用。

Objective-C委託是讓另一個對象響應客戶端消息的常用方法。對象可以檢測到缺少的實現並將方法調用傳遞給委託。當它被調用時，也可以動態添加方法的實現。

這些概念是基於動態方法查找，而不是弱與強打字。但弱打字與動態查詢緊密結合，所以我認爲這是一個優勢。

Answer 2

很明顯，行上沒有可計算性......強類型語言可以是圖靈等價的，假設弱類型語言不是教會圖靈論文的反例（我們可以想象這會被廣泛地公開，如果這是已知的情況），那麼它們至少與弱類型語言一樣強大（計算上講）。

然後我們可以詢問生產線是否有時間或空間複雜性。我的直覺是，答案是否定的;在RAM計算模型下，強類型和弱類型之間的差別可能不顯着（就計算複雜性而言）。我在這裏很容易出錯。然而，強類型語言可能會被編譯爲更嚴格的代碼，所以真正的性能無論如何都可能支持強類型語言。

在我看來，唯一明顯的好處是可編程性/可寫性/可讀性等。也就是說，它讓程序員的生活更輕鬆，讓他們用更少的代碼編寫更少的代碼，以獲得與使用更嚴格的鍵入規則的語言編寫更多代碼相同的效果。再一次，這也是爭論的焦點，因爲強類型可以更容易地提供正確性/健壯性保證。

Answer 3

對我來說，幾乎沒有優勢（只有一堆陷阱）。這很容易出錯，很難調試，做單元測試是啊......（我不知道該說什麼），並且這讓編程初學者認爲編程非常簡單，在項目開始時就沒有設計。

我需要編譯錯誤，我不喜歡調試動態對象爲什麼這是錯的，或........

Answer 4

弱類型是非常容易出錯，因爲你只能找到在運行時錯誤。

編譯錯誤是非常有利的，因爲他們立即顯示，而找到所有運行時錯誤，你需要運行每個用例的每個場景。除非你正在開發涵蓋100％的自動化測試（我還沒有看到像這樣的人），否則你將擁有比使用強類型語言更脆弱的軟件。

弱鍵入不那麼冗長，這意味着你輸入較少，但這也是一個神話，因爲使用強類型語言你會得到代碼完成，這意味着比弱類型語言更少的關鍵筆劃。