Tại sao các công cụ xây dựng sử dụng ngôn ngữ kịch bản khác với ngôn ngữ lập trình cơ bản?

23

Gần đây tôi đã sử dụng một số công cụ xây dựng cho dự án Nodejs khi tôi nhận ra rằng công cụ / hệ thống xây dựng chính của hầu hết các ngôn ngữ sử dụng ngôn ngữ khác với ngôn ngữ lập trình cơ bản.

Ví dụ, make không sử dụng C hoặc C ++ để viết các tập lệnh và ant (cũng không phải Maven) không sử dụng Java làm ngôn ngữ của chúng để viết kịch bản.

Các ngôn ngữ mới hơn như Ruby sử dụng cùng một ngôn ngữ cho các công cụ xây dựng như cào , điều này có ý nghĩa với tôi. Nhưng tại sao điều này không phải luôn luôn như vậy? Lợi thế của việc có một công cụ xây dựng sử dụng ngôn ngữ khác với ngôn ngữ cơ bản là gì?

programming-languages history build-system

— joshin4colours
nguồn

14

Có lẽ ngôn ngữ mục đích chung không đủ phù hợp để sử dụng công cụ chuyên môn? Ví dụ, tôi sẽ không muốn viết các tệp trong C! Đôi khi một DSL là tốt hơn.

— Andres F.

13

Nhìn nó từ một góc độ khác: Tại sao không sử dụng make để viết phần mềm ứng dụng?

— whatsisname

4

Bài viết này chủ yếu về những gì tác giả tin rằng làm cho Lisp trở nên tuyệt vời, nhưng có một số thông tin liên quan về lý do tại sao Ant sử dụng XML thay vì Java.

— 8bittree

6

Nếu bạn muốn viết một chương trình bằng C tự động hóa việc xây dựng các chương trình C, bạn sẽ không kết thúc việc viết makelại (dù sao nó cũng được thực hiện trong C)?

— Brandin

6

@ joshin4colours make được viết bằng C. Tuy nhiên, ngôn ngữ sử dụng là ngôn ngữ khai báo gọi shell khi cần.

36

Việc lựa chọn sử dụng ngôn ngữ lập trình nào để hoàn thành mọi thứ phải phụ thuộc vào các tính năng cụ thể của mục tiêu đó chứ không phụ thuộc vào các nhiệm vụ khác liên quan đến dự án đó.

Công cụ xây dựng thực hiện một công việc rất cụ thể và bất kể bạn đang sử dụng ngôn ngữ nào cho dự án chính, công cụ xây dựng tự nó là một phần mềm.

Cố gắng buộc dự án chính và công cụ xây dựng của nó có thể là một quyết định rất tồi tệ. Những gì bạn cần với một công cụ xây dựng chủ yếu là một quy trình nhanh chóng của các quy tắc đơn giản, với sự quản lý nhanh chóng các tệp và IO.

Nếu các ngôn ngữ như ruby sử dụng chính chúng để triển khai công cụ xây dựng của chúng, thì có liên quan nhiều hơn đến các tính năng của ngôn ngữ đó so với nhu cầu giả định để giữ mọi thứ được viết bằng cùng một ngôn ngữ.

— Nicolá
nguồn

18

Không thể viết một công cụ xây dựng sử dụng ngôn ngữ như C hoặc Java làm ngôn ngữ kịch bản lệnh của họ. Tuy nhiên, các công cụ xây dựng được hưởng lợi từ việc sử dụng nhiều ngôn ngữ kịch bản khai báo hơn . Hãy tưởng tượng nỗi đau và sự luồn lách khi viết một tệp Makefile (hoặc build.xml hoặc bất cứ thứ gì) trong C.

Xây dựng các công cụ được hưởng lợi từ việc sử dụng DSL, một nhiệm vụ mà C không phải là một lựa chọn đặc biệt tốt. C quá chung chung cho một công cụ xây dựng và quá quan tâm đến các chi tiết dễ bị lỗi và mức độ thấp. Ví dụ: bạn không muốn quan tâm đến việc quản lý bộ nhớ rõ ràng trong công cụ xây dựng! Vì vậy, ngay cả khi sử dụng cú pháp giống như C, có lẽ bạn đang sử dụng bộ sưu tập rác trong công cụ tạo tập lệnh của mình, tại thời điểm đó tại sao không sử dụng DSL chuyên dụng?

