Tại sao nhiều ngôn ngữ lập trình được sử dụng để phát triển một sản phẩm hoặc một phần mềm?

Tôi là một sinh viên tốt nghiệp gần đây đang nhắm đến việc bắt đầu bằng Thạc sĩ Khoa học Máy tính. Tôi đã bắt gặp nhiều dự án nguồn mở thực sự gây tò mò cho tôi và khuyến khích tôi đóng góp cho chúng (CloudStack, OpenStack, moby và Kubernetes để kể tên một vài). Một điều tôi đã thấy rằng phần lớn trong số họ có điểm chung là việc sử dụng nhiều ngôn ngữ lập trình (như Java + Python + Go hoặc Python + C ++ + Ruby). Tôi đã xem xét câu hỏi khác này, liên quan đến việc làm thế nào nhiều ngôn ngữ lập trình được thực hiện để giao tiếp với nhau: Làm thế nào để có hai chương trình khác nhau với hai ngôn ngữ khác nhau tương tác?

Tôi muốn hiểu yêu cầu nhắc nhở các doanh nghiệp sử dụng nhiều ngôn ngữ lập trình. Yêu cầu hoặc loại yêu cầu nào khiến kiến ​​trúc sư phần mềm hoặc trưởng dự án nói: "Tôi đang đề xuất chúng tôi sử dụng ngôn ngữ X cho nhiệm vụ 1 và ngôn ngữ Y cho nhiệm vụ 2"? Tôi dường như không thể hiểu lý do tại sao nhiều ngôn ngữ lập trình được sử dụng trong cùng một sản phẩm hoặc phần mềm.

Câu trả lời này có phạm vi bảo hiểm tuyệt vời và các liên kết về lý do tại sao các ngôn ngữ khác nhau có thể cung cấp lợi ích khác biệt cho một dự án. Tuy nhiên, có khá nhiều hơn một chút về sự phù hợp ngôn ngữ liên quan đến lý do tại sao các dự án kết thúc sử dụng nhiều ngôn ngữ.

Các dự án kết thúc bằng nhiều ngôn ngữ vì sáu lý do chính:

1. Lợi ích chi phí của việc tái sử dụng mã được viết bằng các ngôn ngữ khác;
2. Sự cần thiết phải bao gồm và chứa mã kế thừa;
3. Sự sẵn có của các lập trình viên cho các ngôn ngữ cụ thể;
4. Sự cần thiết phải có ngôn ngữ đặc biệt cho nhu cầu đặc biệt;
5. Xu hướng ngôn ngữ kế thừa; và
6. Quản lý dự án kém (sử dụng đa ngôn ngữ ngoài kế hoạch).

Lý do 1-4 là lý do tích cực theo nghĩa là giải quyết trực tiếp chúng có thể giúp dự án kết thúc nhanh hơn, hiệu quả hơn, với sản phẩm chất lượng cao hơn và hỗ trợ dài hạn dễ dàng hơn. Lý do 5 và 6 là tiêu cực, các triệu chứng chống lại sự thay đổi cần thiết, kế hoạch kém, quản lý không hiệu quả hoặc một số kết hợp của tất cả các yếu tố này. Những yếu tố tiêu cực này không may là nguyên nhân phổ biến của việc sử dụng đa ngôn ngữ "tình cờ".

Lý do 1 , lợi ích chi phí của việc tái sử dụng, đã trở thành một lý do ngày càng mạnh mẽ để cho phép sử dụng nhiều ngôn ngữ trong một dự án do cả vai trò lớn hơn của phần mềm nguồn mở và khả năng cải tiến để tìm các thành phần mã phù hợp trên web. Triết lý "hãy mã hóa tất cả nội bộ" trong những thập kỷ qua tiếp tục mờ nhạt khi đối mặt với thực tế kinh tế và về cơ bản không bao giờ là phương pháp hiệu quả nhất về chi phí cho bất kỳ dự án mới nào. Chính điều này làm cho các cơ hội thực thi nghiêm ngặt việc sử dụng một ngôn ngữ trong một dự án ít phổ biến hơn.

Đặc biệt trong trường hợp dự án sử dụng lại các thành phần nguồn mở được quản lý tốt, việc sử dụng nhiều ngôn ngữ có thể mang lại lợi ích tổng thể rất lớn vì các thành phần được sử dụng lại đều ẩn sau các giao diện được thiết kế tốt và được duy trì độc lập bởi các nhóm bên ngoài có chi phí bằng không. Trong các trường hợp tốt nhất, việc trộn các ngôn ngữ thông qua loại tái sử dụng này không gây tốn kém hơn cho dự án so với việc sử dụng các thành phần của hệ điều hành. Tôi biết không có ví dụ nào tốt hơn về giá trị của phương pháp này so với việc áp dụng phần mềm nguồn mở quy mô lớn của Microsoft trong trình duyệt của họ.

Lý do 2 , nhu cầu chứa mã kế thừa, bị bỏ qua trong tình trạng nguy hiểm của bất kỳ dự án lớn nào. Tuy nhiên, rất nhiều rắc rối mã di sản có thể gây ra, ngây thơ cho rằng nó có thể được thay thế dễ dàng bằng mã mới trong một ngôn ngữ mới có thể rất rủi ro. Mã kế thừa, thậm chí mã kế thừa xấu, thường bao gồm số tiền cho một "hợp đồng" ngầm của các tính năng được cộng đồng mong đợi sử dụng sản phẩm cũ. Cộng đồng đó khá thường xuyên là một nguồn thu chính cho một công ty, hoặc mục tiêu chính của hỗ trợ cho phần mềm chính phủ. Đơn giản chỉ cần loại bỏ hợp đồng ngụ ý có thể đuổi theo khách hàng nhận biết và có thể phá sản công ty chỉ sau một đêm nếu có sẵn các lựa chọn khác.

