जावा का निर्माण भाषा के रूप में क्यों नहीं किया जाता है?

Question

यदि जावा एक सामान्य प्रयोजन की भाषा है, और एक प्रोग्राम का निर्माण कुछ ऐसी चीज है जिसे जावा भाषा का उपयोग करके वर्णित किया जा सकता है, तो बिल्ड फ़ाइलों को लिखने का यह सबसे अच्छा तरीका क्यों नहीं है और इसके बजाय हम चींटी, मावेन और ग्रैडल जैसे उपकरणों का उपयोग करते हैं? क्या यह अधिक सीधा नहीं होगा, और एक और प्रोग्रामिंग भाषा सीखने की आवश्यकता को भी दूर करेगा? (BTW - यह प्रश्न अन्य भाषाओं पर भी लागू हो सकता है, जैसे C #)

Comments

आपके पास एक प्रश्न का थोड़ा और दिलचस्प हो सकता है कि "सामान्य प्रयोजन की भाषाओं का निर्माण भाषाओं के लिए क्यों नहीं किया जाता है" - मेरा मतलब है, सी एक निर्मित भाषा भी नहीं है। मैं जावा में एक एकल

इसे संभवतः "डीएसएल से परेशान क्यों?" के रूप में सामान्यीकृत किया जा सकता है।

— FrustratedWithFormsDesigner

एक बेहतर सवाल हो सकता है; आईडीई / कंपाइलर / टूल इतने खराब क्यों हैं कि पहली जगह में उपकरण बनाने की जरूरत होती है।

— ब्रेंडन

@ बेंडन जो एक गैर-प्रश्न है, जैसे कि निर्माण उपकरण और आईडीई विभिन्न उद्देश्यों की पूर्ति करते हैं।

— jwenting

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

— एसके-तर्क

Answer 1

एक विशिष्ट उद्देश्य के लिए विशिष्ट उपकरण

• शब्दाडंबर

  सामान्य प्रयोजन की भाषाएं अक्सर बहुत अधिक होती हैं। अगर मुझे जावा में एक बिल्ड का प्रबंधन करना था, तो मैं जानवर के आकार से बहुत जल्दी उदास हो जाऊंगा। हालाँकि, जावा में लिखे गए DSL का उपयोग करके इसे आसानी से प्रबंधित किया जा सकता है। और कुछ हद तक आप ग्रैडल (ग्रूवी के लिए) और बिल्डर (रूबी के लिए) देख सकते हैं।

• कठिनाई

  सामान्य प्रयोजन की भाषाएँ कठिन हैं। वैसे मुझे नहीं लगता कि प्रोग्रामिंग कठिन है और इसे किसी के द्वारा नहीं उठाया जा सकता है, लेकिन मुद्दा यह है: आपका बिल्ड इंजीनियर जरूरी आपके प्रोग्रामर नहीं है!

• उद्देश्य

  यह कठिनाई और वाचालता के चौराहे पर कमोबेश है । एक भाषा एक उद्देश्य के लिए डिज़ाइन की गई है, और यहाँ हम कुछ विशिष्ट के बारे में बात कर रहे हैं। तो आपको एक सामान्य प्रयोजन की भाषा का उपयोग करने की आवश्यकता क्यों होगी ? बिल्ड के लिए, आपको चाहिए:

  • शाखाएँ और सशर्त अलग-अलग विन्यास, वातावरण, आदि को संभालने के लिए ...
  • अपने वातावरण से डेटा निकालने के लिए निर्देशों का एक सेट,
  • सुपुर्दगी का उत्पादन करने के लिए निर्देशों का एक सेट।

  आपको वास्तव में बहुत अधिक की आवश्यकता नहीं है।

सुनिश्चित करें कि जब आपका निर्माण सिस्टम ऐसा लगता है कि आपके लिए एक विशेष उपयोग के मामले के लिए पर्याप्त लचीला नहीं है, तो यह कष्टप्रद है, लेकिन यह ज्यादातर लोगों के लिए विकल्प से कहीं बेहतर है।

शायद इसीलिए ऐसे लोगों के बीच एक ध्रुवीयता है जो ज्यादातर प्रोग्राम करने योग्य प्याज पर घोषणात्मक बिल्ड सिस्टम पसंद करते हैं: मुझे लगता है कि एक डेवलपर को बॉक्स से बाहर निकलने के तरीकों की तलाश करने की स्वाभाविक प्रवृत्ति हो सकती है।

रुको, क्या हमें वास्तव में एक उपकरण की आवश्यकता है?

एक और संबंधित प्रश्न होगा: क्या हमें वास्तव में एक बिल्ड टूल की आवश्यकता है? क्या यह तथ्य नहीं है कि वे सभी भाषाओं में मौजूद हैं कि वे एक अंतर भरते हैं जो पहली जगह में भी नहीं होना चाहिए?

कुछ भाषाओं के लिए एक निर्माण उपकरण की आवश्यकता नहीं होती है। उदाहरण के लिए, अधिकांश स्क्रिप्टिंग भाषाओं को लोड समय पर एक और समाधान की आवश्यकता नहीं होती है। या ले जाओ, जिसका कंपाइलर आपके लिए सब कुछ संभाल लेगा, जो कि एक अच्छा काउंटरपॉइंट है: क्या होगा अगर जीसीएल जैसे कंपाइलर को अचानक झंडे, लिंकर और सब कुछ एक साथ मरने के लिए मेकअप की जरूरत नहीं है? या अगर javac को एक बिल्ड.xml या pom.xml की जरूरत नहीं है, तो उसे बताएं कि क्या करना है? क्या निर्भरता प्रबंधन सीधे भाषा की अपनी टूलिंग का हिस्सा नहीं होना चाहिए, क्योंकि निर्भरता अंतिम कार्यक्रम का एक हिस्सा है?

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

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

---

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

यह एक बिल्ड टूल है। बस इसे गले लगाना सीखो और इससे लड़ो मत। यह एक हारी हुई लड़ाई है। या कम से कम बहुत बहुत लंबा है।

Comments

वास्तव में आपकी व्यावहारिकता की तरह। मेरा प्रश्न जिज्ञासा से बाहर है। मैं मावेन का उपयोग करता हूं (अतीत में मेक और चींटी का उपयोग करता था), और यह "काला जादू" करता है जो कभी अच्छा और कभी बुरा होता है। लेकिन यह अभी भी जादू है।

— vainolo

"या अगर javac को एक बिल्ड.xml या pom.xml की आवश्यकता नहीं थी, तो उसे बताएं कि क्या करना है?" - हेह। यह नहीं किया और कभी नहीं किया।

— user253751

@ मिनीबिस: यह बहस का मुद्दा है। मैं वास्तव में केवल javac के साथ कार्यालय में अपनी परियोजनाओं के निर्माण का आनंद नहीं लेगा :) यह निश्चित रूप से एक मेकफाइल या एक शेल स्क्रिप्ट के साथ या बहुत कम शेल उपनामों के साथ चीजों को एक साथ रखने के लिए उचित गोंद की आवश्यकता होगी। या एक फ़ोल्डर में सब कुछ के साथ एक विशाल कार्यक्रम और रेपो में सभी डिपो। वास्तव में ऐसा कुछ नहीं जो मुझे पसंद हो! :) लेकिन यह पूरी तरह से एक और बहस है, ओपी के सवाल से संबंधित नहीं है।

