जावा डेवलपर्स स्काला के बारे में क्या सोचते हैं? [बन्द है]

19

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

6 साल पहले बंद हुआ ।

मैंने नोट किया है कि IDE का समर्थन कहीं भी अच्छा नहीं है, लेकिन भाषा स्वयं कार्यात्मक प्रोग्रामिंग मुहावरों का बहुत अधिक सफाई से समर्थन करती है।

— रिचर्ड वारबटन
स्रोत

3

अजगर मेरा धर्म है, इसलिए मुझे केवल इस बात की परवाह है कि गिडो स्काला के बारे में क्या सोचता है। neopythonic.blogspot.com/2008/11/scala.html

— Job

7

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

— सामाजिक धर्म

@soc: बस स्पष्ट होना: मैं स्काला नफरत नहीं है, और लोग हैं, जो यह शायद का उपयोग नहीं कर सकता क्या बारे में कम परवाह (चाहिए नहीं है!) मैं इसके बारे में सोचो। मुझे लगता है कि यह बहुत जटिल है। बस इतना ही। जटिलता उन सभी के लिए सही हो सकती है जिनके पास एक बड़ा मस्तिष्क है। मैं नहीं :-)

— Joonas Pulakka

3

क्षमा करें, मुझे बस तब गुस्सा आता है जब लोग अपने दावों का समर्थन किए बिना मिथकों को दोहराते रहते हैं।

— सामाजिक

2

@ एसोक: ठीक है, यह पूरा प्रश्न पूरी तरह से व्यक्तिपरक है, इसलिए कोई भी उत्तर सही है, यह मिथक है या नहीं।

— पुलसका

18

मैं अब एक वर्ष से अधिक समय से स्काला की प्रोग्रामिंग कर रहा हूं, इसलिए मैं इस प्रश्न का उत्तर देने के लिए स्वयं को एक वर्ष में सेट करने का प्रयास करूंगा।

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

इससे पहले कि मैं इसे सीखना शुरू करूँ, ऊपर दिए गए बिंदु कमोबेश मैं स्काला के बारे में सोचते थे।

एक वर्ष के दौरान, मुझे यहां पता चला है:

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

— huynhjl
स्रोत

21

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

फंक्शनल प्रोग्रामिंग के लिए मैं क्लोजर पसंद करता हूं , जो स्काला की तुलना में सरल है।

पवित्र युद्ध शुरू होने दो ;-)

— जूनस पुलका
स्रोत

2

अगर केवल अमीर हिक्की ने ही .नेट की देखभाल की तो वह जेवीएम के बारे में क्या करता है ...

— जॉब

यह मददगार होगा यदि आप थोड़ा और अधिक बताएंगे कि आपको क्या लगता है कि चीजें बहुत जटिल हैं।

— रिचर्ड वारबटन ने

4

@ रिचर्ड वॉरबर्टन: स्काला की जटिलता के मुद्दे (या, जैसा कि मार्टिन ओडस्की इसे कहते हैं, "ताकत और स्काला की समस्या: इसकी व्यापकता") को बहुत सारे मंचों पर व्यापक रूप से चर्चा में लाया गया है। ऐसी ही एक चर्चा यहाँ है । मैं यह नहीं कह रहा हूं कि जटिल == बुरा प्रति से । समस्या यह है कि जबकि प्रोग्रामर के प्रतिभाशाली 1% स्काला के साथ चमत्कार करने में सक्षम हो सकता है, विशाल बहुमत बस "इसे पाने" के लिए जा रहा नहीं है, और कहा कि है असली दुनिया के उपयोग के लिए एक समस्या है। यह एक फॉर्मूला 1 कार की तरह है: लोगों का विशाल बहुमत बस ऐसे जानवर को ड्राइव करने में सक्षम नहीं होगा।

— जूनास पुलका

2

+1 क्लोजर को वैध विकल्प के रूप में उल्लेख करने के लिए (जब यह कार्यात्मक प्रोग्रामिंग की बात आती है)।

— ओलिवर वीलर

क्लोजर महान है, लेकिन क्या यह स्काला के रूप में प्रदर्शनकारी है? क्या यह सब इतना स्थिर टाइपिंग के बिना रिफ्लेक्टर के लिए आसान है? (उदाहरण के लिए पाइथन को रिफ्लेक्ट करना बहुत कठिन है - मैंने इसके लिए रिफैक्टोरिंग लिखी है।)

— 9000

13

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

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

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