Đồng thời, không thay thế mã cũ bằng ngôn ngữ cũ có thể nguy hiểm như thay thế bán buôn. Một ví dụ tồi tệ nhất là Cơ quan Cựu chiến binh Hoa Kỳ, nơi có một số lượng lớn các hệ thống quan trọng được mã hóa bằng ngôn ngữ gọi là MUMPS (không đùa) được thiết kế bởi các bác sĩ y khoa, không phải các nhà khoa học máy tính. Không ai muốn học MUMPS, và những người biết điều đó thực sự đang chết dần. Do đó, các lập trình viên phải điều chỉnh MUMPS ngay cả khi họ cố gắng chuyển sang sử dụng các ngôn ngữ phổ biến hơn, mạnh hơn và được duy trì tốt hơn.

Loại sử dụng đa ngôn ngữ này đòi hỏi lập kế hoạch cẩn thận. Kế hoạch đó phải điều hướng cạnh dao giữa việc mất hàng thập kỷ kiến ​​thức của khách hàng và mặt khác mất khả năng hỗ trợ phần mềm. Các kỹ thuật cô lập mã cũ đằng sau các giao diện được xác định rõ và cho phép mã mới mạnh hơn để thay thế mã cũ sau khi các hành vi của nó đã được ghi lại tốt, có thể giúp ích. Nhưng kịch bản di sản này không bao giờ dễ dàng, và đã (và sẽ tiếp tục) là nguyên nhân dẫn đến sự sụp đổ của nhiều công ty và tổ chức trên một phạm vi rộng.

Lý do 3 , sự sẵn có của các lập trình viên cho các ngôn ngữ khác nhau, là một yếu tố thực dụng mà các dự án bỏ qua lúc nguy hiểm. Tuy nhiên, nhiều người tổ chức dự án có thể cảm thấy (chính xác hoặc không chính xác) rằng một ngôn ngữ cụ thể là tốt nhất cho mục tiêu của họ, nếu ngôn ngữ đó mâu thuẫn với nhóm chuyên gia ngôn ngữ có sẵn cho họ, cả lịch trình và chất lượng sản phẩm sẽ bị ảnh hưởng từ việc học cong các lập trình viên cố gắng học một ngôn ngữ mới.

Một cách tiếp cận hợp lý hơn là phân tích nhu cầu ngôn ngữ của dự án dựa trên các khu vực chức năng. Ví dụ, xem xét kỹ dự án có thể chỉ ra rằng chỉ có một "đỉnh" nhỏ của mã giá trị cao, ví dụ để thực hiện một số thuật toán độc quyền, đòi hỏi phải có chuyên môn về mã hóa trong một ngôn ngữ ít được sử dụng. Các phần khác của bất kỳ dự án lớn nào thường dễ dàng được cung cấp bởi các ngôn ngữ phổ biến hơn hoặc (thậm chí tốt hơn) bởi các sản phẩm nguồn mở được quản lý tốt. Do đó, phân tích một dự án theo nhu cầu ngôn ngữ có thể cung cấp một cách tiếp cận thực tế và hiệu quả hơn về việc thuê hoặc thuê chuyên môn đặc biệt trong các ngôn ngữ đặc biệt và cũng có thể giúp làm sắc nét các giao diện giữa các ngôn ngữ trong một dự án.

Lý do 4 , sử dụng các ngôn ngữ khác nhau cho các nhu cầu khác nhau, ngay lập tức và thuận lợi từ việc thực hiện loại phân tích nhu cầu dự án đó. Cũng nên sử dụng cẩn thận trong trường hợp này, vì việc chọn quá nhiều ngôn ngữ để hỗ trợ trong một dự án có thể gây ra sự bùng nổ phức tạp cả về hỗ trợ và giao diện giữa các thành phần. Cách an toàn nhất về chi phí là luôn luôn tìm cơ hội tối đa để tái sử dụng trước tiên, đặc biệt nếu có các gói tốt có thể đáp ứng nhu cầu của dự án thông qua ít hơn là tùy chỉnh. Tiếp theo, một số loại quyết định nên được đưa ra đối với một số lượng nhỏ ngôn ngữ có thể giải quyết phần lớn các nhu cầu đã xác định. Trong phát triển tái sử dụng chuyên sâu, đây thường sẽ là một loại mã keo.

Nói chung, không nên chọn nhiều ngôn ngữ có khả năng rất giống nhau chỉ vì một số thành viên của dự án thích một ngôn ngữ khác. Tuy nhiên, nếu có tập hợp năng lực được xác định rõ, được xác định rõ sẽ có lợi từ các kỹ năng ngôn ngữ đặc biệt, đó có thể là một lý do chính đáng để sử dụng nhiều ngôn ngữ để phát triển mã mới.

Lý do 5 , khả năng chống lại những thay đổi cần thiết trong các ngôn ngữ được sử dụng, có thể là nguyên nhân của sự gián đoạn nghiêm trọng của dự án và xung đột nội bộ. Là người dùng Daveochỉ ra trong một nhận xét về câu trả lời này, thay đổi có thể rất khó khăn đối với một số nhân viên dự án. Đồng thời, khả năng chống thay đổi không bao giờ là vấn đề đơn giản, đó chính là lý do tại sao nó có thể gây ra nhiều xung đột. Sử dụng các kỹ năng ngôn ngữ kế thừa có thể là một sự thúc đẩy mạnh mẽ cho năng suất của dự án nếu ngôn ngữ kế thừa đủ mạnh mẽ và có thể dẫn đến một sản phẩm có chất lượng tuyệt vời trong một nhóm hoạt động trơn tru và tôn trọng chất lượng. Tuy nhiên, các kỹ năng ngôn ngữ cũ phải được cân bằng với thực tế là nhiều ngôn ngữ cũ không còn có thể hoàn thiện với các ngôn ngữ gần đây hơn về các tính năng nâng cao, tính sẵn có của thành phần, tùy chọn nguồn mở và hỗ trợ bộ công cụ thông minh.

