Scala जावा से भी बदतर है। जावा प्रोजेक्ट्स का कम से कम आधा हिस्सा

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

लेकिन पहले मेरे बारे में। मेरा नाम डेविड पोलाक है। मैं नवंबर 2006 से स्काला समुदाय का सक्रिय सदस्य रहा हूं। मैं लिफ्ट प्रोजेक्ट का संस्थापक हूं।
उल्लेख के लायक कुछ और महत्वपूर्ण बिंदु:

• मैं ईपीएफएल के लगभग किसी भी व्यक्ति की तुलना में अधिक समय से लगातार स्काला कोड लिख रहा हूं। (लासाॅन पॉलिटेक्निक में स्काला को विकसित किया जा रहा है)। [अपडेट - @propensive और Bill Wenners स्काला समुदाय में मुझसे ज्यादा लंबे समय से शामिल हैं।]
• मैंने 2008 में स्काला लिफ्ट ऑफ का पहला स्कैला सम्मेलन आयोजित किया था, और आज भी इसे जारी रखता हूं।
• ग्रह पर किसी की तुलना में स्काला (250K से अधिक) पर कोड की अधिक लाइनें लिखीं।
• एक लोकप्रिय किताब लिखी, स्कैला: बिगिनिंग स्काला का एक परिचय।
• पिछले पांच वर्षों में, मैंने स्काला और लिफ़्ट मंचों पर, स्कैला और लिफ्ट से संबंधित विषयों पर 10,000 से अधिक बार लिखा है (यह बताता है कि मैंने बड़ी संख्या में डेवलपर्स से बात की थी)।
• मैंने लिफ्ट वेब फ्रेमवर्क परियोजना की स्थापना की और कोर एपीआई के डिजाइन सहित इसके एक महत्वपूर्ण हिस्से को लिखा। लिफ्ट सबसे लोकप्रिय स्काला-आधारित फ्रेमवर्क और पहले व्यापक रूप से ज्ञात स्काला लाइब्रेरी में से एक है।
• पिछले एक साल में स्काला पर कोड की आधा मिलियन से अधिक लाइनों की समीक्षा की।
• मैं मुख्य रूप से स्काला और लिफ्ट के लिए परामर्श करके एक जीवित करता हूं, और इस प्रकार कई परियोजनाओं में सक्रिय रूप से भाग लेता हूं।
• पिछले 5 वर्षों में स्काला और लिफ्ट के बारे में 25 से अधिक प्रस्तुतियों का आयोजन किया।
• छोटी टीमों में सैकड़ों लोगों को स्काला और लिफ्ट का उपयोग करना सिखाया।
• उन्होंने सीधे या परोक्ष रूप से स्काला का प्रतिनिधित्व किया, जो आधे से अधिक उपभोक्ताओं के लिए टाइप टाइप कैफे मुखपृष्ठ (लगभग प्रति जेरॉक्स, सीमेंस, सोनी और अन्य व्हेल ) में सूचीबद्ध हैं।

उपरोक्त सभी को संक्षेप में प्रस्तुत किया जा सकता है: “मुझे स्काला पर कोडिंग, स्काला को पढ़ाने और विभिन्न लोगों और संगठनों को स्काला को प्रस्तुत करने का काफी अनुभव है। "मैंने स्काला के सफल कारकों का विश्लेषण करने के लिए बहुत सारे डेटा संचय करने के लिए स्काला का उपयोग करने या योजना बनाने के लिए पर्याप्त लोगों के साथ बात की है।" इसका मतलब यह नहीं है कि मुझे विश्वास है कि मैं सही हूं, और बाकी सभी गलत हैं। लेकिन फिर भी, यह सुझाव देता है कि जो लोग तर्क के रूप में व्यक्तित्व के संक्रमण के साथ बयानबाजी का उपयोग करते हैं, उनके पास इस चर्चा में वजन नहीं है। [अपडेट: फोगस की पोस्ट पढ़ने के बाद ... मैंने इसे गलत समझा। मुझे लगता है कि मैं फॉगस था और मैं उसी निष्कर्ष पर आया था। मैं इसे अंतिम सत्य घोषित नहीं करते हुए अपनी राय रखता हूं। हालाँकि, मैं फॉगस की कठोरता और उसके पद के लिए माफी माँगता हूँ!]

इस सब तैयारी के बाद, मैं अपना निष्कर्ष व्यक्त करता हूं:

• स्काला अधिकांश जावा डेवलपर्स के लिए एक अनुपयुक्त भाषा है और इसे जावा के लिए प्रतिस्थापन नहीं माना जा सकता है, क्योंकि जावा डेवलपर्स के कम से कम आधे के लिए, स्काला की जटिलता इसकी ताकत को नकारती है।

यह कथन इससे अधिक विवादास्पद नहीं है:

• जावा अधिकांश PHP डेवलपर्स के लिए एक अनुपयुक्त भाषा है और इसे PHP के लिए प्रतिस्थापन के रूप में नहीं माना जा सकता है, क्योंकि कम से कम आधे PHP डेवलपर्स के लिए, जावा की जटिलता इसकी खूबियों को नकारती है।

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

चर्चा

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

अलग-अलग लोग अलग-अलग चीजों को महत्व देते हैं। ऐसे लोगों की एक पूरी कक्षा है जो कंप्यूटर से प्यार करते हैं और कोड लिखना पसंद करते हैं। मैं उनमें से हूं। और ऐसे लोगों का एक वर्ग है जो अपनी पसंदीदा गतिविधियों के शीर्ष 5 में प्रोग्रामिंग नहीं डालेंगे।

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

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

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

मैं पॉल Snively से सहमत हूं कि स्काला सीखा जा सकता है । यही कारण है कि मैं कई वर्षों से स्काला को सक्रिय रूप से बढ़ावा दे रहा हूं। बात यह है कि स्काला का अध्ययन एक खास तरह के लोगों द्वारा किया जा रहा है। इस दृश्य में उन लोगों को शामिल नहीं किया गया है जो सीखना नहीं चाहते हैं, और जिनके पास ऐसा करने की क्षमता नहीं है (ठीक वैसे ही जैसे पीएचपी में कोड लिख सकते हैं, लेकिन जावा में प्रोग्राम करने में सक्षम नहीं हैं।)

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

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

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

• उन प्रोग्रामर और परियोजनाओं पर ध्यान केंद्रित करें जो तीन गुना अधिक कुशल होंगे, उन्हें स्काला का उपयोग करें; या;
• मध्यम आयु वर्ग के प्रोग्रामर के लिए स्काला में सुधार करें (यह तब तक नहीं होगा जब तक कि स्काला, सबसे पहले एक अभिनव, अनुसंधान भाषा नहीं है)

प्रेरणा

"तो क्या?" आप पूछते हैं, "क्या आपने यह साबित करने के लिए इतना लिखा है कि स्काला सफल और कठिन नहीं है?"

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

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

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

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

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

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

ओह ... और आप सभी, दुष्ट स्मार्ट लोग जो धक्का दे रहे हैं (या जल्द ही धक्का देने के लिए निश्चित हैं) सीमाएँ, मेगा-इवेंट-संचालित-रीयल-टाइम गिज़्मो के साथ, आप पाएंगे कि स्काला एक सपना है जो सच हो गया है , और ऐसा कुछ भी नहीं है (ठीक है, शायद हास्केल को छोड़कर)। तो आगे बढ़ें, स्काला पर अपना ठंडा सामान बनाएं और इसे काम करने दें।