(मैं जारी रख सकता था, लेकिन यह पोस्ट स्काला के बारे में है, फेंटम के बारे में नहीं है, इसलिए मैं यहां रुकता हूं। मेरी पसंद स्पष्ट है , फिर भी दोनों की तुलना करने वाला यह पद है । मैं कभी नहीं समझ सका कि स्काला की तुलना में फैंटम को इतना कम ध्यान क्यों जाता है। लेकिन जाहिरा तौर पर मैं केवल एक ही नहीं हूं, अगर आप इस पॉडकास्ट [ एमपी 3 ] को अंत तक सुनते हैं ।)

— इवो
स्रोत

9

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

मुझे क्लोजर पसंद है, लेकिन ऐसी परिस्थितियां हैं, जहां प्लेटफॉर्म को आपको स्थिर बायटेकोड (एंड्रॉइड, एप्लेट्स, ...) को संकलित करने की आवश्यकता होती है और जब आप ऐसा कर सकते हैं, तो स्काला में, यह वहीं है।

हालांकि स्काला आपको कई समस्याओं को कार्यात्मक तरीके से हल करने देता है, मैं अक्सर उन समस्याओं का पता लगाता हूं जहां कक्षाओं का उपयोग करना अधिक स्वाभाविक लगता है। यह चीजों को थोड़ा और अधिक जटिल बनाता है, लेकिन सी ++ की जटिलताओं और दर्द के पास कहीं नहीं है।

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

IDE प्रश्न के बारे में: सब कुछ के लिए Emacs का उपयोग करने के बाद, मेरे सभी IDE मुद्दे दूर हो गए :-)

— boxofrats
स्रोत

9

मुझे कई कारणों से स्काला पसंद है, लेकिन एक है जिसे अक्सर अनदेखा किया जाता है: इसकी सादगी।

ओबेरॉन की तरह स्काला शायद उतना सरल नहीं है, लेकिन यह कुछ अन्य भाषाओं की तुलना में काफी सरल है। स्काला लैंग्वेज स्पेसिफिकेशन ~ 160 पेज है, जावा लैंग्वेज स्पेसिफिकेशन ~ 600 है (सिर्फ भाषा, जेवीएम या लाइब्रेरी नहीं!), ECMA-334 C # लैंग्वेज स्पेसिफिकेशन (जो AFAIK विजुअल C # 2.0 के सबसेट से मेल खाता है) ~ 440 पृष्ठ (यह LINQ क्वेरी कॉम्प्रिहेंशन, लैम्ब्डा एक्सप्रेशन, एक्सटेंशन मेथड, जेनेरिक को- और कंट्रोवर्सी, dynamicडिफॉल्ट मान के साथ वैकल्पिक तर्क, कीवर्ड तर्क जैसे सामान के बिना है var)। यहां तक कि ECMAScript 5.1 का मौजूदा मसौदा ~ 210 पृष्ठों पर बड़ा है। और निश्चित रूप से मेरी अपनी "डिफ़ॉल्ट" भाषा, रूबी, जिसका वर्तमान आईएसओ ड्राफ्ट ~ 310 पृष्ठों पर है, जो केवल रूबी 1.8.6, 1.9.1 और 1.9.2 के चौराहे के लगभग असामान्य रूप से छोटे उपसमूह को निर्दिष्ट करता है।

— जॉर्ग डब्ल्यू मित्तग
स्रोत

6

भाषा विनिर्देश में पृष्ठों की संख्या इसकी जटिलता का एक दिलचस्प उपाय है। यह आश्चर्यजनक है कि कैसे स्काला इस बारे में राय विभाजित करता है। कोई नहीं कह सकते हैं कि अजगर जटिल है, या सी ++ सरल है, लेकिन स्काला दोनों :-) जैसे प्रतीत हो रहा है scala-lang.org/node/7431

— Joonas Pulakka

आप भाषा के साथ जटिल चीजों का निर्माण कर सकते हैं, और कुछ इस तरह दिखेंगे जैसे कि वे भाषा थी - गैर अलनम नामों के साथ तरीके, जो ऑपरेटर ओवरलोडिंग की तरह दिखते हैं, जो कि उदाहरण के लिए नहीं है।

— उपयोगकर्ता अज्ञात

2

भाषा कल्पना में पृष्ठों की संख्या दो भाषाओं की जटिलता की तुलना करने के लिए एक कठिन तरीका है। सिर्फ दो उदाहरण देने के लिए: जावा कल्पना लगभग ट्यूटोरियल फैशन में लिखी गई है, जबकि स्काला कल्पना एक बहुत ही आकर्षक शैली में लिखी गई है। या एक अन्य उदाहरण, सी # 2.0 वास्तव में जावा के रूप में आज के रूप में जटिल था, या शायद थोड़ा और अधिक जटिल "असुरक्षित" मशीनरी, प्रतिनिधियों, और भविष्यवाणियों को देखते हुए। लेकिन जैसा कि आप ध्यान दें कि C # 2.0 कल्पना JLS से छोटी है।

