Các ngôn ngữ gõ tĩnh và động có thể được coi là các công cụ khác nhau cho các loại công việc khác nhau không?

Vâng, những câu hỏi tương tự đã được đặt ra nhưng luôn luôn với mục đích tìm ra 'cái nào tốt hơn'.

Tôi đang hỏi bởi vì tôi đã trở thành một nhà phát triển chủ yếu trong JavaScript và thực sự không có bất kỳ kinh nghiệm nào khi viết bằng các ngôn ngữ được nhập tĩnh.

Mặc dù vậy, tôi chắc chắn thấy giá trị khi học C để xử lý các hoạt động đòi hỏi ở mức mã thấp hơn (mà tôi cho rằng có liên quan nhiều đến tĩnh so với động ở cấp độ trình biên dịch), nhưng những gì tôi đang cố gắng che giấu là liệu có bối cảnh dự án cụ thể (có thể là một số loại hoạt động sử dụng nhiều dữ liệu động nhất định không?) liên quan đến những thứ khác ngoài hiệu năng trong đó có ý nghĩa hơn nhiều khi đi với Java hoặc C # so với một cái gì đó như Python.

Vâng chắc chắn.
Gõ động có những lợi thế nhất định trong trường hợp bạn muốn có thể coi mọi thứ là một kiểu duy nhất. Tuần tự hóa / giải tuần tự hóa là một trong những ví dụ kinh điển. Đây là lý do tại sao rất nhiều chương trình Web được thực hiện bằng các ngôn ngữ kịch bản được gõ động: chúng rất phù hợp với một nhiệm vụ bao gồm rất nhiều chuyển đổi tất cả các loại dữ liệu sang và từ chuỗi.

Mặt khác, đối với lập trình ứng dụng, các ngôn ngữ tĩnh hoạt động tốt hơn nhiều vì cố gắng coi mọi thứ là một loại không thường xuyên là một yêu cầu. Bạn thường muốn có cấu trúc dữ liệu hiệu quả với dữ liệu được biểu diễn như chính nó và không được chuyển đổi sang các loại khác rất thường xuyên. Điều này làm cho các tính năng của gõ động trở thành một nhược điểm thay vì lợi ích, đó là lý do tại sao các ứng dụng hầu như chỉ được viết bằng các ngôn ngữ gõ tĩnh.

Cách tôi nhìn nhận là, nếu bạn có thể làm việc một cách tự nhiên trong một ngôn ngữ được gõ tĩnh, thì gõ tĩnh là cách để đi. Nói chung, mục đích của một hệ thống loại là để ngăn bạn thực hiện các hoạt động với ngữ nghĩa không xác định - như thế nào (string) "hello" + (bool) true. Có thêm mức độ an toàn ngăn bạn thực hiện các hoạt động này có thể là một cách tốt để ngăn chặn các lỗi trong mã của bạn, ngay cả khi không có các bài kiểm tra đơn vị mở rộng. Đó là, an toàn kiểu cung cấp một mức độ tin cậy khác về tính chính xác ngữ nghĩa của mã của bạn.

Nhưng hệ thống loại rất khó để có được đúng. Tôi không tin rằng có là một hệ thống kiểu hoàn hảo trong tự nhiên tại thời điểm viết bài này. (Theo "hệ thống loại hoàn hảo", ý tôi là một hệ thống loại nghiêm ngặt, không yêu cầu chú thích mã dài dòng, không tạo ra lỗi loại dương tính giả và người lập trình có thể hiểu lỗi loại dễ dàng.) khó hiểu các hệ thống loại thực sự tốt tồn tại. Khi tôi đang học Haskell, tôi không thể nói cho bạn biết số lỗi loại tối nghĩa mà tôi gặp phải khi cố gắng viết những gì trông (với tôi) như mã chính xác. Thông thường mã không thực sự chính xác (đó là một điểm có lợi cho hệ thống loại), nhưng nó đã mất rất nhiềucông việc để hiểu các thông báo lỗi từ trình biên dịch, để tôi có thể sửa các vấn đề tiềm ẩn. Trong các ngôn ngữ OO, bạn cuối cùng có thể thấy mình suy nghĩ "lập luận này nên contravariant với các loại đầu vào, không hiệp biến!", Hoặc (nhiều khả năng) quay trở lại typecasts để thoát khỏi bờ cõi của các hệ thống kiểu. Loại hệ thống có thể nhận được nhiều khó khăn hơn bạn nghĩ.

