एक लंबे समय के लिए मैंने एक लेख लिखने का वादा किया कि हास्केल ने उत्पाद में वास्तविक कार्यों में खुद को कैसे दिखाया।

उन लोगों के लिए जो ट्रैक नहीं रखते थे - 2012 की शुरुआत में इसकी पैरवी की गई थी और सेलेक्ट में प्रोग्रामर्स ने उत्साहपूर्वक इसे शुरू किया। फिर मैंने "यह सब कैसे है" का उपयोग करने के बारे में एक रिपोर्ट प्रकाशित करने का वादा किया।

एक व्यावसायिक परियोजना में एक उत्पाद "स्वयं के लिए" एक छोटा सैंडबॉक्स नहीं है, कंप्यूटर विज्ञान में शैक्षणिक प्रयोग नहीं है। नरक, डरावनी और मृत्यु होने पर "पार्टी लाइन" के लिए यह एक अंतहीन संघर्ष है, लेकिन इसे वैसे भी काम करना चाहिए। XML-RPC में Int64 एक स्ट्रिंग के रूप में एन्कोड किया गया है (क्योंकि XML-RPC में इन्ट्स इंट 32 पर हस्ताक्षर किए गए हैं), Opensl जब एक फ़ाइल से कई प्रमाण पत्र पढ़ते हैं तो उनमें से पहला केवल पढ़ता है, बूल में आपको या तो "1" या "0" लिखना होगा, लेकिन कभी-कभी। - "2", क्योंकि यह केवल इस तरह से था कि वे एन्कोड करने के लिए तीसरे मोड के साथ आए थे - और इसी तरह। आदि इन स्थितियों में, भाषा की आवश्यकताएं धीरे-धीरे वास्तविक दुनिया के अनुकूल अपने पारिस्थितिकी तंत्र, बुनियादी ढांचे, तत्परता के लिए आवश्यकताओं में विकसित होती हैं।

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

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

उपभोक्ता गुणों के साथ शुरू करते हैं।

कार्यक्रम निष्पादन की गति

हास्केल कार्यक्रम अजगर, php, रूबी (और अन्य व्याख्या की गई भाषाओं) की तुलना में तेज़ हैं। Erlang / Java (और अन्य vm- आधारित भाषाओं) की तुलना में तेज़। यह आमतौर पर सी की तुलना में धीमा है, हालांकि मैंने कई मामलों को देखा है जहां हास्केल कंपाइलर ने परिणाम उत्पन्न किए जो सी कंपाइलर से बेहतर हैं।

हास्केल प्रदर्शन के सभी व्यावहारिक अनुप्रयोगों के लिए - आंखों के पीछे और कान के पीछे।

अजगर की तुलना में मुख्य लाभ (जिससे हम धीरे-धीरे चले गए) निष्पादन की अपनी उत्कृष्ट समानता है। कोई GIL नहीं, कोई "श्रमिकों के बीच बाहरी बैलेन्स" नहीं, डिबगिंग हेंट के साथ कोई नरक नहीं।

हास्केल में पूर्णकालिक ग्रीनलेट्स और ऑपरेटिंग सिस्टम थ्रेड्स का मूल उपयोग है।

निष्पादन योग्य फ़ाइल आकार

सबसे अधिक बार, यह परवाह नहीं करता है, लेकिन कुछ स्थानों में हमारे कॉन्फ़िगरेशन में यह भीड़ थी - और 22 एमबी में निष्पादन योग्य का न्यूनतम आकार कष्टप्रद था। जब "तंग जगहों" को हल किया गया था, तो आकार किसी भी ठोस भूमिका निभाने के लिए बंद हो गया। हमारा सबसे बड़ा सर्वर 44MB पर कब्जा कर लेता है और गतिशील रूप से तीन दर्जन लिंक करता है।

मेमोरी का उपयोग

(इस खंड में, हम 'संसाधनों' के बारे में बात कर रहे हैं, अर्थात्, मेमोरी जिसमें डेटा संग्रहीत है, कोड नहीं, शीर्ष में यह RES स्तंभ से मेल खाती है)।

कंप्यूटर एल्गोरिदम में, प्रयुक्त मेमोरी की गणना आमतौर पर ओ-नोटेशन में की जाती है, लेकिन एक महत्वपूर्ण कारक है - अगर कई प्रक्रियाएं हैं, और उनमें से प्रत्येक ओ (1) है, तो सर्वर पर कितनी मेमोरी खाए जाएंगे? वही "प्लेबीयन कॉन्स्टेंट", अचानक एक भूमिका निभाने लगते हैं।

हस्केल, अजगर कार्यक्रमों के लिए तुलनीय स्मृति का उपयोग करता है। दानव (उनमें से एक हिस्सा जो डेटा की एक महत्वपूर्ण राशि को संग्रहीत नहीं करता है) 9 से 20 मेगाबाइट तक कब्जा कर लेता है। अजगर दानव उसी के बारे में हैं।

मुझे कहना होगा कि इस पैरामीटर में हास्केल ओमेक्एल से थोड़ा कम है (इसके लिए, मुकाबला सेवाएं 1-2 मेगाबाइट मेमोरी के साथ रह सकती हैं), और, निश्चित रूप से, सी (उदाहरण के लिए, modd केवल 0.15 एमबी खाती है), लेकिन जावा / एरलैंग के साथ स्थिति से बेहतर है ।

