เหตุใดเครื่องมือสร้างจึงใช้ภาษาสคริปต์แตกต่างจากภาษาโปรแกรมพื้นฐาน

23

ฉันเพิ่งได้ใช้เครื่องมือสร้างบางอย่างสำหรับโครงการ Nodejs ในที่ทำงานเมื่อฉันตระหนักว่าเครื่องมือสร้าง / ระบบหลักของภาษาส่วนใหญ่ใช้ภาษาที่แตกต่างจากภาษาโปรแกรมพื้นฐาน

ตัวอย่างเช่นmakeไม่ใช้ C หรือ C ++ เพื่อเขียนสคริปต์และant (หรือ Maven) ไม่ได้ใช้ Java เป็นภาษาสำหรับการเขียนสคริปต์

ภาษาที่ใหม่กว่าอย่าง Ruby ใช้ภาษาเดียวกันเพื่อสร้างเครื่องมือเช่นrakeซึ่งเหมาะสมกับฉัน แต่ทำไมไม่เป็นเช่นนี้เสมอไป? ข้อดีของการมีเครื่องมือสร้างที่ใช้ภาษาต่างจากภาษาต้นแบบคืออะไร

programming-languages history build-system

— joshin4colours
แหล่งที่มา

14

บางทีภาษาที่ใช้งานทั่วไปอาจไม่เหมาะสมสำหรับการใช้งานของผู้เชี่ยวชาญ ตัวอย่างเช่นฉันไม่ต้องการเขียนไฟล์ make ใน C! บางครั้ง DSL ก็ดีกว่า

— Andres F.

13

ดูจากมุมมองอื่น: ทำไมไม่ใช้ซอฟต์แวร์เขียนแอพพลิเคชั่นทำ?

— whatsisname

4

บทความนี้เกี่ยวกับสิ่งที่ผู้เขียนเชื่อว่าทำให้ Lisp ยอดเยี่ยม แต่มีข้อมูลที่เกี่ยวข้องเกี่ยวกับสาเหตุที่ Ant ใช้ XML แทน Java

— 8bittree

6

หากคุณต้องการเขียนโปรแกรมใน C ที่สร้างโปรแกรม C โดยอัตโนมัติคุณจะไม่ต้องเขียนmakeอีกครั้ง (ซึ่งถูกนำไปใช้ใน C อยู่แล้ว)?

— Brandin

6

@ joshin4colours make ถูกเขียนเป็น C อย่างไรก็ตามภาษาที่ใช้งานแล้วเป็นภาษาที่ประกาศใช้ซึ่งเรียกใช้เชลล์ตามต้องการ

36

การเลือกภาษาการเขียนโปรแกรมที่จะใช้เพื่อทำสิ่งใดต้องขึ้นอยู่กับคุณสมบัติเฉพาะของเป้าหมายนั้นและไม่ได้อยู่ในภารกิจอื่นที่เกี่ยวข้องกับโครงการนั้น

เครื่องมือสร้างทำงานเฉพาะอย่างมากและไม่ว่าคุณจะใช้ภาษาใดในโครงการหลักเครื่องมือสร้างเป็นซอฟต์แวร์ด้วยตัวเอง

การพยายามผูกโครงการหลักและเครื่องมือสร้างอาจเป็นการตัดสินใจที่แย่มาก สิ่งที่คุณต้องการด้วยเครื่องมือสร้างเป็นส่วนใหญ่เป็นกระบวนการที่ง่ายของกฎง่าย ๆ ด้วยการจัดการไฟล์และ IO ที่รวดเร็ว

หากภาษาอย่างทับทิมใช้ตัวเองในการสร้างเครื่องมือสร้างความสัมพันธ์กับคุณสมบัติของภาษานั้นจะดีกว่าการสันนิษฐานว่าจะต้องเก็บทุกสิ่งที่เขียนด้วยภาษาเดียวกัน

— Nicolás
แหล่งที่มา

18

