क्या स्कैला 2.8 संग्रह पुस्तकालय "इतिहास का सबसे लंबा सुसाइड नोट" का मामला है? [बन्द है]


873

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

> List("Paris", "London").map(_.length)
res0: List[Int] List(5, 6)

... या तो संस्करणों में काम करेगा। पुस्तकालय मुख्य रूप से प्रयोग करने योग्य है : वास्तव में यह शानदार है। हालाँकि, जो पहले स्काला से अपरिचित थे और भाषा का एहसास पाने के लिए अब इस पर विचार कर रहे थे:

def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That

इस तरह की सरल कार्यक्षमता के लिए, यह एक कठिन हस्ताक्षर है और जिसे मैं खुद को समझने के लिए संघर्ष कर रहा हूं। ऐसा नहीं है कि मुझे लगता है कि स्काला के अगले जावा (या / C / C ++ / C #) होने की संभावना थी - मुझे नहीं लगता कि इसके निर्माता उस बाजार में इसे लक्षित कर रहे थे - लेकिन मुझे लगता है कि यह निश्चित रूप से स्काला बनने के लिए संभव है अगले रूबी या पायथन (यानी एक महत्वपूर्ण वाणिज्यिक उपयोगकर्ता-आधार हासिल करने के लिए)

  • क्या यह लोगों को स्काला में आने से रोकने वाला है?
  • क्या यह स्कैला को व्यावसायिक दुनिया में एक अकादमिक नाटक के रूप में एक बुरा नाम देने वाला है जिसे केवल समर्पित पीएचडी छात्र ही समझ सकते हैं? क्या CTO के सॉफ्टवेयर के प्रमुख डरने वाले हैं?
  • क्या पुस्तकालय फिर से एक समझदार विचार था?
  • यदि आप व्यावसायिक रूप से स्काला का उपयोग कर रहे हैं, तो क्या आप इस बारे में चिंतित हैं? क्या आप तुरंत 2.8 को अपनाने की योजना बना रहे हैं या यह देखने के लिए इंतजार कर रहे हैं कि क्या होता है?

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

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


मेरी पत्नी और सहकर्मी जो कुछ भी मुझे बताते रहते हैं, मुझे नहीं लगता कि मैं एक बेवकूफ हूं: मेरे पास ऑक्सफोर्ड विश्वविद्यालय से गणित में अच्छी डिग्री है , और मैं लगभग 12 वर्षों से और स्काला में व्यावसायिक रूप से प्रोग्रामिंग कर रहा हूं । एक वर्ष (व्यावसायिक रूप से भी)।

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


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

32
यह सवाल स्काला दिन 2010 में मार्टिन ओडर्स्की के उद्घाटन बात में उल्लेख किया गया था days2010.scala-lang.org/node/136
Binil थॉमस

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

87
यह प्रश्न "रचनात्मक नहीं" कैसे हो सकता है जब इसके कारण @MartinOdersky ने स्केला प्रयोज्य को पुन: मूल्यांकन किया और इसकी दस्तावेज़ीकरण प्रणाली को टाइप सिस्टम विवरणों को छिपाया, न कि एक रोशन चर्चा का उल्लेख करने के लिए?
जेरी 101101

14
दरअसल, एसओ केवल तकनीकी के लिए सही प्रारूप के साथ है। यदि आपके पास कुछ नाजुक, पेचीदा और दूरगामी है, तो कृपया कहीं और देखें। नौकरशाही मानसिकता को लंबे समय तक जीते हैं।
QED

जवाबों:


892

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

वास्तव में mapइसकी जटिल प्रकार द्वारा समर्थित की कार्यक्षमता बहुत उन्नत है। इस पर विचार करो:

scala> import collection.immutable.BitSet
import collection.immutable.BitSet

scala> val bits = BitSet(1, 2, 3)
bits: scala.collection.immutable.BitSet = BitSet(1, 2, 3)

scala> val shifted = bits map { _ + 1 }
shifted: scala.collection.immutable.BitSet = BitSet(2, 3, 4)

scala> val displayed = bits map { _.toString + "!" }
displayed: scala.collection.immutable.Set[java.lang.String] = Set(1!, 2!, 3!)

देखें कि आपको हमेशा सबसे अच्छा प्रकार कैसे मिलता है? यदि आप Ints को Intफिर से प्राप्त करने के लिए मैप करते हैं BitSet, लेकिन यदि आप Ints से मैप Stringकरते हैं, तो आपको एक जनरल मिलता है Set। स्थैतिक प्रकार और मानचित्र के परिणाम के रनटाइम प्रतिनिधित्व दोनों उस फ़ंक्शन के परिणाम प्रकार पर निर्भर करते हैं जो इसे पारित किया गया है। और यह तब भी काम करता है जब सेट खाली हो, इसलिए फ़ंक्शन कभी भी लागू नहीं होता है! जहां तक ​​मुझे पता है कि समकक्ष कार्यक्षमता के साथ कोई अन्य संग्रह रूपरेखा नहीं है। फिर भी एक उपयोगकर्ता के दृष्टिकोण से यह है कि चीजों को कैसे काम करना चाहिए

हमारे पास समस्या यह है कि ऐसा करने वाली सभी चतुर तकनीक, प्रकार के हस्ताक्षरों में लीक हो जाती हैं जो बड़े और डरावने हो जाते हैं। लेकिन शायद एक उपयोगकर्ता को पूर्ण प्रकार के हस्ताक्षर को डिफ़ॉल्ट रूप से नहीं दिखाया जाना चाहिए map? कैसे करता है, तो वह ऊपर देखा के बारे में mapमें BitSetवह मिल गया:

map(f: Int => Int): BitSet     (click here for more general type)

डॉक्स उस मामले में झूठ नहीं होगा, क्योंकि उपयोगकर्ता के दृष्टिकोण से वास्तव में मानचित्र का प्रकार होता है (Int => Int) => BitSet। लेकिन mapएक और सामान्य प्रकार भी है जिसका निरीक्षण दूसरे लिंक पर क्लिक करके किया जा सकता है।

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


107
मैं एक शरारती स्कूल की तरह लग रहा है! यहाँ प्रतिक्रिया देने के लिए समय निकालने के लिए बहुत बहुत धन्यवाद। मुझे लगता है कि उत्तरों के संतुलन ने मुझे दिखाया है कि मुझे चिंता करने की आवश्यकता नहीं है; पर्याप्त लोग होंगे जो बिल्कुल भी भयभीत नहीं होंगे।
oxbow_lakes

164
नहीं, मुझे लगता है कि आप उस बिंदु पर हिट करने के लिए बिल्कुल सही थे। और अन्य लोग तब तक डरेंगे जब तक कि हम इसके बारे में कुछ नहीं करेंगे।
मार्टिन ओडस्की

33
मार्टिन, मुझे एक सरलीकृत विधि हस्ताक्षर दिखाने और एक लिंक के पीछे सामान्य विवरण छिपाने के लिए आपका सुझाव पसंद है।
डेरेक महार

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

98
अपडेट: अंतिम स्काला 2.8 रिलीज में मेरे द्वारा वर्णित की तरह एक तंत्र है। यदि आप अपने द्वारा खोजे गए स्कैल्पडॉक्स में बिटसेट देखते हैं: डिफ मैप [बी] (एफ: (इंट) ⇒ बी): बिटसेट [बी] [उपयोग का मामला] इस बिटसेट के सभी तत्वों पर एक फ़ंक्शन लागू करके एक नया संग्रह बनाता है।
मार्टिन ओडस्की

226

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

और फिर भी, मुझे mapआपके द्वारा पोस्ट किए गए फ़ंक्शन के हस्ताक्षर को समझने में कोई परेशानी नहीं है । यह मुझे बहुत हद तक उसी हस्ताक्षर की तरह दिखता mapहै जो हर दूसरी भाषा में है जिसे मैंने कभी देखा है। अंतर यह है कि यह संस्करण अधिक सामान्य है। हास्केल कहते हैं, यह सी ++ एसटीएल की तुलना में अधिक दिखता है। विशेष रूप से, यह केवल तर्क की आवश्यकता है कि ठोस संग्रह प्रकार से दूर सार है IterableLike, और यह भी ठोस रिटर्न प्रकार से दूर सार केवल आवश्यकता है कि एक अंतर्निहित रूपांतरण समारोह मौजूद है जो परिणाम मूल्यों के उस संग्रह से बाहर कुछ का निर्माण कर सकते हैं। हां, यह काफी जटिल है, लेकिन यह वास्तव में सामान्य प्रोग्रामिंग के सामान्य प्रतिमान की एक अभिव्यक्ति है: कुछ भी ऐसा न मानें जो आपको वास्तव में नहीं करना है।

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

तो, के बजाय

map :: (a → b)[a][b]

जो पारंपरिक प्रकार का हस्ताक्षर है map, इसके लिए एक ठोस की आवश्यकता नहीं है List, बल्कि केवल एक IterableLikeडेटा संरचना है

map :: (IterableLike i, IterableLike j)(a → b) → i → j

जिसे तब केवल इस बात की आवश्यकता के द्वारा सामान्यीकृत किया जाता है कि एक फ़ंक्शन मौजूद है जो उपयोगकर्ता को जो भी डेटा संरचना चाहता है, परिणाम को परिवर्तित कर सकता है:

map :: IterableLike i ⇒ (a → b) → i → ([b] → c) → c

मैं मानता हूँ कि वाक्यविन्यास थोड़ा अव्यवस्थित है, लेकिन शब्दार्थ समान हैं। असल में, यह से शुरू होता है

def map[B](f: (A) ⇒ B): List[B]

जिसके लिए पारंपरिक हस्ताक्षर है map। (नोट कैसे स्काला के वस्तु उन्मुख प्रकृति के कारण, इनपुट सूची पैरामीटर गायब हो जाती है, क्योंकि यह अब निहित रिसीवर पैरामीटर एक एकल प्रेषण OO सिस्टम में हर विधि पड़ता है।) तो यह एक ठोस से सामान्यीकृत Listएक अधिक सामान्य करने के लिएIterableLike

def map[B](f: (A) ⇒ B): IterableLike[B]

अब, यह IterableLikeपरिणाम संग्रह को एक फ़ंक्शन के साथ बदलता है जो वास्तव में, किसी भी चीज़ के बारे में वास्तव में उत्पादन करता है।

def map[B, That](f: A ⇒ B)(implicit bf: CanBuildFrom[Repr, B, That]): That

जो मैं वास्तव में मानता हूं कि समझना मुश्किल नहीं है । वास्तव में केवल कुछ बौद्धिक उपकरण हैं जिनकी आपको आवश्यकता है:

  1. आपको यह जानना होगा (मोटे तौर पर) क्या mapहै। यदि आपने विधि के नाम के बिना केवल टाइप हस्ताक्षर दिए हैं , तो मैं मानता हूं कि यह पता लगाना बहुत कठिन होगा कि क्या चल रहा है। लेकिन जब से आप पहले से ही जानते हैं कि क्या mapकरना है, और आप जानते हैं कि इसका प्रकार हस्ताक्षर क्या माना जाता है, आप जल्दी से हस्ताक्षर स्कैन कर सकते हैं और विसंगतियों पर ध्यान केंद्रित कर सकते हैं, जैसे "यह mapदो कार्यों को तर्क के रूप में क्यों लेता है, एक नहीं?"
  2. आपको वास्तव में टाइप सिग्नेचर पढ़ने में सक्षम होना चाहिए । लेकिन यहां तक ​​कि अगर आपने पहले कभी स्काला को नहीं देखा है, तो यह काफी आसान होना चाहिए, क्योंकि यह वास्तव में सिर्फ एक प्रकार का सिंटैक्स है जो आप पहले से ही अन्य भाषाओं से जानते हैं: VB.NET पैरामीट्रिक बहुरूपता के लिए वर्ग कोष्ठक का उपयोग करता है, और एक तीर का उपयोग करने के लिए निरूपित करता है नाम और प्रकार को अलग करने के लिए वापसी प्रकार और एक बृहदान्त्र, वास्तव में आदर्श है।
  3. आपको मोटे तौर पर यह जानने की जरूरत है कि सामान्य प्रोग्रामिंग क्या है। (जो यह पता लगाने के लिए मुश्किल नहीं है , क्योंकि यह मूल रूप से नाम में वर्तनी है: यह सचमुच एक सामान्य फैशन में प्रोग्रामिंग है)।

इन तीनों में से किसी को भी कोई पेशेवर या यहां तक ​​कि शौक़ीन प्रोग्रामर को गंभीर सिरदर्द नहीं देना चाहिए। mapपिछले 50 वर्षों में डिज़ाइन की गई हर भाषा में एक मानक कार्य किया गया है, इस तथ्य को कि अलग-अलग भाषाओं में अलग-अलग वाक्य-विन्यास हैं, उन सभी के लिए स्पष्ट होना चाहिए जिन्होंने HTML और CSS के साथ एक वेबसाइट डिज़ाइन की है और आप दूर से भी प्रोग्रामिंग की सदस्यता नहीं ले सकते। सेंट स्टीफानोव के चर्च से कुछ कष्टप्रद सी ++ फैनबॉय के बिना संबंधित मेलिंगलिस्ट जेनेरिक प्रोग्रामिंग के गुणों को समझाते हुए।

हाँ, स्काला है जटिल। हां, स्काला में सबसे परिष्कृत प्रकार की प्रणाली है जो मनुष्य को ज्ञात है, प्रतिद्वंद्वी और यहां तक ​​कि हास्केल, मिरांडा, स्वच्छ या चक्रवात जैसी भाषाओं को पार करती है। लेकिन अगर एक प्रोग्रामिंग भाषा की सफलता के खिलाफ जटिलता एक तर्क थी, तो C ++ बहुत पहले ही मर गई होगी और हम सभी स्कीम लिख रहे होंगे। बहुत सारे कारण हैं कि स्काला बहुत सफल होने की संभावना नहीं है, लेकिन यह तथ्य कि प्रोग्रामर को कीबोर्ड के सामने बैठने से पहले अपने दिमाग को चालू करने के लिए परेशान नहीं किया जा सकता है, शायद मुख्य नहीं होगा।


36
@ जोर्ग - यह एक भयानक जवाब है; धन्यवाद। आपके पास कोई डिग्री है या नहीं, आप I. की तुलना में एक शानदार व्यक्ति हैं। मेरे पास एकमात्र प्रश्न यह है कि मैं विधि हस्ताक्षर में जो चल रहा है उसकी व्यापक तस्वीर को समझता हूं । हालांकि, विवरण अभी भी भ्रमित कर रहे हैं: किस तरह से Thatअनुमान लगाया जा रहा है और Bएक प्रकार से जुड़ा हुआ है जो एक सवाल है जो मन में आता है। दूसरे कहां से आ रहे हैं। इन विस्तृत टिप्पणियों के बिना भी, मुझे अभी भी व्यक्तिगत रूप से लगता है कि यह एक जटिल हस्ताक्षर है। लेकिन जाहिर है कि वहाँ आप जैसे लोग हैं जो इस सब से हैरान नहीं हैं!
oxbow_lakes 22

50
अच्छा स्पष्टीकरण, लेकिन आपने मुझे और भी आश्वस्त किया है कि स्केल 2.8 "नक्शा" विधि हस्ताक्षर बहुत जटिल है।
डेरेक महार

11
ऐसी भाषा जो इस तरह दिखती है: def map [B] (f: (A) ⇒ B): IterableLike [B] इस तरह दिखने वाले की तुलना में बहुत अधिक आमंत्रित है: def map [B, That] (f: A ⇒ B ) (निहित bf: CanBuildFrom [Repr, B, That]): वह
मार्क एस्सेल

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

14
आपके पास एक मान्य बिंदु है कि हास्केल की तुलना उस "मानचित्र :: (a -> b) -> [[a] -> [b]" सूचियों के लिए विशिष्ट है। हालाँकि, सामान्यीकृत संस्करण, फ़ंक्टर क्लास का, अभी भी स्केला संस्करण की तुलना में बहुत सरल है: क्लास फ़ंक्टर च जहाँ fmap :: (a -> b) -> fa -> fb
Orclev

175

C ++ में समान बात :

template <template <class, class> class C,
          class T,
          class A,
          class T_return,
          class T_arg
              >
C<T_return, typename A::rebind<T_return>::other>
map(C<T, A> &c,T_return(*func)(T_arg) )
{
    C<T_return, typename A::rebind<T_return>::other> res;
    for ( C<T,A>::iterator it=c.begin() ; it != c.end(); it++ ){
        res.push_back(func(*it));
    }
    return res;
}

105
... और वे कहते हैं कि स्काला अस्पष्ट है। ओह!
लापताफैक्टर

24
ज़रा सोचिए कि अगर स्व-वर्णन करने वाले पहचानकर्ताओं का उपयोग मनमाने ढंग से बड़े अक्षरों के बजाय किया गया होता तो यह कैसा दिखता। :-)
टीआई स्ट्रगा

