Trong những trường hợp nào là ngôn ngữ động không phù hợp?

Question

Yếu tố nào cho thấy giải pháp của dự án không nên được mã hóa bằng ngôn ngữ động?

Answer 1

Tốc độ thường là câu trả lời chính. Mặc dù điều này đang trở thành ít hơn của một vấn đề những ngày này.

Answer 2

khi tốc độ rất quan trọng. Ngôn ngữ động đang nhận được nhanh hơn, nhưng vẫn không gần với hiệu suất của một ngôn ngữ biên dịch là gì.

Answer 3

Sự quen thuộc và sẵn sàng của các lập trình viên làm việc với ngôn ngữ.

Ngôn ngữ động của bạn có lẽ là ngôn ngữ tĩnh của tôi.

Answer 4

Phát triển cấp hệ thống là nhóm phần mềm chính thường không được sử dụng bằng ngôn ngữ động. (trình điều khiển, mức hạt nhân, vv).

Về cơ bản, mọi thứ cần phải có mỗi ounce hiệu năng hoặc truy cập phần cứng cấp thấp, phải ở ngôn ngữ cấp thấp hơn.

Một chỉ báo khác là nếu nó là số crunching cao, như crunching số dữ liệu khoa học. Đó là, nếu nó cần phải chạy nhanh và làm số crunching.

Tôi nghĩ rằng một chủ đề phổ biến là vấn đề xử lý chuyên sâu ... trong trường hợp này bạn sẽ dễ dàng thấy sự khác biệt về hiệu suất và bạn sẽ thấy rằng ngôn ngữ động không thể cung cấp cho bạn khả năng sử dụng phần cứng một cách hiệu quả.

Điều đó nói rằng, nếu bạn đang thực hiện công việc xử lý chuyên sâu và bạn không để ý đến hiệu suất hoạt động, thì bạn vẫn có thể sử dụng ngôn ngữ động.

---

Cập nhật:

Lưu ý rằng đối số crunching, tôi có nghĩa là thực sự dài chạy số crunching trong lĩnh vực khoa học mà tiến trình đang chạy trong nhiều giờ hoặc vài ngày ... trong trường hợp này tăng 2x hiệu suất là ginormous ... nếu nó ở quy mô nhỏ hơn nhiều, thì ngôn ngữ động vẫn có thể được sử dụng.

Answer 5

Làm thế nào về interop? Có thể gọi một thành phần COM từ Ruby hoặc Python không?

Answer 6

Interop hoàn toàn có thể với ngôn ngữ động. (nhớ cơ bản hình ảnh cổ điển, có "ràng buộc lười biếng"?) Nó đòi hỏi các thành phần COM được biên dịch với một số tính năng bổ sung mặc dù để giúp người gọi của họ để gọi theo tên.

Tôi không nghĩ rằng việc thu thập số đó phải được biên dịch tĩnh, thông thường nó là vấn đề bạn giải quyết như thế nào. Matlab là một ví dụ tốt được thực hiện cho crunching số, và nó có một ngôn ngữ không biên dịch. Matlab, tuy nhiên, có một thời gian chạy rất cụ thể cho các con số và ma trận.

Answer 7

Tôi tin rằng bạn luôn nên chọn ngôn ngữ được nhập tĩnh nếu có thể. Tôi không nói C# hay Java có hệ thống tĩnh tốt nhưng C# đang tiến gần hơn. Tốt type inference là chìa khóa bởi vì nó sẽ cung cấp cho bạn lợi ích nhìn thấy trong các ngôn ngữ động trong khi vẫn cung cấp cho bạn bảo mật và các tính năng của những người gõ tĩnh. Đã giải quyết được sự cố - không có thêm nhiều lần bùng phát.

Answer 8

Mã cấp hệ thống cho các hệ thống nhúng. Một vấn đề có thể xảy ra là các ngôn ngữ động đôi khi ẩn ý nghĩa hiệu suất của một câu lệnh đơn giản.

Giống như nói tuyên bố này Perl:

@contents = <FILE>; 

Nếu FILE là một vài MB, thì đó là một tuyên bố nguồn lực tốn - bạn có thể làm cạn kiệt đống của bạn, hoặc gây ra một thời gian chờ cơ quan giám sát, hay nói chung là chậm phản ứng của hệ thống nhúng.

Nếu bạn muốn "lập trình gần hơn với kim loại", có thể bạn muốn sử dụng ngôn ngữ được nhập tĩnh và "cấp trung bình".

Answer 9

Trình điều khiển thiết bị thẻ video

Answer 10

Ở mức độ lớn, ngôn ngữ lập trình là lựa chọn kiểu. Sử dụng ngôn ngữ bạn muốn sử dụng và bạn sẽ đạt hiệu quả tối đa và hạnh phúc. Nếu vì một lý do nào đó không thể, thì hy vọng quyết định cuối cùng của bạn sẽ dựa trên một cái gì đó có ý nghĩa, giống như một nền tảng bạn phải đối đầu với những con số thực, thực nghiệm chứ không phải lựa chọn phong cách tùy ý của người khác.