— जाइल

बहुभाषाविद परियोजनाओं के लिए भाषा के साथ निर्माण प्रणाली को एकीकृत करना भी समस्याग्रस्त है। अगर मैं भाषा ए और बी दोनों का उपयोग करता हूं और उनके लिए एक एकल निर्माण प्रक्रिया चाहता हूं, तो मैं किस भाषा की निर्माण प्रणाली का उपयोग करता हूं?

— सेबेस्टियन रेडल

@SebastianRedl तो तीसरी भाषा शुरू करने से समस्या कैसे आसान हो जाती है ? सिर्फ वही भाषा चुनें जो आपके लिए बेहतर काम करे। (और निश्चित रूप से, अगर आपको तीसरी भाषा की आवश्यकता है, तो जावा भी हो सकता है।)

— विले ओइकारिनन

Answer 2

Javaहै एक अनिवार्य भाषा, Ant, Maven, आदि कर रहे हैं कथात्मक भाषाओं:

हम अंतर को इस प्रकार परिभाषित कर सकते हैं:

• इम्पीरेटिव प्रोग्रामिंग: "मशीन" को बताना कि कुछ कैसे करना है, और परिणामस्वरूप आप जो होना चाहते हैं वह होगा।
• घोषणात्मक प्रोग्रामिंग: "मशीन" को बताना कि आप क्या करना चाहते हैं, और कंप्यूटर को यह पता लगाने दें कि यह कैसे करना है। ¹