— जेम्स इरी

1

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

— जेम्स आइरी

3

रुको क्या ? आप कल्पना के आकार के साथ जटिलता को मापने की कोशिश क्यों करेंगे? यह एक भयानक विचार है।

— smartnut007

9

यहाँ Scala के बारे में क्या है:

अशक्त सूचक के साथ शुरू करने के लिए एक बहुत बुरा विचार था। होरे ने इसे अपनी "अरब डॉलर की गलती" कहा, लेकिन स्काला इससे भी बदतर है। इसमें नल, नल, कोई नहीं और नील नाम की वस्तुएं हैं। null Java के साथ इंटरऑपरेबिलिटी के लिए है। Null null पॉइंटर फॉर्म W3C DOM स्पेसिफिकेशन है, कोई भी ऐसा नहीं है जिसे null को बदलना चाहिए था, और Nil एक खाली चीज है।
जब भाषा का निर्माण हैक हो जाता है तो यह आमतौर पर प्रोग्रामर होता है जिसे भाषा को दोष देना होता है न कि उसे। स्काला में, हालांकि, मुख्य भाषा में पहले से ही पुस्तकालय कक्षाएं शामिल हैं, जिसका एकमात्र प्रलेखित व्यवहार "यह एक हैक है"। यह विश्वास नहीं है? स्कैलाडोक को scala.xml.Group के लिए खोजें।
कम से कम नहीं, स्काला बुरी तरह से प्रलेखित है। आधिकारिक दस्तावेज में शायद ही कोई स्काला क्लास उदाहरण कोड के साथ आता है। स्कैला जावा की तुलना में सीखने के लिए काफी कठिन है और इसके लिए कंप्यूटर विज्ञान में गहन ज्ञान की आवश्यकता है।

एक स्काला-हैटर के लिए गलत होने से बचने के लिए, यहाँ मुझे इसके बारे में प्यार है:

मेरे पास कुछ अपवाद नहीं हैं। जावा के साथ बातचीत करते समय मेरे पास कभी भी क्लासकैस्ट अपवाद और बहुत कम NullPointerException नहीं थी।
कोड जावा की तुलना में बहुत छोटा और अधिक संक्षिप्त है
यह बौद्धिक रूप से चुनौतीपूर्ण है। जब तुलना की जाती है तो जावा को शिशु भाषा पसंद आती है।

10

nullजावा का अशक्त सूचक है, Nullइसका "प्रकार" है। Noneएक संभव "राज्य" है Option[T], जो एक या एक शून्य तत्वों के साथ एक संग्रह है। Nilएक खाली सूची है। जब आप इसे भयावह बनाना चाहते हैं, तो यह नहीं है। वे प्रकार एक दूसरे के साथ बदली या विनिमेय नहीं हैं और जैसा वे करना चाहिए वैसा ही व्यवहार करते हैं।

— सामाजिक

9

स्काला है जटिल। इसके आसपास कोई रास्ता नहीं! इसका सिंटैक्स बेहद लचीला है और इसे कई तरीकों से अनुकूलित किया जा सकता है (सभी ऑपरेटरों / इन्फिक्स संकेतन से ऊपर) - और टाइप सिस्टम में किसी भी अन्य भाषा की तुलना में अधिक भिन्न विशेषताएं हैं जो मुझे पता है।

तो चीजें हैं कि सीधे हास्केल में जैसे कि टाइप नहीं कर रहे हैं: Typeclasses उन सभी को कवर करने के लिए।

जैसा कि स्काला कार्यात्मक प्रोग्रामिंग, OO, प्रक्रियात्मक प्रोग्रामिंग और जावा पुस्तकालयों के साथ-साथ स्वयं के विचारों को एक साथ रखने की कोशिश करता है, हम अंत में बहुत सारी अवधारणाओं को समाप्त करते हैं जो किसी भी तरह "एक ही दिशा में" जाते हैं:

निहित मूल्य
निहित कार्य
Existentials
वाइल्डकार्ड
लक्षण
इंटरफेस
सार वर्ग
केस की कक्षाएं
संरचनात्मक प्रकार
सामान्य बाधाओं
सीमा देखें
अनाम प्रकार

