scala - क्या स्कैला 2.8 संग्रह पुस्तकालय "इतिहास में सबसे लंबी आत्महत्या नोट" का मामला है?




scala-2.8 scala-collections (12)

मैंने अभी स्केल संग्रह लाइब्रेरी री-कार्यान्वयन को देखना शुरू कर दिया है जो आने वाली 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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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


Is this going to put people off coming to Scala?

I don't think it is the main factor that will affect how popular Scala will become, because Scala has a lot of power and its syntax is not as foreign to a Java/C++/PHP programmer as Haskell, OCaml, SML, Lisps, etc..

But I do think Scala's popularity will plateau at less than where Java is today, because I also think the next mainstream language must be much simplified, and the only way I see to get there is pure immutability, ie declarative like HTML, but Turing complete. However, I am biased because I am developing such a language, but I only did so after ruling out over a several month study that Scala could not suffice for what I needed.

Is this going to give Scala a bad name in the commercial world as an academic plaything that only dedicated PhD students can understand? Are CTOs and heads of software going to get scared off?

I don't think Scala's reputation will suffer from the Haskell complex. But I think that some will put off learning it, because for most programmers, I don't yet see a use case that forces them to use Scala, and they will procrastinate learning about it. Perhaps the highly-scalable server side is the most compelling use case.

And, for the mainstream market, first learning Scala is not a "breath of fresh air", where one is writing programs immediately, such as first using HTML or Python. Scala tends to grow on you, after one learns all the details that one stumbles on from the start. However, maybe if I had read Programming in Scala from the start, my experience and opinion of the learning curve would have been different.

Was the library re-design a sensible idea?

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

If you're using Scala commercially, are you worried about this? Are you planning to adopt 2.8 immediately or wait to see what happens?

I am using Scala as the initial platform of my new language. I probably wouldn't be building code on Scala's collection library if I was using Scala commercially otherwise. I would create my own category theory based library, since the one time I looked, I found Scalaz's type signatures even more verbose and unwieldy than Scala's collection library. Part of that problem perhaps is Scala's way of implementing type classes, and that is a minor reason I am creating my own language.

I decided to write this answer, because I wanted to force myself to research and compare Scala's collection class design to the one I am doing for my language. Might as well share my thought process.

