ทำไมความพยายามเหล่านี้ถึงทำให้ Scala ล้มเหลวด้วย Xtend และ Kotlin [ปิด]


26

ดังนั้นตอนนี้ Eclipse ได้เสนอ Xtend และ JetBrains กำลังเสนอ Kotlin ซึ่งทั้งสองอย่างนี้ดูเหมือนจะถูก Scala ลงมา คำถามของฉันคือทำไม ผมเคยเล่นกับกาลาบิตและก็ไม่ได้ว่าอย่างหนัก นี่เป็นเพียงปฏิกิริยาตอบสนองต่อความยากลำบากในการก้าวกระโดดจากความจำเป็นต่อการทำงานหรือมีอะไรอีกบ้างที่ทำงานที่นี่?


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


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

8
แอสเซมบลีเป็นเพียงรหัสเครื่องที่ถูกทำให้อ่อนลงใช่ไหม?
Ben Brocka

6
@BenBrocka: ไม่มันเป็น isomorphic กับรหัสเครื่อง;)

4
สกาล่าเป็นสิ่งที่ดี สำหรับฉันฉันเชื่อว่าผู้คนควรยอมแพ้ความลับของ Java และจักรยาน (ภาษาใหม่ทั้งหมดที่กล่าวถึงและไม่ได้) และเพียงแค่ใช้และปรับปรุง Scala IMHO
Ivan

2
@MichaelBogwardt เป็นจุดยุติธรรม ฉันกำลังยืนยันถึงสิ่งที่ฉันเห็นรอบ ๆ blogosphere "Scala ยากเกินไป" และ "Scala ซับซ้อนเกินไป" ดูเหมือนจะเป็นเรื่องร้องเรียนที่พบบ่อย
Onorio Catenacci

คำตอบ:


39

IMHO จากการเขียนโปรแกรมใครบางคนใน Java ในช่วง 7 ปีที่ผ่านมาและเป็นภาษาที่แข็งแกร่งที่สุดของฉันฉันพบว่าสกาล่าค่อนข้างเป็นคนต่างด้าวและฉันรู้สึกลำบากในการทำความคุ้นเคย

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

ผู้คนจะเลือกนรกที่คุ้นเคยเหนือสวรรค์ที่ไม่คุ้นเคย


19
+1: "ผู้คนจะเลือกนรกที่คุ้นเคยเหนือสวรรค์ที่ไม่คุ้นเคย"
Giorgio

18

JetBrains มีหน้าวิกิเปรียบเทียบ Scala กับ Kotlin และดูเหมือนจะมีบางสิ่งที่ Kotlin ทำและ Scala ไม่:

  • ความปลอดภัยเป็นศูนย์ค่าใช้จ่ายเป็นศูนย์ Scala มีตัวเลือกซึ่งเป็นเสื้อคลุมไวยากรณ์และเวลาทำงาน
  • สมาร์ทดุ
  • ฟังก์ชั่นการขยายแบบคงที่ แทนที่จะห่อที่รันไทม์
  • ฟังก์ชั่น Inline ของ Kotlin ช่วยให้กระโดดได้เร็วขึ้น
  • แม่แบบสตริง มีปลั๊กอินคอมไพเลอร์บุคคลที่สามสำหรับ scala ที่มีฟังก์ชันการทำงานที่คล้ายกัน: ScalaEnhancedStrings
  • คณะผู้แทนชั้นหนึ่ง มีการใช้งานผ่านปลั๊กอินของบุคคลที่สาม: โมดูล Autoproxy

ดังนั้นการเรียก Kotlin ว่ายน้ำสกาล่าอาจเป็นเรื่องที่ธรรมดามาก สำหรับ Xtend ฉันคิดว่าเป้าหมายส่วนใหญ่เป็นผู้ใช้ Xtext ไม่ใช่กลุ่มเป้าหมายที่กว้างขึ้น ความแตกต่างที่สำคัญของ Scala ก็คือ Xtend รวบรวมไปยัง Java มากกว่า bytecode

อีกภาษา "Java killer" ที่คุณควรเพิ่มในรายการของคุณคือCeylon ของ Red Hatแม้ว่าฉันจะไม่รู้ว่ามันเปรียบเทียบกับ Scala หรือไม่


