ห้องสมุดคอลเลกชัน Scala 2.8 เป็นกรณีของ "บันทึกการฆ่าตัวตายที่ยาวที่สุดในประวัติศาสตร์" หรือไม่? [ปิด]

ฉันเพิ่งเริ่มดูที่การนำคอลเลคชั่นห้องสมุดสกาล่ากลับมาใช้ใหม่ซึ่งกำลังจะวางตลาดในรุ่น2.8 ที่ใกล้เข้ามา ผู้ที่คุ้นเคยกับห้องสมุดจาก 2.7 จะสังเกตเห็นว่าห้องสมุดจากมุมมองการใช้งานมีการเปลี่ยนแปลงเล็กน้อย ตัวอย่างเช่น...

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

... สามารถใช้งานได้ทั้งสองรุ่น ห้องสมุดใช้ประโยชน์ได้อย่างเด่นชัดจริงๆแล้วมันยอดเยี่ยมมาก อย่างไรก็ตามผู้ที่ไม่คุ้นเคยกับ Scala ก่อนหน้านี้และได้พูดคุยกับคนอื่นเพื่อทำความเข้าใจกับภาษาในขณะนี้ต้องทำให้ความรู้สึกของลายเซ็นวิธีการเช่น:

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

สำหรับฟังก์ชั่นการใช้งานที่เรียบง่ายนี่เป็นลายเซ็นที่น่ากลัวและเป็นสิ่งที่ฉันคิดว่าตัวเองต้องดิ้นรนที่จะเข้าใจ ไม่ใช่ว่าฉันคิดว่า Scala น่าจะเป็น Java คนต่อไป (หรือ / C / C ++ / C #) - ฉันไม่เชื่อว่าผู้สร้างมันเล็งไปที่ตลาดนั้น - แต่ฉันคิดว่ามัน / เป็นไปได้อย่างแน่นอนที่ Scala จะกลายเป็น Ruby หรือ Python ถัดไป (เช่นเพื่อเพิ่มฐานผู้ใช้เชิงพาณิชย์ที่สำคัญ)

• นี่จะทำให้คนออกมาที่สกาล่าหรือไม่?
• สิ่งนี้จะทำให้สกาล่าเป็นชื่อที่ไม่ดีในโลกการค้าในฐานะของเล่นเพื่อการศึกษาที่มี แต่นักศึกษาระดับปริญญาเอกที่ทุ่มเทเท่านั้นที่สามารถเข้าใจได้ จะCTOและหัวของซอฟแวร์จะได้รับการกลัวปิด?
• ห้องสมุดออกแบบใหม่แนวคิดที่เหมาะสมหรือไม่
• หากคุณกำลังใช้งานสกาล่าในเชิงพาณิชย์คุณกังวลเรื่องนี้หรือไม่? คุณวางแผนที่จะปรับใช้ 2.8 ทันทีหรือรอเพื่อดูว่าเกิดอะไรขึ้น

Steve Yegge เคยโจมตี Scala (ในความคิดของฉันผิด ๆ ) สำหรับสิ่งที่เขาเห็นว่าเป็นระบบพิมพ์ที่ซับซ้อน ฉันกังวลว่ามีใครบางคนกำลังจะมีวันภาคสนามแพร่กระจายFUDด้วย API นี้ (คล้ายกับที่ Josh Bloch กลัวJCPจากการเพิ่มการปิดไปยัง Java)

หมายเหตุ - ฉันควรจะชัดเจนว่าในขณะที่ฉันเชื่อว่าJoshua Blochมีอิทธิพลในการปฏิเสธข้อเสนอการปิด BGGA ฉันไม่ได้อธิบายเรื่องนี้กับสิ่งอื่นใดนอกจากความเชื่อที่จัดขึ้นโดยสุจริตว่าข้อเสนอนั้นเป็นข้อผิดพลาด

แม้จะมีภรรยาและเพื่อนร่วมงานของฉันบอกฉันฉันไม่คิดว่าฉันเป็นคนงี่เง่า: ฉันมีระดับที่ดีในวิชาคณิตศาสตร์จากUniversity of Oxfordและฉันได้เขียนโปรแกรมเชิงพาณิชย์มาเกือบ 12 ปีและในScalaประมาณ หนึ่งปี (เช่นในเชิงพาณิชย์)

หมายเหตุ: ชื่อเรื่องการอักเสบเป็นใบเสนอราคาทำเกี่ยวกับแถลงการณ์ของพรรคการเมืองในสหราชอาณาจักรในช่วงต้นปี 1980 คำถามนี้เป็นอัตนัย แต่เป็นคำถามที่แท้จริงฉันได้ทำมัน CW และฉันต้องการความคิดเห็นบางอย่างเกี่ยวกับเรื่องนี้

ฉันหวังว่ามันไม่ใช่ "โน้ตฆ่าตัวตาย" แต่ฉันเห็นประเด็นของคุณ คุณตีในสิ่งที่เป็นในเวลาเดียวกันทั้งความแข็งแรงและปัญหาของการ Scala A: มันขยาย สิ่งนี้ทำให้เราสามารถใช้งานฟังก์ชั่นที่สำคัญที่สุดในห้องสมุด ในบางภาษาอื่น ๆ ลำดับที่มีลักษณะคล้ายmapหรือcollectจะสร้างขึ้นและไม่มีใครเห็นห่วงทั้งหมดที่คอมไพเลอร์ต้องผ่านเพื่อให้ทำงานได้อย่างราบรื่น ใน Scala ทุกอย่างอยู่ในห้องสมุดและเปิดให้เข้าชม

อันที่จริงแล้วฟังก์ชั่นการทำงาน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!)

ดูว่าคุณจะได้รับประเภทที่ดีที่สุดได้อย่างไร หากคุณ map Intเพื่อInts คุณจะได้รับอีกครั้งBitSetแต่ถ้าคุณ map Intเพื่อStrings Setคุณจะได้รับทั่วไป ทั้งชนิดสแตติกและการแทนค่ารันไทม์ของผลลัพธ์ของแผนที่ขึ้นอยู่กับประเภทผลลัพธ์ของฟังก์ชันที่ส่งผ่านไปยังมัน และใช้งานได้แม้ว่าชุดจะว่างเปล่าดังนั้นฟังก์ชั่นจะไม่ถูกนำไปใช้! เท่าที่ฉันรู้ไม่มีกรอบการเก็บรวบรวมอื่น ๆ ที่มีฟังก์ชั่นที่เทียบเท่า แต่จากมุมมองของผู้ใช้นี่คือสิ่งที่ควรจะทำงาน

ปัญหาที่เรามีคือเทคโนโลยีที่ชาญฉลาดทั้งหมดที่ทำให้สิ่งนี้เกิดขึ้นรั่วไหลลงในลายเซ็นประเภทซึ่งมีขนาดใหญ่และน่ากลัว แต่บางทีผู้ใช้ไม่ควรแสดงค่าเริ่มต้นเป็นลายเซ็นแบบเต็มของmap? วิธีการเกี่ยวกับถ้าเธอเงยหน้าขึ้นมองmapในBitSetเธอได้รับ:

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

(Int => Int) => BitSetเอกสารจะไม่อยู่ในกรณีที่ว่าเพราะจากมุมมองของผู้ใช้แผนที่แน่นอนมีชนิด แต่mapยังมีประเภททั่วไปที่สามารถตรวจสอบได้โดยคลิกที่ลิงค์อื่น

เรายังไม่ได้ใช้ฟังก์ชันการทำงานเช่นนี้ในเครื่องมือของเรา แต่ฉันเชื่อว่าเราต้องทำสิ่งนี้เพื่อหลีกเลี่ยงการทำให้ผู้คนกลัวและให้ข้อมูลที่มีประโยชน์มากขึ้น ด้วยเครื่องมือเช่นนี้หวังว่ากรอบงานและห้องสมุดที่ชาญฉลาดจะไม่กลายเป็นบันทึกการฆ่าตัวตาย

