अंतर्निहित टूल अंतर्निहित प्रोग्रामिंग भाषा की तुलना में स्क्रिप्टिंग भाषा का उपयोग क्यों करते हैं?

23

मैं हाल ही में काम पर एक Nodejs परियोजना के लिए कुछ बिल्ड टूल का उपयोग कर रहा हूं जब मुझे एहसास हुआ कि ज्यादातर भाषाओं के मुख्य बिल्ड टूल / सिस्टम अंतर्निहित प्रोग्रामिंग भाषा की तुलना में एक अलग भाषा का उपयोग करते हैं।

उदाहरण के लिए, मेकअप लिखने स्क्रिप्ट और करने के लिए सी या सी ++ का उपयोग नहीं करता चींटी (और न ही Maven) स्क्रिप्टिंग के लिए उनकी भाषा के रूप में जावा का उपयोग नहीं करता।

रूबी जैसी नई भाषाएं रेक जैसे उपकरण बनाने के लिए उसी भाषा का उपयोग करती हैं , जो मुझे समझ में आता है। लेकिन हमेशा ऐसा क्यों नहीं हुआ है? अंतर्निहित भाषा से भिन्न भाषा का उपयोग करने वाले बिल्ड टूल होने का क्या फ़ायदा नहीं है?

programming-languages history build-system

— joshin4colours
स्रोत

14

हो सकता है कि सामान्य प्रयोजन की भाषा उपकरण के विशेषज्ञ के उपयोग के लिए पर्याप्त रूप से उपयुक्त न हो? उदाहरण के लिए, मैं सी में फाइल बनाना नहीं लिखना चाहूंगा! कभी-कभी एक डीएसएल बेहतर होता है।

— एंड्रेस एफ।

13

इसे दूसरे कोण से देखें: एप्लिकेशन सॉफ़्टवेयर लिखने के लिए मेक इन का उपयोग क्यों न करें?

— whatsisname

4

यह लेख मुख्य रूप से इस बारे में है कि लेखक का मानना है कि लिस्प महान है, लेकिन कुछ प्रासंगिक जानकारी है कि चींटी जावा के बजाय एक्सएमएल का उपयोग क्यों करती है।

— 8bittree

6

यदि आप C में एक प्रोग्राम लिखना चाहते हैं जो C प्रोग्राम्स का निर्माण करता है, तो क्या आप makeफिर से लिखना शुरू नहीं करेंगे (जो वैसे भी C में लागू है)?

— ब्रैंडिन

6

@ joshin4colours मे लिखा है। सी। भाषा जो उपयोग करती है, हालांकि, एक घोषणात्मक भाषा है जो शेल को आवश्यकतानुसार खोलती है ।

36

किसी भी चीज़ को प्राप्त करने के लिए प्रोग्रामिंग भाषा का उपयोग करने का विकल्प उस लक्ष्य की विशिष्ट विशेषताओं पर निर्भर होना चाहिए, न कि उस परियोजना से संबंधित अन्य कार्यों पर।

एक बिल्ड टूल एक बहुत ही विशिष्ट काम करता है, और इससे कोई फर्क नहीं पड़ता कि आप मुख्य परियोजना के लिए किस भाषा का उपयोग कर रहे हैं, एक बिल्ड टूल अपने आप में एक सॉफ्टवेयर है।

मुख्य परियोजना और इसके निर्माण उपकरण को टाई करने की कोशिश करना बहुत बुरा निर्णय हो सकता है। बिल्ड टूल के साथ आपको जो चाहिए, वह मुख्य रूप से सरल नियमों की एक तेज प्रक्रिया है, जिसमें फाइलों और आईओ का तेज प्रबंधन है।

यदि रूबी जैसी भाषाएं अपने बिल्ड टूल को लागू करने के लिए स्वयं का उपयोग करती हैं, तो उस भाषा की विशेषताओं पर अधिक संबंधित होती है, जिस पर उसी भाषा के साथ लिखी गई सभी चीजों को रखने की आवश्यकता होती है।

— निकोलस
स्रोत

18