बिल्ड लैंग्वेज बिल्डर को बताती है कि उसे क्या करना चाहिए, कहाँ से लिया जाना चाहिए, आदि। इंजन जो बिल्ड को चलाता है (जो कि अनिवार्य भाषा में लिखा गया है, जैसे @ElliottFrisch ने नोट किया है), इन निर्देशों को पढ़ता है, और उन्हें पूरा करता है।

बिल्ड परिदृश्यों में घोषणात्मक भाषाएँ अधिक उपयुक्त लग सकती हैं, क्योंकि निर्माण कार्य आम तौर पर सभी पर समान होते हैं, और यह पूर्ण रूप से कोड फ़ॉर्म की तुलना में उस रूप में अधिक बनाए रखने योग्य और पठनीय माना जाता है।

Comments

कम से कम एक बिल्ड सिस्टम है जो एक अनिवार्य भाषा का उपयोग करता है। पॉनथन का उपयोग करता है।

— user16764

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

@Lee: लगभग सभी निर्माण उपकरण जावा दुनिया में इस्तेमाल किया (चींटी, Maven, Gradle, एसबीटी, ...) भी आम तौर पर (रैक, Buildr या SCons के अपवाद हैं, जिसके साथ JVM पर चलाने के कर सकते हैं , लेकिन नहीं है है करने के लिए JVM पर चलने)।

— जोर्ग डब्ल्यू मित्तग

@vainolo "ज्यादातर लोग वास्तव में चींटी / मावेन / मेक" पसंद नहीं करते हैं? यह एक साहसिक बयान है!

— बेन थर्ले

@BenThurley मैं लोगों को बनाना पसंद था, तो चींटी क्यों बनाई गई? और अगर चींटी को पसंद किया गया था, तो मावेन क्यों था? और अब लोग ग्रैडल का उपयोग क्यों कर रहे हैं? लेकिन मैं मानता हूँ कि यह एक साहसिक कथन है, और यह केवल जावा डेवलपर्स के कुछ दसियों के "उपाख्यान" साक्ष्य द्वारा समर्थित है

— vainolo

Answer 3

यदि आप एक विशिष्ट बिल्ड सिस्टम की विशेषताओं को देखते हैं जो आप पाते हैं:

1. डेटा के बहुत सारे: नाम, स्विच, सेटिंग्स, कॉन्फ़िगरेशन आइटम, स्ट्रिंग्स, आदि
2. पर्यावरण के साथ बातचीत के बहुत सारे: आदेश, पर्यावरण चर
3. एक अपेक्षाकृत सीधा "निर्माण इंजन" निर्भरता से निपटने, सूत्रण, लॉगिंग आदि।