वास्तविक निष्पादन

अधिकांश आरामदायक सॉफ़्टवेयर वातावरण (jvm, python, bea.smp, ​​php, perl, .net, आदि) के लिए काफी बुनियादी सुविधाओं की आवश्यकता होती है (एक दुभाषिया / आभासी मशीन को चलाने, सही स्थानों पर फाइलों का एक गुच्छा, आदि)। जब आप एक प्रोग्राम लिखते हैं जो "उपयोगकर्ता से दो नंबर प्राप्त करता है, तो उन्हें डेटाबेस में लिखता है और परियोजना प्रशासक को उनकी राशि दिखाता है", सब कुछ ठीक है।

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

हास्केल एक निष्पादन योग्य फ़ाइल उत्पन्न करता है। वास्तविक ईएलएफ। जो स्थिर या गतिशील हो सकता है। और यह बहुत अच्छा है।

दूसरा महत्वपूर्ण कारक: स्टार्टअप की गति। कई मामलों में, कार्यक्रम शुरू होता है और समाप्त होता है। अजगर (और कई अन्य व्याख्या की गई भाषाओं) में, 100500 अलग-अलग फाइलें स्टार्टअप पर स्कैन की जाती हैं, विशेष रूप से आयातों के एक समूह के साथ, जिससे स्टार्टअप पर 100-200 एमएस की देरी होती है। हास्केल में, यह मान बहुत छोटा है, क्योंकि ld अजगर या PHP की तुलना में कई गुना तेजी से काम करता है।

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

यह एक माइनस है: 32/64 बिट्स, अचानक, विभिन्न निष्पादन योग्य फाइलें हैं, और libffi5 या libffi6 पहले से ही एक बड़ा अंतर है जो किसी विशेष वितरण के लिए "क्रॉस-अनुकूलता" अनुप्रयोगों के साथ हस्तक्षेप करता है, या यहां तक ​​कि उसी के विभिन्न संस्करण भी वितरण किट।

निगरानी

चूंकि हास्केल कार्यक्रम ऑपरेटिंग सिस्टम के लिए "मूल" है, इसलिए कोई विशेष निगरानी विशेषताएं नहीं हैं (तुलना के लिए, जावा मशीन के अपने संकेतक हैं, जिन्हें हमें मॉनिटर करने की आवश्यकता है, एर्लांग का अपना है)।

कोड की गुणवत्ता

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

बेवकूफ गलतियों की संभावना बहुत कम है। और जब मैं कहता हूं "महत्वपूर्ण रूप से", यह सिद्धांत में नहीं है, लेकिन व्यवहार में है, अर्थात, एक ही उत्पाद का अवलोकन करके, ज्यादातर लोगों द्वारा हास्केल और पायथन में लिखा गया है।

पायथन, किसी भी अन्य गतिशील रूप से टाइप की गई भाषा की तरह, एक निरंतर समय बम है। सभी बुरी स्थितियों को स्पष्ट रूप से समझा जाना चाहिए, साथ ही साथ कोई भी छोटी-मोटी स्थानीय त्रुटियों या लापरवाही के खिलाफ नहीं। त्रुटियां या तो रनटाइम में दिखाई देती हैं, या उन्हें या तो एक निहित में छिपाया जा सकता है: पास (जो और भी बदतर है)। ऑब्जेक्ट 'टाइप टाइप' की कोई विधि नहीं है - बस इतना ही। और अगर यह त्रुटि एक दुर्लभ शाखा में होती है, तो खदान पूरी तरह से धीमी हो जाती है और जब कोड लंबे समय से "स्थिर और खुद को अच्छी तरह से दिखा रहा है" तो आग लग जाती है, और सामान्य तौर पर, 300 दिनों का अपटाइम।

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

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

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

यह एक विरोधाभासी निष्कर्ष की ओर जाता है: गतिशील टाइपिंग वाली भाषाओं की तुलना में हास्केल में एक कार्यक्रम में बग को ठीक करना अधिक कठिन है, क्योंकि गतिशील टाइपिंग वाली भाषा में, अगली जगह जहां कोई भी अचानक क्रॉल किया गया था, उसे सही किया गया था, और हास्केल के साथ, आपको एल्गोरिथ्म से निपटना होगा हाँ अन्य लोगों के शपथ ग्रहण के साथ टीके की स्पष्टता की कमी।

पुस्तकालय की परिपक्वता

वैक्यूम कार्यक्रमों में गोलाकार केवल गोलाकार स्थितियों में और वैक्यूम में काम करते हैं। बाकी सभी वास्तविक दुनिया में काम करते हैं, जहां लाखों जटिल प्रारूप, विनिर्देश और प्रोटोकॉल हैं। यानी पुस्तकालयों की जरूरत है। उनमें से हजारों।

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

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

संकलन की गति

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

ट्रैकिंग में कठिनाई

रखरखाव प्रासंगिक छोटे परिवर्तनों का परिचय है, "क्या गलत है," संक्षेप में, एक जीवित "स्वयं" परियोजना की दिनचर्या।

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

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

श्रम बाजार में प्रोग्रामर की ज्ञात कमी के संदर्भ में, यह एक बाधा है। दूसरी ओर, ऐसी चीजों की उपस्थिति प्रोग्रामर को आकर्षित करती है जो "php + js" से थक चुके हैं, यहाँ से दोपहर तक।

विकास की गति

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

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

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