एक बिल्ड टूल लिखना असंभव नहीं है जो सी या जावा जैसी भाषा का उपयोग उनकी स्क्रिप्टिंग भाषाओं के रूप में करता है। हालाँकि, अधिक घोषणात्मक स्क्रिप्टिंग भाषाओं का उपयोग करने से उपकरण लाभान्वित होते हैं। सी में मेकफाइल (या बिल्ड.xml, या जो कुछ भी) लिखने के दर्द और बॉयलरप्लेट की कल्पना करें।

डीएसएल के उपयोग से बिल्ड टूल्स लाभ, एक कार्य जिसके लिए सी एक विशेष रूप से अच्छा विकल्प नहीं है। C एक बिल्ड टूल के लिए बहुत सामान्य है , और त्रुटि-प्रवण और निम्न-स्तरीय विवरणों से भी संबंधित है। उदाहरण के लिए, आप बिल्ड टूल में स्पष्ट मेमोरी-मैनेजमेंट से चिंतित नहीं होना चाहते हैं! यहां तक कि अगर सी-सिंटैक्स का उपयोग करते हुए, आप शायद अपने स्क्रिप्टिंग टूल में कचरा संग्रह का उपयोग कर रहे हैं, तो किस बिंदु पर बस एक समर्पित डीएसएल का उपयोग क्यों न करें?

यह समझ में आता है कि रूबी को इसके लिए इस्तेमाल किया जा सकता है, क्योंकि यह उच्च-स्तरीय, सी या जावा की तुलना में अधिक घोषणात्मक भाषा है। यह भी देखें: स्नातक, sbt

— एंड्रेस एफ।
स्रोत

13

Imagine the pain and boilerplate of writing a makefile (or build.xml, or whatever) in C.एक घोषित XML स्क्रिप्ट में गैर-तुच्छ सशर्त तर्क (आप जानते हैं, मानक अनिवार्य सामान) को व्यक्त करने की कोशिश करने के दर्द और गड़बड़ की कल्पना करें। ओह, रुको, तुम्हें कल्पना नहीं करनी है; आपको शायद इससे निपटना था, और यह शायद एक गड़बड़ और एक आधा था, है ना? एक घोषणात्मक स्क्रिप्टिंग भाषा के लिए बिल्ड सबसे खराब संभव विकल्पों में से एक है, क्योंकि गंभीर समस्याएं जल्दी-जल्दी घोषणा-नेस की सीमाओं के खिलाफ खत्म हो जाती हैं, और जो सरल नहीं हैं, उन्हें बिल्ड टूल की आवश्यकता नहीं है।

— मेसन व्हीलर

7

@MasonWheeler ऐसे मामले हैं जहां मौजूदा बिल्ड टूल्स ने मुझे पीड़ित किया है, हाँ। निम्न-स्तरीय सी-जैसी अनिवार्य भाषा का उपयोग करके उनमें से किसी की भी मदद नहीं की गई होगी। मैं रूबी को शायद आदर्श के रूप में देखता हूं: घोषित और अत्यावश्यक। सी मुझे इस कार्य के लिए बुरे सपने देगा। मेरे लिए सिस्टम बनाना (ज्यादातर) घोषणात्मक DSL के लिए एक अच्छा उपयोग मामला है: आप इस बात की परवाह करते हैं कि क्या करना है, न कि इसे कैसे करना है (अधिकांश समय)।

— एंड्रेस एफ।

2

काफी उचित। मुझे हमेशा लगा है कि C उनमें से एक है "यदि X का उत्तर है तो आप गलत प्रश्न पूछ रहे हैं" प्रौद्योगिकियों, पूरी तरह से ईमानदार होने के लिए; यह सिर्फ इतना है कि XML "स्क्रिप्ट्स" के साथ काम करना हर बार एक बुरा सपना रहा है जो मुझे एक में गोता लगाने के लिए पड़ा है। मैं सहमत हूं कि डीएसएल क्षमताओं के साथ एक उच्च स्तरीय अनिवार्य भाषा आदर्श होगी।

— मेसन व्हीलर