14
यह तुलना देखने के लिए उपयोगी है, लेकिन अगर इसे छोड़ दिया गया तो यह अधिक उचित होगा।
आरोन नोवस्त्रुप

2
मैं अनिवार्य फ़ंक्शन पॉइंटर का बहुत बड़ा प्रशंसक नहीं हूं। स्पष्ट रूप से एक प्रकार का funcटेम्पलेट टेम्प्लेट पैरामीटर होना चाहिए, और आपको अन्य प्रकारों को प्राप्त करने के लिए उपयोग करना चाहिए result_ofऔर is_callableओवरलोड सेट को उचित रूप से
रोकना चाहिए

1
मेरी आंखों में चोट लगी !!!
अशोकन ख। नाज़री

71

ठीक है, मैं आपके दर्द को समझ सकता हूं, लेकिन, काफी स्पष्ट रूप से, आप और मैं जैसे लोग - या बहुत अधिक किसी भी नियमित स्टैक ओवरफ्लो उपयोगकर्ता - नियम नहीं हैं।

मेरे कहने का मतलब यह है कि ... अधिकांश प्रोग्रामर उस प्रकार के हस्ताक्षर की परवाह नहीं करेंगे, क्योंकि वे उन्हें कभी नहीं देखेंगे ! वे प्रलेखन नहीं पढ़ते हैं।

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