Cả lúc đó và bây giờ, đối số phổ biến nhất (và trớ trêu thay, thường đúng nhất) để tiếp tục sử dụng ngôn ngữ kế thừa yếu hơn, ít đọc hơn hoặc kém năng suất hơn là ngôn ngữ cũ cho phép sản xuất mã hiệu quả hơn. Đây là một lập luận cũ, một cuộc tranh cãi từ những năm 1950 khi những người sử dụng ngôn ngữ lắp ráp bực bội, thường cay đắng, sự xuất hiện của lập trình trong FORTRAN và LISP. Một ví dụ mà ngay cả bây giờ có thể thấy đối số hiệu quả mã có thể có hiệu lực trong mã chuyên sâu xử lý, chẳng hạn như nhân hệ điều hành, trong đó C vẫn là ngôn ngữ được lựa chọn so với C ++ (mặc dù vì lý do vượt quá hiệu quả đơn giản).

Tuy nhiên, trong môi trường dự án được hỗ trợ bởi máy toàn cầu và được hỗ trợ mạnh mẽ trong thiên niên kỷ mới, hiệu quả mã là đối số chính để chọn ngôn ngữ dự án đã phát triển thậm chí còn yếu hơn. Sự bùng nổ tương tự của phần cứng máy tính và mạng đã cho phép tiếp thị đại trà các ứng dụng trí tuệ nhân tạo cũng có nghĩa là chi phí lập trình của con người có thể dễ dàng giảm bớt những vấn đề thực thi mã không hiệu quả trên phần cứng và phần mềm đám mây giá rẻ. Khi điều đó được kết hợp với tính khả dụng cao hơn đối với các ngôn ngữ gần đây hơn của các thư viện thành phần, tùy chọn nguồn mở và bộ công cụ thông minh tiên tiến, số trường hợp chỉ giữ ngôn ngữ vì lý do hiệu quả trở nên rất hẹp. Ngay cả trong trường hợp nó được áp dụng,

Một lý do thuyết phục hơn cho một dự án ở lại với các ngôn ngữ cũ xảy ra khi vì bất kỳ lý do gì một dự án có ít hoặc không có tùy chọn để thay đổi nhân viên của mình. Điều này có thể xảy ra ví dụ khi một dòng sản phẩm chính được mã hóa hoàn toàn bằng ngôn ngữ mà chỉ có nhân viên hiện có là thông thạo. Trong những trường hợp như vậy, dự án phải tiếp tục con đường cố gắng lập trình bằng ngôn ngữ cũ hoặc cố gắng đào tạo nhân viên hiện có về cách sử dụng ngôn ngữ mới.

Đào tạo nhân viên ngôn ngữ kế thừa trong một ngôn ngữ mới có thể là một mối nguy hiểm của chính nó. Tôi vẫn nhớ một trường hợp một thành viên của một dự án vừa được đào tạo và chuyển đổi từ C sang C ++ đã phàn nàn với tôi bằng tất cả sự chân thành rằng anh ta chỉ không hiểu những lợi thế của phương pháp hướng đối tượng. Khi tôi xem mã của anh ta, anh ta đã chuyển đổi 103 hàm C trước đó của mình thành 103 phương thức cho một lớp đối tượng C ++ duy nhất ... và đúng là không thấy điều đó giúp được gì.

Thông điệp sâu xa hơn là khi mọi người đã lập trình theo một ngôn ngữ và phong cách ngôn ngữ duy nhất trong nhiều năm hoặc nhiều thập kỷ, khó khăn trong việc khiến họ "suy nghĩ" theo những cách mới có thể trở nên gần như không thể vượt qua, ngay cả với các chương trình đào tạo tốt. Trong một số trường hợp có thể không có lựa chọn nào khác ngoài việc đưa vào các nhà thiết kế và lập trình viên trẻ, những người đồng điệu hơn với các xu hướng và phương pháp hiện tại.

Lý do 6 , quản lý dự án kém, nói cho chính nó. Lựa chọn và sử dụng ngôn ngữ trong một dự án phải luôn luôn được xem xét và đánh giá một cách rõ ràng và không được phép xảy ra chỉ do tình cờ. Ít nhất, lựa chọn ngôn ngữ có thể tạo ra sự khác biệt lớn trong số phận dài hạn và chi phí hỗ trợ của một dự án, và do đó, luôn phải được tính đến và lên kế hoạch. Đừng trở thành một MUMPS!

Tôi dường như không thể hiểu lý do là tại sao nhiều ngôn ngữ lập trình được sử dụng trong cùng một sản phẩm hoặc phần mềm?

Nó khá đơn giản: không có ngôn ngữ lập trình duy nhất phù hợp với mọi nhu cầu và mục tiêu.

Đọc cuốn sách Ngôn ngữ lập trình của Michael L. Scott

Một số ngôn ngữ lập trình ủng hộ tính biểu cảm và tính khử (rất nhiều ngôn ngữ kịch bản, nhưng cũng có các ngôn ngữ lập trình cấp cao như Agda , Prolog , Lisp , Haskell, Ocaml, ...). Khi chi phí phát triển là quan trọng (thời gian và chi phí của nhà phát triển), việc sử dụng chúng là phù hợp (ngay cả khi hiệu suất thời gian chạy không tối ưu).

Các ngôn ngữ lập trình khác thiên về hiệu năng thời gian chạy (nhiều ngôn ngữ cấp thấp, với các triển khai thường được biên dịch, như C ++, Rust, Go, C, trình biên dịch, cũng là các ngôn ngữ chuyên ngành như OpenCL ...); thường đặc điểm kỹ thuật của họ cho phép một số hành vi không xác định . Khi hiệu suất của mã quan trọng, tốt hơn là sử dụng các ngôn ngữ này.