@AndresF .: फाइलें बनाने जैसी चीजों को दृष्टिकोण के मिश्रण की आवश्यकता होती है। वांछित आउटपुट राज्य को घोषित रूप से निर्दिष्ट किया जाता है, लेकिन उस राज्य को प्राप्त करने के लिए आवश्यक क्रियाएं अनिवार्य रूप से निर्दिष्ट की जाती हैं।

— सुपरकाट

1

@MasonWheeler मुझे लगता है कि उन लोगों की बहुत समस्या है जिन्होंने XML की तुलना में कॉन्फ़िगर भाषा को डिज़ाइन किया है। ऐसी भाषाओं के लेखकों द्वारा आम गलती यह मान लेना है कि क्योंकि XML में कुछ है, यह स्वचालित रूप से मानव-पठनीय होगा। (मुझे पता है कि मैंने इस गलती को अधिक बार किया है क्योंकि मैं इसके साथ सहज हूं। यह बहुत लुभावना है।) एक अच्छी तरह से डिजाइन और दुबला विन्यास भाषा केवल एक्सएमएल के साथ-साथ किसी अन्य रूप में भी काम कर सकती है।

— biziclop

12

आइए आपको एक वास्तविक दुनिया का उदाहरण देते हैं।

लगभग 15 साल पहले मैंने यूनिक्स से विंडोज में सी में लिखे एक बड़े सिस्टम को पोर्ट करने पर काम किया था, यह कोड की लगभग 3 मिलियन लाइनें थी। आपको पैमाने का कुछ विचार देने के लिए, हमारे कुछ यूनिक्स सिस्टम (RS6000) पर संकलन करने में 210 से अधिक का समय लगा, विंडोज़ सिस्टम को लगभग 4hrs में संकलित कर सकता है।

(हमारी अपनी व्याख्या की गई भाषा में भी हमारे पास 2 मिलियन लाइन कोड था, लेकिन बिल्ड सिस्टम के लिए हमारी भाषा का उपयोग नहीं करने का निर्णय लिया गया क्योंकि यह फ़ाइल प्रसंस्करण के लिए कभी डिज़ाइन नहीं किया गया था। इसके अलावा हमें अपनी भाषा को लागू करने वाले C कोड को संकलित करने के लिए एक बिल्ड सिस्टम की आवश्यकता थी। ।)

जिस समय बिल्ड सिस्टम को शेल स्क्रिप्ट्स और फ़ाइलों को बनाने के मिश्रण में लिखा गया था, ये विंडोज़ के लिए पोर्टेबल नहीं थे - इसलिए हमने अपनी खुद की बिल्ड सिस्टम लिखने का फैसला किया।

हम सी का उपयोग कर सकते थे, हालांकि हमने अजगर का उपयोग करने का फैसला किया, इसके कुछ कारण थे। (हम एक ही समय में अजगर में हमारे स्रोत कोड नियंत्रण प्रणाली को फिर से लिखते हैं, यह निर्माण प्रणाली के साथ बहुत ही हस्तक्षेप किया गया था, इसलिए मॉड्यूल में जांचे गए ऑब्जेक्ट फ़ाइलों को डेवलपर्स द्वारा साझा किया जा सकता है।)

हमारे अधिकांश कोड कुछ सरल नियमों (सभी प्लेटफार्मों, विंडोज, वीएमएस और यूनिक्स के 6 संस्करणों के लिए केवल अजगर की कुछ हजार लाइनें) के साथ बनाए जा सकते हैं, जिन्हें फाइलों के नामकरण सम्मेलनों से चुना गया था।
जिस समय RegEx विभिन्न प्लेटफार्मों पर C सिस्टम के बीच बहुत मानक नहीं था, पायथन ने RegEx में बनाया था।
कुछ मॉड्यूल को कस्टम बिल्ड चरणों की आवश्यकता थी, पायथन ने कक्षा की फ़ाइलों को गतिशील रूप से लोड करने की अनुमति दी। हमने एक कस्टम वर्ग को एक मॉड्यूल (lib) बनाने के लिए उपयोग करने की अनुमति दी है, जो कि फ़ोल्डर में एक जादुई नाम के साथ अजगर फ़ाइल होने पर आधारित है। यह अजगर का उपयोग करने का हत्यारा कारण था।
हमने जावा पर विचार किया, लेकिन यह उस समय सभी प्लेटफार्मों पर शिपिंग नहीं था।