ฉันไม่มีปริญญาเอกหรือปริญญาในสาขา CS หรือคณิตศาสตร์หรือสาขาอื่นใด ฉันไม่มีประสบการณ์มาก่อนเกี่ยวกับสกาล่าหรือภาษาอื่นที่คล้ายคลึงกัน ฉันไม่มีประสบการณ์กับระบบประเภทที่เทียบเคียงได้จากระยะไกล ในความเป็นจริงภาษาเดียวที่ฉันมีมากกว่าความรู้ผิวเผินซึ่งแม้มีระบบพิมพ์เป็น Pascal ไม่รู้จักระบบพิมพ์ที่ซับซ้อน (แม้ว่าจะมีประเภทแบบช่วงซึ่ง AFAIK ค่อนข้างไม่มีภาษาอื่น ๆ แต่นั่นไม่เกี่ยวข้องกับที่นี่จริงๆ) อีกสามภาษาที่ฉันรู้จักคือ BASIC, Smalltalk และ Ruby ไม่มีภาษาใดที่มีระบบพิมพ์

แต่ถึงกระนั้นฉันก็ไม่มีปัญหาในการทำความเข้าใจกับลายเซ็นของmapฟังก์ชั่นที่คุณโพสต์ ดูเหมือนว่าฉันจะเหมือนลายเซ็นเดียวกันกับmapภาษาอื่น ๆ ที่ฉันเคยเห็น ความแตกต่างคือรุ่นนี้เป็นแบบทั่วไปมากขึ้น มันดูเหมือน C ++ STL มากกว่า Haskell โดยเฉพาะอย่างยิ่งมันแยกออกจากประเภทคอลเลกชันที่เป็นรูปธรรมโดยกำหนดให้อาร์กิวเมนต์เป็น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

ฉันยอมรับว่าไวยากรณ์เป็นบิต clunkier แต่ความหมายเหมือนกัน โดยทั่วไปมันเริ่มต้นจาก

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

mapซึ่งเป็นลายเซ็นแบบดั้งเดิมสำหรับ (โปรดสังเกตว่าเนื่องจากลักษณะเชิงวัตถุของ Scala พารามิเตอร์รายการอินพุตหายไปเพราะตอนนี้มันเป็นพารามิเตอร์ตัวรับโดยปริยายซึ่งทุกวิธีในระบบ 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. คุณต้องสามารถอ่านลายเซ็นประเภทได้จริง แต่แม้ว่าคุณจะไม่เคยเห็น Scala มาก่อนมันควรจะค่อนข้างง่ายเพราะมันเป็นเพียงการผสมผสานของประเภทไวยากรณ์ที่คุณรู้จักจากภาษาอื่น: VB.NET ใช้วงเล็บเหลี่ยมสำหรับความหลากหลายแบบพาราเมตริกและการใช้ลูกศรเพื่อแสดงถึง return type และเครื่องหมายโคลอนเพื่อแยกชื่อและชนิดเป็นจริง
3. คุณต้องรู้คร่าว ๆ ว่าโปรแกรมทั่วไปเกี่ยวกับอะไร (ซึ่งไม่ว่ายากที่จะคิดออกเพราะมันเป็นพื้นสะกดออกทั้งหมดในชื่อ: มันอย่างแท้จริงเพียงแค่การเขียนโปรแกรมในแฟชั่นทั่วไป)

ไม่มีของสามเหล่านี้ควรให้โปรแกรมมืออาชีพหรือแม้แต่งานอดิเรกปวดหัวอย่างจริงจัง mapเป็นฟังก์ชั่นมาตรฐานในทุกภาษาที่ออกแบบมาในช่วง 50 ปีที่ผ่านมาความจริงที่ว่าภาษาต่าง ๆ มีรูปแบบที่แตกต่างกันควรจะชัดเจนสำหรับทุกคนที่ได้ออกแบบเว็บไซต์ด้วย HTML และ CSS และคุณไม่สามารถสมัครเป็นสมาชิกโปรแกรมระยะไกล รายชื่อผู้รับจดหมายที่เกี่ยวข้องโดยไม่ต้องมีแฟน C ++ ที่น่ารำคาญจากโบสถ์ St. Stepanov อธิบายถึงคุณธรรมของการเขียนโปรแกรมทั่วไป

ใช่สกาล่ามีความซับซ้อน ใช่สกาล่ามีระบบพิมพ์ที่ทันสมัยที่สุดระบบหนึ่งที่มนุษย์รู้จักใช้แข่งขันและแม้แต่ภาษาที่เหนือกว่าอย่าง Haskell, Miranda, Clean หรือ Cyclone แต่ถ้าความซับซ้อนขัดแย้งกับความสำเร็จของภาษาการเขียนโปรแกรม C ++ คงจะเสียชีวิตไปนานแล้วและเราทุกคนจะเขียน Scheme มีหลายเหตุผลที่ว่าทำไมสกาล่าจะไม่ประสบความสำเร็จมากนัก แต่ความจริงที่ว่าโปรแกรมเมอร์ไม่สามารถที่จะเปิดสมองของพวกเขาก่อนที่จะนั่งลงที่หน้าคีย์บอร์ดอาจจะไม่เป็นตัวหลัก

สิ่งเดียวกันใน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;
}

ฉันสามารถเข้าใจความเจ็บปวดของคุณได้ แต่อย่างตรงไปตรงมาคนอย่างคุณและฉัน - หรือผู้ใช้ Stack Overflow ทั่วไป - ไม่ใช่กฎ

สิ่งที่ฉันหมายถึงคือ ... โปรแกรมเมอร์ส่วนใหญ่ไม่สนใจลายเซ็นประเภทนั้นเพราะพวกเขาจะไม่เห็นพวกเขา ! พวกเขาไม่อ่านเอกสาร

ตราบใดที่พวกเขาเห็นตัวอย่างของการทำงานของโค้ดและโค้ดไม่ได้ล้มเหลวในการสร้างผลลัพธ์ที่พวกเขาคาดหวังพวกเขาจะไม่ได้ดูเอกสารประกอบเลย เมื่อล้มเหลวพวกเขาจะดูเอกสารประกอบและคาดว่าจะเห็นตัวอย่างการใช้งานที่ด้านบน

ด้วยสิ่งเหล่านี้ในใจฉันคิดว่า:

1. ทุกคน (ในคนส่วนใหญ่) ที่เคยเจอลายเซ็นประเภทนั้นจะเยาะเย้ยสกาล่าไม่สิ้นสุดหากพวกเขาถูกกำจัดก่อนและจะถือว่าเป็นสัญลักษณ์ของพลังของสกาล่าถ้าพวกเขาชอบสกาล่า

2. หากเอกสารไม่ได้รับการปรับปรุงเพื่อให้ตัวอย่างการใช้งานและอธิบายอย่างชัดเจนว่าวิธีการคืออะไรและวิธีการใช้งานนั้นสามารถเบี่ยงเบนความสนใจจากการใช้ Scala ได้เล็กน้อย

3. ในระยะยาวมันจะไม่สำคัญ Scala นั้นสามารถทำสิ่งต่าง ๆ เช่นนั้นจะทำให้ห้องสมุดที่เขียนขึ้นสำหรับ Scala มีประสิทธิภาพและปลอดภัยยิ่งขึ้นในการใช้งาน ไลบรารีและกรอบงานเหล่านี้จะดึงดูดโปรแกรมเมอร์ให้เข้าถึงเครื่องมือที่ทรงพลัง

4. โปรแกรมเมอร์ที่ชอบความเรียบง่ายและตรงไปตรงมาจะยังคงใช้ PHP หรือภาษาที่คล้ายกัน

อนิจจาโปรแกรมเมอร์ Java เป็นเครื่องมือไฟฟ้าเป็นอย่างมากดังนั้นในการตอบว่าฉันเพิ่งแก้ไขความคาดหวังของฉันในการนำสกาลาไปใช้ ฉันไม่สงสัยเลยเลยว่าสกาล่าจะกลายเป็นภาษาหลัก ไม่ใช่ภาษาซี - เมน แต่อาจเป็นภาษา Perl หรือภาษา PHP