13
อัตโนมัติปลดเปลื้องเสียงที่น่ากลัว
Jonas

14
อุตสาหกรรมนี้มีวัฏจักรการปฏิวัติเหล่านี้ซึ่งนักพัฒนาจะไปจากที่หนึ่งสุดขั้วและย้อนกลับมาครั้งแล้วครั้งเล่า ฟีเจอร์ภาษา coder ที่ทรงพลังนั้นดีมากจากนั้นคนโง่ก็เขียนโค้ดไม่ดีและเราก็พบว่าอันตราย ดูว่า Javascript และเบราว์เซอร์นั้นดีอย่างไรจากนั้นแอปเพล็ตมาพร้อมกับ RIA ที่มีปลั๊กอินของเบราว์เซอร์ที่ดีและ Javascript แย่แล้วเฟรมเวิร์ก AJAX ที่ทันสมัยมาพร้อมและปลั๊กอินไม่ปลอดภัยและไม่ดี เป็นสมัยและปลั๊กอินไม่ดีอีกครั้ง! :)
maple_shaft

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

2
@ โจนัสมีเพียงการใช้เทคโนโลยีที่มีความซับซ้อนสูงในระดับสูงเท่านั้นที่จะแสดงความคิดเห็นได้ ผมไม่เห็นด้วยกับ maple_shaft แม้ว่าวิวัฒนาการทางเทคโนโลยีจะมีซ้ำรู้สึก
yannis

3
@ Jonas นักแสดงเหล่านี้ไม่ได้อัตโนมัติ แต่สมาร์ท casts: ถ้าคุณมองเข้าไปคุณจะเห็นว่ามันไม่เหมือนกัน: kotlinlang.org/docs/reference/typecasts.html
cy6erGn0m

11

ฉันใช้ Scala เป็นภาษาหลักของฉันในปีที่ผ่านมา (ด้วย Java เป็นวินาทีที่ใกล้ทั้งภายในฐานรหัส Java แบบดั้งเดิมขนาดใหญ่) ฉันยังต้องค้นหาคุณลักษณะพื้นฐานที่ค่อนข้างยุติธรรมหากฉันไม่ได้ใช้มันใน ในขณะที่ แน่นอนว่าคุณสามารถเขียน Scala บางส่วนได้อย่างรวดเร็ว แต่เป็นภาษาที่มีคุณสมบัติหลากหลายมากและใช้เวลานานกว่าจะเชี่ยวชาญ

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

ฉันมีประสิทธิภาพใน Scala มากกว่า Java และรหัสนั้นกะทัดรัดและอ่านง่าย (เมื่อคุณรู้จัก Scala เล็กน้อย) แต่ความซับซ้อนของมันทำให้ฉันลังเลที่จะแนะนำให้คนอื่น ๆ ภาษาที่มีความซับซ้อน 20% แต่ความสามารถ 80% เป็นทางเลือกที่น่ายินดี

[แก้ไขเพื่อลบการกล่าวถึงรหัสดั้งเดิมดูความคิดเห็นด้านล่าง]

[2017 ภาคผนวก: Scala สนับสนุน JavaScript เป็นเป้าหมายการสร้างในขณะที่ Kotlin ยังคงเพิ่มคุณสมบัติที่เหมาะสมสำหรับการเปลี่ยน Java / Groovy / JavaScript เหมือน Scala ตอนนี้พวกเขาเป็นภาษาที่โดดเด่นกว่าเมื่อฉันเขียนสิ่งนี้เป็นครั้งแรก]


คุณช่วยอธิบายเพิ่มเติมส่วน "lagacy" อีกเล็กน้อยได้ไหม? ตัวอย่างเช่นวิธีใดที่คุณหมายถึงใช้รายการแทน Seqs
kiritsuku

