क्यों आदमी स्काला?

नमस्कार साथियों!

बहुत पहले नहीं, हमने स्केला 2.12 के बारे में ओडस्की, स्पून और वेनर्स की किताब छापी। आखिरकार, स्काला 3 अभी भी दूर है।


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


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



यही सवाल है!

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

तो चलिए एक कदम पीछे लेते हैं : आपको स्काला की आवश्यकता क्यों होगी? इस भाषा के साथ काम करने के तकनीकी और व्यावसायिक कारण क्या हैं?

परियोजना विषय क्षेत्र

शुरुआत के लिए, स्काला भाषा विशेष रूप से कुछ विषय क्षेत्रों के लिए अच्छी है (लेकिन हर किसी के लिए नहीं!)। Scala की सबसे महत्वपूर्ण संपत्ति सार को परिभाषित करने में इसका लचीलापन है । अपने निपटान में - इसके लिए सरल "ईंटों" की एक संख्या; कभी-कभी एक अमूर्तता को परिभाषित करना वर्ग, विधियों और लंबोदर अभिव्यक्तियों का उपयोग करने से अधिक कठिन नहीं होता है। कभी-कभी आपको एक अंतर्निहित पैरामीटर या विस्तार विधि का उपयोग करना पड़ता है; दुर्लभ मामलों में, यह केवल मैक्रो कमांड का सहारा लेने के लिए ही रहता है। हालांकि, वहाँ विकल्प हैं ।

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

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

भाषा कठिनाई

नोट: जब स्काला के बारे में बात की जाती है, तो हर कोई इस भाषा की संभावनाओं की चौड़ाई पर जोर देना पसंद करता है, इस बात पर जोर देते हुए कि इतनी बहुमुखी प्रतिभा के कारण, यह भाषा इतनी जटिल है। यह पूरी तरह सच नहीं है।

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

इस प्रकार, बुनियादी सुविधाओं की अपेक्षाकृत कम संख्या के साथ (स्काला व्याकरण का आकार कोटलिन, जावा या स्विफ्ट की तुलना में सरल है!) - जो बदले में, सीखने की सुविधा देता है - संयोजन विकल्प बहुत अधिक हैं।

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

जावा ही बेहतर

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

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

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

वर्ग प्रकार क्या हैं? उनकी भूमिका लगभग जावा में डिज़ाइन पैटर्न के समान है, हालांकि, जैसे ही आप उनके अर्थ को दृढ़ता से समझ लेते हैं, वे अधिक लचीले और उपयोग में आसान होते हैं। इस बारे में कुछ उत्कृष्ट गाइड हैं, जैसे 1 , 2 ।

प्रकार के निर्माणकर्ताओं के बारे में क्या? ये प्रकार हैं जैसे कि Future या Option , अन्य प्रकारों के लिए "कंटेनर" या "रैपर" के रूप में कार्य करना। तो, आपके पास Option[String] या Future[Int] । उच्च आदेश प्रकार आपको कोड लिखने की अनुमति देते हैं जो किसी भी आवरण को सार करता है। उदाहरण के लिए देखें। 1 , 2 ।

अचानक आप सोच रहे हैं, क्यों भी Future / Task सहारा? मुद्दा केवल यह नहीं है कि अधिकांश उच्च-प्रदर्शन "प्रतिक्रियाशील" गणना में न्यूनतम विलंब के साथ अतुल्यकालिक I / O का उपयोग किया जाता है, जिसके लिए बस ऐसे डिजाइनों का अनुरोध किया जाता है। रेडिट पर इस चर्चा में और मेरे लेख में अन्य कारण दिए गए हैं " रैपर से परेशान क्यों? "।

मुख्य रूप से अपरिवर्तित वातावरण में काम करना, साथ ही साथ Future , Promise या Task (और उन्हें अमूर्त!) जैसे निर्माणों को आसानी से संभालने की क्षमता आपके कोड को बदल देती है। पहली नज़र में, यह स्पष्ट नहीं हो सकता है: यदि आपके पास जावा या रूबी का अनुभव है, तो आप तुरंत स्काला के इन पहलुओं का एहसास नहीं कर पाएंगे। लेकिन, एक शैक्षिक दृष्टिकोण से भी, यह समझना उपयोगी है कि "कार्यात्मक" दृष्टिकोण कैसे काम करता है और, इससे भी महत्वपूर्ण बात यह है कि यह एक बहुत ही योग्य विकल्प क्यों बन सकता है।

स्वाभाविक रूप से, स्काला और कोटलिन दोनों के जावा पर कई सामान्य लाभ हैं, उदाहरण के लिए:

• अधिक कॉम्पैक्ट सिंटैक्स
• कम स्टीरियोटाइप्ड कोड
• एक अमीर प्रकार की प्रणाली
• भाषा की गिट्टी की कमी

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

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

एफपी बनाम ओओपी

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

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

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

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

स्काला 3

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

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

ये सक्रिय रूप से विकसित भाषा के साथ काम करने की लागतें हैं: आपको नवीनतम अवसर मिलते हैं, लेकिन उनमें से कुछ वास्तव में इतने अच्छे नहीं हैं और इसमें सुधार करने की आवश्यकता है। फिर भी, प्रस्तावित परिवर्तन क्रांतिकारी नहीं हैं। Scala 3 भाषा, Scala 2 से बहुत मिलती-जुलती है, इसमें किसी बड़े बदलाव की उम्मीद नहीं है।

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

अंत में, अभी तक अपूर्ण टास्ट टूल (जो, तदनुसार, अभी तक मूल्यांकन नहीं किया जा सकता है) को स्केल 2 से स्केल 3 तक द्विआधारी फ़ाइलों का उपयोग सुनिश्चित करना चाहिए।

तो स्काला का उपयोग क्यों करें?

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

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

सारांश

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

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

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

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