(हमारे सोर्स कोड कंट्रोल सिस्टम के लिए यूआई ने एक वेब ब्राउज़र का उपयोग किया है जो सभी प्लेटफॉर्म पर पोर्टेबल था। इंटरनेट कनेक्शन के 6 महीने पहले। हमें ब्राउज़र को X25 पर डाउनलोड करना था!)

— इयान
स्रोत

कई बीघे प्रणालियों पर काम करने के बाद मुझे कभी-कभी ऐसा लगता है कि मेरे पास विकास के पैमानों पर नियंत्रण है। फिर मैंने इस तरह की कहानियाँ पढ़ीं। शीश।

— dmckee

@immibis यह 15 साल पहले की फैशनेबल चीज़ थी। इससे भी अधिक, यह अभ्यास वास्तव में अग्रणी यूनिक्स विक्रेताओं (एसजीआई और विशेष रूप से, लेकिन आईबीएम भी) द्वारा प्रोत्साहित और प्रोत्साहित किया गया था।

— ओकाद

1

लोग यह भूल जाते हैं कि यूनिक्स का अर्थ "महंगा" था। विंडोज ने सस्ता होकर डेस्कटॉप / वर्कस्टेशन युद्ध जीता। यह उसी कारण से है कि लिनक्स ने बाद में सर्वर युद्ध जीता।

— स्लीपबेटमैन

1

अगर मैं चाहता हूं कि कोई ऐसा कंप्यूटर जिसे मैंने स्वयं लिखा हो, तो मैं चाहता हूं कि वह लचीला हो और 101 विकल्प हों कि गुठली कैसे संकलित है आदि। हालांकि अगर मैं ग्राहक के कंप्यूटर पर स्थापित होने के लिए सॉफ्टवेयर बेच रहा हूं, तो मैं चाहता हूं कि ग्राहक हो। एक OS चलाना जो लचीला नहीं है, ताकि मुझे पता हो कि यह उनके कंप्यूटर पर काम करेगा अगर यह मेरा काम करता है। लिनक्स को सॉफ्टवेयर विक्रेता के रूप में देखते समय यह एक बड़ा कारक था - समर्थन सिर्फ बहुत महंगा लग रहा था। लिनक्स ने होस्ट किए गए सर्वर सॉफ्टवेयर युद्धों को जीत लिया है , जहां सॉफ्टवेयर विक्रेता द्वारा सर्वर प्रदान किया जाता है - जैसे अधिकांश वेब तैनात सॉफ्टवेयर।

— इयान

3

@slebetman यह केवल उचित है - यूनिक्स ने सस्ता (LISPM और इसी तरह की सामग्री की तुलना में) पिछले "युद्ध" जीता। यह बिल्कुल भयावह था, लगातार डिज़ाइन किया गया और दुर्घटनाग्रस्त हो गया (लेकिन यह LISPM की तुलना में बहुत तेज़ी से बूट होता है: P), प्राथमिक प्रोग्रामिंग भाषा के रूप में C का उपयोग करते हुए (LISP और इसी तरह का एक उच्च पतन), लेकिन यह बहुत सस्ता था। वास्तव में, कई लोगों ने इसे अपनाया क्योंकि यह मुफ़्त था (लिनक्स से बहुत पहले बहुत से मुक्त परिवर्तन हुए हैं)। वास्तव में, मैं बहुत सारे पुराने स्कूल के LISPers से मिला हूं, जिन्होंने उस समय के यूनिक्स के लिए MS-DOS को प्राथमिकता दी थी। हाँ, वह भयानक।

— लुअन

3

इस प्रश्न का संक्षिप्त उत्तर यह है कि यह एक बिल्ड टूल है । एक उपकरण जो अन्य उपकरणों के उपयोग को स्वचालित करता है, कुछ स्रोत फ़ाइलों से अंतिम उत्पाद बनाने के उद्देश्य से। यदि हम उत्पाद के रूप में उसी भाषा में बिल्ड स्क्रिप्ट लिख रहे हैं, तो हम भाषा-विशिष्ट टूल के क्षेत्र में हैं, जिसे उसी तरह बिल्ड टूल नहीं माना जाएगा।