มันเป็นไปไม่ได้ที่จะเขียนเครื่องมือสร้างที่ใช้ภาษาเช่น C หรือ Java เป็นภาษาสคริปต์ของพวกเขา อย่างไรก็ตามการสร้างเครื่องมือได้รับประโยชน์จากการใช้ภาษาสคริปต์ที่เปิดเผยมากขึ้น ลองนึกภาพความเจ็บปวดและความร้อนของการเขียน makefile (หรือ build.xml หรืออะไรก็ตาม) ใน C

เครื่องมือสร้างได้รับประโยชน์จากการใช้ DSL ซึ่งเป็นงานที่ C ไม่ใช่ตัวเลือกที่ดีโดยเฉพาะ C นั้นกว้างเกินไปสำหรับเครื่องมือสร้างและเกี่ยวข้องกับรายละเอียดข้อผิดพลาด & ระดับต่ำเกินไป ตัวอย่างเช่นคุณไม่ต้องการเกี่ยวข้องกับการจัดการหน่วยความจำอย่างชัดเจนในเครื่องมือสร้าง! ดังนั้นแม้ว่าการใช้ไวยากรณ์แบบ C คุณอาจใช้การรวบรวมขยะในเครื่องมือการเขียนสคริปต์ของคุณ ณ จุดนี้ทำไมไม่ใช้ DSL เฉพาะ

มันสมเหตุสมผลแล้วที่ Ruby สามารถใช้สิ่งนี้ได้เนื่องจากเป็นภาษาระดับสูงกว่าและมีการประกาศมากกว่า C หรือ Java ดูเพิ่มเติมที่: Gradle, sbt

— Andres F.
แหล่งที่มา

13

Imagine the pain and boilerplate of writing a makefile (or build.xml, or whatever) in C.ลองนึกภาพความเจ็บปวดและความยุ่งเหยิงของการพยายามแสดงตรรกะเงื่อนไขที่ไม่สำคัญ (คุณรู้ว่าสิ่งที่จำเป็นมาตรฐาน) ในสคริปต์ XML ที่เปิดเผย โอ้รอคุณไม่ต้องจินตนาการ คุณอาจต้องจัดการกับมันและมันอาจเป็นระเบียบและครึ่งใช่มั้ย บิวด์เป็นหนึ่งในตัวเลือกที่เลวร้ายที่สุดสำหรับภาษาสคริปต์เชิงประกาศเนื่องจากปัญหาร้ายแรงจะจบลงอย่างรวดเร็ว แต่ขัดแย้งกับข้อ จำกัด ของการประกาศและตัวที่ไม่ง่ายพอที่ไม่ต้องการเครื่องมือสร้าง

— Mason Wheeler

7

@MasonWheeler มีหลายกรณีที่เครื่องมือสร้างที่มีอยู่ทำให้ฉันต้องทนทุกข์ใช่ ไม่มีใครในพวกเขาที่จะได้รับความช่วยเหลือโดยใช้ภาษาที่จำเป็นในระดับต่ำเช่น C ฉันเห็นบางสิ่งบางอย่างเช่น Ruby ซึ่งอาจเป็นอุดมคติ: ที่เปิดเผยและจำเป็นเพียงพอตามความจำเป็น C จะให้ฝันร้ายแก่ฉันสำหรับงานนี้ สำหรับฉันแล้วการสร้างระบบเป็นกรณีการใช้งานที่ดีสำหรับ DSL ส่วนใหญ่ที่คุณสนใจว่าจะทำอย่างไรไม่เกี่ยวกับวิธีการทำ (ส่วนใหญ่)

— Andres F.

2

ยุติธรรมพอสมควร ฉันคิดเสมอว่า C เป็นหนึ่งในเทคโนโลยี "ถ้า X คือคำตอบที่คุณถามคำถามที่ผิด" เพื่อที่จะซื่อสัตย์อย่างสมบูรณ์ เป็นเพียงการทำงานกับ XML "สคริปต์" เป็นฝันร้ายทุกครั้งที่ฉันต้องดำดิ่งลงไป ฉันเห็นด้วยว่าภาษาที่จำเป็นในระดับสูงกว่าด้วยความสามารถของ DSL จะเหมาะ

— Mason Wheeler

@AndresF: สิ่งที่ทำให้ไฟล์ต้องมีวิธีการผสมผสาน สถานะเอาต์พุตที่ต้องการถูกระบุอย่างชัดเจน แต่การดำเนินการที่จำเป็นเพื่อให้ได้สถานะนั้นถูกระบุไว้อย่างไม่ถูกต้อง