Điều này có nghĩa là Ruby có thể được sử dụng cho việc này, vì nó là ngôn ngữ khai báo cao hơn, cấp độ cao hơn C hoặc Java. Cũng xem: Gradle, sbt.

— Andres F.
nguồn

13

Imagine the pain and boilerplate of writing a makefile (or build.xml, or whatever) in C.Hãy tưởng tượng nỗi đau và sự lộn xộn của việc cố gắng diễn đạt logic điều kiện không tầm thường (bạn biết đấy, thứ bắt buộc tiêu chuẩn) trong một tập lệnh XML khai báo. Oh, đợi đã, bạn không cần phải tưởng tượng; có lẽ bạn đã phải đối phó với nó, và nó có lẽ là một mớ hỗn độn và một nửa, phải không? Bản dựng là một trong những lựa chọn tồi tệ nhất có thể cho ngôn ngữ kịch bản khai báo, bởi vì các vấn đề nghiêm trọng nhanh chóng kết thúc với giới hạn của tính khai báo và những thứ không đủ đơn giản để không cần công cụ xây dựng.

— Mason Wheeler

7

@MasonWheeler Có những trường hợp các công cụ xây dựng hiện có khiến tôi đau khổ, vâng. Không ai trong số họ có thể được giúp đỡ bằng cách sử dụng ngôn ngữ mệnh lệnh cấp độ thấp giống như C. Tôi thấy một cái gì đó giống như Ruby có lẽ là lý tưởng: đủ khai báo và bắt buộc, khi cần thiết. C sẽ cho tôi ác mộng cho nhiệm vụ này. Đối với tôi, hệ thống xây dựng là một trường hợp sử dụng tốt cho (hầu hết) DSL khai báo: bạn quan tâm đến việc phải làm, không phải về cách thực hiện (hầu hết thời gian).

— Andres F.

2

Đủ công bằng. Tôi đã luôn nghĩ rằng C là một trong những công nghệ "nếu X là câu trả lời bạn đặt câu hỏi sai", phải hoàn toàn trung thực; chỉ là làm việc với các "tập lệnh" XML đã là một cơn ác mộng mỗi khi tôi phải lao vào một. Tôi đồng ý rằng một ngôn ngữ mệnh lệnh cấp cao hơn với khả năng DSL sẽ là lý tưởng.

— Mason Wheeler

@AndresF.: Những thứ như tạo tập tin đòi hỏi một hỗn hợp các phương pháp. Trạng thái đầu ra mong muốn được chỉ định khai báo, nhưng các hành động cần thiết để đạt được trạng thái đó được chỉ định bắt buộc.

— supercat

1

@MasonWheeler Tôi nghĩ đó là vấn đề của những người thiết kế ngôn ngữ cấu hình hơn chính XML. Lỗi phổ biến của các tác giả của các ngôn ngữ như vậy là cho rằng chỉ vì một cái gì đó có trong XML, nó sẽ tự động có thể đọc được. (Tôi biết rằng tôi đã mắc lỗi này nhiều lần hơn là tôi cảm thấy thoải mái. Thật hấp dẫn.) Một ngôn ngữ cấu hình gọn gàng và được thiết kế tốt có thể hoạt động tốt hơn cả XML như bất kỳ hình thức nào khác.

— biziclop

12

Hãy cho bạn một ví dụ thực tế.

Khoảng 15 năm trước tôi đã làm việc về việc chuyển một hệ thống lớn được viết bằng C từ Unix sang Windows, đó là khoảng 3 triệu dòng mã. Để cung cấp cho bạn một số ý tưởng về quy mô, phải mất 24 giờ để biên dịch trên một số hệ thống unix của chúng tôi (RS6000), các cửa sổ có thể biên dịch hệ thống trong khoảng 4 giờ.