उनके बीच चयन करना पहली बार में मुश्किल लगता है और कोई भी आसानी से आश्चर्यचकित हो सकता है यदि किसी समस्या का सही समाधान मिल गया है। यह भी आसानी से हैक करके सामान का उत्पादन संभव है implicit।

लेकिन दिलचस्प बात यह है: स्काला काम करता है। यह समझना कभी-कभी कठिन होता है कि (विशेष रूप से निहितार्थ रूपांतरण + विरासत के माध्यम से पता लगाना क्यों ... किसी वस्तु को कार्यक्षमता मिली है X), लेकिन आपको उस समय के बारे में परेशान करने की आवश्यकता नहीं है।

स्काला को जितना संभव हो उतना सीधा लिखें और यह काम करेगा। हर उस चीज़ से भ्रमित मत होइए जो संभव है और बस वही उपयोग करें जो आपको चाहिए। और अगर आपको कुछ चाहिए, तो आप सुनिश्चित हो सकते हैं कि किसी तरह स्काला के पास है;)

और जितना बेहतर आप प्राप्त करेंगे, उतने ही अधिक आप Scala को ऑपरेटरों, इंक्विटिस, मोनडेस, फंकी सिंटैक्स के साथ कस्टमाइज़ कर पाएंगे ... और अंत में एक डीएसएल के करीब कुछ प्राप्त करेंगे जो आपकी समस्या को पूरी तरह से संबोधित करेंगे।

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

— दारियो
स्रोत

1

"सभी ऑपरेटर्स / इनफिक्स नोटेशन के ऊपर" - बस उस स्कैला में ऑपरेटरों की कमी है। :) यह सिर्फ तरीके हैं।

— उपयोगकर्ता अज्ञात

6

यह एक उत्कृष्ट भाषा है जो कई मायनों में जावा की तुलना में सरल है।

ज्यादातर लोग, प्रोग्रामर या नहीं, उन्हीं कारणों से जावा प्रोग्रामर इसे पसंद नहीं करेंगे, जावा प्रोग्रामर या नहीं, नई प्रोग्रामिंग लैंग्वेज सीखना पसंद नहीं करते हैं। मुझे संदेह है कि प्रोग्रामिंग भाषा सीखने वाले अधिकांश लोगों को यह सीखना पसंद नहीं था।

यदि आप किसी भाषा के C ++ के रूप में जटिल होने के बारे में चिंतित हैं, तो मैं प्लेग की तरह क्लोजर से बचूंगा। क्लींजर की तुलना में स्काला अधिक जटिल है, ऐसे लोगों के लिए, जो एक या दोनों भाषाओं के बारे में पूरी तरह से अनभिज्ञ हैं।

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

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

— जोश
स्रोत

6

अपने स्काला बनाम क्लोजर इनपुट के लिए धन्यवाद, लेकिन क्या ओपी मैं वास्तव में पूछ रहा हूं?

— मार्टिन विकमैन

दिलचस्प बिंदु पुनः: मैक्रोज़। थोड़ी चिंता, भी। क्या मैक्रो या स्काला में समान उपलब्ध हैं, या संपूर्ण "कृत्रिम रूप से सीमित" चीज एक व्याकुलता है?

— आर्मंड

1

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

— जूनास पुलकका

> यह इस तथ्य को नहीं बदलता है कि क्लोजर भाषा सबसे सरल लोगों में से एक है। <यह भी पूरी तरह से गलत है, जब तक कि आप कुछ मीट्रिक का उपयोग नहीं कर रहे हैं जैसे "भाषा निर्माण की संख्या"। यदि आप कुछ उपयोगी का उपयोग कर रहे हैं, जैसे कि भाषा में कार्यक्रमों को पढ़ना और लिखना कितना आसान है, तो क्लोजर सबसे सरल में से एक नहीं है।

— जोश

इसलिए कृपया आगे बढ़ें और हमें भाषा की जटिलता का अच्छा मेट्रिक दें। "भाषा में कार्यक्रमों को पढ़ना और लिखना कितना आसान है" पूरी तरह से व्यक्तिपरक है , इसलिए यह वास्तव में यहां मदद नहीं करता है। दी, एक उपयोगी और उद्देश्य मीट्रिक के साथ आना लगभग असंभव हो सकता है। (उदाहरण के लिए Jörg W Mittag नीचे एक जटिलता माप के रूप में भाषा विनिर्देश में पृष्ठों की संख्या का उपयोग कर रहा है। जबकि उद्देश्य, मुझे यकीन नहीं है कि यह बहुत उपयोगी है।)

— Joonas Pulakka

4

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

— मैट एच
स्रोत

2

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

— ब्रायन नॉबलुच
स्रोत