Mengapa alat bangun menggunakan bahasa penulisan yang berbeda dari bahasa pemrograman yang mendasarinya?

23

Saya baru-baru ini menggunakan beberapa alat bangun untuk proyek Nodejs di tempat kerja ketika saya menyadari bahwa alat / sistem bangunan utama kebanyakan bahasa menggunakan bahasa yang berbeda dari bahasa pemrograman yang mendasarinya sendiri.

Misalnya, make tidak menggunakan C atau C ++ untuk menulis skrip dan semut (atau Maven) tidak menggunakan Java sebagai bahasa mereka untuk skrip.

Bahasa yang lebih baru seperti Ruby memang menggunakan bahasa yang sama untuk membuat alat seperti rake , yang masuk akal bagi saya. Tetapi mengapa tidak selalu demikian? Apa keuntungan memiliki alat bangun yang menggunakan bahasa berbeda dari bahasa yang mendasarinya?

programming-languages history build-system

— joshin4colours
sumber

14

Mungkin bahasa tujuan umum tidak cukup cocok untuk penggunaan spesialis alat ini? Sebagai contoh, saya tidak ingin menulis membuat file dalam C! Terkadang DSL lebih baik.

— Andres F.

13

Lihatlah dari sudut lain: Mengapa tidak menggunakan make untuk menulis perangkat lunak aplikasi?

— whatsisname

4

Artikel ini terutama tentang apa yang menurut penulis membuat Lisp hebat, tetapi memiliki beberapa informasi yang relevan tentang mengapa Ant menggunakan XML dan bukan Java.

— 8bittree

6

Jika Anda ingin menulis sebuah program dalam C yang mengotomatiskan pembuatan program C, bukankah Anda hanya akan menulis makelagi (yang tetap diterapkan dalam C)?

— Brandin

6

@ joshin4colours membuat yang ditulis dalam C. Bahasa yang membuat penggunaan, bagaimanapun, adalah bahasa deklaratif yang memanggil shell yang diperlukan.

36

Pilihan bahasa pemrograman apa yang akan digunakan untuk menyelesaikan sesuatu harus bergantung pada fitur spesifik dari tujuan itu dan bukan pada tugas-tugas lain yang terkait dengan proyek itu.

Alat bangun melakukan pekerjaan yang sangat spesifik, dan tidak peduli bahasa apa yang Anda gunakan untuk proyek utama, alat bangun adalah perangkat lunak dengan sendirinya.

Mencoba mengikat proyek utama dan alat pembangunannya bisa menjadi keputusan yang sangat buruk. Apa yang seharusnya Anda butuhkan dengan alat bantu bangunan adalah proses cepat dari aturan sederhana, dengan manajemen file dan IO yang cepat.

Jika bahasa seperti ruby menggunakan diri mereka sendiri untuk mengimplementasikan alat bangun mereka, lebih terkait pada fitur-fitur bahasa itu daripada pada kebutuhan diasumsikan untuk menjaga semua yang ditulis dengan bahasa yang sama.

— Nicolás
sumber

18

Bukan tidak mungkin untuk menulis alat build yang menggunakan bahasa seperti C atau Java sebagai bahasa scripting mereka. Namun, alat bantu membangun manfaat dari menggunakan bahasa skrip deklaratif yang lebih banyak . Bayangkan rasa sakit dan semangat menulis makefile (atau build.xml, atau apa pun) di C.

Alat Bangun diuntungkan dari penggunaan DSL, tugas yang C bukan pilihan yang sangat baik. C terlalu umum untuk alat bangun, dan terlalu mementingkan rincian tingkat kesalahan & rendah. Misalnya, Anda tidak ingin peduli dengan manajemen memori eksplisit dalam alat build! Jadi, bahkan jika menggunakan sintaks mirip C, Anda mungkin akan menggunakan pengumpulan sampah di alat skrip Anda, pada saat itu mengapa tidak menggunakan DSL khusus?

Masuk akal bahwa Ruby dapat digunakan untuk ini, karena ini adalah bahasa tingkat tinggi, lebih deklaratif daripada C atau Java. Lihat juga: Gradle, sbt.

— Andres F.
sumber

13

Imagine the pain and boilerplate of writing a makefile (or build.xml, or whatever) in C.Bayangkan rasa sakit dan kekacauan dari mencoba untuk mengekspresikan logika kondisional non-sepele (Anda tahu, hal-hal penting standar) dalam skrip XML deklaratif. Oh, tunggu, Anda tidak perlu membayangkan; Anda mungkin harus menghadapinya, dan itu mungkin berantakan setengah, bukan? Build adalah salah satu pilihan terburuk untuk bahasa scripting deklaratif, karena masalah serius dengan cepat berakhir melawan batas-batas deklaratif-ness, dan yang tidak cukup sederhana untuk tidak memerlukan alat build.

— Mason Wheeler

7