เมื่อพูดถึง Java คุณเคยเปลี่ยน class loader หรือไม่? คุณเคยดูสิ่งที่เกี่ยวข้องหรือไม่? Java สามารถน่ากลัวถ้าคุณดูที่นักเขียนกรอบสถานที่ทำ เป็นเพียงที่คนส่วนใหญ่ไม่ได้ สิ่งเดียวกันนี้นำไปใช้กับ Scala, IMHO แต่ผู้ใช้ในช่วงแรกมีแนวโน้มที่จะดูใต้หินแต่ละก้อนที่พวกเขาพบเพื่อดูว่ามีอะไรซ่อนอยู่หรือไม่

นี่จะทำให้คนออกมาที่สกาล่าหรือไม่?

ใช่ แต่มันจะป้องกันไม่ให้คนถูกปลด ฉันถือว่าขาดคอลเลกชันที่ใช้ประเภทที่สูงกว่าเป็นจุดอ่อนที่สำคัญนับตั้งแต่ Scala ได้รับการสนับสนุนสำหรับประเภทที่สูงขึ้น มันทำให้เอกสาร API มีความซับซ้อนมากขึ้น แต่มันทำให้การใช้งานเป็นธรรมชาติยิ่งขึ้น

นี่จะเป็นชื่อที่ไม่ดีในโลกการค้าในฐานะของเล่นเชิงวิชาการที่มี แต่นักศึกษาเอกเท่านั้นที่เข้าใจ CTOs และหัวหน้าของซอฟต์แวร์ต่าง ๆ จะต้องกลัวหรือไม่?

บางคนอาจจะ ฉันไม่คิดว่าสกาล่าสามารถเข้าถึงนักพัฒนา "มืออาชีพ" หลายคนได้บางส่วนเนื่องจากความซับซ้อนของสกาล่าและบางส่วนเนื่องจากความไม่เต็มใจของนักพัฒนาหลายคนที่จะเรียนรู้ CTO ที่จ้างนักพัฒนาดังกล่าวจะถูกทำให้หวาดกลัว

ห้องสมุดออกแบบใหม่แนวคิดที่เหมาะสมหรือไม่

อย่างแน่นอน มันทำให้คอลเล็กชั่นเข้ากันได้ดีขึ้นกับส่วนที่เหลือของภาษาและระบบพิมพ์แม้ว่ามันจะยังมีขอบที่ขรุขระอยู่บ้าง

หากคุณใช้สกาล่าในเชิงพาณิชย์คุณกังวลเกี่ยวกับเรื่องนี้หรือไม่? คุณวางแผนที่จะปรับใช้ 2.8 ทันทีหรือรอเพื่อดูว่าเกิดอะไรขึ้น

ฉันไม่ได้ใช้มันในเชิงพาณิชย์ ฉันอาจรอจนกว่าอย่างน้อยสองสาม revs ในซีรีส์ 2.8.x ก่อนที่จะพยายามแนะนำเพื่อให้ข้อบกพร่องสามารถล้างออก ฉันจะรอดูว่าความสำเร็จของ EPFL ในการปรับปรุงกระบวนการพัฒนาเป็นอย่างไร สิ่งที่ฉันเห็นดูมีความหวัง แต่ฉันทำงานให้กับ บริษัท อนุรักษ์นิยม

หนึ่งในหัวข้อทั่วไปของ "Scala ซับซ้อนเกินไปสำหรับนักพัฒนาหลักหรือไม่" ...

นักพัฒนาส่วนใหญ่กระแสหลักหรืออื่น ๆ กำลังรักษาหรือขยายระบบที่มีอยู่ ซึ่งหมายความว่าส่วนใหญ่ของสิ่งที่พวกเขาใช้ถูกกำหนดโดยการตัดสินใจที่ทำมานานแล้ว ยังมีคนอีกมากที่เขียนภาษาโคบอล

ผู้พัฒนาที่สำคัญในอนาคตจะทำงานดูแลและขยายแอปพลิเคชันที่สร้างขึ้นในวันนี้ แอปพลิเคชั่นเหล่านี้จำนวนมากไม่ได้ถูกสร้างโดยนักพัฒนาหลัก ผู้พัฒนาที่สำคัญในอนาคตจะใช้ภาษาที่นักพัฒนาซอฟต์แวร์แอปพลิเคชันใหม่ประสบความสำเร็จมากที่สุดในปัจจุบัน

วิธีหนึ่งที่ชุมชน Scala สามารถช่วยบรรเทาความกลัวของโปรแกรมเมอร์ใหม่ให้กับ Scala คือการมุ่งเน้นที่การฝึกฝนและการสอนตามตัวอย่าง - ตัวอย่างมากมายที่เริ่มต้นเล็ก ๆ และขยายใหญ่ขึ้นเรื่อย ๆ นี่คือบางเว็บไซต์ที่ใช้วิธีนี้:

• สกาล่ารายวัน
• การเรียนรู้สกาล่าในการกัดขนาดเล็ก
• เพียงสกาล่า

หลังจากใช้เวลากับไซต์เหล่านี้แล้วใคร ๆ ก็รู้ว่าสกาล่าและห้องสมุดของมันแม้ว่าอาจจะยากในการออกแบบและติดตั้ง แต่ก็ไม่ยากที่จะใช้โดยเฉพาะอย่างยิ่งในกรณีทั่วไป

ฉันได้รับปริญญาตรีจากมหาวิทยาลัยในอเมริกา "ตลาดมวลชน" ราคาถูกดังนั้นฉันบอกได้เลยว่าฉันตกอยู่ในระดับสติปัญญาของผู้ใช้ (หรืออย่างน้อยการศึกษา) ขนาด :) ฉันได้เล่นน้ำกับสกาล่ามาหลายเดือนแล้ว และทำงานกับแอพที่ไม่สำคัญสองหรือสามแอป

โดยเฉพาะอย่างยิ่งตอนที่ IntelliJ ได้เปิดตัว IDE ที่ดีกับ IMHO ที่เป็นปลั๊กอินสกาล่าที่ดีที่สุดในขณะนี้การพัฒนา Scala ค่อนข้างเจ็บปวด:

• ฉันพบว่าฉันสามารถใช้ Scala เป็น "Java โดยไม่มีเครื่องหมายอัฒภาค" นั่นคือฉันเขียนโค้ดที่ดูคล้ายกับสิ่งที่ฉันทำใน Java และได้รับประโยชน์เล็กน้อยจากความซับซ้อนทางไวยากรณ์เช่นที่ได้จากการอนุมานประเภท การจัดการข้อยกเว้นเมื่อฉันทำทุกอย่างจะสะดวกกว่า คำจำกัดความของคลาสนั้นมีความละเอียดน้อยกว่ามาก

• นาน ๆ ครั้งฉันก็สามารถเขียนบรรทัดเดียวเพื่อให้ได้ผลเทียบเท่า Java หลายบรรทัด ในกรณีที่สามารถใช้งานได้โซ่ของวิธีการทำงานเช่นแผนที่การพับการรวบรวมตัวกรองและอื่น ๆ นั้นสนุกในการเขียนและดูสง่างาม

• ฉันไม่ค่อยพบว่าตัวเองได้รับประโยชน์จากฟีเจอร์ที่ทรงพลังมากขึ้นของ Scala: ฟังก์ชั่นการปิดและ (หรือ curated) บางส่วนการจับคู่รูปแบบ ... สิ่งนั้น

ในฐานะที่เป็นมือใหม่ฉันยังคงต่อสู้กับไวยากรณ์สั้นและสำนวน การเรียกเมธอดที่ไม่มีพารามิเตอร์ไม่จำเป็นต้องใช้วงเล็บยกเว้นว่าจะใช้ที่ใด กรณีในคำสั่งการจับคู่ต้องการลูกศรอ้วน ( =>) แต่ยังมีสถานที่ที่คุณต้องการลูกศรบาง ( ->) วิธีการหลายวิธีมีชื่อที่สั้น แต่ค่อนข้างลึกลับเช่น/:หรือ\:- ฉันสามารถทำสิ่งต่าง ๆ ให้เสร็จได้ถ้าฉันพลิกหน้าหนังสือเองได้มากพอ แต่รหัสบางส่วนของฉันจบลงด้วยรูปลักษณ์เหมือน Perl หรือสัญญาณรบกวนสาย กระแทกแดกดันหนึ่งในบิตที่นิยมมากที่สุดของวากยสัมพันธ์วากยสัมพันธ์หายไปในการดำเนินการ: ฉันได้รับการกัดโดยความจริงที่Intไม่ได้กำหนด++วิธีการ