यह सवाल उठाता है - कम्पाइलर बिल्ड ऑटोमेशन के प्रकार को क्यों नहीं प्रदान करते हैं जिसका उपयोग हम मेक अप जैसे टूल से करते हैं? जिसके लिए इसका जवाब सिर्फ इसलिए है क्योंकि वहां मौजूद है । यूनिक्स दर्शन "एक काम करो, और इसे अच्छी तरह से करो" बताता है कि यह * प्रदान करने के लिए संकलक की जिम्मेदारी नहीं है। उस ने कहा, मैं व्यक्तिगत रूप से अपने हिस्से को सिरदर्द बनाने के माध्यम से रहा हूं, और एक संकलक की कोशिश करने के लिए इच्छुक होगा, जो इसे स्वयं-बोली "मूल" बिल्ड सिस्टम प्रदान करता है।

इस तरह से तैयार किए गए एक कंपाइलर के उदाहरण के लिए, जॉन ब्लो (जैसा कि अभी तक अप्रकाशित) जय, सी ++ प्रतिस्थापन के रूप में अभिप्रेत भाषा देखें। संकलक की बातचीत और डेमो के लिंक यहां एकत्र किए गए हैं । यह भाषा बाइट-कोड को संकलित करती है जो संकलक के भीतर चलती है, बाइनरी के संकलन के साथ एक मानक लाइब्रेरी प्रदान की जाती है जो बाइट-कोड से सुलभ होती है। इरादा भाषा के मूल सिंटैक्स के भीतर निर्माण स्वचालन और मेटा-प्रोग्रामिंग दोनों के लिए अनुमति देता है।

_{* माइक्रोसॉफ्ट के विजुअल स्टूडियो पर एक नज़र आपको विपरीत दर्शन का एक उदाहरण दिखाएगा। :)}

— हेडन की सीडी।
स्रोत

2

बिल्ड टूल सबसे पहले और एक टूल है, जैसे 'gcc', 'ls', 'awk' या 'gz'। आप उपकरण को एक इनपुट (फ़ाइल नाम, पैरामीटर, आदि) खिलाते हैं और यह तदनुसार कुछ सामान करेगा।

ये सभी उपकरण आपको अपने इनपुट को उन तरीकों से पारित करने की अनुमति देते हैं जो लिखने और समझने के लिए पर्याप्त सरल होना चाहिए। बिल्ड टूल्स के विशेष मामले में, इनपुट एक रेसिपी फाइल है, एक फाइल जो यह बताती है कि आपका प्रोजेक्ट सोर्स फाइल से तैयार उत्पाद तक कैसे जाता है।

यदि आपका नुस्खा उस फ़ोल्डर में पास होने के समान सरल है जिसमें परियोजना और संकलक का उपयोग करना है, तो एक घोषणात्मक "भाषा" पर्याप्त है। एक बार जब नुस्खा अधिक से अधिक जटिल हो जाता है, तो अधिक तर्क के साथ, इसे घोषणात्मक भाषाओं के साथ संभालना मुश्किल हो जाता है और अधिक सामान्य प्रयोजन भाषाओं का उपयोग किया जाता है।

अब यह स्पष्ट होना चाहिए कि आपके बिल्ड व्यंजनों को लिखने के लिए उपयोग की जाने वाली भाषा और आपके उत्पाद कोड लिखने के लिए उपयोग की जाने वाली भाषाओं के बीच कोई संबंध नहीं है, क्योंकि उनके पास अलग-अलग उद्देश्य और आवश्यकताएं हैं। निर्माण उपकरण में लिखी गई भाषा के बीच भी कोई संबंध नहीं है और "भाषा" में निर्मित व्यंजनों को लिखा जाना चाहिए। हमेशा नौकरी के लिए सबसे अच्छा उपकरण का उपयोग करें!

— Tibos
स्रोत