इन बातों को ध्यान में रखते हुए, मुझे लगता है कि:

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

  2. यदि दस्तावेज़ का उपयोग उदाहरण प्रदान करने के लिए नहीं किया गया है और यह स्पष्ट रूप से समझाता है कि एक विधि क्या है और इसका उपयोग कैसे करना है, तो यह स्केला अपनाने से थोड़ा हट सकता है।

  3. लंबे समय में, यह कोई फर्क नहीं पड़ेगा। यह कि स्केला सामान की तरह काम कर सकता है, जिससे स्कैला के लिए लिखी गई लाइब्रेरी अधिक शक्तिशाली और उपयोग करने के लिए सुरक्षित हो जाएगी। इन पुस्तकालयों और चौखटे प्रोग्रामर को आकर्षित करेगी शक्तिशाली उपकरण।

  4. प्रोग्रामर जो सादगी और प्रत्यक्षता पसंद करते हैं वे PHP, या इसी तरह की भाषाओं का उपयोग करना जारी रखेंगे।

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

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


10
As long as they saw some example of how the code works, and the code doesn't fail them in producing the result they expect, they won't ever look at the documentation. When that fails, they'll look at the documentation and expect to see usage examples at the top.दुखद लेकिन सत्य।
गमलीला

9
@ गेमलीला, मुझे नहीं लगता कि हम इस बारे में दुखी होंगे। ज्ञान को लागू करने के लिए हमेशा एक से अधिक स्तर होते हैं, और किसी भी प्रणाली में दूसरों के काम और विश्वास (सहकर्मी-समीक्षा) को हमेशा लाभ दिया जा सकता है, जैसे हम रोज़ाना अंकगणित का उपयोग करते हैं और इसके पीछे काम करने वाले डरावने बीजगणितों की पूरी तरह से उपेक्षा करते हैं।
lcn