— supercat

1

@ MasonWheeler ฉันคิดว่านั่นเป็นปัญหาของคนที่ออกแบบภาษา config มากกว่า XML เอง ข้อผิดพลาดทั่วไปของผู้เขียนภาษาดังกล่าวคือการสันนิษฐานว่าเพราะมีบางสิ่งใน XML มันจะสามารถอ่านได้โดยอัตโนมัติ (ฉันรู้ว่าฉันทำผิดพลาดครั้งนี้มากกว่าที่ฉันพอใจมันดึงดูดมาก) ภาษาที่ได้รับการออกแบบมาอย่างดีและลีนสามารถทำงานได้ดีกับ XML เช่นเดียวกับในรูปแบบอื่น ๆ

— biziclop

12

ขอยกตัวอย่างโลกแห่งความจริงให้คุณ

ประมาณ 15 ปีที่แล้วฉันทำงานเกี่ยวกับการย้ายระบบขนาดใหญ่ที่เขียนใน C จาก Unix ไปยัง Windows มันเป็นรหัสประมาณ 3 ล้านบรรทัด เพื่อให้คุณมีความคิดเกี่ยวกับการปรับขนาดใช้เวลามากกว่า 24 ชั่วโมงในการรวบรวมระบบยูนิกซ์บางส่วนของเรา (RS6000) หน้าต่างสามารถรวบรวมระบบในเวลาประมาณ 4 ชั่วโมง

(เรามีรหัส 2 ล้านบรรทัดในภาษาที่แปลของเราเอง แต่ตัดสินใจที่จะไม่ใช้ภาษาของเราสำหรับระบบการสร้างเนื่องจากไม่ได้ออกแบบมาสำหรับการประมวลผลไฟล์นอกจากนี้เราต้องการระบบสร้างเพื่อรวบรวมรหัส C ที่ใช้ภาษาของเรา .)

ในขณะที่ระบบบิลด์เขียนด้วยเชลล์สคริปต์และสร้างไฟล์เหล่านี้ไม่สามารถพกพาไปยัง windows ได้ดังนั้นเราจึงตัดสินใจเขียนระบบ build ของเราเอง

เราสามารถใช้ C ได้ แต่เราตัดสินใจที่จะใช้ python มันมีเหตุผลสองสามข้อ (เราเขียนระบบควบคุมซอร์สโค้ดของเราอีกครั้งในไพ ธ อนพร้อมกันซึ่งเป็นระบบที่ประกอบขึ้นด้วยระบบการสร้างดังนั้นวัตถุไฟล์สำหรับการตรวจสอบในโมดูลสามารถแชร์โดยนักพัฒนาได้)

รหัสของเราส่วนใหญ่สามารถสร้างด้วยกฎง่าย ๆ (เพียงไม่กี่พันบรรทัดของงูใหญ่สำหรับทุกแพลตฟอร์ม, Windows, VMS, และ Unix 6 เวอร์ชัน) ที่ถูกขับออกมาจากการตั้งชื่อไฟล์
ในเวลานั้น RegEx ไม่ได้มาตรฐานมากระหว่างระบบ C บนแพลตฟอร์มที่ต่างกัน Python ได้สร้างใน RegEx
บางโมดูลต้องการขั้นตอนการสร้างที่กำหนดเอง Python อนุญาตให้โหลดไฟล์คลาสแบบไดนามิก เราอนุญาตให้ใช้คลาสที่กำหนดเองเพื่อสร้างโมดูล (lib) โดยยึดตามไฟล์ python ที่มีชื่อเวทย์มนตร์ในโฟลเดอร์ นี่เป็นเหตุผลที่นักฆ่าใช้งูหลาม
เราพิจารณา Java แต่มันไม่ได้จัดส่งในทุกแพลตฟอร์ม ณ จุดนั้น

(UI สำหรับระบบควบคุมซอร์สโค้ดของเราใช้เว็บเบราว์เซอร์เหมือนกับพกพาได้ทั่วทุกแพลตฟอร์มนี่คือ 6 เดือนก่อนที่เราจะมีการเชื่อมต่ออินเทอร์เน็ตเราต้องดาวน์โหลดเบราว์เซอร์ผ่าน X25!)