Một số thư viện bên ngoài được viết bằng và cho một ngôn ngữ cụ thể và ABI và gọi các quy ước . Bạn có thể cần sử dụng ngôn ngữ khác đó và tuân theo các quy ước giao diện chức năng nước ngoài , có thể bằng cách viết một số mã keo .

Trong thực tế, không có ngôn ngữ lập trình nào có tính biểu cảm cao (vì vậy sẽ cải thiện năng suất của nhà phát triển, giả sử một nhóm nhà phát triển đủ kỹ năng) và rất hiệu quả trong thời gian chạy. Trong thực tế, có một sự đánh đổi giữa biểu cảm và hiệu suất.

Lưu ý: tuy nhiên, đã có một số tiến bộ chậm trong các ngôn ngữ lập trình: Rust biểu cảm hơn C hoặc thậm chí là C ++ nhưng việc triển khai của nó gần như là hiệu suất và có thể sẽ cải thiện để tạo ra các tệp thực thi nhanh không kém. Vì vậy, bạn cần học các ngôn ngữ lập trình mới trong cuộc sống chuyên nghiệp của bạn; tuy nhiên không có viên đạn bạc

Lưu ý rằng chi phí phát triển ngày càng đáng kể ngày nay (đó không phải là trường hợp trong những năm 1970 - đó là những máy tính thời gian rất tốn kém - hoặc trong một số ứng dụng nhúng - với khối lượng sản phẩm lớn). Nguyên tắc cơ bản (rất gần đúng) là một nhà phát triển lành nghề có thể viết khoảng 25 nghìn dòng mã nguồn (gỡ lỗi & ghi lại) mỗi năm và điều đó không phụ thuộc nhiều vào ngôn ngữ lập trình được sử dụng.

Một cách tiếp cận phổ biến là nhúng một số ngôn ngữ kịch bản (hoặc một số ngôn ngữ cụ thể theo tên miền ) trong một ứng dụng lớn. Ý tưởng thiết kế này (liên quan đến ngôn ngữ dành riêng cho tên miền) đã được sử dụng trong nhiều thập kỷ (một ví dụ điển hình là trình soạn thảo mã nguồn Emacs , sử dụng Elisp để viết kịch bản từ những năm 1980). Sau đó, bạn sẽ sử dụng trình thông dịch có thể nhúng dễ dàng (như Guile , Lua , Python, ...) bên trong một ứng dụng lớn hơn. Quyết định nhúng một trình thông dịch bên trong một ứng dụng lớn phải được thực hiện từ rất sớm và có ý nghĩa kiến ​​trúc mạnh mẽ. Sau đó, bạn sẽ sử dụng hai ngôn ngữ: đối với các công cụ cấp thấp phải chạy nhanh, một số ngôn ngữ cấp thấp như C hoặc C ++; đối với các tập lệnh cấp cao, DSL hoặc ngôn ngữ kịch bản lệnh khác.

Cũng lưu ý rằng một phần mềm nhất định có thể chạy, trong hầu hết các hệ điều hành hiện tại (bao gồm Linux, Windows, Android, MacOSX, Hurd, ...), trong một số quy trình hợp tác sử dụng một số loại kỹ thuật giao tiếp giữa các quá trình . Nó thậm chí có thể chạy trên một số máy tính (hoặc nhiều trong số chúng), sử dụng các kỹ thuật điện toán phân tán (ví dụ: điện toán đám mây , HPC, máy chủ khách, ứng dụng web , v.v ...). Trong cả hai trường hợp, thật dễ dàng để sử dụng một số ngôn ngữ lập trình (ví dụ mã mỗi chương trình chạy trên một tiến trình hoặc máy tính bằng ngôn ngữ lập trình riêng của nó). Đọc hệ điều hành: Ba phần dễ dàng để biết thêm. Ngoài ra, giao diện chức năng nước ngoài(ví dụ: JNI ), ABI , gọi các quy ước , v.v ... tạo điều kiện trộn một số ngôn ngữ trong cùng một chương trình (hoặc có thể thực thi ) - và bạn sẽ tìm thấy các trình tạo mã như SWIG để trợ giúp.

Trong một số trường hợp, bạn phải trộn một số ngôn ngữ lập trình: các ứng dụng web cần Javascript hoặc Webassugging (ngôn ngữ duy nhất chạy bên trong hầu hết các trình duyệt web) cho phần chạy trong trình duyệt (có các khung tạo ra các ngôn ngữ này, ví dụ như ocsigen ). Mã hạt nhân cần một số nội dung (ví dụ: bộ lập lịch hoặc xử lý các mức ngắt thấp) để được viết một phần bằng trình biên dịch, bởi vì C hoặc C ++ không thể diễn tả những gì cần thiết ở đó, các truy vấn RDBMS nên sử dụng SQL, GPGPU cần có nhân máy tính được mã hóa trong OpenCL hoặc CUDA được quản lý bởi mã máy chủ C hoặc C ++, v.v .... Một số ngôn ngữ được thiết kế để tạo điều kiện cho một hỗn hợp như vậy (ví dụ: các asmcâu lệnh trong C,các đoạn mã trong GCC MELT cuối của tôi , v.v ...).

Trong một số trường hợp, bạn sử dụng các kỹ thuật siêu lập trình : một số phần trong dự án phần mềm lớn của bạn sẽ có mã (ví dụ: trong C hoặc C ++) được tạo bởi các công cụ khác (có thể là các công cụ cụ thể của dự án) từ một số chính thức ad-hoc: trình tạo trình phân tích cú pháp (được gọi không đúng là trình biên dịch- trình biên dịch) như bison hoặc ANTLR đến với tâm trí, nhưng cũng có SWIG hoặc RPCGEN. Và lưu ý rằng GCC có hơn một tá trình tạo mã C ++ chuyên dụng (một cho mỗi DSL bên trong GCC) bên trong nó. Xem thêm ví dụ này . Lưu ý rằng metabugs rất khó tìm. Đọc thêm về trình biên dịch bootstrapping , và về tính đồng nhất và phản xạ(rất đáng để học Lisp , chơi với SBCL và đọc SICP ; cũng tìm hiểu các thư viện biên dịch JIT như GCCJIT ; trong một số chương trình lớn, bạn có thể tạo một số mã khi chạy bằng cách sử dụng chúng; hãy biết về quy tắc thứ mười của Greensasta ). Cũng tìm hiểu về cuộc nói chuyện ít đi du lịch tại FOSDEM2018.