นี่เป็นเพียงความคิดเห็นของฉัน: ฉันรู้สึกว่า Scala มีพลังของ C ++ รวมกับความซับซ้อนและความสามารถในการอ่านของ C ++ ความซับซ้อนทางไวยากรณ์ของภาษาทำให้เอกสาร API ยากต่อการอ่าน

สกาล่าเป็นคนที่คิดดีมากและเก่งในหลาย ๆ ด้าน ฉันสงสัยว่านักวิชาการหลายคนชอบที่จะเขียนโปรแกรม อย่างไรก็ตามมันเต็มไปด้วยความฉลาดและ gotchas มันมีช่วงการเรียนรู้ที่สูงกว่า Java และอ่านยากกว่ามาก ถ้าฉันสแกนหน้าเวทีและดูว่านักพัฒนาซอฟต์แวร์จำนวนมากยังคงดิ้นรนกับคะแนนปลีกย่อยของ Java ฉันไม่สามารถเข้าใจว่า Scala จะกลายเป็นภาษาหลักได้ ไม่มี บริษัท ใดที่สามารถปรับการส่งนักพัฒนาในหลักสูตร Scala 3 สัปดาห์ได้เมื่อก่อนหน้านี้พวกเขาต้องการเพียงหลักสูตร Java 1 สัปดาห์เท่านั้น

ฉันคิดว่าปัญหาหลักของวิธีการนี้คือการที่(implicit bf : CanBuildFrom[Repr, B, That])ไม่มีคำอธิบายใด ๆ แม้ว่าฉันจะรู้ว่าข้อโต้แย้งโดยนัยไม่มีอะไรบ่งบอกว่าสิ่งนี้มีผลต่อการโทรอย่างไร การไล่ตาม scaladoc ทำให้ฉันสับสนมากขึ้นเท่านั้น (มีบางคลาสที่เกี่ยวข้องกับการCanBuildFromมีเอกสารประกอบ)

ฉันคิดว่าง่าย "จะต้องมีวัตถุโดยปริยายในขอบเขตbfที่ให้สร้างสำหรับวัตถุประเภทBเป็นประเภทกลับThat" จะช่วยค่อนข้าง แต่มันเป็นแนวคิดที่รุนแรงเมื่อทุกสิ่งที่คุณต้องการจะทำคือแผนที่Aเพื่อB's ในความเป็นจริงฉันไม่แน่ใจว่าถูกต้องเพราะฉันไม่รู้ว่าประเภทReprหมายถึงอะไรและเอกสารประกอบการTraversableให้เบาะแสอย่างแน่นอนไม่ให้เลย

ดังนั้นฉันเหลือสองตัวเลือกไว้ซึ่งไม่น่าพอใจเลย:

• สมมติว่ามันใช้งานได้เพียงว่าแผนที่เก่าทำงานอย่างไรและแผนที่ทำงานอย่างไรในภาษาอื่น ๆ ส่วนใหญ่
• ขุดลงในซอร์สโค้ดเพิ่มเติม

ฉันเข้าใจว่าสกาล่ากำลังเปิดเผยความกล้าในการทำงานของสิ่งเหล่านี้และท้ายที่สุดนี่คือวิธีการทำสิ่งที่ oxbow_lakes อธิบาย แต่มันเป็นสิ่งที่ทำให้ไขว้เขวในลายเซ็น

ฉันเป็นผู้เริ่มต้นสกาล่าและฉันก็ไม่เห็นปัญหาเกี่ยวกับลายเซ็นประเภทนั้น พารามิเตอร์คือฟังก์ชั่นในการแมปและพารามิเตอร์ implicit ผู้สร้างเพื่อกลับคอลเลกชันที่ถูกต้อง ชัดเจนและอ่านได้

จริง ๆ แล้วสิ่งทั้งหมดนั้นงดงาม พารามิเตอร์ชนิดตัวสร้างให้คอมไพเลอร์เลือกชนิดการส่งคืนที่ถูกต้องในขณะที่กลไกพารามิเตอร์ implicit ซ่อนพารามิเตอร์พิเศษนี้จากผู้ใช้คลาส ฉันลองสิ่งนี้:

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

นั่นคือความแตกต่างที่ถูกต้อง

ตอนนี้ได้รับแล้วมันไม่ใช่กระบวนทัศน์หลักและมันจะทำให้หลายคนหวาดกลัว แต่มันจะดึงดูดคนจำนวนมากที่เห็นคุณค่าความงดงามและสง่างาม

น่าเสียดายที่ลายเซ็นสำหรับแผนที่ที่คุณให้นั้นไม่ถูกต้องสำหรับแผนที่และมีการวิจารณ์ที่ถูกต้องตามกฎหมาย

บทวิจารณ์แรกคือการทำลายลายเซ็นของแผนที่เรามีบางสิ่งที่กว้างกว่า เป็นข้อผิดพลาดทั่วไปที่เชื่อว่านี่เป็นคุณธรรมตามค่าเริ่มต้น มันไม่ใช่ ฟังก์ชั่นแผนที่นั้นได้รับการกำหนดไว้เป็นอย่างดีในฐานะนักแสดงโควาเรียนท์ Fx -> (x -> y) -> Fy โดยยึดมั่นกับกฎหมายทั้งสองของการจัดองค์ประกอบและเอกลักษณ์ สิ่งอื่นใดที่เกี่ยวข้องกับ "แผนที่" คือการเลียนแบบ

ลายเซ็นที่ระบุนั้นเป็นอย่างอื่น แต่ไม่ใช่แผนที่ สิ่งที่ฉันคิดว่ามันพยายามจะเป็นลายเซ็น "การสำรวจ" ที่มีความพิเศษและเปลี่ยนแปลงเล็กน้อยจากกระดาษ The Essence of the Iterator Pattern นี่คือลายเซ็น:

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

ฉันจะแปลงเป็น Scala:

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

แน่นอนมันล้มเหลว - มันไม่ธรรมดาพอ! นอกจากนี้ยังแตกต่างกันเล็กน้อย (โปรดทราบว่าคุณสามารถรับแผนที่ได้ด้วยการใช้งานการท่องไปตาม Identifier functor) อย่างไรก็ตามฉันสงสัยว่าหากผู้เขียนห้องสมุดมีความตระหนักมากขึ้นเกี่ยวกับลักษณะทั่วไปของห้องสมุดที่มีการบันทึกไว้อย่างดี (การเขียนโปรแกรมประยุกต์ด้วยเอฟเฟกต์นำหน้าดังกล่าวข้างต้น) เราจะไม่เห็นข้อผิดพลาดนี้

ประการที่สองฟังก์ชั่นแผนที่เป็นกรณีพิเศษใน Scala เพราะมันใช้ในการทำความเข้าใจ น่าเสียดายที่นี่หมายความว่านักออกแบบห้องสมุดที่มีอุปกรณ์ที่ดีกว่าจะไม่สามารถเพิกเฉยต่อข้อผิดพลาดนี้ได้ กล่าวอีกนัยหนึ่งถ้าผู้ออกแบบห้องสมุดสกาล่าต้องทำลายวิธีการสิ่งนี้จะถูกเพิกเฉยได้ง่าย แต่โปรดอย่าแมป!