(Chúng tôi cũng có 2 triệu dòng mã bằng ngôn ngữ được dịch riêng, nhưng quyết định không sử dụng ngôn ngữ của chúng tôi cho các hệ thống xây dựng vì nó không bao giờ được thiết kế để xử lý tệp. .)

Vào thời điểm hệ thống xây dựng được viết bằng hỗn hợp các tập lệnh shell và tạo các tệp, chúng không thể di chuyển được tới windows - do đó chúng tôi quyết định viết hệ thống xây dựng của riêng mình.

Chúng tôi có thể đã sử dụng C, tuy nhiên chúng tôi quyết định sử dụng python, có vài lý do. (Chúng tôi cũng viết lại hệ thống kiểm soát mã nguồn của chúng tôi bằng python cùng một lúc, điều này rất được nâng cấp với hệ thống xây dựng, vì vậy các tệp đối tượng để kiểm tra trong các mô-đun có thể được chia sẻ bởi các nhà phát triển.)

Hầu hết các mã của chúng tôi có thể được xây dựng với một vài quy tắc đơn giản (chỉ vài nghìn dòng python cho tất cả các nền tảng, Windows, VMS và 6 phiên bản Unix) được đưa ra từ các quy ước đặt tên của các tệp.
Vào thời điểm RegEx không chuẩn lắm giữa các hệ thống C trên các nền tảng khác nhau, Python đã tích hợp sẵn trong RegEx.
Một vài mô-đun cần các bước xây dựng tùy chỉnh, Python cho phép các tệp lớp được tải động. Chúng tôi đã cho phép một lớp tùy chỉnh được sử dụng để xây dựng một mô-đun (lib), dựa trên việc có tệp python có tên ma thuật trong thư mục. Đây là lý do giết người để sử dụng trăn.
Chúng tôi đã xem xét Java, nhưng nó không được vận chuyển trên tất cả các nền tảng tại thời điểm đó.

(Giao diện người dùng cho hệ thống kiểm soát mã nguồn của chúng tôi đã sử dụng trình duyệt web vì nó có thể di động trên tất cả các nền tảng. Đây là 6 tháng trước khi chúng tôi có kết nối internet. Chúng tôi phải tải xuống trình duyệt qua X25!)

— Ian
nguồn

Đã làm việc trên một số hệ thống lớn, đôi khi tôi cảm thấy như mình nắm được quy mô phát triển như thế nào. Sau đó tôi đọc những câu chuyện như thế này. Sheesh.

— dmckee

@immibis Đây là điều thời thượng để làm 15 năm trước. Thậm chí nhiều hơn, thực tế này đã thực sự được chứng thực và khuyến khích bởi các nhà cung cấp Unix hàng đầu (đặc biệt là SGI và DEC, nhưng IBM cũng vậy).

— Oakad

1

Mọi người có xu hướng quên rằng Unix từng có nghĩa là "đắt tiền". Windows đã chiến thắng trong cuộc chiến máy tính để bàn / máy trạm bằng cách rẻ hơn. Vì lý do tương tự mà Linux sau đó đã chiến thắng trong cuộc chiến máy chủ.

— slebetman

1

Nếu tôi muốn máy tính chạy phần mềm do tôi tự viết, thì tôi muốn nó linh hoạt và có 101 tùy chọn cách thức nhân được biên dịch, v.v. Tuy nhiên, nếu tôi bán phần mềm để cài đặt trên máy tính của khách hàng, tôi muốn khách hàng chạy một hệ điều hành không linh hoạt, để tôi biết nó sẽ hoạt động trên máy tính của họ nếu nó hoạt động trên máy của tôi. Đó là một yếu tố lớn khi xem Linux như một nhà cung cấp phần mềm - hỗ trợ trông có vẻ quá đắt đỏ. Linux đã chiến thắng trong cuộc chiến phần mềm máy chủ được lưu trữ , trong đó máy chủ được cung cấp bởi nhà cung cấp phần mềm - ví dụ: hầu hết các phần mềm được triển khai trên web.

— Ian

3