Đôi khi, bạn muốn cung cấp các chú thích chính thức cho mã của mình (ví dụ: để giúp các trình duyệt, máy phân tích tĩnh, trình biên dịch), sử dụng một số ngôn ngữ chú thích chuyên biệt (có thể được xem như một số DSL). Nhìn vào ACSL với Frama-C để chú thích các chương trình C (các chương trình quan trọng về an toàn) hoặc các pragma OpenMP cho HPC. Hãy cẩn thận: viết các chú thích như vậy có thể đòi hỏi rất nhiều kỹ năng và thời gian phát triển.

BTW, điều này cho thấy rằng một số kỹ năng về trình biên dịch và trình thông dịch là hữu ích cho mọi nhà phát triển (ngay cả khi không làm việc bên trong trình biên dịch). Vì vậy, hãy đọc Sách Rồng ngay cả khi bạn không làm việc trên trình biên dịch. Nếu bạn viết mã trình thông dịch của riêng bạn (hoặc nếu bạn thiết kế DSL của mình), hãy đọc Lisp In Small Pieces .

Xem thêm này & rằng & rằng & rằng câu trả lời của tôi liên quan đến câu hỏi của bạn.

Nghiên cứu mã nguồn của một số dự án phần mềm miễn phí lớn (trên github hoặc từ bản phân phối Linux của bạn ) để tìm cảm hứng và giác ngộ.

Ngoài ra, một số ngôn ngữ lập trình phát triển bằng cách thêm chú thích (dưới dạng pragma hoặc nhận xét ) vào các ngôn ngữ hiện có. Đối với ví dụ, suy nghĩ của ACSL (một lời nhận xét có phần mở rộng được chú giải chương trình C để cho phép chứng minh của họ bằng cách FRAMA-C ) hoặc của OpenCL (một phương ngữ C lập trình GPGPU vậy) hoặc OpenMP hoặc OpenACC #pragmas hoặc loại chú thích Common Lisp .

PS: cũng có những lý do xã hội hoặc tổ chức hoặc lịch sử để trộn lẫn các ngôn ngữ lập trình; Tôi bỏ qua chúng ở đây, nhưng tôi biết rằng trong thực tế những lý do như vậy là chủ yếu. Đọc thêm Tháng đàn ông huyền thoại

Nhiều dự án không được xây dựng với nhiều ngôn ngữ lập trình. Tuy nhiên, thông thường sử dụng các tập lệnh trong các ngôn ngữ khác để hỗ trợ phần mềm.

• Các công cụ quản trị là các chương trình riêng biệt đôi khi được viết bằng một ngôn ngữ khác.
• Các thư viện và API thường xuyên cung cấp các ràng buộc cho nhiều ngôn ngữ, để các nhà phát triển có thể sử dụng bất kỳ ngôn ngữ nào họ thích.
• Xây dựng các kịch bản và các kịch bản phát triển liên quan thường sử dụng các ngôn ngữ chuyên ngành.
• Các bài kiểm tra từ đầu đến cuối của một ứng dụng không cần sử dụng cùng một ngôn ngữ.

Một vài dự án sử dụng nhiều ngôn ngữ trong ứng dụng, ví dụ như một lõi trong ngôn ngữ cấp thấp hơn có thể tích hợp các plugin trong ngôn ngữ kịch bản. Trong một số hệ sinh thái (ví dụ JVM hoặc .NET), ngôn ngữ chính xác được sử dụng không quá quan trọng vì nhiều ngôn ngữ trên cùng một thời gian chạy ngôn ngữ có khả năng tương tác tốt. Ví dụ, tôi có thể viết một dự án bằng Scala sử dụng các thư viện Java hiện có và tích hợp chức năng viết kịch bản với Groovy.

Nếu một dự án bao gồm nhiều công cụ, chúng cũng có thể được phát triển bằng các ngôn ngữ khác nhau. Mặc dù tính nhất quán sẽ tốt, đặc biệt đối với các dự án nguồn mở, nỗ lực phát triển có sẵn có thể là một nút cổ chai. Nếu ai đó sẵn sàng phát triển một công cụ hữu ích nhưng không quen thuộc với ngôn ngữ chính, có thể công cụ đó có giá trị hơn tính nhất quán.

Điều này có hai hình thức và rất nhiều tổ chức nằm ở đâu đó giữa hai hình thức:

Hình thức tồi tệ - tổ chức là một mớ hỗn độn, và không ai chắc chắn rằng có một tầm nhìn công nghệ duy nhất cho nỗ lực này. Các nhà phát triển rất có thể sử dụng bất kỳ ngôn ngữ nào họ cảm thấy thoải mái nhất hoặc gần đây đã thử nghiệm một khuôn khổ hoặc ngôn ngữ mới và quyết định chỉ bắt đầu sử dụng ngôn ngữ đó do sự lạc quan ngây thơ.

Hình thức tốt - tổ chức có kiến ​​trúc thực sự tốt, sạch sẽ, rất phù hợp với lập trình polyglot; tách các ứng dụng thành các thành phần độc lập với bối cảnh giới hạn được xác định rõ và sự kết hợp này cho phép chúng chọn ngôn ngữ lập trình đơn giản nhất cho phép chúng viết thành phần cụ thể đó.