Đối với những gì đáng giá, tôi hiểu rằng khó khăn trong việc đưa ra các hệ thống loại tốt là một phần trong những gì thúc đẩy Gilad Bracha đưa vào hỗ trợ hệ thống loại có thể cắm được trong Drameak.

Chúng là những công cụ khác nhau, nhưng nó không phải bởi hiệu suất. Đó là tất cả về sự phức tạp .

Các ngôn ngữ động thường hướng đến sự linh hoạt tối đa, và nó mang lại sự thiếu xác nhận và một loại đảm bảo. Sau đó, nó rất mạnh trong các chương trình quy mô nhỏ, nhưng hầu như không thể duy trì các chương trình quy mô lớn (độ phức tạp).

Ngôn ngữ tĩnh thường nhằm xác nhận tối đa. Mục tiêu đầu tiên của họ thường là bắt lỗi (hoặc lỗi) càng sớm càng tốt. Nhiều đảm bảo được thực hiện để xác nhận. Sau đó, việc học và bắt đầu khó hơn, nhưng khi các chương trình lớn hơn, nó cung cấp xác nhận chương trình tốt hơn với chi phí thấp hơn nhiều (nỗ lực mã hóa).

Do đó, các ngôn ngữ động thường phù hợp với các chương trình nhỏ (ý tôi là rất nhỏ) như các trang web động, DSL của trình duyệt web (không dành cho các ứng dụng trình duyệt!) Hoặc shell script. Ngôn ngữ tĩnh phù hợp hơn cho các chương trình hệ thống hoặc bất kỳ nội dung nào khác.

Trên mô tả là một cái gì đó về ngôn ngữ rất thuần túy động hoặc tĩnh. Hầu hết các ngôn ngữ thực tế nằm ở giữa chúng, và cho thấy các đặc điểm khác nhau.

Xem tại đây để biết thêm chi tiết: https://softwareengineering.stackexchange.com/a/105417/17428

Tôi hiện đang lập trình bằng các ngôn ngữ loại tĩnh (C # và F #), nhưng tôi thích lập trình bằng các ngôn ngữ động (Smalltalk, Ruby). Có rất nhiều ưu và nhược điểm mà mọi người liên kết với một loại so với loại khác liên quan đến ngôn ngữ hơn là khi bạn thực thi các loại. Ví dụ, các ngôn ngữ động thường có cú pháp gọn gàng hơn, ngắn gọn hơn, tuy nhiên F # và OCaml với hệ thống suy luận kiểu của chúng có cú pháp rõ ràng như bất kỳ ngôn ngữ động nào. Và với kiểu gõ tĩnh, bạn có cấu trúc lại tự động thực sự và tự động hoàn thành, nhưng Smalltalk, với toàn bộ mã nguồn trong cơ sở dữ liệu và mỗi phương thức được biên dịch riêng, là ngôn ngữ đầu tiên thực sự có cấu trúc lại tự động nghiêm trọng và nó hoạt động rất tốt. Cuối cùng, các ngôn ngữ động và tĩnh hiện đại ngày nay là loại an toàn, đó là khía cạnh quan trọng nhất trong hệ thống loại của bạn,

Bây giờ là năm 2015, có thêm một số đoạn thú vị cho cuộc trò chuyện:

1. Các phần quan trọng của thế giới phụ trợ doanh nghiệp đang xem xét hoặc bắt đầu sử dụng Python (động) thay cho Java (tĩnh nghiêm ngặt)
2. Thế giới lối vào doanh nghiệp đang chứng kiến ​​những thứ như AngularJS v2, dựa trên TypeScipt: một phần mở rộng được gõ của Javascript.

Vì vậy, những người phụ nữ đã mệt mỏi với chiếc áo khoác thẳng không cần thiết của việc gõ nghiêm ngặt, trong khi những người ở phía trước đã mệt mỏi với sự hỗn loạn của kiểu gõ năng động.

Khá mỉa mai: Tôi tự hỏi liệu họ sẽ gặp nhau ở giữa, hay lướt qua nhau với sự bùng nổ âm thanh của một thời hạn đi qua ...? ;)