— เอียน
แหล่งที่มา

การทำงานกับระบบใหญ่ ๆ หลายครั้งบางครั้งฉันรู้สึกว่าฉันมีส่วนช่วยในการพัฒนา จากนั้นฉันก็อ่านเรื่องราวเช่นนี้ Sheesh

— dmckee

@immibis นี่เป็นสิ่งที่ทันสมัยที่ต้องทำเมื่อ 15 ปีก่อน ยิ่งไปกว่านั้นการฝึกฝนนี้ได้รับการรับรองและสนับสนุนจากผู้จำหน่าย Unix ชั้นนำ (โดยเฉพาะ SGI และ DEC แต่ IBM ก็เช่นกัน)

— oakad

1

คนมักจะลืมว่า Unix เคยหมายถึง "แพง" Windows ชนะสงคราม desktop / เวิร์กสเตชันโดยถูกกว่า ด้วยเหตุผลเดียวกันกับที่ภายหลัง Linux ชนะสงครามเซิร์ฟเวอร์

— slebetman

1

ถ้าฉันต้องการให้คอมพิวเตอร์ใช้งานซอฟต์แวร์ที่ฉันเขียนเองฉันก็ต้องการให้มันมีความยืดหยุ่นและมี 101 ตัวเลือกว่าจะรวบรวมเมล็ดได้อย่างไรอย่างไรก็ตามถ้าฉันขายซอฟต์แวร์ที่จะติดตั้งบนคอมพิวเตอร์ของลูกค้าฉันต้องการให้ลูกค้าเป็น ใช้งานระบบปฏิบัติการที่ไม่ยืดหยุ่นดังนั้นฉันจึงรู้ว่ามันจะทำงานบนคอมพิวเตอร์ของพวกเขาหากใช้งานได้จริง นั่นเป็นปัจจัยใหญ่เมื่อมอง Linux ในฐานะผู้จำหน่ายซอฟต์แวร์ - การสนับสนุนดูแพงเกินไป ลีนุกซ์ชนะสงครามซอฟต์แวร์เซิร์ฟเวอร์โฮสต์ , ซึ่งเซิร์ฟเวอร์จัดทำโดยผู้จำหน่ายซอฟต์แวร์ - เช่นซอฟต์แวร์ที่ติดตั้งบนเว็บส่วนใหญ่

— เอียน

3

@slebetman มันยุติธรรมเท่านั้น - Unix ชนะ "สงคราม" ครั้งก่อนโดยถูกกว่า (เทียบกับ LISPM และเครื่องจักรที่คล้ายคลึงกัน) มันน่ากลัวอย่างยิ่งออกแบบมาอย่างยอดเยี่ยมและล้มเหลวอย่างต่อเนื่อง (แต่มันบูทเร็วกว่า LISPM!: P) โดยใช้ C เป็นภาษาโปรแกรมหลัก (ค่อนข้างสูงจาก LISP และที่คล้ายกัน) ในความเป็นจริงหลายคนยอมรับมันเพราะมันฟรี (มีการกลายพันธุ์ฟรีมากมายมานานก่อน Linux) ในความเป็นจริงฉันได้พบ LISPers สมัยเก่าจำนวนมากที่ชอบMS-DOSเพื่อใช้เวลาในระบบยูนิกซ์ ใช่ว่าน่ากลัว

— Luaan

3

คำตอบสั้น ๆ สำหรับคำถามนี้ก็คือว่านี่คือสิ่งที่เป็นเครื่องมือที่สร้างคือ เครื่องมือที่ใช้งานเครื่องมืออื่น ๆ โดยอัตโนมัติโดยมีจุดประสงค์ในการสร้างผลิตภัณฑ์สุดท้ายจากไฟล์ต้นฉบับบางไฟล์ หากเราเขียนสคริปต์สร้างในภาษาเดียวกับผลิตภัณฑ์นั้นเราจะเข้าสู่อาณาจักรของเครื่องมือเฉพาะภาษาซึ่งจะไม่ถือว่าเป็นเครื่องมือสร้างในลักษณะเดียวกัน