ฉันหวังว่าจะมีคนพูดถึงเกี่ยวกับเรื่องนี้เพราะมันจะยากที่จะแก้ไขข้อผิดพลาดที่สกาล่ายืนยันในการทำดูเหมือนว่าด้วยเหตุผลที่ฉันมีการคัดค้านอย่างหนัก นั่นคือคำตอบของ "การคัดค้านที่ไม่รับผิดชอบจากโปรแกรมเมอร์โดยเฉลี่ย (ยากเกินไป!)" ไม่ใช่ "เอาใจช่วยพวกเขาเพื่อให้ง่ายขึ้นสำหรับพวกเขา" แต่ให้คำแนะนำและความช่วยเหลือในการเป็นโปรแกรมเมอร์ที่ดีขึ้นแทน วัตถุประสงค์ของ Myself and Scala กำลังเป็นที่ถกเถียงกันในประเด็นนี้ แต่กลับไปที่ประเด็นของคุณ

คุณอาจจะทำให้ประเด็นของคุณทำนายการตอบสนองเฉพาะจาก "โปรแกรมเมอร์เฉลี่ย" นั่นคือคนที่จะอ้างสิทธิ์ "แต่มันซับซ้อนเกินไป!" หรือบางอย่างเช่น เหล่านี้คือ Yegges หรือ Blochs ที่คุณอ้างถึง การตอบสนองของฉันต่อคนเหล่านี้เกี่ยวกับขบวนการต่อต้านปัญญาชน / ลัทธิปฏิบัตินิยมนั้นค่อนข้างรุนแรงและฉันก็คาดหวังว่าจะมีการตอบโต้มากมายดังนั้นฉันจะละเว้นมัน

ฉันหวังว่าห้องสมุดสกาล่าจะปรับปรุงหรืออย่างน้อยก็ข้อผิดพลาดสามารถซ่อนตัวได้อย่างปลอดภัยในมุมหนึ่ง Java เป็นภาษาที่ "พยายามทำสิ่งที่มีประโยชน์" นั้นมีค่าใช้จ่ายสูงอย่างไม่น่าเชื่อบ่อยครั้งที่มันไม่คุ้มเพราะข้อผิดพลาดจำนวนมากไม่สามารถหลีกเลี่ยงได้ ฉันขอร้องสกาล่าไม่ให้ลงไปในเส้นทางเดียวกัน

ฉันเห็นด้วยกับคำถามและคำตอบของมาร์ตินโดยสิ้นเชิง :) แม้ใน Java การอ่าน javadoc กับ generics นั้นยากกว่าที่ควรจะเป็นเพราะมีเสียงรบกวนเป็นพิเศษ นี่คือการรวมกันใน Scala ที่มีการใช้พารามิเตอร์โดยนัยเช่นในรหัสตัวอย่างของคำถาม

ฉันไม่คิดว่ามันจะมีปัญหากับภาษาต่อ se - ฉันคิดว่ามันเป็นปัญหาการใช้เครื่องมือมากขึ้น และในขณะที่ฉันเห็นด้วยกับสิ่งที่Jörg W Mittag พูดฉันคิดว่าการดู scaladoc (หรือเอกสารประเภทหนึ่งใน IDE ของคุณ) - มันควรจะต้องใช้พลังสมองน้อยที่สุดเท่าที่จะเป็นไปได้ ไม่จำเป็นต้องทำการแฮ็กพีชคณิตสักนิดหน่อยเพื่อรับมัน :)

แน่นอนว่า IDEs ต้องการวิธีที่ดีในการแสดงวิธีการทั้งหมดสำหรับตัวแปร / การแสดงออก / ประเภทใด ๆ (เช่นเดียวกับตัวอย่างของ Martin ที่สามารถให้อินทิกรัลทั้งหมดได้อินไลน์เพื่อให้ดีและง่ายต่อการติดตาม) ฉันชอบความคิดของมาร์ตินในการซ่อนนัยโดยปริยายเช่นกัน

เพื่อยกตัวอย่างใน scaladoc ...

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

เมื่อดูสิ่งนี้ใน scaladoc ฉันต้องการบล็อกทั่วไป [B นั่นคือ] ถูกซ่อนโดยค่าเริ่มต้นรวมถึงพารามิเตอร์โดยนัย (บางทีพวกเขาแสดงถ้าคุณวางเมาส์เหนือไอคอนเล็ก ๆ ด้วยเมาส์) - เป็นสิ่งพิเศษที่จะทำให้สับสน อ่านมันซึ่งมักจะไม่เกี่ยวข้อง เช่นลองนึกภาพถ้ามันดูเหมือน ...

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

ดีและชัดเจนและชัดเจนว่ามันทำอะไร คุณอาจสงสัยว่า 'นั่น' คืออะไรหากคุณวางเมาส์ไว้หรือคลิกมันอาจขยายข้อความ [B] ที่เน้นข้อความ 'That'

บางทีไอคอนเล็ก ๆ อาจใช้สำหรับการประกาศ [] และ (โดยปริยาย ... ) บล็อกเพื่อให้ชัดเจนว่ามีคำสั่งเล็ก ๆ น้อย ๆ ที่ยุบอยู่หรือไม่ มันยากที่จะใช้โทเค็นสำหรับมัน แต่ฉันจะใช้ สำหรับตอนนี้...

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

ดังนั้นโดยค่าเริ่มต้น 'สัญญาณรบกวน' ของระบบประเภทจะถูกซ่อนจากหลัก 80% ของสิ่งที่ผู้คนต้องการดู - ชื่อวิธี, ประเภทพารามิเตอร์และประเภทการส่งคืนในลักษณะที่เรียบง่ายดี - มีลิงก์ขยายเล็กน้อยเพื่อดูรายละเอียด ถ้าคุณแคร์มากจริงๆ

คนส่วนใหญ่กำลังอ่าน scaladoc เพื่อหาวิธีการที่พวกเขาสามารถโทรหาประเภทและพารามิเตอร์ที่พวกเขาสามารถผ่าน เรากำลังให้รายละเอียดกับผู้ใช้มากจนเกินไปจนเกินไปว่า 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. ประเภท Covariant และ contravariant ใน generics เพิ่มเสียงมากมายเช่นกันซึ่งสามารถแสดงในวิธีที่ง่ายกว่ามากในการหาผู้ใช้ที่ฉันคิดว่า

ฉันไม่รู้วิธีที่จะทำลายคุณ แต่ฉันมีปริญญาเอกจากเคมบริดจ์และฉันใช้ 2.8 ได้ดี

อย่างจริงจังยิ่งขึ้นฉันแทบจะไม่ได้ใช้เวลากับ 2.7 (จะไม่ทำงานร่วมกับห้องสมุด Java ที่ฉันใช้) และเริ่มใช้ Scala เมื่อเดือนที่แล้ว ฉันมีประสบการณ์กับ Haskell (ไม่มาก) แต่เพียงเพิกเฉยสิ่งที่คุณกังวลและมองหาวิธีการที่ตรงกับประสบการณ์ของฉันกับ Java (ซึ่งฉันใช้เพื่อหาเลี้ยงชีพ)

ดังนั้น: ฉันเป็น "ผู้ใช้ใหม่" และฉันก็ไม่ได้ถูกปลดออก - ความจริงที่ว่ามันใช้งานได้เหมือน Java ทำให้ฉันมั่นใจพอที่จะเพิกเฉยต่อบิตที่ฉันไม่เข้าใจ

(อย่างไรก็ตามเหตุผลที่ฉันดู Scala นั้นเป็นส่วนหนึ่งเพื่อดูว่าจะผลักมันในที่ทำงานหรือไม่และฉันยังไม่ทำเช่นนั้นการทำเอกสารน้อยกว่าการข่มขู่จะช่วยได้แน่นอน แต่สิ่งที่ทำให้ฉันประหลาดใจก็คือ การเปลี่ยนแปลงและการพัฒนา (เพื่อความยุติธรรมสิ่งที่ทำให้ฉันประหลาดใจมากที่สุดคือความยอดเยี่ยม แต่การเปลี่ยนแปลงเกิดขึ้นอย่างใกล้ชิดในวินาที) ดังนั้นฉันเดาว่าฉันกำลังพูดอะไรอยู่ว่าฉันต้องการทรัพยากรที่มีอยู่อย่าง จำกัด รัฐสุดท้าย - ฉันไม่คิดว่าพวกเขาคาดหวังว่าจะได้รับความนิยมในไม่ช้านี้)