55

क्या यह लोगों को स्काला में आने से रोकने वाला है?

हां, लेकिन यह लोगों को टालमटोल करने से भी रोकेगा। मैंने संग्रह की कमी पर विचार किया है जो उच्च-प्रकार के प्रकारों का उपयोग करता है, क्योंकि स्केला ने उच्च-प्रकार के प्रकारों के लिए समर्थन प्राप्त किया है। यह एपीआई डॉक्स को और अधिक जटिल बनाता है, लेकिन यह वास्तव में उपयोग को और अधिक प्राकृतिक बनाता है।

क्या यह व्यावसायिक दुनिया में एक अकादमिक नाटक के रूप में स्काला को एक बुरा नाम देने वाला है जिसे केवल समर्पित पीएचडी छात्र समझ सकते हैं? क्या सीटीओ और सॉफ्टवेयर के प्रमुख डरने वाले हैं?

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

क्या पुस्तकालय फिर से एक समझदार विचार था?

पूर्ण रूप से। यह बाकी की भाषा और प्रकार प्रणाली के साथ संग्रह को बहुत बेहतर बनाता है, भले ही इसमें अभी भी कुछ खुरदरे किनारे हों।

यदि आप व्यावसायिक रूप से स्काला का उपयोग कर रहे हैं, तो क्या आप इस बारे में चिंतित हैं? क्या आप तुरंत 2.8 को अपनाने की योजना बना रहे हैं या यह देखने के लिए इंतजार कर रहे हैं कि क्या होता है?

मैं इसका व्यावसायिक उपयोग नहीं कर रहा हूं। मैं शायद तब तक इंतजार करूंगा जब तक कि कम से कम एक युगल 2.8.x श्रृंखला में नहीं आता, इससे पहले कि वह इसे शुरू करने की कोशिश करे ताकि कीड़े को बाहर निकाला जा सके। मैं यह भी देखने के लिए इंतजार करूंगा कि ईपीएफएल को अपने विकास में सुधार करने में कितनी सफलता मिली है। मैं जो देख रहा हूं वह आशावादी है, लेकिन मैं एक रूढ़िवादी कंपनी के लिए काम करता हूं।

का एक और सामान्य विषय "मुख्यधारा के डेवलपर्स के लिए स्काला बहुत जटिल है?" ...

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

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


31
"यह लोगों को बंद करने से भी रोकेगा"। इस। पूर्ण रूप से। scala वह पहली भाषा है जो इंजीनियरिंग को कुछ हद तक हैस्केल (इसकी प्रकार प्रणाली की शक्ति में) के साथ तुलना करती है जो हम में से कई लोगों के लिए एक संभावना है। वहाँ कोई च *** आईएनजी रास्ता है कि मैं haskell का उपयोग करने के लिए काम करने के लिए राजी कर सकता है, लेकिन scala वास्तव में एक मौका है और इसके लिए मैं इसे प्यार करता हूँ और (जब मुझे लगता है कि यह समझ में आता है) इसे अपनाने की कोशिश करें, या कम से कम स्वीकार किए जाते हैं, काम पर।
andrew Cooke

मुझसे भी +1। यह देखते हुए कि स्काला भाषाई गहराई और द्रव्यमान की तुलना में कठोरता पर अधिक जोर देता है, ये उत्तर पूरी तरह से फिट होते हैं।
कार्ल स्मोत्रिकज़

16
"कल के मुख्यधारा के डेवलपर्स उस भाषा का उपयोग करेंगे जिसका उपयोग आज के नए अनुप्रयोगों के सबसे सफल डेवलपर्स द्वारा किया जा रहा है।" +1। शानदार ढंग से कहा।
वासिल रेमेनाइक

46

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

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


43

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

विशेष रूप से अब जब इंटेलीज ने अपनी ठीक आईडीई जारी की है कि आईएमएचओ वर्तमान में सबसे अच्छा स्काला प्लगइन है, तो स्कैला विकास अपेक्षाकृत दर्द रहित है:

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

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

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

एक नौसिखिया के रूप में, मैं निरंतर और मुहावरेदार वाक्यविन्यास के साथ संघर्ष करना जारी रखता हूं। मापदंडों के बिना विधि कॉल को कोष्ठक की आवश्यकता नहीं है सिवाय इसके कि वे कहाँ करते हैं; मैच स्टेटमेंट में मामलों को एक वसा तीर ( =>) की आवश्यकता होती है , लेकिन ऐसे स्थान भी हैं जहां आपको एक पतली तीर ( ->) की आवश्यकता होती है । कई विधियों में संक्षिप्त /:या क्रिप्टिक नाम हैं जैसे \:- या अगर मैं पर्याप्त मैनुअल पेज फ्लिप करता हूं, तो मैं अपना सामान प्राप्त कर सकता हूं, लेकिन मेरे कुछ कोड पर्ल या लाइन शोर की तरह लग रहे हैं। विडंबना यह है कि सिंटैक्टिक शॉर्टहैंड के सबसे लोकप्रिय बिट्स में से एक कार्रवाई में गायब है: मैं इस तथ्य से काटता रहता हूं कि Intकोई ++विधि परिभाषित नहीं करती है ।

यह सिर्फ मेरी राय है: मुझे ऐसा लगता है कि स्काला में सी ++ की शक्ति है जो सी ++ की जटिलता और पठनीयता के साथ संयुक्त है। भाषा की वाक्यात्मक जटिलता भी एपीआई प्रलेखन को पढ़ने के लिए कठिन बनाती है।

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


9
क्षमा करें सभी टिप्पणियों का डटकर सामना करें। 1 सप्ताह व्यावहारिक रूप से किसी भी भाषा के लिए एक मजाक है, लेकिन यह प्रबंधकों को उस मजाक को अभ्यास में डालने से नहीं रोकता है। मुझे जावा में C ++ डेवलपर्स के एक समूह को "क्रैश-ट्रेन" करने के लिए 3 दिन का समय दिया गया था। मैंने 5 दिनों का समय मांगा, लेकिन बजट कारणों से छोटा हो गया।
कार्ल स्मोत्रिकज

22
अपनी पहली नौकरी के लिए मुझे इंटरव्यू के अंत में C ++ की किताब दी गई थी ताकि मैं सोमवार को काम शुरू करने से पहले सीख सकूं। तुम सब व्यर्थ हो।
टॉम हॉकिन -

12
@ टॉम @ एरिक तुम लड़कों के लिए यह आसान है। मुझे कंप्यूटर के लिए सर्किट आरेख दिए गए (फिर सीपीयू वापस नहीं), और बताया कि साक्षात्कार के रूप में बग को ठीक करने के लिए मेरे पास दो घंटे थे ।
डैनियल सी। सोबरल

