Tại sao các ứng dụng Linux thường đặt ngôn ngữ mà nó được viết trong bản tóm tắt?

Khi giới thiệu các ứng dụng, Windows và Mac chủ yếu nói về các tính năng. Mặt khác, các ứng dụng Linux có nhiều chi tiết hơn về ngôn ngữ nào được sử dụng để viết nó (và các thư viện đi kèm) thay vì các tính năng. Tại sao vậy?

Tôi có thể hiểu được sự khác biệt giữa GTK + so với QT tạo ra sự khác biệt chỉ vì các yêu cầu tích hợp trên máy tính để bàn, nhưng C vs C ++ so với Python vs hội vs vv? Có thật không?

Ví dụ: foo là một blah blah đơn giản được viết bằng C / GTK +.

Tôi nghĩ rằng người dùng Linux truyền thống (một người tin học táo bạo thực sự tự cài đặt hệ thống) không quan tâm đến thông tin đó (công nghệ nào đứng sau công cụ này?). Tôi cũng là một trong những kẻ lập dị, những người sẽ không cài đặt và sử dụng một gói chỉ vì nó sử dụng một số công nghệ mà tôi không thích. Một số người gọi đây là loại tôn giáo hành vi tất nhiên. Ngớ ngẩn phải không?

Dù sao tôi có thể nghĩ ra hai lý do:

• Các trình đóng gói cũng táo tợn (nếu không nhiều hơn) so với những người dùng Linux đó, vì vậy họ thấy nên thêm thông tin như vậy.

• Tôi nghĩ rằng khi những người đóng gói này đưa thông tin như vậy vào các mô tả gói của họ, họ có khả năng thực hiện nó như một hình thức khuyến mãi. Nó hoạt động nhiều lần (nó làm việc với tôi khá nhiều lần).

Tất nhiên đây chỉ là phỏng đoán.

Ý nghĩa của tôi là nó liên quan đến thứ hai trong bốn quyền tự do phần mềm :

Tự do nghiên cứu cách chương trình hoạt động, và thay đổi nó để làm cho nó làm những gì bạn muốn (tự do 1). Truy cập vào mã nguồn là điều kiện tiên quyết cho việc này.

Công khai ngôn ngữ (hoặc các tính năng kỹ thuật khác) hỗ trợ khả năng lựa chọn của mọi người và khuyến khích sự tham gia vào các dự án của những người thành thạo các ngôn ngữ đó.

Đây có thể là một phần lịch sử. Ngay cả trong quá khứ không xa, thông thường các quản trị viên hệ thống riêng lẻ sẽ xây dựng và cài đặt mọi thứ chạy trên hệ thống của họ.

Lưu ý về ngôn ngữ và thư viện đã được sử dụng để triển khai một công cụ đưa ra gợi ý cho quản trị viên về quy trình mà công việc sẽ diễn ra cho họ hệ thống .

Trong thời đại phổ biến và vươn xa các công cụ quản lý gói này, đây là một chút lỗi thời, nhưng văn hóa unix bảo thủ theo nghĩa là không vứt bỏ những thứ dường như đang hoạt động, vì vậy sẽ mất một thời gian trước khi thói quen này chết.

Trong phần mở rộng cho câu trả lời của jasonwryans :

Nếu bạn đặt tên cho ngôn ngữ mà nó được viết, người nhận nó có thể ước tính mức độ khó của việc cung cấp một bản vá, hoặc để có được một số hiểu biết, hoặc để mở rộng chương trình.

Tất nhiên điều này chỉ có ý nghĩa nếu bạn là một lập trình viên.

Bạn đã thấy các bản tóm tắt ở đâu? Trong một kho lưu trữ, hoặc một gói như .deb hoặc .rpm?

Nếu bạn xây dựng nó từ nguồn, thông tin có thể hữu ích để xác định, cho dù bạn phải cài đặt các công cụ khác (trình biên dịch, thư viện, công cụ xây dựng).

Unix, và giờ là LInux và BSD, luôn có một cơ sở phần mềm thực sự bị bẻ gãy và một cơ sở phần cứng đa dạng hơn rất nhiều đã tồn tại trong quá khứ gần đây. Điều quan trọng là phải biết rằng một số phần mềm chạy trong các phần mềm giao tiếp bạn có trên hệ thống của bạn hoặc bạn có thể biên dịch mã nguồn. Nếu bạn không có trình thông dịch Lisp thông thường hoặc trình thông dịch Tcl hoặc trình thông dịch bất kỳ, bạn không muốn tải xuống nguồn, chỉ để biết rằng bạn không thể chạy nó.

Có một mô tả về ngôn ngữ gì đó đã được ngăn chặn rất nhiều thời gian lãng phí.

Khi được nhắc nhở, đây là thứ gì? Một nhà phát triển sẽ có xu hướng mô tả bản chất của nó, mà đối với họ được gắn với mã nguồn, thay vì chức năng của nó. Ai đó sẽ hy vọng viết lại mô tả để lấy người dùng làm trung tâm hơn trước khi kết thúc gói, nhưng đề cập đến ngôn ngữ vẫn có thể có liên quan, ví dụ như khả năng mở rộng và khả năng viết kịch bản, hoặc hữu ích cho cơ hội thu hút người đóng góp.