ฉันจะแก้ไขมันเนื่องจากเมื่อสะท้อนกลับห้องสมุดสกาลามาตรฐานก็ไม่ค่อยทำเช่นนั้น JSONArray รับรายการ แต่ผู้สร้างส่วนใหญ่ไม่ได้ โดยไม่คำนึงถึงยังคงมีอคติในเอกสารที่มีต่อรายการโดยเฉพาะอย่างยิ่งตั้งแต่การเขียนโปรแกรมใน Scala รุ่นที่ 2 ครอบคลุมเฉพาะ Scala 2.8 ซึ่งถือเป็นเวกเตอร์ และตัวอย่างรหัสของมันมักจะมีคอนสตรัคเตอร์ที่ใช้ List ซึ่ง Seq น่าจะดีกว่า
David Leppik

ใช่สำหรับ 2.10 บางสิ่งจะดีกว่า ( +:ตัวอย่างเช่นตัวแยกข้อมูล) ฉันหวังว่าการเขียนโปรแกรมใน Scala จะได้รับการอัปเดตในอนาคตอันใกล้ สำหรับ 2.11 บางสิ่งปรับปรุงเพิ่มเติม stdlib ได้รับการปลดปล่อยจากค่าเสื่อมราคาและจะลดขนาดลงเล็กน้อย อาจscala.util.parsingจะถูกย้ายออกไปนอก stdlib ด้วย เราจะเห็น ...
kiritsuku

1
ฉันควรเพิ่มว่าปัญหาที่แท้จริงของฉันกับรายการเทียบกับเวกเตอร์คือการเพิ่มรายการลงในรายการ (เช่น Seq ใน Scala) เป็นการดำเนินการขั้นพื้นฐานมากและมีวิธีที่เทียบเท่ากันมากเกินไปที่จะทำมันทั้งหมดที่มีสัญลักษณ์ตลกที่ยากที่จะ จำ วิธีที่ยอมรับคือ::, ::=หรือ+:=ที่ย่อหน้า แต่คนส่วนใหญ่ต้องการ:+=ที่ผนวก แต่ที่ไม่ได้เป็นที่มีประสิทธิภาพสำหรับรายการ
David Leppik

10

JetBrains ระบุวัตถุประสงค์ของพวกเขาไว้อย่างชัดเจนสำหรับ Kotlin :

เราต้องการที่จะมีประสิทธิผลมากขึ้นโดยการเปลี่ยนเป็นภาษาที่แสดงออกมากขึ้น ในขณะเดียวกันเราไม่สามารถยอมรับการประนีประนอมในแง่ของความสามารถในการทำงานร่วมกันของ Java (ภาษาใหม่จะถูกนำมาใช้อย่างค่อยเป็นค่อยไปและจำเป็นต้องทำงานร่วมกันอย่างราบรื่นกับฐานรหัสที่มีอยู่) หรือความเร็วในการรวบรวม javac และเราไม่สามารถทำให้ช้าลงได้) สิ่งต่อไปก็ค่อนข้างตรงไปตรงมา: เราคาดว่า Kotlin จะผลักดันยอดขายของ IntelliJ IDEA


8

ฉันใช้ Scala สองสามเดือนใน Eclipse กับ Play Framework ฉันชอบภาษา แต่ก็มีหลายสิ่งที่ฉันไม่ชอบ

สำหรับฉันเหตุผลในการเปลี่ยนจาก Java เป็นภาษาอื่นให้มีประสิทธิผลมากกว่า

จนถึงตอนนี้ฉันยังไม่ได้ผลมากขึ้นกับสกาลา เหตุผลหนึ่งคือการขาดการสนับสนุนที่ดีสำหรับ Scala ใน Eclipse ปลั๊กอิน Scala ไม่ดี (เช่นการเยื้องล้มเหลว) และยังไม่มีฟังก์ชั่นมากมาย (เช่นไม่มี "Open Call Hierarchy") คอมไพเลอร์ Scala ก็ช้าเช่นกันนี่อาจไม่เป็นปัญหา แต่ฉันใช้ Scala กับ Play Framework ที่รวบรวมโค้ดสำหรับทุกคำขอและมีความเร็วของคอมไพเลอร์เป็นสิ่งสำคัญ