ไม่ทราบว่าสกาล่าเลย แต่ไม่กี่สัปดาห์ที่ผ่านมาฉันไม่สามารถอ่าน Clojure ได้ ตอนนี้ผมสามารถอ่านมากที่สุดของมัน แต่ไม่สามารถเขียนอะไรเลยเกินง่ายที่สุดตัวอย่าง ฉันสงสัยว่าสกาล่าไม่แตกต่างกัน คุณต้องมีหนังสือหรือหลักสูตรที่ดีขึ้นอยู่กับว่าคุณเรียนรู้อย่างไร แค่อ่านประกาศแผนที่ข้างบนฉันอาจจะได้หนึ่งในสามของมัน

ฉันเชื่อว่าปัญหาที่ใหญ่กว่านั้นไม่ใช่ไวยากรณ์ของภาษาเหล่านี้ แต่การนำไปใช้และทำให้เกิดกระบวนทัศน์ภายในที่ทำให้พวกเขาสามารถใช้งานได้ในรหัสการผลิตประจำวัน สำหรับผม Java ไม่ได้ก้าวกระโดดครั้งใหญ่จาก C ++ ซึ่งไม่ได้ก้าวกระโดดครั้งใหญ่จากซีซึ่งไม่ได้เป็นก้าวกระโดดที่ทุกคนจากปาสกาลมิได้พื้นฐาน ฯลฯ ... แต่เขียนโปรแกรมในภาษาทำงานเช่น Clojure เป็นก้าวกระโดดครั้งใหญ่ (สำหรับ ต่อไป) ฉันเดาใน Scala คุณสามารถโค้ดในสไตล์ Java หรือสไตล์ Scala แต่ใน Clojure คุณจะสร้างความยุ่งเหยิงพยายามที่จะรักษานิสัยที่จำเป็นของคุณจาก Java

Scala มีคุณสมบัติที่บ้าคลั่งมากมาย (โดยเฉพาะอย่างยิ่งที่เกี่ยวข้องกับพารามิเตอร์โดยปริยาย) ที่ดูซับซ้อนและเป็นเชิงวิชาการ แต่ถูกออกแบบมาเพื่อให้ใช้งานง่าย สิ่งที่มีประโยชน์มากที่สุดจะได้รับน้ำตาลซินแทคติค (เช่น[A <% B]ซึ่งหมายความว่าวัตถุประเภท A มีการแปลงเป็นวัตถุประเภท B โดยปริยาย) และคำอธิบายที่มีเอกสารครบถ้วนเกี่ยวกับสิ่งที่พวกเขาทำ แต่ส่วนใหญ่ในฐานะลูกค้าของห้องสมุดเหล่านี้คุณสามารถละเว้นพารามิเตอร์โดยนัยและไว้วางใจให้พวกเขาทำสิ่งที่ถูกต้อง

นี่จะทำให้คนออกมาที่สกาล่าหรือไม่?

ฉันไม่คิดว่ามันเป็นปัจจัยหลักที่จะส่งผลกระทบต่อความนิยมของ Scala เนื่องจาก Scala มีพลังมากและไวยากรณ์ของมันไม่ต่างจากโปรแกรมเมอร์ Java / C ++ / PHP เช่น Haskell, OCaml, SML, Lisps ฯลฯ ..

แต่ฉันคิดว่าความนิยมของสกาล่าจะราบเรียบน้อยกว่าที่ Java เป็นอยู่ในปัจจุบันเพราะฉันยังคิดว่าภาษากระแสหลักถัดไปจะต้องเรียบง่ายกว่ามาก . อย่างไรก็ตามฉันลำเอียงเพราะฉันกำลังพัฒนาภาษาดังกล่าว แต่ฉันก็ทำเช่นนั้นได้หลังจากศึกษาหลายเดือนว่าสกาล่าไม่สามารถพอเพียงสำหรับสิ่งที่ฉันต้องการ

สิ่งนี้จะทำให้สกาล่าเป็นชื่อที่ไม่ดีในโลกการค้าในฐานะของเล่นเพื่อการศึกษาที่มี แต่นักศึกษาระดับปริญญาเอกที่ทุ่มเทเท่านั้นที่สามารถเข้าใจได้? CTOs และหัวหน้าของซอฟต์แวร์ต่าง ๆ จะต้องกลัวหรือไม่?

ฉันไม่คิดว่าชื่อเสียงของสกาล่าจะได้รับจากคอมเพล็กซ์ Haskell แต่ฉันคิดว่าบางคนจะชะลอการเรียนรู้เพราะสำหรับโปรแกรมเมอร์ส่วนใหญ่ฉันยังไม่เห็นกรณีการใช้งานที่บังคับให้พวกเขาใช้ Scala และพวกเขาจะเลื่อนการเรียนรู้เกี่ยวกับเรื่องนี้ บางทีฝั่งเซิร์ฟเวอร์ที่ปรับขนาดได้เป็นกรณีการใช้งานที่น่าสนใจที่สุด

และสำหรับตลาดหลักการเรียนรู้ครั้งแรกของสกาล่าไม่ใช่ "ลมหายใจแห่งอากาศบริสุทธิ์" ที่หนึ่งกำลังเขียนโปรแกรมทันทีเช่นครั้งแรกโดยใช้ HTML หรือ Python สกาล่ามีแนวโน้มที่จะเติบโตกับคุณหลังจากที่ได้เรียนรู้รายละเอียดทั้งหมดที่หนึ่งสะดุดตั้งแต่เริ่มต้น อย่างไรก็ตามถ้าฉันได้อ่านการเขียนโปรแกรมใน Scala ตั้งแต่เริ่มต้นประสบการณ์และความคิดเห็นของฉันเกี่ยวกับช่วงการเรียนรู้จะแตกต่างกัน

ห้องสมุดออกแบบใหม่แนวคิดที่เหมาะสมหรือไม่

อย่างแน่นอน.

หากคุณกำลังใช้งานสกาล่าในเชิงพาณิชย์คุณกังวลเรื่องนี้หรือไม่? คุณวางแผนที่จะปรับใช้ 2.8 ทันทีหรือรอเพื่อดูว่าเกิดอะไรขึ้น

ฉันใช้ Scala เป็นแพลตฟอร์มเริ่มต้นของภาษาใหม่ของฉัน ฉันอาจจะไม่สร้างรหัสในห้องสมุดรวบรวมของ Scala ถ้าฉันใช้ Scala ในเชิงพาณิชย์เป็นอย่างอื่น ฉันจะสร้างห้องสมุดตามหมวดหมู่ทฤษฎีของฉันเองตั้งแต่ครั้งแรกที่ฉันดูฉันพบว่าลายเซ็นประเภทของ Scalaz ยิ่งละเอียดและเทอะทะกว่าห้องสมุดเก็บของ Scala ส่วนหนึ่งของปัญหานั้นอาจเป็นวิธีของ Scala ในการนำคลาสเรียนมาใช้และนั่นเป็นเหตุผลเล็กน้อยที่ฉันสร้างภาษาของตัวเอง

ฉันตัดสินใจที่จะเขียนคำตอบนี้เพราะฉันต้องการบังคับให้ฉันค้นคว้าและเปรียบเทียบการออกแบบคลาสคอลเลคชัน Scala กับที่ฉันทำเพื่อภาษาของฉัน อาจแบ่งปันกระบวนการคิดของฉันด้วย

คอลเล็กชั่น Scala 2.8 การใช้ตัวสร้างนามธรรมเป็นหลักการออกแบบเสียง ฉันต้องการสำรวจการแลกเปลี่ยนสองแบบด้านล่างนี้