@MasonWheeler Ada kasus di mana alat membangun yang ada membuat saya menderita, ya. Tak satu pun dari mereka akan terbantu dengan menggunakan bahasa imperatif tingkat C seperti rendah. Saya melihat sesuatu seperti Ruby mungkin ideal: cukup deklaratif dan imperatif, sesuai kebutuhan. C akan memberi saya mimpi buruk untuk tugas ini. Bagi saya, membangun sistem adalah kasus penggunaan yang baik untuk (kebanyakan) DSL deklaratif: Anda peduli tentang apa yang harus dilakukan, bukan tentang bagaimana melakukannya (sebagian besar waktu).

— Andres F.

2

Cukup adil. Saya selalu menganggap C adalah salah satu dari teknologi "jika X adalah jawaban yang Anda ajukan dengan pertanyaan yang salah", jujur saja; hanya saja bekerja dengan "skrip" XML telah menjadi mimpi buruk setiap kali saya harus menyelami satu. Saya setuju bahwa bahasa imperatif tingkat tinggi dengan kemampuan DSL akan ideal.

— Mason Wheeler

@AndresF .: Hal-hal seperti membuat file memerlukan campuran pendekatan. Status output yang diinginkan ditentukan secara deklaratif, tetapi tindakan yang diperlukan untuk mencapai kondisi tersebut ditentukan secara imperatif.

— supercat

1

@MasonWheeler Saya pikir itu adalah masalah orang-orang yang mendesain bahasa konfigurasi daripada XML itu sendiri. Kesalahan umum oleh penulis bahasa tersebut adalah dengan menganggap bahwa hanya karena ada sesuatu dalam XML, maka secara otomatis akan terbaca oleh manusia. (Saya tahu saya telah membuat kesalahan ini lebih dari yang saya nyamankan. Ini sangat menggoda.) Bahasa konfigurasi yang dirancang dengan baik dan ramping dapat bekerja dengan baik di atas XML seperti halnya dalam bentuk lainnya.

— biziclop

12

Mari kita beri contoh dunia nyata.

Sekitar 15 tahun yang lalu saya bekerja pada porting sistem besar yang ditulis dalam C dari Unix ke Windows, itu sekitar 3 juta baris kode. Untuk memberi Anda gambaran skala, butuh waktu 24 jam untuk mengkompilasi pada beberapa sistem unix kami (RS6000), windows dapat mengkompilasi sistem dalam waktu sekitar 4 jam.

(Kami juga memiliki 2 juta baris kode dalam bahasa yang kami interpretasikan sendiri, tetapi memutuskan untuk tidak menggunakan bahasa kami untuk sistem build karena tidak pernah dirancang untuk pemrosesan file. Juga kami membutuhkan sistem build untuk mengkompilasi kode C yang mengimplementasikan bahasa kami. .)

Pada saat sistem build ditulis dalam campuran skrip shell dan membuat file, ini tidak portabel untuk windows - oleh karena itu kami memutuskan untuk menulis sistem build kami sendiri.

Kami bisa menggunakan C, namun kami memutuskan untuk menggunakan python, ada beberapa alasan. (Kami juga menulis ulang sistem kontrol kode sumber kami di python pada saat yang sama, ini sangat terintegrasi dengan sistem build, sehingga file objek untuk diperiksa dalam modul dapat dibagikan oleh pengembang.)

Sebagian besar kode kami dapat dibangun dengan beberapa aturan sederhana (hanya beberapa ribu baris python untuk semua platform, Windows, VMS, dan 6 versi Unix) yang digerakkan dari konvensi penamaan file.
Pada saat itu RegEx tidak terlalu standar antara sistem C pada platform yang berbeda, Python telah membangun di RegEx.
Beberapa modul membutuhkan langkah-langkah membangun kustom, Python memungkinkan file kelas dimuat secara dinamis. Kami mengizinkan kelas khusus untuk digunakan untuk membangun modul (lib), berdasarkan memiliki file python dengan nama ajaib di folder. Ini adalah alasan pembunuh untuk menggunakan python.
Kami mempertimbangkan Java, tetapi tidak mengirim pada semua platform pada saat itu.

(UI untuk sistem kontrol kode sumber kami menggunakan browser web karena itu portabel di semua platform. Ini adalah 6 bulan sebelum kami memiliki koneksi internet. Kami harus mengunduh browser melalui X25!)

— Ian
sumber

Setelah bekerja pada beberapa sistem bigish, kadang-kadang saya merasa memiliki pegangan tentang bagaimana skala pengembangan. Lalu saya membaca cerita seperti ini. Sheesh.

— dmckee

@immibis Ini adalah hal yang modis untuk dilakukan 15 tahun yang lalu. Terlebih lagi, praktik ini sebenarnya didukung dan didorong oleh vendor Unix terkemuka (SGI dan DEC pada khususnya, tetapi IBM juga).

— oakad

1

