मुझे एक उपकरण के लिए एक डोमेन विशिष्ट भाषा को लागू करने का काम सौंपा गया है जो कंपनी के लिए काफी महत्वपूर्ण हो सकता है। भाषा सरल है, लेकिन तुच्छ नहीं है, यह पहले से ही नेस्टेड छोरों, स्ट्रिंग संघनन, आदि की अनुमति देता है और यह व्यावहारिक रूप से सुनिश्चित है कि अन्य निर्माणों को परियोजना अग्रिम के रूप में जोड़ा जाएगा।
मैं अनुभव से जानता हूं कि व्याकरण को तुच्छ समझने के लिए हाथ से शब्द / परसर लिखना एक समय लेने वाली और त्रुटि प्रवण प्रक्रिया है। इसलिए मुझे दो विकल्पों के साथ छोड़ दिया गया: एक पार्सर जनरेटर आ ला याक या पारसेक जैसे एक कॉम्बिनेटर पुस्तकालय। पहले भी अच्छा था, लेकिन मैंने विभिन्न कारणों से उत्तरार्द्ध चुना, और एक कार्यात्मक भाषा में समाधान लागू किया।
परिणाम मेरी आँखों के लिए बहुत शानदार है, कोड बहुत संक्षिप्त, सुरुचिपूर्ण और पठनीय / धाराप्रवाह है। मैं मानता हूं कि यह थोड़ा अजीब लग सकता है यदि आपने कभी भी जावा / सी # के अलावा किसी और चीज में प्रोग्राम नहीं किया है, लेकिन फिर यह जावा / सी # में नहीं लिखी गई किसी भी चीज के बारे में सच होगा।
कुछ बिंदु पर, मुझे सचमुच एक सहकर्मी द्वारा हमला किया गया है। मेरी स्क्रीन पर एक त्वरित नज़र के बाद उन्होंने घोषणा की कि कोड अप्रतिस्पर्धी है और मुझे पार्सिंग को फिर से नहीं करना चाहिए, लेकिन बस एक स्टैक का उपयोग करें और स्ट्रिंग करें। जैसा कि हर कोई करता है। उसने बहुत शोर मचाया, और मैं उसे मना नहीं कर सका, आंशिक रूप से क्योंकि मुझे आश्चर्य से लिया गया है और इसकी कोई स्पष्ट व्याख्या नहीं थी, आंशिक रूप से क्योंकि उसकी राय अपरिवर्तनीय थी (कोई भी दंडित इरादा नहीं)। मैंने उसे भाषा समझाने की भी पेशकश की, लेकिन कोई फायदा नहीं हुआ।
मैं सकारात्मक हूं कि चर्चा प्रबंधन के सामने फिर से जा रही है, इसलिए मैं कुछ ठोस तर्क तैयार कर रहा हूं।
ये पहले कुछ कारण हैं जो मेरे दिमाग में एक स्ट्रिंग से बचने के लिए आते हैं। समाधान आधारित समाधान:
- आपको विशेष मामलों और चीजों को नियंत्रण से बाहर सर्पिल करने के लिए बहुत सारे ifs की आवश्यकता होती है
- बहुत सारे हार्डकोड एरंड इंडेक्स रखरखाव को दर्दनाक बनाते हैं
- फंक्शन कॉल जैसी चीजों को विधि तर्क के रूप में संभालना बेहद कठिन है (उदाहरण के लिए। (a, b जोड़ें), c)
- वाक्यविन्यास त्रुटियों के मामले में सार्थक त्रुटि संदेश प्रदान करने के लिए बहुत मुश्किल है (ऐसा होने की संभावना है)
- मैं सभी सादगी, स्पष्टता और अनावश्यक स्मार्ट-गुप्त चीजों से बचने के लिए हूं, लेकिन मेरा मानना है कि यह कोडबेस के हर हिस्से को गूंगा करने के लिए एक गलती है, ताकि एक बर्गर फ्लिपर भी इसे समझ सके। यह वही तर्क है जो मैं इंटरफेस का उपयोग नहीं करने, चिंताओं को अलग करने, कोडिंग-पेस्टिंग कोड को अपनाने, आदि के लिए नहीं सुनता हूं। न्यूनतम तकनीकी योग्यता और सीखने की इच्छा के बाद सॉफ्टवेयर प्रोजेक्ट पर काम करना आवश्यक है। (मैं इस तर्क का उपयोग नहीं करूंगा क्योंकि यह संभवतः आक्रामक लगेगा, और युद्ध शुरू करना किसी की मदद करने वाला नहीं है)
Cthulhu रास्ता पार्स करने के खिलाफ आपके पसंदीदा तर्क क्या हैं ? *
* बेशक अगर आप मुझे समझा सकते हैं कि वह सही है तो मैं भी पूरी तरह से खुश रहूंगा