यदि आप कुछ भाषा (जावा / सी # / पायथन / आदि) का उपयोग करके बिल्ड फ़ाइलों की एक श्रृंखला लिखने के लिए निर्धारित करते हैं, तो तीसरे या चौथे पुनरावृत्ति के बारे में आप (क) अधिकांश डेटा और बाहरी आदेशों को किसी चीज़ में डेटा के रूप में रखते हैं। XML की तरह (b) अपनी पसंदीदा भाषा में "build engine" लिखना।

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

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

Answer 4

इन मामलों में जावा / सी ++ / सी # का उपयोग करने के खिलाफ कई कारकों की गणना होती है।

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

दूसरे, बिल्ड फाइलें डेटा भारी होती हैं जबकि Java / C ++ / C # बहुत अधिक कोड और एल्गोरिदम लिखने की दिशा में सक्षम होते हैं। जावा और दोस्तों के पास आपके द्वारा संग्रहीत सभी डेटा का बहुत ही संक्षिप्त प्रतिनिधित्व नहीं है।

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

Answer 5

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

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

अस्वीकरण : इस उत्तर में मैं इवांट को बढ़ावा दे रहा हूं , एक निर्माण प्रणाली जिसे मैं विकसित कर रहा हूं। लेकिन जब से यह एक राय चर्चा है, मुझे यकीन है कि यह ठीक है।

मैं विशेष रूप से जावा (शक्ति और अभिव्यक्ति) या iwant के लाभों के बारे में विस्तार से नहीं बताऊंगा। यदि आप रुचि रखते हैं, तो आप iwant पृष्ठ पर अधिक पढ़ सकते हैं ।

इसके बजाय मैं इस बात पर विचार करूंगा कि जावा (और अन्य जीपीएल) को निर्माण के लिए अनुपयुक्त के रूप में इतनी आसानी से खारिज क्यों किया जाता है। यहाँ कई उत्तर और टिप्पणियाँ ऐसी सोच के अच्छे उदाहरण हैं। आइए कुछ विशिष्ट तर्कों पर विचार करें:

"जावा अनिवार्य है, लेकिन निर्माणों को एक घोषणात्मक तरीके से परिभाषित किया जाता है" , वे कह सकते हैं।

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

JacocoTargetsOfJavaModules.with()
    .jacocoWithDeps(jacoco(), modules.asmAll.mainArtifact())
    .antJars(TestedIwantDependencies.antJar(),
            TestedIwantDependencies.antLauncherJar())
    .modules(interestingModules).end().jacocoReport(name)

यह इवांट के डेमो प्रोजेक्ट का एक वास्तविक उदाहरण है ।

वास्तव में, इसकी तुलना कुछ कथित रूप से घोषित निर्माण प्रणालियों से की जाती है जो अपने उपयोगकर्ताओं को "परीक्षण" या "संकलन" के रूप में ऐसी अनिवार्य क्रियाओं के लिए उजागर करते हैं। उपरोक्त घोषणा में केवल संज्ञाएं हैं, कोई क्रिया नहीं। संकलन और परीक्षण वे कार्य हैं, जो उपयोगकर्ता द्वारा उन संज्ञाओं को प्रदान करने के लिए iwant द्वारा संकलित किए गए हैं जो वह चाहता है। यह भाषा नहीं है। यह है कि आप इसका उपयोग कैसे करते हैं।

"जावा क्रिया है"

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

एक्सएमएल में लिखे गए उपरोक्त जावा स्निपेट की कल्पना करें। कोष्ठक को कोष्ठक से बदलें और उन्हें चारों ओर घुमाएँ। और फिर हर कीवर्ड को एक समापन टैग के रूप में डुप्लिकेट करें ! एक के रूप में जावा वाक्य रचना है नहीं वर्बोज़।

(मुझे पता है, एक्सएमएल की तुलना एक बच्चे से कैंडी लेने के समान है, लेकिन इतने सारे बिल्ड सिर्फ एक्सएमएल में परिभाषित होने के लिए होते हैं।)

"आपको अपनी बिल्ड स्क्रिप्ट संकलित करनी होगी"

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

"जावा में बॉयलरप्लेट है"

सच। आपको कक्षाएं आयात करनी होंगी, आपको "सार्वजनिक", "वर्ग" और इसी तरह का उल्लेख करना होगा। और यहां सरल बाहरी DSLs एक प्रारंभिक आसान जीत दर्ज करते हैं।

और अगर आपकी परियोजना इतनी तुच्छ है कि यह बॉयलरप्लेट महत्वपूर्ण है, बधाई हो। आपकी समस्या कठिन नहीं है और यह वास्तव में मायने नहीं रखता कि आप इसे कैसे हल करते हैं।

लेकिन कई परियोजनाओं को संकलन, कवरेज रिपोर्ट और पैकेजिंग की तुलना में बहुत अधिक की आवश्यकता है। यदि जावा का बॉयलरप्लेट ग्राहकों की समस्याओं के लिए स्वीकार्य है, तो समस्याओं का निर्माण क्यों नहीं किया जाता है? केवल दूसरों के बच्चों के लिए जूते क्यों बनाते हैं?

Answer 6

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

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

Comments

इसमें ग्रैडल कैसे फिट होता है? यह एक सामान्य उद्देश्य भाषा (ग्रूवी) का उपयोग करते हुए, एक घोषणात्मक शैली में निर्भरता को परिभाषित करता है। एक ग्रूवी, जावास्क्रिप्ट या लिस्प आधारित टूल में, भाषा के संकलक या व्याख्याकार का उपयोग पार्स घोषणाओं के लिए किया जाता है, चाहे आप उन्हें पढ़ना चाहते हैं या उन्हें निष्पादित करना चाहते हैं (कुछ फ़ंक्शन लागू करें)। कोड और डेटा का यह द्वंद्व आमतौर पर स्वीकृत जावा मुहावरे का हिस्सा नहीं है, हालांकि यह असंभव नहीं है। ट्यूरिंग पूर्णता अच्छे डेटा प्रतिनिधित्व को नहीं रोकती है। यह संभावना को खोलता है कि आपका डेटा कुछ ऐसा करेगा जिसकी आपको अपेक्षा नहीं थी।

— joshp

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

— जिम्मीजम्स

व्यक्तिगत रूप से मुझे भी सकर्मक निर्भरता पसंद नहीं है। अक्सर वे सिर्फ क्लासपाथ (पुस्तकालयों के कई असंगत संस्करण) में आश्चर्य का कारण बनते हैं। यही कारण है कि मावेन में बहिष्कृत तत्व होता है, लेकिन परेशानी केवल इसके लायक नहीं है। स्पष्ट निर्भरताएं जीवन को सरल बनाती हैं। फिर भी, जावा के साथ सकर्मक निर्भरता को लागू किया जा सकता है। मैंने अन्य परियोजनाओं की निर्माण परिभाषाओं का पुन: उपयोग करके iwant के साथ ऐसा कुछ किया है ।

— विले ओकारिनेन

@VilleOikarinen मैं आपके साथ ज्यादातर सहमत हूँ। मुझे लगता है कि यह भी ब्लोट की एक टन का कारण बनता है क्योंकि अधिक निर्भरता में खींचने की कोई कथित लागत नहीं है, भले ही आप उनका उपयोग न करें। हालांकि, इस उत्तर के संदर्भ में, मैं उस सुविधा के मूल्य या ज्ञान पर टिप्पणी नहीं कर रहा हूं, लेकिन इस पर डीएसएल का उपयोग कैसे होता है।

— जिमीजैम

@VilleOikarinen मुझे लगता है कि हम इस तरह के अंत तक पहुँच चुके हैं लेकिन मैं केवल यह स्पष्ट करना चाहता हूँ कि मैं pom / maven के बारे में बात नहीं कर रहा हूँ। यह एक बिल्ड डीएसएल का एक उदाहरण है लेकिन मैं इसके बारे में ज्यादा नहीं सोचता। मैं इसे begrudgingly का उपयोग करता हूं और मुझे लगता है कि यह क्लंकी है। लेकिन जिस चीज में इतना दम है, वह निर्भरता की घोषणा है। मैं कुछ समय के लिए Buildr का उपयोग करता था और यह निर्भरता के लिए pom पढ़ता है, लेकिन यह उन्हें बिल्ड विनिर्देशों के लिए उपयोग नहीं करता है। ऐसे कई उपकरण हैं जो जावा आधारित नहीं हैं जो इस पोम को समझते हैं लेकिन AFAIK, वे सभी परवाह करते हैं जो निर्भरताएं हैं।

— जिम्मीजम्स