Thực tế - nó thường là cái trước nhiều hơn cái sau. Tôi đã thấy một vài công ty chọn một ngôn ngữ cho lĩnh vực kinh doanh của họ và một ngôn ngữ khác cho máy chủ web của họ và thường là thứ ba cho quản trị cơ sở dữ liệu của họ, điều này rất tốt về mặt kỹ thuật nhưng gần như họ không hiểu kỹ thuật (hoặc từ chối lắng nghe nhân viên của họ) có nghĩa là họ kết thúc với cả ba cùng làm mờ trong một mớ hỗn độn lớn và thường giới thiệu thêm nhiều ngôn ngữ phù hợp để giải quyết các phần cụ thể của mớ hỗn độn.

Tôi có thể đóng góp một ví dụ, về một dự án lập trình đã hoạt động được 32 năm và dường như vẫn còn nhiều sức sống trong đó. Đó là thương mại chứ không phải là nguồn mở.

Cốt lõi được viết bằng ngôn ngữ dành riêng cho tên miền, được tạo riêng cho dự án. Điều này đã tỏ ra cực kỳ hữu ích, đáng chú ý vì nó tích hợp rollback vào kiến ​​trúc cơ bản, nhưng nó biên dịch thành mã C, sau đó chúng tôi biên dịch với trình biên dịch của nền tảng. Nó đã hỗ trợ khoảng hai mươi nền tảng trong thời gian đó, không kể các biến thể 32- vs 64 bit, và hiện đang xuất xưởng trên sáu trong số đó.

Nó có một tiện ích bổ sung, được viết bằng C ++, được bắt đầu khi một người đứng đầu dự án trước đây tin rằng C ++ / MFC / Windows / x86 sẽ thay thế tất cả các kiến ​​trúc và nền tảng khác, vì vậy cần phải cung cấp công việc cho C ++ có thể thuê nhân viên. Mọi thứ đã không diễn ra như anh mong đợi.

Ngoài ngôn ngữ miền và C ++, các nhà phát triển làm việc trong LISP, được sử dụng để viết các trường hợp thử nghiệm, sử dụng trình thông dịch được nhúng trong khai thác thử nghiệm. Chúng tôi đã cân nhắc việc thay thế LISP bằng Java tại một thời điểm, nhưng hóa ra may mắn là chúng tôi đã không làm vậy.

Nó cũng có một trình bao bọc cho API chính của nó, được viết bằng C #. Điều này được thực hiện khi khách hàng yêu cầu, để họ có thể viết lại ứng dụng của mình trong C #. Nó được tạo bởi tập lệnh Perl, đọc các tệp tiêu đề C cho API, cộng với một tệp cấu hình quan trọng và viết mã C # cho trình bao bọc. Làm tất cả những gì xử lý văn bản trong Perl chỉ là dễ dàng hơn so với làm việc đó trong C ++.

Nó đã xây dựng các hệ thống của riêng mình và cần chúng, vì ngôn ngữ miền không phù hợp với các hệ thống xây dựng dựa trên chế tạo. Một nền tảng giống như UNIX được viết bằng shell script, Perl và một số chương trình nhỏ bằng ngôn ngữ miền. Một cho các nền tảng Windows được viết bằng ngôn ngữ hàng loạt, Perl và các chương trình nhỏ tương tự trong ngôn ngữ miền. Hệ thống xây dựng VMS cũ được viết bằng DCL, nhưng nó đã không được sử dụng trong hơn một thập kỷ.

Có một số lập trình YACC / Bison trong trình biên dịch cho ngôn ngữ miền. Có một số mã thử nghiệm cho các nền tảng của Apple được viết bằng Objective-C ++. Một số trang web nội bộ của nhóm (được sử dụng để quản lý dự án, không phải là một phần của phân phối) được viết bằng ASP và các trang web khác dưới dạng tập lệnh CGI trong Perl.

Về cơ bản, điều này bắt đầu như một dự án để giải quyết một vấn đề khó khăn, vì vậy nó đáng để tạo ra các công cụ chuyên dụng, có vẻ vẫn phù hợp với công việc này hơn bất kỳ thứ gì khác có sẵn. Nhóm nghiên cứu coi lập trình là một kỹ năng hơi độc lập với ngôn ngữ được sử dụng, vì vậy họ sẵn sàng sử dụng ngôn ngữ mới nếu việc này giúp công việc trở nên dễ dàng hơn. Tuy nhiên, thời trang không đạt được vị trí cao trong danh sách ưu tiên của họ, vì vậy họ sẽ không phân chia nhiệm vụ bằng cách giới thiệu một ngôn ngữ mới một cách vô cớ.

Chức năng của mã này là mô hình toán học, được sử dụng trên các máy trạm và máy chủ (tôi có thể nói chuyện thoải mái hơn một chút nếu tôi không xác định sản phẩm). Hiện tại nó có khoảng 25 triệu LoC, với tổng quy mô đội khoảng năm mươi.

Trong một số trường hợp, có một công cụ bạn cần sử dụng (chẳng hạn như bộ công cụ UI của HĐH) có thể truy cập dễ dàng nhất từ ​​một ngôn ngữ nhất định. Ví dụ: trên iOS và macOS, nếu bạn muốn viết các ứng dụng GUI bằng UIKit và AppKit, viết bằng Swift hoặc Objective-C là cách nhanh nhất, dễ nhất để làm điều đó. (Có thể có các ràng buộc cho các ngôn ngữ khác, nhưng chúng có thể đứng sau bản phát hành HĐH mới nhất mà bạn đang xây dựng, vì vậy có thể không cung cấp tất cả các tính năng.)

Vì vậy, điều thường xảy ra là khi một ứng dụng đa nền tảng, logic cốt lõi của ứng dụng được viết bằng một số ngôn ngữ có thể truy cập được cho cả hai và các phần cụ thể của UI / OS được viết bằng bất kỳ ngôn ngữ nào chúng hoạt động nguyên bản.