@slebetman Chỉ có công bằng - Unix đã chiến thắng "cuộc chiến" trước đó bằng cách rẻ hơn (so với các máy tương tự của LISPM). Nó hoàn toàn khủng khiếp, được thiết kế khủng khiếp và bị rơi liên tục (nhưng nó khởi động nhanh hơn nhiều so với LISPM !: P), sử dụng C làm ngôn ngữ lập trình chính (khá cao từ LISP và tương tự), nhưng nó rẻ hơn nhiều. Trên thực tế, nhiều người đã chấp nhận nó vì nó miễn phí (đã có nhiều đột biến miễn phí từ lâu trước Linux). Trên thực tế, tôi đã gặp rất nhiều LISPers trường học cũ, những người thích MS-DOS hơn là không trộn lẫn thời gian. Đúng là kinh khủng.

— Luaan

3

Câu trả lời ngắn cho câu hỏi này là đây là công cụ xây dựng . Một công cụ tự động hóa việc sử dụng các công cụ khác, với mục đích xây dựng một sản phẩm cuối từ một số tệp nguồn. Nếu chúng ta viết tập lệnh xây dựng bằng cùng ngôn ngữ với chính sản phẩm, chúng ta sẽ vào vương quốc của các công cụ dành riêng cho ngôn ngữ, sẽ không được coi là công cụ xây dựng theo cùng một cách.

Điều này đặt ra câu hỏi - tại sao các trình biên dịch không cung cấp loại tự động hóa xây dựng mà chúng ta đã sử dụng từ các công cụ như make? Câu trả lời đơn giản là vì tồn tại . Triết lý Unix "làm một việc và làm tốt" cho thấy rằng trình biên dịch không cung cấp trách nhiệm này *. Điều đó nói rằng, cá nhân tôi đã trải qua những chia sẻ đau đầu của mình và sẽ rất thích thử một trình biên dịch cung cấp hệ thống xây dựng "bản địa" trích dẫn riêng của nó.

Để biết ví dụ về trình biên dịch được thiết kế theo cách này, hãy xem Jai (chưa được phát hành) của Jon Blow , một ngôn ngữ được dùng để thay thế C ++. Liên kết đến các cuộc đàm phán và bản demo của trình biên dịch được thu thập ở đây . Ngôn ngữ này biên dịch thành mã byte chạy trong trình biên dịch, với việc biên dịch thành nhị phân là một hàm thư viện chuẩn được cung cấp, có thể truy cập từ mã byte. Mục đích là cho phép cả tự động hóa xây dựng và lập trình meta trong cú pháp riêng của ngôn ngữ.

_{* Một cái nhìn về Visual Studio của Microsoft sẽ cho bạn thấy một ví dụ về triết lý ngược lại. :)}

— CD Haddon.
nguồn

2

Công cụ xây dựng trước hết là một công cụ, giống như 'gcc', 'ls', 'awk' hoặc 'git'. Bạn cung cấp cho công cụ một đầu vào (tên tệp, tham số, v.v.) và nó sẽ thực hiện một số công cụ tương ứng.

Tất cả các công cụ này cho phép bạn chuyển vào đầu vào của mình theo những cách đủ đơn giản để viết và hiểu. Trong trường hợp cụ thể của các công cụ xây dựng, đầu vào là một tệp công thức, một tệp mô tả cách dự án của bạn đi từ các tệp nguồn đến thành phẩm.

Nếu công thức của bạn đơn giản như chuyển vào thư mục chứa dự án và trình biên dịch để sử dụng, thì "ngôn ngữ" khai báo là đủ. Một khi công thức trở nên ngày càng phức tạp hơn, với logic hơn, việc xử lý nó bằng các ngôn ngữ khai báo và các ngôn ngữ mục đích chung hơn sẽ được sử dụng trở nên rắc rối hơn.

Bây giờ rõ ràng là không có mối liên hệ nào giữa ngôn ngữ được sử dụng để viết công thức xây dựng của bạn và ngôn ngữ được sử dụng để viết mã sản phẩm của bạn chỉ vì chúng có mục đích và yêu cầu khác nhau. Thậm chí không có mối liên hệ nào giữa ngôn ngữ mà công cụ xây dựng được viết và "ngôn ngữ" công thức xây dựng nên được viết. Luôn luôn sử dụng công cụ tốt nhất cho công việc!

— Tê giác
nguồn