सिंटैक्टिक शुगर के खतरे

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

यहां की स्थिति उन सड़कों के बारे में एक मजाक की तरह है जिसमें अमेरिकी दावा करते हैं:
- जब मैं सड़क पर ड्राइव करता हूं, तो मैं हुड पर एक गिलास पानी डालता हूं और 100 किमी / घंटा की गति से ड्राइव करता हूं। पानी की एक भी बूंद नहीं छलकती।
रूसी क्या कहता है:
- और हम सभी पीछे की सीट पर चढ़ गए और पूरे रास्ते कार्ड काट दिए, लेकिन हमने बीयर पी।
- और मशीन को कौन नियंत्रित करता है ?!
- लेकिन वह कहाँ जा रहा है?

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

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

var names = [];
for ( var i = 0 , l = fields.length; i < l; i ++ ) {
names.push(fields[i].name);
}


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

var names = fields.map( function (field) {
return field.name;
});


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

names = [field . name for field in fields]


एक लाइन! ऐसा लगता है कि हम आदर्श तक पहुंच गए हैं, लेकिन वास्तव में यह विकल्प कुछ मायनों में पिछले एक से भी बदतर है: इसका विस्तार करना मुश्किल है और इसका पुन: उपयोग करना लगभग असंभव है। सच? आइए, कोशिश करें कि मान लें कि हमें कभी-कभी फ़ील्ड नामों से पहले तालिका के लिए एक उपनाम देने की आवश्यकता है:

names = [ " %s . %s " % (alias, field . name) if alias
else field . name for field in fields]


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

if alias:
names = [ " %s . %s " % (alias, field . name) for field in fields]
else :
names = [field . name for field in fields]


स्पष्टता लौट आई, लेकिन दोहराव दिखाई दिया। यह कोई संयोग नहीं है कि सूची अभिव्यक्तियाँ जिनका उपयोग हम एकल वाक्य रचना संरचना में लिंक का उपयोग करते हैं, एक रन और एक अलग तत्व पर एक ऑपरेशन के लिए करते हैं। कोई समस्या नहीं है, बस एक सूची अभिव्यक्ति बनी रहनी चाहिए:

if alias:
get_name = lambda field: " %s . %s " % (alias, field . name)
else :
get_name = lambda field: field . name
names = map (get_name, fields)


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

इसलिए, मैं लूप और पाइथोनिक सूची अभिव्यक्तियों के लिए "निपटा" रहा हूं, यह आगे बढ़ने का समय है। क्या आप किसी वस्तु के गुणों को डॉट के माध्यम से एक्सेस करना पसंद करते हैं? मेरे लिए - बहुत, यह संक्षिप्त है (केवल वस्तु को छोड़कर और आवश्यक संपत्ति केवल एक छोटी सी डॉट है) और अभिव्यंजक (यहां तक ​​कि वस्तुओं से दूर एक व्यक्ति आसानी से समझ जाएगा कि नमक क्या है)। यह इतना सुविधाजनक है कि हम विकल्पों के बारे में नहीं सोचते हैं, और एक ही अजगर में एक वस्तु की विशेषता प्राप्त करने के तीन तरीके हैं (__getattr__, आदि के लिए प्रत्यक्ष पहुंच) जो कुछ भी मौलिक रूप से नया नहीं देता है:

obj . name
getattr (obj, "name" )
operator . attrgetter( "name" )(obj)


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

from operator import attrgetter
names = map (attrgetter( "name" ), fields)


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

PS मैं जावास्क्रिप्ट में ORM नहीं लिखता।
PPS मैं ORM को या तो python में नहीं लिखता, हालांकि कई बार मैं ORM Django में तल्लीन हो जाता हूं।
पीपीपीएस एक प्रैक्टिकल कॉमन लिस्प पढ़ते हुए यहां प्रस्तुत एक विचित्र विचार मेरे सामने आया। जो लोग नहीं जानते हैं, उनके लिए लिस्प कार्यक्रम नेस्टेड सूचियों का एक समूह है, जिनमें से प्रत्येक में एक "क्या करना है" (फ़ंक्शन नाम, ऑपरेटर या मैक्रो) और बाद के तर्क हैं, अर्थात्। स्वयं के वाक्यविन्यास वृक्ष का प्रतिनिधित्व करता है। दूसरे शब्दों में, लिस्प में कोई सिंटैक्स नहीं है। और अजीब तरह से, यह उस पर कार्यक्रमों को आश्चर्यजनक रूप से लचीला बनाता है।

अद्यतन। अधिकांश आपत्तियों का जवाब देने के लिए, मैं थोड़ा अलग आता हूं। ध्यान दें कि नक्शा (), जो मैं अंततः उपयोग करता हूं, एक काफी उच्च-स्तरीय अमूर्तता भी है। वास्तव में, मेरे द्वारा उपयोग किए गए सार को एक पदानुक्रम में व्यवस्थित किया जा सकता है:
अनुक्रमणिका के लिए + सार = के लिए सी-शैली
प्रत्येक पुनरावृत्ति = नक्शे पर में + वापसी परिणाम
map + लंबदा = सूची अभिव्यक्ति।

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

संक्षेप में:
1. भाषा में एक विशिष्ट वाक्यविन्यास की कमी के कारण अधिक लचीले कोड लिखना पड़ता है।
2. यह अधिक लचीला कोड निचले स्तर का होगा।

पहले के लिए दूसरा शुल्क,

from operator import attrgetter
names = map (attrgetter( "name" ), fields)


- समय से पहले सामान्यीकरण, अगर हमारे पास एक बिंदु है।