हाँ वर्जीनिया, स्काला जटिल है!

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

• स्काला बहुत अधिक लेने की कोशिश कर रही है। इसका मतलब है कि आप जावा-शैली कोड लिखना जारी रख सकते हैं, जो एक अभिशाप और आशीर्वाद दोनों है। लेकिन लंबे समय में, मुझे लगता है कि यह अभी भी एक अभिशाप है। OO और FP के बीच कंट्रास्ट को लेकर बहुत ज्यादा बहस है। यदि आप एक छोटी सी टीम हैं, तो इस तरह की चर्चा स्वीकार्य है, लेकिन वे बहुत खराब हैं, जब आप स्काला जावा लिखने की कोशिश कर रहे हैं - डेवलपर्स जो वास्तव में सीखना या बदलना नहीं चाहते हैं। स्काला के आश्चर्यजनक लाभ वास्तव में तब दिखाई देने लगते हैं जब आप एफपी शैली में लिखते हैं, लेकिन ओओ डेवलपर्स को आकर्षित करना लगभग असंभव है जब तक कि वे खुद एक असामान्य शैली में लिखना नहीं चाहते। इस मामले में, जावा या रूबी की तरह कम भाषा की विशेषताएं, संभावित समाधानों की सीमा को कम करना, अनुकूलित करना आसान है।
• IDE से खराब समर्थन (और हमेशा रहेगा)। स्काला के लिए एक्लिप्स प्लगइन (या इस सप्ताह इसे वहां जो भी कहा जाता है) बकवास है। वह स्काला के साथ मेरे काम के पिछले 5 वर्षों के लिए ऐसा करना जारी रखता है। लगातार मैं सुनता हूं "यह बेहतर होगा", लेकिन फिर भी बेकार है! स्केला के लिए इंटेलीज का समर्थन मुझे स्वीकार्य है। लेकिन जिन लोगों को अपने आईडीई में टेम्प्लेट की आवश्यकता होती है, उन्हें स्कैला समर्थन पर्याप्त नहीं मिलेगा। सबसे पहले, स्काला टेम्प्लेट / पैटर्न इतने विविध और खंडित हैं (मिक्स के माध्यम से ओओ स्कैज का तरीका है) कि वास्तव में उनमें से एक अविश्वसनीय राशि है। यदि आप सफलतापूर्वक Emacs, Vi या TextMate में कोड लिखते हैं - सब कुछ क्रम में है, और IntelliJ को संक्रमण अच्छा लगेगा। लेकिन अगर आप जावा आईडीई से प्राप्त एक "सद्भावना" की अपेक्षा करते हैं, तो आपके सपने टूट जाएंगे और स्काला की व्यापक शक्ति के कारण कभी भी सच नहीं होंगे, जिसे लागू करना मुश्किल होगा, भारी मात्रा में निवेश की आवश्यकता होगी। और यहां तक ​​कि खाते में उनके 3 मिलियन के साथ टाइपसेफ यह गारंटी नहीं दे सकता है।
• स्काला टाइप सिस्टम बेहद शक्तिशाली है, लेकिन आपके दृष्टिकोण से, शायद बहुत ज्यादा। ScalaDocs में, कुछ हस्ताक्षर बहुत भयभीत कर सकते हैं। देख लेना
  

  flatMap [B, That] (f: (A) ⇒ Traversable[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That 

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

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

• आपकी कंपनी के जावाऑन, ओएससीओएन, स्ट्रेंज लूप, क्यूकॉन - स्केला में बोलने वाले आसान होंगे
• जिन चर्चाओं को आयोजित किया जा रहा है, उनमें एक नियमित विकासकर्ता से वरिष्ठ के पास जाने के मानदंड हैं - स्काला मुश्किल होगा
• यदि आवश्यक हो, तो आपके डेवलपर्स नोटपैड में कोड लिखने में सक्षम होंगे - सरल
• जब वे "ज़ेड शॉ" नाम सुनते हैं तो आपके डेवलपर्स उदासीन होते हैं या 3 "हेल मैरी" कहते हैं: स्कोर == हार्ड
• ट्विटर पर डीन वामप्लर पर डेवलपर्स चुनाव का अनुसरण करते हैं: स्काला सरल है
• आपके डेवलपर 9.15 पर काम करते हैं और 6 तक छोड़ देते हैं, उनके ईमेल की जांच के बिना - मुश्किल

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

• हां, स्काला में टाइप सिस्टम बहुत शक्तिशाली है और इससे स्काला कलेक्शन की तरह शानदार कोड ब्यूटी हो सकती है।
  Stackoverflow.com/questions/1722726/is-the-scala-2-8-collections-library-a-case-of-the-longest-suicide-note-in-histo और www.scala-lang.org/docu पर एक नज़र डालें /files/collections-api/collections-impl.html
  लेकिन भाषा / पुस्तकालय डिजाइनरों और मध्य-आकार के डेवलपर्स की जरूरतों के बीच अंतर है। और स्काला में इस तरह के अलगाव की कमी उत्तरार्द्ध के लिए कठिनाइयों को बढ़ाती है। व्यक्तिगत रूप से, मुझे नहीं लगता कि मैं लिफ्ट में विचारों को स्पष्ट रूप से और किसी अन्य भाषा में स्पष्ट रूप से व्यक्त कर सकता हूं। इसलिए, एक पुस्तकालय डिजाइनर के रूप में, मुझे स्काला बहुत पसंद है। लेकिन मेरी तरह, और कई लोग जो स्काला को मुश्किल नहीं मानते हैं, वे औसत लोग नहीं हैं। और स्काला पर 11 साल का बच्चा लेखन भी बीच में नहीं है।
• हां, स्कालाडॉक्स में एक सुधार जो "सरल" और "वास्तुशिल्प" देखने के लिए एक बड़ी जीत हो सकती है। लेकिन यह अभी भी केवल शुरुआती बिंदु है, लेकिन अंत नहीं है।
• मैं असमानता से तर्क को अस्वीकार करता हूं "उत्कृष्ट, फिर हम अधिक पेशेवर डेवलपर्स पाएंगे"। हमें डेवलपर्स की क्षमता को बेहतर बनाने के लिए काम करते हुए "स्काला हार्ड है" की समस्या को हल करना चाहिए (कुछ लोग जो प्रकार के हस्ताक्षर पढ़ सकते हैं, अन्य जो गणितीय दृष्टिकोण आदि का उपयोग करके अपने कार्यक्रमों को व्यक्त कर सकते हैं), लेकिन हम खुद को सार से दूर कर रहे हैं। और लब्बोलुआब यह है कि स्काला प्रशिक्षण, शिक्षा या काम पर रखने में क्रांति शुरू करने के लिए इतना उपयुक्त नहीं है, क्योंकि यह उसके लिए मुश्किल होने से रोकने के लिए औसत डेवलपर की व्यावसायिकता को बढ़ाने के लिए है।
• मुझे संदेह है कि जो कोई भी इसे या मेरे ट्विटर को पढ़ता है, वह एक औसत डेवलपर है और पॉल Snively, आप औसत से बहुत दूर हैं, और कोशिश भी नहीं करते हैं!