Từ quan điểm của tôi, thông tin như vậy rất cần thiết để thu hút những người đóng góp mới, cũng như cung cấp cho người dùng tiềm năng một ý tưởng ngay lập tức về việc họ có thể đòi hỏi bao nhiêu công việc để tích hợp ứng dụng vào hệ thống của họ.

• Một khía cạnh chung là các thư viện được sử dụng khi chạy ứng dụng.

Một số cài đặt được giới hạn trong một số bộ công cụ được chọn, như GTK + nhưng không phải là QT hoặc ngược lại. Đối với một quản trị viên duy trì một hệ thống và thường xuyên cập nhật các thành phần của nó trong một thời gian dài, đây có thể chỉ là một câu hỏi thực tế và không phải là một câu hỏi tôn giáo.

• Một khía cạnh khác là các thư viện được sử dụng và các điều kiện tiên quyết cần thiết để biên dịch ứng dụng.

Tức là đối với người dùng phân phối Linux dựa trên nguồn, nó tạo ra sự khác biệt lớn cho dù ứng dụng được viết bằng C hay Objective-C, vì trình biên dịch của họ cần hỗ trợ ngôn ngữ ngay từ đầu. Các ngôn ngữ khác có thể khiến bạn cần phải cài đặt một đống thư viện khổng lồ. Câu hỏi sau đó là, một lần nữa, bạn sẵn sàng chấp nhận bao nhiêu công việc để biên dịch ứng dụng này.

• Một khía cạnh khác là ý định thu hút những người đóng góp.

Hầu hết các nhà phát triển có sở thích cho một số ít ngôn ngữ hoặc có thể đơn giản là thiếu kinh nghiệm trong các ngôn ngữ khác. Để cho phép số lượng người đóng góp nhiều hơn cho một ứng dụng, một số dự án thậm chí còn chia nguồn của họ thành hai ngôn ngữ khác nhau (như Wesnoth, Vega Strike, Naev, chỉ để nêu tên một số). Một trong số chúng cho ứng dụng lõi (như C hoặc C ++), một cái khác để dễ dàng sửa đổi (như Python hoặc Lua). Đây là một liên kết đến một chương của "Kiến trúc của các ứng dụng nguồn mở" mô tả cách thức và lý do tại sao điều này được thực hiện trong Wesnoth.

• Cuối cùng, rõ ràng có rất nhiều thành kiến ​​và thành kiến ​​đối với một số ngôn ngữ.

Tôi sẽ chỉ nói rằng tôi đã thấy phần mềm kém hiệu quả khủng khiếp được viết bằng bất kỳ ngôn ngữ nào. Nếu bạn hỏi tôi, về hiệu quả, chất lượng mã của ứng dụng quan trọng hơn nhiều so với ngôn ngữ mà nó được viết.

Tôi nghĩ rằng rất nhiều trong số đó phải làm với quảng cáo hiệu suất. Một ứng dụng được viết bằng ngôn ngữ được biên dịch (C, C ++, ...) sẽ thực hiện một công việc tốt hơn rất nhiều so với một ứng dụng được viết bằng ngôn ngữ script (perl, python, ...).

Nhưng nó cũng liên quan đến khả năng tương thích. Một ứng dụng được viết bằng ngôn ngữ kịch bản cũng có khả năng dễ mang theo hơn trên các kiến ​​trúc & hệ điều hành mà không cần sửa đổi gì.

Trên các hệ thống máy tính để bàn / máy chủ ngày nay có thể không liên quan lắm, nhưng đối với các hệ thống nhỏ hơn, từ hệ thống nhúng đến netbook và máy tính bảng SSD, ngôn ngữ hoặc thư viện được sử dụng bởi một chương trình có thể là vấn đề khó khăn, cả do kích thước và cân nhắc tính di động.

Về kích thước: Thêm trình thông dịch cho một ngôn ngữ bổ sung, cùng với tất cả các mô-đun tiêu chuẩn và mô-đun bổ trợ thường được sử dụng, có thể dễ dàng thêm hàng trăm megabyte vào yêu cầu lưu trữ. Điều tương tự cũng xảy ra với các gia đình thư viện, đặc biệt là các gia đình liên kết với các môi trường máy tính để bàn lớn như Gnome và KDE. Tệ hơn nữa, từ việc chạy nđến n+1các chương trình Perl có thể không bổ sung quá nhiều vào yêu cầu sử dụng bộ nhớ, vì có thể chia sẻ rất nhiều bộ nhớ, nhưng đi từn các chương trình Perl và 0 chương trình Python sangnCác chương trình Perl và 1 chương trình Python dẫn đến việc sử dụng bộ nhớ tăng đột biến. Điều này càng trở thành vấn đề khi mọi phần mềm viết lách miễn phí đều có ngôn ngữ script / radtool yêu thích của riêng họ mà họ muốn lập trình trong ... Perl, Python, PHP, Ruby, JavaScript, Bourne shell, Bash, Csh, ....

Về tính di động: Rất nhiều ngôn ngữ được dịch (cũng như khung thư viện) sử dụng nhiều tính năng có thể có trên các hệ thống máy tính để bàn / máy chủ Linux lớn nhưng không nhất thiết có sẵn trên các hệ thống nhỏ hơn / nhúng / MMU. Sự phụ thuộc vào .sotải mô-đun động khi chạy đến với tâm trí ...