The 2.8 Scala collections use of a builder abstraction is a sound design principle. I want to explore two design tradeoffs below.

  1. WRITE-ONLY CODE: After writing this section, I read Carl Smotricz's comment which agrees with what I expect to be the tradeoff. James Strachan and davetron5000's comments concur that the meaning of That (it is not even That[B]) and the mechanism of the implicit is not easy to grasp intuitively. See my use of monoid in issue #2 below, which I think is much more explicit. Derek Mahar's comment is about writing Scala, but what about reading the Scala of others that is not "in the common cases".

    One criticism I have read about Scala, is that it is easier to write it, than read the code that others have written. And I find this to be occasionally true for various reasons (eg many ways to write a function, automatic closures, Unit for DSLs, etc), but I am undecided if this is major factor. Here the use of implicit function parameters has pluses and minuses. On the plus side, it reduces verbosity and automates selection of the builder object. In Odersky's example the conversion from a BitSet, ie Set[Int], to a Set[String] is implicit. The unfamiliar reader of the code might not readily know what the type of collection is, unless they can reason well about the all the potential invisible implicit builder candidates which might exist in the current package scope. Of course, the experienced programmer and the writer of the code will know that BitSet is limited to Int, thus a map to String has to convert to a different collection type. But which collection type? It isn't specified explicitly.

  2. AD-HOC COLLECTION DESIGN: After writing this section, I read Tony Morris's comment and realized I am making nearly the same point. Perhaps my more verbose exposition will make the point more clear.

    In "Fighting Bit Rot with Types" Odersky & Moors, two use cases are presented. They are the restriction of BitSet to Int elements, and Map to pair tuple elements, and are provided as the reason that the general element mapping function, A => B, must be able to build alternative destination collection types. However, afaik this is flawed from a category theory perspective. To be consistent in category theory and thus avoid corner cases, these collection types are functors, in which each morphism, A => B, must map between objects in the same functor category, List[A] => List[B], BitSet[A] => BitSet[B]. For example, an Option is a functor that can be viewed as a collection of sets of one Some( object ) and the None. There is no general map from Option's None, or List's Nil, to other functors which don't have an "empty" state.

    There is a tradeoff design choice made here. In the design for collections library of my new language, I chose to make everything a functor, which means if I implement a BitSet, it needs to support all element types, by using a non-bit field internal representation when presented with a non-integer type parameter, and that functionality is already in the Set which it inherits from in Scala. And Map in my design needs to map only its values, and it can provide a separate non-functor method for mapping its (key,value) pair tuples. One advantage is that each functor is then usually also an applicative and perhaps a monad too. Thus all functions between element types, eg A => B => C => D => ..., are automatically lifted to the functions between lifted applicative types, eg List[A] => List[B] => List[C] => List[D] => .... For mapping from a functor to another collection class, I offer a map overload which takes a monoid, eg Nil, None, 0, "", Array(), etc.. So the builder abstraction function is the append method of a monoid and is supplied explicitly as a necessary input parameter, thus with no invisible implicit conversions. (Tangent: this input parameter also enables appending to non-empty monoids, which Scala's map design can't do.) Such conversions are a map and a fold in the same iteration pass. Also I provide a traversable, in the category sense, "Applicative programming with effects" McBride & Patterson, which also enables map + fold in a single iteration pass from any traversable to any applicative, where most every collection class is both. Also the state monad is an applicative and thus is a fully generalized builder abstraction from any traversable.

    So afaics the Scala collections is "ad-hoc" in the sense that it is not grounded in category theory, and category theory is the essense of higher-level denotational semantics. Although Scala's implicit builders are at first appearance "more generalized" than a functor model + monoid builder + traversable -> applicative, they are afaik not proven to be consistent with any category, and thus we don't know what rules they follow in the most general sense and what the corner cases will be given they may not obey any category model. It is simply not true that adding more variables makes something more general, and this was one of huge benefits of category theory is it provides rules by which to maintain generality while lifting to higher-level semantics. A collection is a category.

    I read somewhere, I think it was Odersky, as another justification for the library design, is that programming in a pure functional style has the cost of limited recursion and speed where tail recursion isn't used. I haven't found it difficult to employ tail recursion in every case that I have encountered so far.

Additionally I am carrying in my mind an incomplete idea that some of Scala's tradeoffs are due to trying to be both an mutable and immutable language, unlike for example Haskell or the language I am developing. This concurs with Tony Morris's comment about for comprehensions. In my language, there are no loops and no mutable constructs. My language will sit on top of Scala (for now) and owes much to it, and this wouldn't be possible if Scala didn't have the general type system and mutability. That might not be true though, because I think Odersky & Moors ("Fighting Bit Rot with Types") are incorrect to state that Scala is the only OOP language with higher-kinds, because I verified (myself and via Bob Harper) that Standard ML has them. Also appears SML's type system may be equivalently flexible (since 1980s), which may not be readily appreciated because the syntax is not so much similar to Java (and C++/PHP) as Scala. In any case, this isn't a criticism of Scala, but rather an attempt to present an incomplete analysis of tradeoffs, which is I hope germane to the question. Scala and SML don't suffer from Haskell's inability to do diamond multiple inheritance , which is critical and I understand is why so many functions in the Haskell Prelude are repeated for different types.


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

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

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

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

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

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

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

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

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

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


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

पहली आलोचना यह है कि मानचित्र के लिए हस्ताक्षर को कम करके, हमारे पास कुछ सामान्य है जो अधिक सामान्य है। यह विश्वास करने में एक आम त्रुटि है कि यह डिफ़ॉल्ट रूप से एक गुण है। यह नहीं है मानचित्र फ़ंक्शन को कॉन्वेंटेंट फ़ैक्टर 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]

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

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