Orang cenderung lupa bahwa Unix dulu berarti "mahal". Windows memenangkan perang desktop / workstation dengan menjadi lebih murah. Itu karena alasan yang sama bahwa Linux kemudian memenangkan perang server.

— slebetman

1

Jika saya ingin komputer untuk menjalankan perangkat lunak yang saya tulis sendiri, maka saya ingin itu fleksibel dan memiliki 101 pilihan bagaimana kernel dikompilasi dll. Namun jika saya menjual perangkat lunak yang akan diinstal pada komputer pelanggan, saya ingin pelanggan menjadi menjalankan OS yang tidak fleksibel, sehingga saya tahu itu akan berfungsi di komputer mereka jika itu bekerja pada saya. Itu adalah faktor besar ketika melihat Linux sebagai vendor perangkat lunak - dukungan hanya terlihat terlalu mahal. Linux telah memenangkan perang perangkat lunak server yang di- host , di mana server disediakan oleh vendor perangkat lunak - misalnya kebanyakan perangkat lunak yang digunakan web.

— Ian

3

@slebetman Ini adil - Unix memenangkan "perang" sebelumnya dengan menjadi lebih murah (dibandingkan dengan LISPM dan mesin sejenis). Itu benar-benar mengerikan, sangat dirancang dan menabrak terus-menerus (tetapi booting jauh lebih cepat daripada LISPM!: P), menggunakan C sebagai bahasa pemrograman utama (jatuh cukup tinggi dari LISP dan sejenisnya), tetapi itu jauh lebih murah. Bahkan, banyak yang mengadopsinya karena gratis (sudah ada banyak mutasi gratis jauh sebelum Linux). Bahkan, saya sudah bertemu banyak LISP sekolah lama yang lebih suka MS-DOS daripada unix waktu itu. Ya, itu mengerikan.

— Luaan

3

Jawaban singkat untuk pertanyaan ini adalah bahwa ini adalah alat build . Alat yang mengotomatiskan penggunaan alat lain, dengan tujuan membangun produk akhir dari beberapa file sumber. Jika kami menulis skrip build dalam bahasa yang sama dengan produk itu sendiri, kami masuk ke ranah alat khusus bahasa, yang tidak akan dianggap sebagai alat build dengan cara yang sama.

Ini menimbulkan pertanyaan - mengapa kompiler tidak menyediakan otomatisasi build seperti yang kami gunakan dari alat seperti make? Yang jawabannya adalah karena ada . Filosofi Unix tentang "lakukan satu hal, dan lakukan dengan baik" menunjukkan bahwa bukan tanggung jawab kompiler untuk menyediakan * ini. Yang mengatakan, saya secara pribadi telah melalui bagian saya dari membuat sakit kepala, dan akan tertarik untuk mencoba kompiler yang menyediakan itu sendiri kutipan-tanda kutip membangun sistem "asli".

Untuk contoh kompiler yang dirancang dengan cara ini, lihat Jai Jon Blow (yang belum dirilis), bahasa yang dimaksudkan sebagai pengganti C ++. Tautan ke pembicaraan dan demo pengumpul dikumpulkan di sini . Bahasa ini mengkompilasi ke kode byte yang berjalan di dalam kompiler, dengan kompilasi ke biner menjadi fungsi perpustakaan standar yang disediakan, dapat diakses dari kode byte. Tujuannya adalah untuk memungkinkan otomatisasi pembuatan dan meta-pemrograman dalam sintaksis asli bahasa.

_{* Pandangan di Visual Studio Microsoft akan menunjukkan kepada Anda contoh filosofi yang berlawanan. :)}

— CD Haddon.
sumber

2

Tool build adalah alat yang pertama dan terutama, seperti 'gcc', 'ls', 'awk' atau 'git'. Anda memberi makan alat input (nama file, parameter, dll) dan itu akan melakukan beberapa hal yang sesuai.

Semua alat ini memungkinkan Anda memberikan masukan dengan cara yang seharusnya cukup sederhana untuk ditulis dan dipahami. Dalam kasus khusus alat pembuatan, input adalah file resep, file yang menjelaskan bagaimana proyek Anda beralih dari file sumber ke produk jadi.

Jika resep Anda sesederhana melewati folder yang berisi proyek dan kompiler untuk digunakan, maka "bahasa" deklaratif sudah cukup. Setelah resep menjadi lebih dan lebih rumit, dengan lebih banyak logika, menjadi sulit untuk menanganinya dengan bahasa deklaratif dan bahasa tujuan yang lebih umum digunakan.

Seharusnya sekarang menjadi jelas bahwa tidak ada hubungan antara bahasa yang digunakan untuk menulis resep bangunan Anda dan bahasa yang digunakan untuk menulis kode produk Anda hanya karena mereka memiliki tujuan dan persyaratan yang berbeda. Tidak ada hubungan bahkan di antara bahasa alat bangun ditulis dan "bahasa" resep membangun harus ditulis. Selalu gunakan alat terbaik untuk pekerjaan itu!

— Tibos
sumber