Vì vậy, nếu bạn đang viết một ứng dụng Windows và macOS, bạn có thể viết logic cốt lõi trong C ++ và sử dụng C # cho UI trên Windows và Swift cho UI trên macOS. Điều này giúp tiết kiệm thời gian vì bạn không cần phải viết logic lõi hai lần và xử lý các bộ lỗi khác nhau trong cả hai ứng dụng, v.v. Nhưng nó cũng cho phép một giao diện người dùng thực sự không phục vụ cho mẫu số chung thấp nhất giữa các nền tảng như sử dụng một thư viện UI đa nền tảng sẽ.

Ngoài thực tế là một số ngôn ngữ lập trình có thể phù hợp hơn cho một số nhiệm vụ cụ thể, đó là thực tế thực tế.

Trong thực tế thực tế, có 2 điểm đặc biệt quan trọng cần được xem xét:

1. Mọi người có kinh nghiệm và mức độ quan tâm khác nhau trong các ngôn ngữ lập trình khác nhau. - Cho phép mọi người làm việc trong các ngôn ngữ họ thích và thành thạo trong một số trường hợp có thể dẫn đến một kết quả cuối cùng tốt hơn so với việc buộc họ phải sử dụng một ngôn ngữ chung.
2. Các cơ sở mã lớn được xây dựng trong thời gian dài bởi những người khác nhau. - Không có cách nào để có được tài trợ hoặc số lượng tình nguyện viên cần thiết để viết lại toàn bộ dự án một khi ngôn ngữ phù hợp hơn với nó xuất hiện.

Và tất nhiên, thường có những phần cụ thể của một ứng dụng có nhu cầu hoàn toàn khác nhau, chẳng hạn như:

• Hiệu suất khu vực nhạy cảm được phát triển trong một ngôn ngữ biên dịch. Ngôn ngữ ví dụ: C ++
• Các lĩnh vực cần phải rẻ, dễ thay đổi và có khả năng tùy biến, được phát triển bằng ngôn ngữ kịch bản. Ngôn ngữ ví dụ: Lua.
• Giao diện GUI. Ngôn ngữ ví dụ: HTML
• Trình cài đặt. Ví dụ ngôn ngữ / công cụ: WiX.
• Xây dựng. Ngôn ngữ / công cụ ví dụ: Quá nhiều để liệt kê, thường là một vài trong số chúng cùng một lúc.

Và trên hết, có khá nhiều công cụ được sử dụng bởi một cơ sở mã tinh vi, nhiều công cụ cho phép tùy chỉnh và bổ trợ cần thiết với một ngôn ngữ khác.

Ngoài những điểm chính xác khác đã được đưa ra:
Từ kinh nghiệm, nhiều quyết định về ngôn ngữ hoặc môi trường được đưa ra bởi 'nếu bạn có một cái búa, mọi thứ trông giống như một cái đinh', nghĩa là mọi người có xu hướng sử dụng các công cụ mà họ quen thuộc.

Ngoài ra, giới thiệu một môi trường mới hoặc thậm chí ngôn ngữ là một khoản đầu tư lớn vào giấy phép, đào tạo, có thể là phần cứng và đi kèm với tổn thất lớn về thời gian sản xuất - mua sắm, cài đặt, định cấu hình, đào tạo mỗi tuần trong một công ty lớn hơn và về cơ bản bạn kết thúc với một loạt các nhà phát triển mới bắt đầu.
Về cơ bản, không bao giờ có thời gian để 'đầu tư' vào một môi trường hoặc ngôn ngữ hiện đại hơn hoặc phù hợp hơn, vì vậy họ gắn bó với những gì họ có cho đến khi nó không thể hoạt động được nữa.

Cụ thể với câu hỏi của bạn, nếu nhiều người / nhóm tham gia phát triển giải pháp, mỗi nhóm có xu hướng gắn bó với những gì họ biết rõ nhất, vì vậy giải pháp tổng thể có nhiều ngôn ngữ trong đó và đang phát triển trong nhiều môi trường.

Câu hỏi này (và một số câu trả lời) dường như cho rằng các ứng dụng là các khối mã nguyên khối - điều này không nhất thiết phải như vậy.

Trang web điển hình của bạn như Stack Exchange thực sự là một loạt các dịch vụ khác nhau, tất cả đều hoạt động độc lập với nhau, với một số loại tin nhắn giữa chúng. Các dịch vụ này có thể (và thường được) triển khai bằng các ngôn ngữ khác nhau, mỗi ngôn ngữ có thế mạnh riêng.

Tôi làm việc trên một mảnh nhỏ của một nền tảng ngân hàng trực tuyến, nhắm mục tiêu đến các ngân hàng cộng đồng và công đoàn tín dụng nhỏ hơn. Nền tảng này có nhiều thành phần - mặt trước Web, lớp cơ sở dữ liệu, lớp truyền thông của bên thứ ba, v.v ... Đây là tất cả các ứng dụng độc lập chạy trên các máy chủ khác nhau với các hệ điều hành khác nhau. Bạn có Javascript chạy ở phía máy khách trong trình duyệt, bạn có các trang xây dựng Perl ở phía máy chủ, bạn có nhiều dịch vụ được viết bằng C ++ hoạt động như một lớp trừu tượng giữa mã Perl và bộ xử lý lõi của ngân hàng, một bộ ứng dụng C ++ khác. định tuyến các thông điệp giữa các lớp khác nhau, phân tán các ứng dụng C ++ và tập lệnh Perl để theo dõi tình trạng của các quy trình khác nhau và báo cáo trạng thái của chúng cho một màn hình nội bộ, v.v., v.v., v.v.