2
บางทีคุณอาจยังไม่ได้เรียนสำนวนสกาลาเพียงพอ ฉันเคยใช้ Scala สำหรับโครงการขนาดเล็ก (เครื่องมือ) และฉันก็ทำงานได้ดีกว่าใน Scala มากกว่าใน Java แม้ว่าฉันจะมีประสบการณ์ใน Java (มากกว่า 10 ปี) มากกว่าใน Scala (<2 ปี)
Giorgio

4

ไม่ทราบเกี่ยวกับ Kotlin แต่ Scala และ Xtend เป็นสัตว์สองชนิดที่แตกต่างกันมาก

ตรงกันข้ามกับคำพูดทั่วไป Scala ไม่ใช่ Java ที่ดีกว่า Scala เป็นภาษาที่โดดเด่นกว่า Java ด้วยไวยากรณ์และความหมายของมันเองและชุดของไลบรารีฐานของตัวเอง

Xtend IS เป็น Java ที่ดีกว่า มันเก็บความหมายของ Java และปรับปรุงไวยากรณ์ของมัน โค้ด Xtend ทุกบรรทัดสามารถแปลโดยตรงไปยังโค้ด java จำนวนมาก ไม่มีรันไทม์เพิ่มเติมทั้ง

ฉันคิดว่าทั้งสองวิธีนั้นถูกต้องแม้ว่าจะแตกต่างกัน ฉันไม่ชอบ Scala (เป็นภาษา) แต่ไม่ชอบที่จะเพิ่มไห Scala ลงในโครงการของฉัน ฉันไม่สามารถใช้ Scala ได้อย่างถูกต้องใน Android ไม่ใช่ (เพิ่มปัญหาเรื่องน้ำหนักและประสิทธิภาพ) Xtend ไม่ค่อยโดดเด่นเท่าไหร่ แต่ใช้ได้สำหรับฉัน (คุ้มค่ากับการใช้งานมากกว่าภาษา Java) และใช้งานได้กับทุกแพลตฟอร์มราวกับว่าฉันกำลังเขียนโดยตรงใน Java

ฉันเชื่อว่าทั้งสองภาษาครอบคลุมความแตกต่างกันและสามารถอยู่ร่วมกันได้โดยไม่รบกวนซึ่งกันและกัน IMHO, Scala ซับซ้อนเกินไปไม่เพิ่มอะไรใหม่ ถ้าคุณต้องการที่จะทำงานได้มากขึ้นและ OO น้อยลงเพียงเลือกหนึ่งในภาษาที่ใช้งานได้ง่ายเช่น Clojure หรือ JHaskell หากคุณต้องการ Java ที่มีไวยากรณ์ที่ดีกว่าและมีการเขียนโปรแกรมฟังก์ชั่นนิดหน่อย Fantom ก็น่าจะดีเท่ากับ Scala (มันคล้ายกับ C # มาก)

แต่ฉันพบว่า Xtend อยู่ในจุดที่น่าสนใจระหว่างภาษาเหล่านั้นทั้งหมด มันเพิ่มรูปแบบวากยสัมพันธ์ทั้งหมดที่ฉันต้องการสำหรับ Java รักษาส่วนที่ดีของ Java (ความหมายของมัน) คิดว่ามันเป็น Coffescript สำหรับ Java

และการรองรับ Eclipse นั้นยอดเยี่ยม ...


…และรองรับเฉพาะใน Eclipse ขวา? และ Eclipse เป็นนรก…
Sarge Borsch

Xtend มีรันไทม์เพิ่มเติม ฉันตรวจสอบประมาณ 3MB ครั้งล่าสุด
mm2001

@ mm2001 ใช่มีการอ้างอิง: ประมาณ 300 Ko สำหรับ xtend และ 2 Mo สำหรับฝรั่งในโครงการทดสอบขนาดเล็กของฉัน ( github.com/pdemanget/examples/tree/master/xtend/message-send ) แต่นั่นไม่ใช่ runtime คลาสเพิ่มเติมของสิ่งต่างๆเช่น InputOutput, หมายเหตุประกอบเพิ่มเติม มันไม่ได้ลบประเด็นหลักสำหรับฉันที่ Scala และ Xtend เป็น 2 ภาษาที่แตกต่างกันอย่างที่กล่าวไว้ในคำตอบนี้
pdem
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.