33
@Daniel @Tom @ एरिक I को एक बार एक 0 और 1 दिया गया था और साक्षात्कार के दौरान रैखिक समय में शाप की समस्या को हल करने के लिए उनका उपयोग करने के लिए कहा गया था। मैंने इसे एक शॉट दिया लेकिन दुर्भाग्य से मेरे पास केवल एक्लिप्स बनाने का समय था (जिस पर मुझे संदेह है कि इसे फिर से शुरू करना है)। #tall_tale
एलेक्स मिलर

10
@ एलेक्स जो कल्पना की कमी को दर्शाता है। बाईं ओर एक बड़ा शून्य रखें, और इसके दाईं ओर दो अन्य छोटे शून्य हैं: एक दूसरे के ऊपर, दूसरा ऊपर थोड़ा बाईं ओर। इन दो छोटे शून्य के बीच एक को रखें, निचले बाएं से ऊपर दाईं ओर जा रहे हैं। कहो कि रैखिक समय में शूरवीर को हल करने का मौका है। वहाँ, आप कर रहे हैं। :-) हालांकि ग्रहण और नैकपैक की बराबरी के लिए +1। :-)
डैनियल सी। सोबरल

33

मुझे लगता है कि इस पद्धति के साथ प्राथमिक समस्या यह है कि (implicit bf : CanBuildFrom[Repr, B, That])बिना किसी स्पष्टीकरण के चलते हैं । हालांकि मुझे पता है कि क्या निहितार्थ तर्क हैं, यह दर्शाता है कि यह कॉल को कैसे प्रभावित करता है। स्केलडॉक के माध्यम से पीछा करना मुझे और अधिक भ्रमित कर देता है (कुछ वर्गों के CanBuildFromपास दस्तावेज भी हैं)।

मुझे लगता है कि एक साधारण "इसमें एक अंतर्निहित वस्तु होनी चाहिए, जो bfउस प्रकार की वस्तुओं के लिए एक बिल्डर Bको रिटर्न प्रकार में प्रदान करता है That" कुछ हद तक मदद करेगा, लेकिन यह एक तरह की मादक अवधारणा है जब आप वास्तव में करना चाहते हैं, तो यह नक्शा Aहै B'है। वास्तव में, मुझे यकीन नहीं है कि यह सही है, क्योंकि मुझे नहीं पता कि प्रकार Reprका क्या मतलब है, और Traversableनिश्चित रूप से प्रलेखन के लिए कोई सुराग नहीं देता है।

इसलिए, मैं दो विकल्पों में से हूं, दोनों में से कोई भी सुखद नहीं है:

  • मान लें कि यह केवल काम करेगा कि पुराना नक्शा कैसे काम करता है और अधिकांश अन्य भाषाओं में मानचित्र कैसे काम करता है
  • स्रोत कोड में कुछ और खोदो

मुझे लगता है कि स्काला अनिवार्य रूप से हिम्मत दिखा रहा है कि ये चीजें कैसे काम करती हैं और आखिरकार यह एक ऐसा तरीका प्रदान करता है जो कि oxbow_lakes वर्णन कर रहा है। लेकिन यह हस्ताक्षर में एक व्याकुलता है।


2
Reprट्रैवर्सेबल प्रतिनिधित्व है, अर्थात। Listया Setया Map। मुझे लगता है कि, एक रूपरेखा के रूप में, यदि आप विधि हस्ताक्षरों को देखना शुरू करने जा रहे हैं (उदाहरणों की नकल करके केवल विधियों का उपयोग करने के बजाय), तो आपको पहले सामान्य डिजाइन को समझना होगा। IMHO द स्कैलाडॉक उदाहरण के उपयोग से भरा होना चाहिए
ox 23_09 ऑक्सो_लैक्स

10
तो, मैंने कैसे निर्धारित किया होगा कि Reprइसका क्या मतलब है? मैं स्केलडॉक में एक स्पष्टीकरण की उम्मीद करूंगा, लेकिन यह मेरे लिए वास्तव में स्पष्ट नहीं था। मुझे लगता है कि यह स्केलडॉक में एक सामान्य पैटर्न है (देखो Actor.reactऔर Actor.receive- मुझे बताया गया है, और देखा है, कि वे पूरी तरह से अलग चीजें करते हैं, फिर भी उनका स्केलडॉक समान है)।
davetron5000

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

22

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

पूरी बात काफी सुरुचिपूर्ण है, वास्तव में। बिल्डर प्रकार के पैरामीटर कंपाइलर सही रिटर्न प्रकार का चयन करते हैं, जबकि अंतर्निहित पैरामीटर तंत्र वर्ग उपयोगकर्ता से इस अतिरिक्त पैरामीटर को छुपाता है। मैंने यह कोशिश की:

Map(1 -> "a", 2 -> "b").map((t) => (t._2) -> (t._1)) // returns Map("a" -> 1, "b" -> 2)
Map(1 -> "a", 2 -> "b").map((t) =>  t._2)            // returns List("a", "b")

यह बहुरूपता ही सही है।

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


20

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

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

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

traverse :: (Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b)

मैं इसे स्काला में बदलूंगा:

def traverse[A, B](f: A => F[B], a: T[A])(implicit t: Traversable[T], ap: Applicative[F]): F[T[B]

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

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

मुझे आशा है कि कोई इसके बारे में बोलता है, क्योंकि जैसा कि यह है, यह त्रुटियों को हल करने के लिए कठिन हो जाएगा, जो कि स्काला बनाने पर जोर देती है, जाहिर है उन कारणों के लिए जिन पर मुझे सख्त आपत्ति है। यही है, "औसत प्रोग्रामर (यानी बहुत कठिन!)" से गैर जिम्मेदाराना आपत्तियों का समाधान "उन्हें उनके लिए इसे आसान बनाने के लिए अपील नहीं करता है" बल्कि, बेहतर प्रोग्रामर बनने के लिए संकेत और सहायता प्रदान करते हैं। इस मुद्दे पर स्वयं और स्काला के उद्देश्य विवाद में हैं, लेकिन अपनी बात पर वापस।

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

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


3
हाय टोनी - यहाँ आपके विचारशील इनपुट के लिए धन्यवाद। मैं इस पर 2 प्रतिक्रियाएं दूंगा। पहला यह है कि मैंने "औसत प्रोग्रामर" का उल्लेख नहीं किया है और यह नहीं मानता कि स्काला का उद्देश्य एक ही है। चाहे वह मेरी कल्पना हो या अन्यथा, मेरा मानना ​​है कि मैं औसत से ऊपर हूं; हालाँकि, मुझे अभी भी लगता है कि टाइप हस्ताक्षर चुनौतीपूर्ण है! मुझे अभी भी चिंता है, दूसरे शब्दों में, कि ऊपर के औसत प्रोग्रामर, स्काला के लक्षित बाजार को दूर किया जा सकता है।
oxbow_lakes 12:15 पर

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

3
हैलो oxbow_lakes, यह सटीकता और व्यावहारिकता की कीमत पर भी, विशिष्ट प्रोग्रामर को खुश करने के लिए स्काला का एक घोषित लक्ष्य है। औसत-औसत प्रोग्रामर दूर हैं (मेरे पास कई उपाख्यान हैं), लेकिन इसलिए नहीं कि प्रकार के हस्ताक्षर कठिन हैं, बल्कि कुछ गलतियों की प्रकृति के कारण। मैंने नहीं कहा कि स्काला व्यावहारिक या सिद्धांतवादी नहीं है। इसके अलावा, मैं भी (आम?) विचार के लिए सदस्यता नहीं है कि इस तरह के एक dichotomy मौजूद है। स्काला पुस्तकालयों ने मानचित्र पर हस्ताक्षर किए हैं। मैं अब सालों से स्काला की गलतियों पर काम कर रहा हूं; विशेष रूप से पुस्तकालयों। फिर से करने का समय।
टोनी मॉरिस

5
मैं बलोच या येज को अत्यधिक सम्मानित या बुद्धिमान नहीं मानता, लेकिन वे वास्तव में काफी प्रभावशाली हैं। हां, यह दुर्भाग्यपूर्ण है।
टोनी मोरिस

9
आप स्काला के विस्तारित हस्ताक्षर से संबंधित क्यों हैं? मोनोफ़नक्टरों के लिए स्काला का नक्शा, मानक फ़ैप है। लेकिन न तो BitSet और न ही Map [A, B] मोनोफ़नक्टर हैं, फिर भी मानचित्र उनके लिए एक सार्थक परिभाषा है। यह स्काला के हस्ताक्षर की प्रेरणा है, और ट्रैवर्स इस समस्या को हल नहीं करता है। सामान्यता एक बुरी चीज क्यों है? एप्लाइड फंक्शनलर्स ट्रैक इफेक्ट्स, स्कैला में उनका क्या कहना है? अंत में, मेरा मानना ​​है कि स्काला के जेनेरिक नक्शे को एक सामान्यीकृत यात्रा के रूप में लागू किया जा सकता है, एक CanBuildFrom को स्वीकार करना और संभावित रूप से भिन्न ट्रैवर्सेबल को वापस करना: समझ के लिए बलिदान करने की आवश्यकता नहीं है!
ब्लेज़ोरब्लेड

15

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

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

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

स्केलडॉक में उदाहरण लेने के लिए ...

def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That

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

def map(f: A => B): That

अच्छा और स्पष्ट और स्पष्ट है कि यह क्या करता है। आप आश्चर्यचकित हो सकते हैं कि 'वह' क्या है, यदि आप माउस पर क्लिक करते हैं या इसे बढ़ा सकते हैं, तो उदाहरण के लिए 'बी', उस पाठ को उजागर कर सकता है।

हो सकता है कि [] घोषणा और (निहित ...) ब्लॉक के लिए एक छोटा सा आइकन इस्तेमाल किया जा सकता है, इसलिए यह स्पष्ट है कि कथन के थोड़े से टुकड़े टकरा गए हैं? इसके लिए एक टोकन का उपयोग करना कठिन है, लेकिन मैं इसका उपयोग करूंगा। अभी के लिए...

def map.(f: A => B).: That

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

ज्यादातर लोग स्केलडॉक पढ़ रहे हैं ताकि यह पता लगा सकें कि वे किस प्रकार के तरीकों को कॉल कर सकते हैं और वे किन मापदंडों से गुजर सकते हैं। हम थोड़े बहुत ही सही तरीके से उपयोगकर्ताओं को ओवरलोडिंग कर रहे हैं कि कैसे IMHO।

यहाँ एक और उदाहरण है ...

def orElse[A1 <: A, B1 >: B](that: PartialFunction[A1, B1]): PartialFunction[A1, B1]

अब अगर हम जेनेरिक घोषणापत्र को पढ़ने में आसान समझते हैं

def orElse(that: PartialFunction[A1, B1]): PartialFunction[A1, B1]

फिर अगर लोग ओवर होवर करते हैं, तो कहें, A1 हम A1 के ऐलान दिखा सकते हैं A1 <: A. कोविरिएंट और कॉन्ट्रावेरिएंट प्रकार के जेनेरिक में बहुत शोर मिलाते हैं, जो उपयोगकर्ताओं के लिए बहुत आसान तरीके से प्रस्तुत किया जा सकता है जो मुझे लगता है।


5
लेकिन परिणाम के रूप में "दैट" का क्या अर्थ है?
ब्लिसोरब्लेड

11

मैं नहीं जानता कि आप इसे कैसे तोड़ सकते हैं, लेकिन मेरे पास कैम्ब्रिज से पीएचडी है, और मैं 2.8 का उपयोग कर रहा हूं।

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

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

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


22
मुझे लगता है कि वह जानना चाहते हैं कि क्या कैम्ब्रिज से पीएचडी के बिना लोग स्काला 2.8 को संभाल सकते हैं।
केन ब्लूम

2
हाहा: टौच! खैर, मैंने कहा कि स्कैला 2.8 का उपयोग करना आसान है - मेरा सवाल यह था कि एपीआई को ब्राउज़ करने वाले व्यक्ति को क्या पसंद आएगा, यह देखने के लिए क्या पसंद है, यह देखते हुए कि उन्हें स्कैला में कोई पिछला अनुभव नहीं था।
15

1
@andrew - yout वेबसाइट ( acooke.org ) के लुक से , आप दृष्टिबाधित अवधारणाओं से असहज नहीं हैं
15

Malbolge प्रोग्रामिंग के साथ किसी ने भी कब्जा कर लिया है, भले ही यह "हैलो" हो, वर्ल्ड, किसी भी चीज से भयभीत होने की संभावना नहीं है।
कार्ल स्मोट्रिकस

10

स्काला को बिल्कुल भी नहीं जानते, हालाँकि कुछ हफ्ते पहले मैं क्लोजर नहीं पढ़ सकता था। अब मैं इसमें से अधिकांश को पढ़ सकता हूं, लेकिन सबसे सरल उदाहरणों से परे अभी तक कुछ भी नहीं लिख सकता हूं । मुझे लगता है कि स्काला अलग नहीं है। आप कैसे सीखते हैं इसके आधार पर आपको एक अच्छी किताब या पाठ्यक्रम की आवश्यकता होती है। ऊपर दिए गए नक्शे के ऐलान को पढ़ते हुए शायद मुझे मिल गया इसके बारे में 1/3।

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


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

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

7

स्काला में बहुत सारी पागल विशेषताएं हैं (विशेषकर जहां निहित मापदंडों का संबंध है) जो बहुत जटिल और अकादमिक हैं, लेकिन चीजों को उपयोग करने में आसान बनाने के लिए डिज़ाइन किए गए हैं। सबसे उपयोगी लोगों को सिंटैक्टिक शुगर मिलती है (जैसे [A <% B]कि इसका मतलब है कि टाइप ए के ऑब्जेक्ट का प्रकार बी का ऑब्जेक्ट में एक अंतर्निहित रूपांतरण है) और वे क्या करते हैं, इसकी एक अच्छी तरह से प्रलेखित व्याख्या। लेकिन ज्यादातर समय, इन पुस्तकालयों के एक ग्राहक के रूप में आप निहित मापदंडों की अनदेखी कर सकते हैं और सही काम करने के लिए उन पर भरोसा कर सकते हैं।


हां, सिंटैक्स देखने से बात तेजी से समझ में आती है।
एगागा

6

क्या यह लोगों को स्काला में आने से रोकने वाला है?

मुझे नहीं लगता कि यह मुख्य कारक है जो प्रभावित करेगा कि लोकप्रिय स्केला कैसे बनेगा, क्योंकि स्काला में बहुत अधिक शक्ति है और इसका सिंटैक्स जावा / सी ++ / पीएचपी प्रोग्रामर के लिए हास्केल, ओकेमेल, एसएमएल, लिस्प्स जितना विदेशी नहीं है। आदि..

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

क्या यह स्कैला को व्यावसायिक दुनिया में एक अकादमिक नाटक के रूप में एक बुरा नाम देने वाला है जिसे केवल समर्पित पीएचडी छात्र ही समझ सकते हैं? क्या सीटीओ और सॉफ्टवेयर के प्रमुख डरने वाले हैं?

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

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

क्या पुस्तकालय फिर से एक समझदार विचार था?

निश्चित रूप से।

यदि आप व्यावसायिक रूप से स्काला का उपयोग कर रहे हैं, तो क्या आप इस बारे में चिंतित हैं? क्या आप तुरंत 2.8 को अपनाने की योजना बना रहे हैं या यह देखने के लिए इंतजार कर रहे हैं कि क्या होता है?

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


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

एक बिल्डर अमूर्त के 2.8 स्काला संग्रह का उपयोग एक ध्वनि डिजाइन सिद्धांत है। मैं नीचे दो डिज़ाइन ट्रेडऑफ़ का पता लगाना चाहता हूं।

  1. राइट-ओनली कोड: इस सेक्शन को लिखने के बाद, मैंने कार्ल स्मोट्रिकस की टिप्पणी पढ़ी जो इस बात से सहमत है कि मुझे ट्रेडऑफ़ होने की क्या उम्मीद है। जेम्स स्ट्रेचन और davetron5000 की टिप्पणियों से पता चलता है कि इसका अर्थ (यह भी नहीं है कि [बी]) और निहितार्थ के तंत्र को सहज रूप से समझ पाना आसान नहीं है। नीचे दिए अंक # 2 में मोनॉयड का मेरा उपयोग देखें, जो मुझे लगता है कि बहुत अधिक स्पष्ट है। डेरेक महार की टिप्पणी स्काला लिखने के बारे में है, लेकिन दूसरों के स्काला को पढ़ने के बारे में जो "सामान्य मामलों में" नहीं है।

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

  2. AD-HOC संकलन डिजाइन: इस खंड को लिखने के बाद, मैंने टोनी मॉरिस की टिप्पणी पढ़ी और महसूस किया कि मैं लगभग एक ही बिंदु बना रहा हूं। शायद मेरी अधिक क्रिया प्रदर्शन से बात और स्पष्ट हो जाएगी।

    ओडस्की और मूर के साथ "फाइटिंग बिट रोट" में, दो उपयोग के मामले प्रस्तुत किए जाते हैं। वे बिटसैट टू इंट एलिमेंट्स और मैप टू टपल एलिमेंट्स को प्रतिबंधित करते हैं, और इस कारण से प्रदान किया जाता है कि सामान्य तत्व मैपिंग फ़ंक्शन, ए => बी, वैकल्पिक गंतव्य संग्रह प्रकारों का निर्माण करने में सक्षम होना चाहिए। हालाँकि, afaik यह एक श्रेणी सिद्धांत के दृष्टिकोण से त्रुटिपूर्ण है। श्रेणी सिद्धांत में सुसंगत होना और इस प्रकार कोने के मामलों से बचना, ये संग्रह प्रकार फ़ंक्शंस हैं, जिसमें प्रत्येक आकृतिवाद, ए => बी, एक ही फ़नकार की श्रेणी में वस्तुओं के बीच मैप करना होगा, सूची [ए] => सूची [बी], बिटसेट [A] => बिटसेट [B] उदाहरण के लिए, एक विकल्प एक फ़नकार है जिसे कुछ (ऑब्जेक्ट) और कोई नहीं के सेट के संग्रह के रूप में देखा जा सकता है। ऑप्शन के नो, या लिस्ट के निल से कोई अन्य सामान्य नक्शा नहीं है, अन्य फंक्शनलर्स के लिए जो डॉन '

    यहां एक ट्रेडऑफ डिज़ाइन विकल्प बनाया गया है। अपनी नई भाषा के संग्रह पुस्तकालय के लिए डिज़ाइन में, मैंने सब कुछ एक फ़ंक्शनल बनाने के लिए चुना, जिसका मतलब है कि अगर मैं एक बिटसेट लागू करता हूं, तो इसे गैर-बिट फ़ील्ड आंतरिक प्रतिनिधित्व का उपयोग करके सभी तत्व प्रकारों का समर्थन करने की आवश्यकता होती है, जब एक गैर के साथ प्रस्तुत किया जाता है- पूर्णांक प्रकार पैरामीटर, और यह कार्यक्षमता पहले से ही सेट में है जो इसे स्काला से विरासत में मिली है। और मेरे डिजाइन में मैप को केवल इसके मूल्यों को मैप करने की आवश्यकता है, और यह इसकी (कुंजी, मूल्य) जोड़ी ट्यूपल्स की मैपिंग के लिए एक अलग गैर-फंक्शनल विधि प्रदान कर सकता है। एक फ़ायदा यह है कि प्रत्येक फ़नकार आम तौर पर एक आवेदक भी होता है और शायद एक सन्यासी भी। इस प्रकार तत्व प्रकारों के बीच के सभी कार्य, जैसे ए => बी => सी => डी => ..., स्वचालित रूप से उठाए गए आवेदक प्रकारों के बीच के कार्यों के लिए उठाए जाते हैं, जैसे सूची [ए] => सूची [बी] => सूची [ C] => सूची [D] =>…। फ़ंक्टर से दूसरे संग्रह वर्ग में मैपिंग के लिए, मैं एक मानचित्र अधिभार प्रदान करता हूं, जो एक मोनॉइड लेता है, जैसे निल, कोई नहीं, 0, "", एरे (), आदि। इसलिए बिल्डर एब्स्ट्रैक्शन फ़ंक्शन एक मोनॉइड का एपेंड विधि है और स्पष्ट रूप से एक आवश्यक इनपुट पैरामीटर के रूप में आपूर्ति की जाती है, इस प्रकार कोई अदृश्य निहितार्थ नहीं है। (स्पर्शरेखा: यह इनपुट पैरामीटर गैर-रिक्त मोनॉयड्स को जोड़ने में भी सक्षम बनाता है, जो स्काला का मानचित्र डिजाइन नहीं कर सकता है।) इस तरह के रूपांतरण एक नक्शा और उसी पुनरावृत्ति पास में गुना होते हैं। इसके अलावा, मैं श्रेणी अर्थों में, "प्रभाव के साथ लागू प्रोग्रामिंग" मैकब्राइड और पैटरसन को एक ट्रैवर्सेबल भी प्रदान करता हूं, जो किसी भी ट्रैवर्सेबल से किसी भी एप्लिकेशन से पास होने के लिए मैप + फोल्ड को सक्षम बनाता है, जहां अधिकांश हर संग्रह वर्ग दोनों है।

    इसलिए आफलाक स्कैला संग्रह "एड-हॉक" इस अर्थ में है कि इसे श्रेणी के सिद्धांत में नहीं रखा गया है, और श्रेणी सिद्धांत उच्च-स्तरीय संप्रदाय शब्दार्थ का सार है। हालाँकि, स्काला के निहित बिल्डरों की उपस्थिति पहली बार "अधिक सामान्यीकृत" है, जैसे कि एक फ़नकार मॉडल + मोनोइड बिल्डर + ट्रैवर्सेबल -> आवेदक, वे किसी भी श्रेणी के अनुरूप नहीं साबित होते हैं, और इस प्रकार हम नहीं जानते कि वे किसका अनुसरण करते हैं। सबसे सामान्य ज्ञान और कोने के मामलों को क्या दिया जाएगा वे किसी भी श्रेणी के मॉडल का पालन नहीं कर सकते हैं। यह केवल सच नहीं है कि अधिक चर जोड़ने से कुछ अधिक सामान्य हो जाता है, और यह श्रेणी सिद्धांत का एक बड़ा लाभ था, यह नियम प्रदान करता है जिसके द्वारा उच्च स्तर के शब्दार्थों को उठाते हुए सामान्यता बनाए रखना है। एक संग्रह एक श्रेणी है।

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


इसके अतिरिक्त मैं अपने दिमाग में एक अधूरा विचार ले रहा हूं कि स्काला के कुछ ट्रेडऑफ्स एक परस्पर और अपरिवर्तनीय भाषा दोनों की कोशिश करने के कारण हैं, उदाहरण के लिए हास्केल या मैं जिस भाषा को विकसित कर रहा हूं, उसके विपरीत। यह टोनी मॉरिस की समझ के बारे में टिप्पणी करता है। मेरी भाषा में, कोई लूप नहीं हैं और न ही कोई परिवर्तनशील निर्माण हैं। मेरी भाषा स्काला के ऊपर (अभी के लिए) बैठ जाएगी और इसके लिए बहुत कुछ देना होगा, और यह संभव नहीं होगा यदि स्काला में सामान्य प्रकार की प्रणाली और परिवर्तनशीलता नहीं होती। हालांकि यह सच नहीं हो सकता है, क्योंकि मुझे लगता है कि ओडस्की और मूर ("फाइटिंग बिट रोट विद टाइप्स") यह कहना गलत है कि स्कैला केवल ओओपी भाषा है जिसमें उच्च-प्रकार होते हैं, क्योंकि मैंने सत्यापित किया (स्वयं और बॉब हार्पर के माध्यम से) कि मानक एमएल उनके पास है। यह भी प्रतीत होता है कि एसएमएल का प्रकार सिस्टम समान रूप से लचीला हो सकता है (1980 के दशक से), जिसे आसानी से सराहा नहीं जा सकता क्योंकि सिंटैक्स जावा (और C ++ / PHP) के समान नहीं है। किसी भी मामले में, यह स्काला की आलोचना नहीं है, बल्कि ट्रेडऑफ़्स का अधूरा विश्लेषण प्रस्तुत करने का एक प्रयास है, जो मुझे उम्मीद है कि जर्मे इस सवाल का जवाब देगा। स्काला और एसएमएल हास्केल की अक्षमता से ग्रस्त नहीं हैंडायमंड मल्टीपल इनहेरिटेंस , जो महत्वपूर्ण है और मुझे समझ में आता है कि हास्केल प्रेल्यूड में इतने सारे कार्यों को विभिन्न प्रकारों के लिए दोहराया जाता है।


तो, क्या आपकी भाषा वस्तु-उन्मुख होने जा रही है?
लापताफैक्टर

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

5

यहां राज्य की डिग्री आवश्यक है: राजनीति विज्ञान में बीए और कंप्यूटर विज्ञान में बीएड।

मुद्दे पर:

क्या यह लोगों को स्काला में आने से रोकने वाला है?

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

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

यदि आप व्यावसायिक रूप से स्काला का उपयोग कर रहे हैं, तो क्या आप इस बारे में चिंतित हैं? क्या आप तुरंत 2.8 को अपनाने की योजना बना रहे हैं या यह देखने के लिए इंतजार कर रहे हैं कि क्या होता है?

मुझे चिंता नहीं होगी।


4

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

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

मेरी मुख्य चिंता यह अधिक है: जब 2.8 रिलीज होने वाली है? इसके लिए बग रिपोर्ट कब आना बंद हो जाएगी? स्कैला टीम ने 2.8 से अधिक चबाया जा सकता है / एक बार में बहुत अधिक बदलने की कोशिश की?

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


-1

उपयोग साइट में त्रुटि संदेशों के बारे में क्या?

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

यह जानना बहुत अच्छा है कि ज्यादातर यह सरल है, लेकिन जरूरी नहीं कि यह पर्याप्त हो। कम से कम एक आदमी होना चाहिए जो इस सामान को जानता हो अगर व्यापक पुस्तकालय को डिजाइन किया जाए।


लेकिन प्राथमिक बिंदुओं में से एक उपयोगकर्ता और रचनाकारों के दृष्टिकोण से पुस्तकालय के बीच अंतर है । स्पष्ट रूप से रचनाकारों को आवश्यक भाषा सुविधाओं की एक प्रभावशाली समझ की आवश्यकता होती है (जैसे उच्चतर प्रकार के, अंतर्निहित पूर्वता) - सवाल यह है: "क्या उपयोगकर्ता करते हैं?"
oxbow_lakes
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.