1. รหัสสำหรับเขียนเท่านั้น: หลังจากเขียนหัวข้อนี้ฉันอ่านความคิดเห็นของ Carl Smotriczซึ่งเห็นด้วยกับสิ่งที่ฉันคาดหวังว่าจะเป็นการแลกเปลี่ยน James Strachan และความคิดเห็นของ davetron5000 เห็นพ้องกันว่าความหมายของ That (มันไม่ใช่แม้แต่ [B]) และกลไกของนัยก็ไม่ใช่เรื่องง่ายที่จะเข้าใจโดยสังหรณ์ใจ ดูการใช้งาน monoid ในฉบับที่ 2 ด้านล่างซึ่งฉันคิดว่าชัดเจนกว่านี้มาก ความคิดเห็นของดีเร็กมาฮาร์เป็นเรื่องเกี่ยวกับการเขียนสกาล่า แต่สิ่งที่เกี่ยวกับการอ่านสกาล่าของผู้อื่นที่ไม่ใช่ "ในกรณีทั่วไป"

   คำวิจารณ์อย่างหนึ่งที่ฉันได้อ่านเกี่ยวกับสกาล่าคือการเขียนมันง่ายกว่าอ่านโค้ดที่คนอื่นเขียน และฉันพบว่าสิ่งนี้เป็นจริงในบางครั้งด้วยเหตุผลต่าง ๆ (เช่นหลายวิธีในการเขียนฟังก์ชั่นการปิดอัตโนมัติหน่วยสำหรับ DSL ฯลฯ ) แต่ฉันไม่แน่ใจว่านี่เป็นปัจจัยสำคัญหรือไม่ นี่คือการใช้พารามิเตอร์ฟังก์ชันโดยนัยมีข้อดีและข้อเสีย ในด้านบวกจะช่วยลดความฟุ่มเฟื่อยและเลือกวัตถุสร้างโดยอัตโนมัติ ใน Odersky'sตัวอย่างการแปลงจาก BitSet เช่น Set [Int] เป็น Set [String] นั้นเป็นนัย ตัวอ่านที่ไม่คุ้นเคยของโค้ดอาจไม่ทราบว่าเป็นคอลเลกชันประเภทใดเว้นแต่พวกเขาสามารถให้เหตุผลที่ดีเกี่ยวกับตัวสร้างตัวสร้างโดยนัยที่มองไม่เห็นทั้งหมดซึ่งอาจมีอยู่ในขอบเขตแพ็คเกจปัจจุบัน แน่นอนโปรแกรมเมอร์ที่มีประสบการณ์และนักเขียนของรหัสจะรู้ว่า BitSet จำกัด อยู่ที่ Int ดังนั้นแผนที่ไปยัง String จะต้องแปลงเป็นคอลเลกชันประเภทอื่น แต่คอลเล็กชันประเภทใด มันไม่ได้ระบุไว้อย่างชัดเจน

2. การออกแบบคอลเลคชั่น AD-HOC: หลังจากเขียนหัวข้อนี้ฉันได้อ่านความคิดเห็นของโทนี่มอร์ริสและรู้ว่าฉันกำลังทำสิ่งเดียวกัน บางทีการอธิบายอย่างละเอียดมากขึ้นของฉันอาจทำให้ประเด็นชัดเจนยิ่งขึ้น

   ใน "Fighting Bit Rot with Types" Odersky & Moors มีการใช้สองกรณี สิ่งเหล่านี้เป็นข้อ จำกัด ขององค์ประกอบ BitSet to Int และ Map ในการจับคู่องค์ประกอบ tuple และได้รับการจัดให้เป็นเหตุผลที่ฟังก์ชั่นการจับคู่องค์ประกอบทั่วไป A => B จะต้องสามารถสร้างประเภทคอลเลกชันปลายทางได้ อย่างไรก็ตาม Afaik นี้มีข้อบกพร่องจากมุมมองทฤษฎีหมวดหมู่ เพื่อให้สอดคล้องในทฤษฎีหมวดหมู่และหลีกเลี่ยงกรณีมุมประเภทคอลเลกชันเหล่านี้คือ functors ซึ่งแต่ละมอร์ฟิซึ่มส์ A => B จะต้องแมประหว่างวัตถุในประเภท functor เดียวกัน List [A] => List [B], BitSet [A] => BitSet [B] ตัวอย่างเช่นตัวเลือกเป็น functor ที่สามารถดูได้เป็นชุดของชุดหนึ่งบาง (วัตถุ) และไม่มี ไม่มีแผนที่ทั่วไปจากตัวเลือกไม่มีหรือไม่มีรายการของไปยังฟังก์ชันอื่น ๆ ที่ไม่มี

   มีตัวเลือกการออกแบบให้แลกกันที่นี่ ในการออกแบบไลบรารีคอลเลกชันของภาษาใหม่ของฉันฉันเลือกที่จะทำให้ทุกสิ่งเป็น functor ซึ่งหมายความว่าถ้าฉันใช้ BitSet มันจำเป็นต้องสนับสนุนองค์ประกอบทุกประเภทโดยใช้การเป็นตัวแทนเขตข้อมูลที่ไม่ใช่บิตเมื่อนำเสนอด้วย non- พารามิเตอร์ชนิดจำนวนเต็มและฟังก์ชันนั้นมีอยู่แล้วในชุดซึ่งสืบทอดมาจากใน Scala และแผนที่ในการออกแบบของฉันจำเป็นต้องแมปเฉพาะค่าของมันและสามารถให้วิธีการที่ไม่ใช่ functor แยกต่างหากสำหรับการแมปทูเปิล (คีย์ค่า) ของการจับคู่ ข้อดีอย่างหนึ่งก็คือ functor แต่ละคนนั้นมักจะใช้และอาจ monad เกินไป ดังนั้นฟังก์ชั่นทั้งหมดระหว่างประเภทองค์ประกอบเช่น A => B => C => D => ... จะถูกยกโดยอัตโนมัติไปยังฟังก์ชั่นระหว่างประเภทการประยุกต์ใช้ยกเช่นรายการ [A] => รายการ [B] => รายการ [ C] => รายการ [D] => .... สำหรับการแมปจาก functor ไปยังคลาสคอลเลคชันอื่นฉันขอเสนอการโอเวอร์โหลดแผนที่ซึ่งใช้ monoid เช่น Nil, None, 0, "", Array () ฯลฯ ดังนั้นฟังก์ชัน abstraction ของ builder จึงเป็นวิธีต่อท้ายของ monoid และ มีการระบุอย่างชัดเจนว่าเป็นพารามิเตอร์ป้อนข้อมูลที่จำเป็นดังนั้นจึงไม่มีการแปลงโดยนัยที่มองไม่เห็น (แทนเจนต์: พารามิเตอร์อินพุตนี้ยังช่วยให้ผนวกกับ monoids ที่ไม่ว่างซึ่งการออกแบบแผนที่ของ Scala ไม่สามารถทำได้) การแปลงดังกล่าวเป็นแผนที่และการพับซ้ำในการทำซ้ำแบบเดียวกัน ในแง่ของหมวดหมู่ "การเขียนโปรแกรมประยุกต์ที่มีเอฟเฟกต์" McBride & Patterson ซึ่งเปิดใช้งานแผนที่ + พับในการวนซ้ำครั้งเดียวจากการสำรวจเส้นทางไปสู่การประยุกต์ใช้ใด ๆ

   ดังนั้น afaics คอลเลกชันสกาล่าคือ "ad-hoc" ในแง่ที่ว่ามันไม่ได้มีพื้นฐานมาจากทฤษฎีหมวดหมู่และทฤษฎีหมวดหมู่เป็นสาระสำคัญของซีแมนทิคส์การตีความในระดับที่สูงขึ้น ถึงแม้ว่าผู้สร้างโดยนัยของ Scala จะปรากฏตัวครั้งแรก "มีความชัดเจนมากกว่า" มากกว่าโมเดล functor + monoid builder + traversable -> การใช้งานพวกเขาเป็น afaik ที่ไม่ได้รับการพิสูจน์แล้วว่าสอดคล้องกับหมวดหมู่ใด ๆ และดังนั้นเราจึงไม่รู้ว่า ความรู้สึกทั่วไปมากที่สุดและสิ่งที่จะได้รับมุมกรณีพวกเขาอาจไม่ปฏิบัติตามรูปแบบหมวดหมู่ มันไม่เป็นความจริงเลยที่การเพิ่มตัวแปรทำให้บางสิ่งเป็นเรื่องทั่วไปมากขึ้นและนี่คือหนึ่งในผลประโยชน์มหาศาลของทฤษฎีหมวดหมู่คือมันมีกฎที่จะรักษากฎเกณฑ์โดยทั่วไปในขณะที่ยกระดับความหมายระดับสูงขึ้น คอลเลกชันเป็นหมวดหมู่

   ฉันอ่านบางที่ฉันคิดว่ามันเป็น Odersky เป็นอีกเหตุผลสำหรับการออกแบบห้องสมุดคือการเขียนโปรแกรมในลักษณะการทำงานที่บริสุทธิ์มีค่าใช้จ่ายในการสอบถามซ้ำ จำกัด และความเร็วที่ไม่ได้เรียกใช้ tail recursion ฉันไม่ได้พบว่ามันยากที่จะใช้การเรียกซ้ำหางในทุกกรณีที่ฉันได้พบจนถึงตอนนี้