मुझे आशा है कि कोई इसके बारे में बात करेगा, क्योंकि जैसा कि है, स्केल ने उन त्रुटियों को हल करने में कठोर परिश्रम किया है, जो स्पष्ट रूप से उन कारणों से हैं जिनके लिए मेरे पास मजबूत आपत्तियां हैं। यही है, "औसत प्रोग्रामर (यानी बहुत कठिन!) से गैर जिम्मेदार आपत्तियों का समाधान" उन्हें उनके लिए आसान बनाने के लिए खुश नहीं है "बल्कि इसके बजाय, बेहतर प्रोग्रामर बनने के लिए पॉइंटर्स और सहायता प्रदान करते हैं। Myself and Scala's objectives are in contention on this issue, but back to your point.

You were probably making your point, predicting specific responses from "the average programmer." That is, the people who will claim "but it is too complicated!" or some such. These are the Yegges or Blochs that you refer to. My response to these people of the anti-intellectualism/pragmatism movement is quite harsh and I'm already anticipating a barrage of responses, so I will omit it.

I truly hope the Scala libraries improve, or at least, the errors can be safely tucked away in a corner. Java is a language where "trying to do anything useful" is so incredibly costly, that it is often not worth it because the overwhelming amount of errors simply cannot be avoided. I implore Scala to not go down the same path.


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

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

तो, मुझे दो विकल्पों के साथ छोड़ दिया गया है, उनमें से कोई भी सुखद नहीं है:

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

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


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

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

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

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

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

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

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

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


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

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

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")

वह polymorphism सही किया है।

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


सी ++ में वही बात:

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;
}

I don't know how to break it to you, but I have a PhD from Cambridge, and I'm using 2.8 just fine.

More seriously, I hardly spent any time with 2.7 (it won't inter-op with a Java library I am using) and started using Scala just over a month ago. I have some experience with Haskell (not much), but just ignored the stuff you're worried about and looked for methods that matched my experience with Java (which I use for a living).

So: I am a "new user" and I wasn't put off - the fact that it works like Java gave me enough confidence to ignore the bits I didn't understand.

(However, the reason I was looking at Scala was partly to see whether to push it at work, and I am not going to do so yet. Making the documentation less intimidating would certainly help, but what surprised me is how much it is still changing and being developed (to be fair what surprised me most was how awesome it is, but the changes came a close second). So I guess what I am saying is that I'd rather prefer the limited resources were put into getting it into a final state - I don't think they were expecting to be this popular this soon.)


I have a maths degree from Oxford too! It took me a while to 'get' the new collections stuff. But I like it a lot now that I do. In fact, the typing of 'map' was one of the first big things that bugged me in 2.7 (perhaps since the first thing I did was subclass one of the collection classes).

Reading Martin's paper on the new 2.8 collections really helped explain the use of implicits, but yes the documentation itself definitely needs to do a better job of explaining the role of different kind of implicits within method signatures of core APIs.

My main concern is more this: when is 2.8 going to be released? When will the bug reports stop coming in for it? have scala team bitten off more than they can chew with 2.8 / tried to change too much at once?

I'd really like to see 2.8 stabilised for release as a priority before adding anything else new at all, and wonder (while watching from the sidelines) if some improvements could be made to the way the development roadmap for the scala compiler is managed.


It seems necessary to state ones degree here: BA in Political Science and B.ed in Computer Science.

To the point:

Is this going to put people off coming to Scala?

Scala is difficult, because its underlying programming paradigm is difficult. Functional programming scares a lot of people. It is possible to build closures in PHP but people rarely do. So no, not this signature but all the rest will put people off, if they do not have the specific education to make them value the power of the underlying paradigm.

If this education is available, everyone can do it. Last year I build a chess computer with a bunch of school kids in SCALA! They had their problems but they did fine in the end.

If you're using Scala commercially, are you worried about this? Are you planning to adopt 2.8 immediately or wait to see what happens?

I would not be worried.


Scala has a lot of crazy features (particularly where implicit parameters are concerned) that look very complicated and academic, but are designed to make things easy to use. The most useful ones get syntactic sugar (like [A <% B] which means that an object of type A has an implicit conversion to an object of type B) and a well-documented explanation of what they do. But most of the time, as a client of these libraries you can ignore the implicit parameters and trust them to do the right thing.





scala-collections