นี่ทำให้เกิดคำถามขึ้น - ทำไมคอมไพเลอร์ไม่ให้การสร้างอัตโนมัติแบบที่เราเคยชินจากเครื่องมืออย่าง make? ซึ่งคำตอบก็คือเพราะทำอยู่ ปรัชญา Unix ของ "ทำสิ่งหนึ่งสิ่งใดและทำมันให้ดี" แสดงให้เห็นว่ามันไม่ใช่ความรับผิดชอบของคอมไพเลอร์ในการให้ * ที่กล่าวว่าฉันได้รับผ่านส่วนตัวของฉันทำให้ปวดหัวและจะสนใจลองแปลที่ให้มันเป็นระบบสร้าง "เจ้าของ" อ้างคำพูดของตัวเอง

สำหรับตัวอย่างของคอมไพเลอร์ที่ออกแบบมาในลักษณะนี้โปรดดูที่จอนโบล (ที่ยังไม่ได้เผยแพร่) จึยภาษาที่ตั้งใจจะใช้แทนซีพลัสพลัส เชื่อมโยงไปยังการเจรจาและการสาธิตของคอมไพเลอร์จะถูกเก็บรวบรวมที่นี่ ภาษานี้คอมไพล์ไปยังโค้ดไบต์ที่ทำงานภายในคอมไพเลอร์โดยมีการคอมไพล์ไปเป็นไบนารี่ซึ่งเป็นไลบรารีมาตรฐานที่จัดเตรียมการทำงานให้สามารถเข้าถึงได้จากไบต์โค้ด ความตั้งใจคือการอนุญาตสำหรับทั้งการสร้างอัตโนมัติและการเขียนโปรแกรมเมตาภายในไวยากรณ์ดั้งเดิมของภาษา

_{* ดูที่ Visual Studio ของ Microsoft จะแสดงตัวอย่างของปรัชญาตรงกันข้าม :)}

— ซีดี Haddon
แหล่งที่มา

2

เครื่องมือสร้างเป็นอันดับแรกและสำคัญที่สุดเครื่องมือเช่น 'gcc', 'ls', 'awk' หรือ 'git' คุณป้อนเครื่องมือป้อนข้อมูล (ชื่อไฟล์พารามิเตอร์ ฯลฯ ) และจะทำบางสิ่งตามลำดับ

เครื่องมือเหล่านี้ทั้งหมดช่วยให้คุณสามารถส่งผ่านข้อมูลของคุณในรูปแบบที่ควรจะง่ายพอที่จะเขียนและเข้าใจ ในกรณีเฉพาะของเครื่องมือสร้างอินพุตเป็นไฟล์สูตรซึ่งเป็นไฟล์ที่อธิบายว่าโครงการของคุณดำเนินไปอย่างไรจากไฟล์ต้นฉบับไปยังผลิตภัณฑ์สำเร็จรูป

หากสูตรของคุณเรียบง่ายเหมือนกับส่งผ่านในโฟลเดอร์ที่มีโครงการและคอมไพเลอร์ที่จะใช้ดังนั้น "ภาษา" ที่ประกาศได้ก็เพียงพอแล้ว เมื่อสูตรมีความซับซ้อนมากขึ้นและมีตรรกะมากขึ้นมันจะลำบากในการจัดการกับภาษาที่มีการประกาศและมีการใช้ภาษาที่ใช้ทั่วไปมากขึ้น

ตอนนี้มันควรจะชัดเจนว่าไม่มีการเชื่อมต่อระหว่างภาษาที่ใช้ในการเขียนสูตรการสร้างของคุณและภาษาที่ใช้ในการเขียนรหัสผลิตภัณฑ์ของคุณเพียงเพราะพวกเขามีวัตถุประสงค์และข้อกำหนดที่แตกต่างกัน ไม่มีการเชื่อมต่อระหว่างภาษาที่เครื่องมือสร้างเขียนและ "ภาษา" สูตรการประกอบที่ควรเขียนควรใช้เครื่องมือที่ดีที่สุดสำหรับงานเสมอ!

— Tibos
แหล่งที่มา