นอกจากนี้ฉันกำลังคิดถึงความคิดที่ไม่สมบูรณ์ที่การแลกเปลี่ยนของ Scala บางอย่างเกิดขึ้นเนื่องจากพยายามเป็นทั้งภาษาที่ไม่แน่นอนและไม่เปลี่ยนรูปซึ่งแตกต่างจากภาษา Haskell หรือภาษาที่ฉันกำลังพัฒนา เห็นด้วยกับความคิดเห็นของโทนี่มอร์ริสเกี่ยวกับความเข้าใจ ในภาษาของฉันไม่มีลูปและไม่มีโครงสร้างที่ไม่แน่นอน ภาษาของฉันจะอยู่ด้านบนของสกาล่า (ตอนนี้) และเป็นหนี้มากและมันจะเป็นไปไม่ได้ถ้าสกาล่าไม่มีระบบประเภททั่วไปและความไม่แน่นอน นั่นอาจไม่เป็นความจริงเพราะฉันคิดว่า Odersky & Moors ("การต่อสู้ Bit Rot ด้วยประเภท") ไม่ถูกต้องที่จะระบุว่า Scala เป็นภาษา OOP เพียงภาษาเดียวที่มีชนิดสูงกว่าเพราะฉันตรวจสอบ (ตัวเองและผ่าน Bob Harper) มาตรฐานนั้น ML มีพวกเขา ปรากฏว่าระบบประเภทของ SML อาจมีความยืดหยุ่นเท่ากัน (ตั้งแต่ปี 1980) ซึ่งอาจไม่ได้รับการชื่นชมอย่างง่ายดายเนื่องจากไวยากรณ์ไม่เหมือนกับ Java (และ C ++ / PHP) เท่า Scala ไม่ว่าในกรณีใดนี่ไม่ใช่คำวิจารณ์ของสกาล่า แต่เป็นความพยายามที่จะนำเสนอการวิเคราะห์ที่ไม่สมบูรณ์ของการแลกเปลี่ยนซึ่งฉันหวังว่าจะเป็นคำถามที่ดี Scala และ SML ไม่ต้องทนทุกข์กับ Haskellไดมอนด์หลายมรดกซึ่งมีความสำคัญและฉันเข้าใจว่าทำไมฟังก์ชั่นมากมายใน Haskell Prelude จึงถูกทำซ้ำสำหรับประเภทที่แตกต่างกัน

ดูเหมือนว่าจำเป็นต้องระบุระดับปริญญาตรีที่นี่: ปริญญาตรีสาขารัฐศาสตร์และปริญญาตรีสาขาวิทยาศาสตร์คอมพิวเตอร์

ตรงประเด็น:

นี่จะทำให้คนออกมาที่สกาล่าหรือไม่?

สกาล่าเป็นเรื่องยากเพราะกระบวนทัศน์การเขียนโปรแกรมพื้นฐานของมันเป็นเรื่องยาก การเขียนโปรแกรมฟังก์ชั่นทำให้ผู้คนจำนวนมากกลัว เป็นไปได้ที่จะสร้างการปิดใน PHP แต่คนไม่ค่อยทำ ดังนั้นไม่ใช่ไม่ใช่ลายเซ็นนี้ แต่ส่วนที่เหลือทั้งหมดจะทำให้ผู้คนหลงทางถ้าพวกเขาไม่มีการศึกษาที่เฉพาะเจาะจงเพื่อทำให้พวกเขาเห็นคุณค่าของพลังของกระบวนทัศน์พื้นฐาน

หากการศึกษานี้พร้อมใช้งานทุกคนสามารถทำได้ ปีที่แล้วฉันสร้างคอมพิวเตอร์หมากรุกกับกลุ่มเด็กนักเรียนใน SCALA! พวกเขามีปัญหา แต่ก็ทำได้ดีในที่สุด

หากคุณกำลังใช้งานสกาล่าในเชิงพาณิชย์คุณกังวลเรื่องนี้หรือไม่? คุณวางแผนที่จะปรับใช้ 2.8 ทันทีหรือรอเพื่อดูว่าเกิดอะไรขึ้น

ฉันจะไม่กังวล

ฉันมีวิชาคณิตศาสตร์จากอ๊อกซฟอร์ดด้วยเช่นกัน! ฉันใช้เวลาสักครู่เพื่อ 'รับ' สิ่งสะสมใหม่ แต่ฉันชอบมันมากตอนนี้ที่ฉันทำ ในความเป็นจริงการพิมพ์ 'map' เป็นหนึ่งในสิ่งที่ยิ่งใหญ่ครั้งแรกที่ bugged ฉันใน 2.7 (อาจเป็นเพราะสิ่งแรกที่ฉันทำคือ subclass หนึ่งในชั้นเรียนคอลเลกชัน)

การอ่านกระดาษของ Martin ในคอลเล็กชั่น 2.8 ใหม่ช่วยอธิบายการใช้ implicits ได้จริง ๆ แต่ใช่ว่าตัวเอกสารเองต้องทำงานได้ดีกว่าในการอธิบายบทบาทของ implicits ชนิดต่างๆภายในลายเซ็นต์เมธอดของ core APIs

ความกังวลหลักของฉันคือสิ่งนี้มากกว่า: เมื่อไรจะปล่อย 2.8? รายงานข้อผิดพลาดจะหยุดลงเมื่อไหร่ ทีมสกาล่าถูกกัดมากกว่าที่พวกเขาสามารถเคี้ยวด้วย 2.8 / พยายามเปลี่ยนมากเกินไปในครั้งเดียว?

ฉันอยากจะเห็นว่า 2.8 เสถียรสำหรับการเปิดตัวเป็นลำดับความสำคัญก่อนที่จะเพิ่มสิ่งใหม่ ๆ และสงสัย (ในขณะที่ดูจากข้างสนาม) หากการปรับปรุงบางอย่างสามารถทำให้วิธีการพัฒนาแผนงานสำหรับคอมไพเลอร์สกาล่าได้รับการจัดการ

สิ่งที่เกี่ยวกับข้อผิดพลาดในการใช้งานเว็บไซต์?

และสิ่งที่เกี่ยวกับเมื่อมาถึงกรณีการใช้งานหนึ่งต้องรวมประเภทที่มีอยู่กับหนึ่งที่กำหนดเองที่เหมาะกับ DSL เราจะต้องมีการศึกษาที่ดีในเรื่องของการเชื่อมโยงลำดับความสำคัญการแปลงโดยปริยายพารามิเตอร์โดยนัยชนิดที่สูงกว่าและประเภทที่อาจมีอยู่

เป็นเรื่องที่ดีมากที่รู้ว่าส่วนใหญ่เป็นเรื่องง่าย แต่ก็ไม่เพียงพอ อย่างน้อยก็ต้องมีผู้ชายคนหนึ่งที่รู้เรื่องนี้ถ้าห้องสมุดที่กว้างขวางได้รับการออกแบบ