Các ứng dụng nguyên khối vẫn tồn tại, nhưng thậm chí chúng có thể tận dụng các ngôn ngữ khác nhau vì những lý do khác nhau. Bạn có thể viết 90% ứng dụng bằng Java, nhưng sử dụng JNI để tận dụng C hoặc C ++ cho các phần quan trọng hơn về hiệu năng.

Tôi muốn chỉ ra một ví dụ rất cụ thể về mô típ 'ngôn ngữ khác nhau có thế mạnh khác nhau': FORTRAN.

Fortran ban đầu được phát triển để giúp các kỹ sư thực hiện công việc phân tích số dễ dàng hơn và từ đó đã có rất nhiều nỗ lực để tạo ra các trình biên dịch Fortran phát ra mã số rất hiệu quả. Mặt khác, vì những ngày đầu, việc sử dụng máy tính đã bùng nổ theo một ngàn hướng, không có phương pháp nào liên quan đến phân tích số và sự phát triển của các ngôn ngữ lập trình phần lớn tuân theo việc bỏ qua thế giới 'thực' [tha thứ cho trò chơi chữ].

SO: Hôm nay, và bạn thấy mình đang làm việc cho một công ty với một sản phẩm khá phong phú, hầu hết được viết bằng (nói) Java (tôi nói từ kinh nghiệm cá nhân ở đây) . Nhưng bạn thấy rằng một trong những tính năng cốt lõi của sản phẩm sẽ giới thiệu một số hình thức phân tích số và tất cả các mã tốt nhất cho phân tích cụ thể đó đã có sẵn trên mạng - ở Fortran. Vậy bạn làm gì? Bạn tải xuống một trong những mã Fortran đó, tìm ra giao diện của nó [tức là các đối số của chương trình con trên cùng], lấy ra một trình bao bọc JNI cho nó trong C và đóng gói nó như một lớp Java. BAM! Bạn chỉ cần phát triển ba ngôn ngữ cùng một lúc. [đặc biệt nếu bạn thấy rằng mã Fortran của bạn sử dụng các khối CommON - tức là lưu trữ tĩnh - và phải được sửa đổi để đảm bảo an toàn cho luồng]

Bởi vì lập trình không phải là một nhiệm vụ. Ngay cả việc tạo ra một sản phẩm không phải là một nhiệm vụ. Có nhiều loại nhiệm vụ được thể hiện tốt nhất với các ngôn ngữ khác nhau.

Để làm cho nó cụ thể hơn, hãy giả sử một cái gì đó đơn giản như một ứng dụng độc lập (có nhiều nhiệm vụ được thực hiện cho các ứng dụng phân tán).

Một sản phẩm cần phải được

• bằng văn bản
• kết hợp lại với nhau (điều này liên quan đến cả việc biên dịch và thu thập các tài nguyên như hình ảnh, phông chữ, v.v. để triển khai)
• triển khai
• cấu hình
• theo dõi

Một ngôn ngữ có thể tốt cho việc viết thời gian chạy của sản phẩm rất khó có thể tốt như việc kết hợp một sản phẩm với nhau. Và như vậy.

Tuy nhiên, ngay cả quá trình viết một sản phẩm có thể không được thực hiện tối ưu trong 1 ngôn ngữ.

Giả sử có rất nhiều dữ liệu có cấu trúc được xử lý trong sản phẩm. Là cấu trúc của dữ liệu được biết tại thời điểm viết? Nếu có, bạn sẽ muốn định cấu hình một số cơ sở dữ liệu tại thời điểm triển khai. Điều này được thực hiện tối ưu trong một ngôn ngữ có thể tạo ra ngôn ngữ sẽ biên dịch vào thời gian chạy của bạn.

Bây giờ nếu cấu trúc của dữ liệu có thể thay đổi theo thời gian thì sao? Hơn bạn cần một cách có cấu trúc để biến các cấu trúc dữ liệu mới thành mã và cấu hình cơ sở dữ liệu. Điều này được thực hiện tốt nhất trong ngôn ngữ khác.

Bạn có thể làm tất cả trong cùng một ngôn ngữ? Chắc chắn rồi. Nhưng hiệu quả của bạn được xác định bởi mức độ nhanh chóng bạn có thể hoàn thành một dự án và khả năng phục hồi để thay đổi nó nhanh như thế nào. Nếu nhiều công việc của bạn có thể được tự động hóa với các công cụ đã có sẵn, thì những gì bạn mất 3 tháng để làm có thể được thực hiện bởi người khác trong 2 ngày. Nhưng ai đó sẽ sử dụng các ngôn ngữ khác để tự động hóa những gì bạn sẽ làm thông qua việc lặp lại.

Phát triển phần mềm đã phát triển đến mức bạn có thể sử dụng các ngôn ngữ lập trình khác nhau trong cùng một dự án và bạn có thể làm cho nó hoạt động.

Sau đó, có câu hỏi tại sao bạn sẽ sử dụng nhiều hơn một ngôn ngữ.

Một lý do là các ngôn ngữ trở nên lỗi thời và dần được thay thế bằng những ngôn ngữ mới hơn và nếu bạn may mắn có thể thực hiện từng chút một. Vì vậy, dự án của bạn sẽ có sự pha trộn của ngôn ngữ cũ và mới.

Một lý do khác là tình huống ngôn ngữ X rất nhiều những gì được sử dụng trên nền tảng A, ngôn ngữ Y rất nhiều những gì được sử dụng trên nền tảng B, nhưng ngôn ngữ Z được hỗ trợ trên cả hai nền tảng. Vì vậy, mã phổ biến được viết bằng ngôn ngữ Z, sau đó được kết hợp với X hoặc Y, tùy thuộc vào nền tảng.

Và mọi người thích sử dụng mã được viết bởi người khác (nói cách khác, mã mà họ không phải dành thời gian để tự viết mã). Họ cảm thấy thoải mái khi sử dụng mã được viết bởi người khác bằng bất kỳ ngôn ngữ nào và sau đó thêm mã bằng ngôn ngữ họ thích.