นักพัฒนา Java คิดอย่างไรกับ Scala [ปิด]


19

ฉันได้ตั้งข้อสังเกตว่าการสนับสนุน IDE นั้นใกล้เคียงกับที่ดี แต่ภาษานั้นรองรับสำนวนการเขียนโปรแกรมที่ใช้งานได้ดีกว่าหมดจด


3
Python เป็นศาสนาของฉันดังนั้นฉันสนใจเฉพาะสิ่งที่ Guido คิดว่า Scala neopythonic.blogspot.com/2008/11/scala.html
งาน

7
สกาล่าเป็นภาษาที่ยอดเยี่ยมที่ไม่เพียง แต่ดึงดูดความคิดที่ยอดเยี่ยมเหล่านี้ทั้งหมดในชุมชนสกาล่าเท่านั้น แต่ยังมีผู้เกลียดชังอิจฉาจำนวนมากที่พยายามค้นหาสิ่งต่าง ๆเพื่อโจมตีภาษาและผู้คนที่ใช้มัน
soc

@soc: เพียงเพื่อให้ชัดเจน: ฉันไม่ได้เกลียดสกาล่าและผู้ที่ใช้มันอาจไม่สามารถ (ไม่ควร!) สนใจน้อยกว่าสิ่งที่ฉันคิดเกี่ยวกับมัน ฉันคิดว่ามันซับซ้อนเกินไป นั่นคือทั้งหมดที่ ความซับซ้อนอาจเป็นสิ่งที่ถูกต้องสำหรับผู้ที่มีสมองขนาดใหญ่ ฉันไม่ :-)
Joonas Pulakka

3
ขออภัยฉันรู้สึกรำคาญเมื่อมีคนทำซ้ำตำนานโดยไม่ต้องสำรองการอ้างสิทธิ์
soc

2
@ โซค: คำถามทั้งหมดนี้เป็นอัตวิสัยทั้งหมดดังนั้นคำตอบใด ๆ ที่ถูกต้องไม่ว่าจะเป็นตำนานหรือไม่
Joonas Pulakka

คำตอบ:


18

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

  • รหัสสกาล่ามีความกระชับมากกว่าโค้ด Java (ไม่มีตัวตั้งค่าหรือผู้ทะเยอทะยานสามารถพิมพ์ข้อมูลจำนวนมากได้)
  • การสนับสนุน XML ในตัวนั้นเป็นที่น่าสนใจอย่างมาก
  • ความเข้ากันได้ของไลบรารี Java และการทำงานร่วมกันนั้นยอดเยี่ยม
  • การสนับสนุนสำนวนฟังก์ชั่นบางอย่างกำลังรีเฟรช (สำหรับความเข้าใจ, ปิด, ฟังก์ชั่นแลมบ์ดา, แผนที่, พับ, ลด)
  • ดูเหมือนจะไม่มีคุณสมบัติเจ๋ง ๆ ที่ผู้สร้างภาษาไม่ต้องการรวม

ประเด็นข้างต้นเป็นสิ่งที่ฉันคิดเกี่ยวกับสกาล่ามากขึ้นหรือน้อยลงก่อนที่ฉันจะเริ่มเรียนรู้

ในช่วงเวลาหนึ่งปีนี่คือสิ่งที่ฉันค้นพบ:

  • การซื้อหนังสือบันไดเป็นการลงทุนที่ยอดเยี่ยมและช่วยให้ฉันได้เรียนรู้สิ่งต่าง ๆ ด้วยตนเอง
  • ไวยากรณ์มีนิสัยแปลก ๆ และบางครั้งฉันก็งงว่าทำไมบางอย่างไม่ถูกต้อง การแลกเปลี่ยนคือเมื่อคุณคุ้นเคยรหัสมีความยุ่งเหยิงน้อยลงและอ่านง่ายขึ้น โปรดทราบว่านี่ไม่ใช่ปัญหาถ้าคุณอ่านมากกว่าเขียนรหัส
  • ห้องสมุดคอลเลกชันใน 2.8 มีความสุขที่จะใช้ มันยากที่จะกลับมาที่จาวาหนึ่ง
  • XML ตามตัวอักษรเป็นสิ่งที่ดี แต่นอกเหนือจากสิ่งพื้นฐานบางอย่างฉันต้องเข้าถึงระบบนิเวศห้องสมุด Java มันสะดวกแม้ว่า
  • การใช้ห้องสมุด Java จาก Scala นั้นง่ายและสะดวกมาก การใช้คลาส Scala จาก Java นั้นค่อนข้างยุ่งยากกว่า แต่ก็ใช้งานได้
  • ฉันเปลี่ยนไปใช้ IntelliJ IDEA community edition แล้วและถึงแม้ว่ามันจะไม่สมบูรณ์แบบ
  • ผู้สร้างภาษาคิดเกี่ยวกับชุดคุณลักษณะและทำงานร่วมกันได้ดีจริงๆ การสนับสนุนเชิงวัตถุนั้นดีกว่าใน Java (ด้วยลักษณะ) และคุณสามารถทำการเขียนโปรแกรมการทำงานได้
  • เป็นภาษาที่ผู้พัฒนา Java บางคนเกลียดชังด้วยความหลงใหล สำหรับฉันมันได้นำความสุขของการเขียนโปรแกรมกลับมา

21

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

สำหรับการเขียนโปรแกรมการทำงานฉันชอบClojureซึ่งเป็นวิธีที่ง่ายกว่า Scala

ให้สงครามศักดิ์สิทธิ์เริ่มต้น ;-)


2
หาก Rich Hickey เพียงคนเดียวที่ใส่ใจเกี่ยวกับ. Net มากพอ ๆ กับที่เขาทำเกี่ยวกับ JVM ...
งาน

มันจะมีประโยชน์ถ้าคุณอธิบายเพิ่มเติมเล็กน้อยเกี่ยวกับสิ่งที่คุณรู้สึกว่าซับซ้อนเกินไป
Richard Warburton

4
@ Richard Warburton: ปัญหาของความซับซ้อนของ Scala (หรืออย่างที่ Martin Odersky กล่าวไว้ว่า "จุดแข็งและปัญหาของ Scala: ความสามารถในการขยาย") ได้มีการพูดคุยกันอย่างกว้างขวางในฟอรัมมากมาย หนึ่งในการอภิปรายดังกล่าวเป็นที่นี่ ผมไม่ได้บอกว่ามีความซับซ้อน == ไม่ดีต่อ se ปัญหาคือในขณะที่โปรแกรมเมอร์ที่สว่างที่สุด 1% อาจสามารถทำปาฏิหาริย์กับ Scala ส่วนใหญ่ก็ไม่ได้ "รับ" และนั่นเป็นปัญหาสำหรับการใช้งานในโลกแห่งความเป็นจริง มันเหมือนกับรถฟอร์มูล่าวัน: คนส่วนใหญ่ไม่สามารถขับสัตว์ร้ายเช่นนี้ได้
Joonas Pulakka

2
+1 สำหรับการกล่าวถึง Clojure เป็นทางเลือกที่ถูกต้อง (เมื่อมันมาถึงการเขียนโปรแกรมการทำงาน)
Oliver Weiler

Clojure ยอดเยี่ยม แต่มันก็เป็นนักแสดงที่สกาล่า? มันเป็นเรื่องง่ายที่จะ refactor โดยไม่ต้องพิมพ์คงที่นี้ (Refactoring Python ค่อนข้างยากตัวอย่างเช่น - ฉันเขียน refactorings เพื่อมัน)
9000

13

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

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

โชคดีที่ไม่ยาวเกินไปหลังจากนั้นผมพบข้อมูลเกี่ยวFantom โอ้ฉันรักมันมาก! สำหรับฉันมันเป็นเหมือนคำตอบอันงดงามของอเมริกันต่อระบบราชการของเยอรมัน! มันจับคู่ความต้องการของผมกำลังมองหาใน Scala แต่มากขึ้นอย่างหรูหรา มันมีการรวมกันเป็นกลุ่ม , EclipseและNetbeans , กรอบเว็บที่ดี, ผลิตภัณฑ์ที่เป็นผู้ใหญ่ทำงานกับมัน, ชุมชนขนาดเล็ก แต่มีประโยชน์อย่างไม่น่าเชื่อ... การพิมพ์แบบไดนามิกและแบบคงที่! ฉันดีใจ!

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


9

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

ฉันชอบ Clojure แต่มีบางสถานการณ์ที่แพลตฟอร์มต้องการให้คุณคอมไพล์ไปเป็น bytecode แบบสแตติก (Android, applets, ... ) และในขณะที่คุณสามารถทำได้ใน Scala ก็แค่นั้นเอง

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

สิ่งที่ดีที่สุดสำหรับฉันเมื่อฉันเริ่มเรียนรู้ภาษาคือฉันสามารถเขียนโปรแกรมในภาษาจาวาได้โดยไม่ต้องมีเสียงรบกวน (นิด ๆ หน่อย ๆ เหมือนตอนที่คุณเริ่ม Groovy) แต่ในที่สุดคุณต้องการที่จะดำดิ่งสู่พลัง ของภาษา - มันเติบโตไปพร้อมกับคุณ

เกี่ยวกับคำถาม IDE: หลังจากใช้ Emacs สำหรับทุกสิ่งแล้วปัญหา IDE ทั้งหมดของฉันก็หายไป :-)


9

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

สกาล่าอาจไม่ง่ายเหมือนพูดโอเบรอน แต่มันค่อนข้างง่ายกว่าภาษาอื่น ๆ ข้อมูลจำเพาะภาษาสกาล่าคือ ~ 160 หน้าข้อมูลจำเพาะภาษา Java คือ ~ 600 (เฉพาะภาษาไม่ใช่ JVM หรือห้องสมุด!) ข้อมูลจำเพาะภาษา ECMA-334 C # (AFAIK สอดคล้องกับชุดย่อยของ Visual C # 2.0) คือ ~ 440 หน้า (สิ่งนี้ไม่มีสิ่งใดเช่นความเข้าใจในการสืบค้น LINQ, การแสดงออกแลมบ์ดา, วิธีการขยาย, การร่วมกันทั่วไปและความdynamicขัดแย้ง, อาร์กิวเมนต์ที่เป็นตัวเลือกที่มีค่าเริ่มต้น, อาร์กิวเมนต์ของคำหลักvar) แม้แต่ร่างปัจจุบันสำหรับ ECMAScript 5.1 ก็ใหญ่กว่าที่ประมาณ 210 หน้า และแน่นอนว่าภาษา "เริ่มต้น" ของฉันเอง Ruby ซึ่งมี ISO Draft ปัจจุบันมีน้ำหนักอยู่ที่ ~ 310 หน้าซึ่งระบุเซตย่อยเล็ก ๆ ที่แทบผิดปกติของการแยก Ruby 1.8.6, 1.9.1 และ 1.9.2


6
จำนวนหน้าในข้อกำหนดภาษาเป็นตัวชี้วัดความซับซ้อนที่น่าสนใจ มันน่าอัศจรรย์ที่สกาล่าแบ่งความคิดเห็นเกี่ยวกับเรื่องนี้ ไม่มีใครพูดว่า Python นั้นซับซ้อนหรือ C ++ นั้นง่าย แต่ Scala นั้นดูเหมือนจะเป็นทั้ง :-) เช่นscala-lang.org/node/7431
Joonas Pulakka

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

2
จำนวนหน้าในข้อมูลจำเพาะภาษาเป็นวิธี TERRIBLE เพื่อเปรียบเทียบความซับซ้อนของสองภาษา เพียงแค่ให้สองตัวอย่าง: ข้อมูลจำเพาะ Java ถูกเขียนในแบบฝึกหัดเกือบในขณะที่ข้อมูลจำเพาะของ Scala นั้นเขียนในลักษณะแบบสั้นมาก หรืออีกตัวอย่างหนึ่ง C # 2.0 มีความซับซ้อนพอ ๆ กับ Java วันนี้หรืออาจจะซับซ้อนกว่านี้เล็กน้อยเนื่องจากเครื่องจักร "ไม่ปลอดภัย" ผู้ได้รับมอบหมายและคุณสมบัติเบื้องต้น แต่ตามที่คุณทราบสเปค C # 2.0 นั้นเล็กกว่า JLS
James Iry

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

3
รออะไร ? ทำไมคุณถึงพยายามวัดความซับซ้อนด้วยขนาดของสเป็ค? มันเป็นความคิดที่แย่มาก
smartnut007

9

นี่คือสิ่งที่ sucks เกี่ยวกับสกาล่า:

  • ตัวชี้โมฆะเป็นความคิดที่เลวทีเดียว Hoare เรียกมันว่า "ข้อผิดพลาดพันล้านดอลลาร์" ของเขา แต่ Scala ยิ่งแย่ลงไปอีก มันมีวัตถุที่ชื่อว่า null, Null, None และ Nil null ใช้สำหรับการทำงานร่วมกันกับ Java Null เป็นรูปแบบตัวชี้โมฆะข้อกำหนด W3C DOM ไม่มีสิ่งที่ควรถูกแทนที่ด้วย null และไม่มีเป็นสิ่งที่ว่างเปล่า

  • เมื่อภาษาสร้างกลายเป็นแฮ็คมันมักจะเป็นโปรแกรมเมอร์ที่จะตำหนิและไม่ใช่ภาษา อย่างไรก็ตามใน Scala ภาษาหลักประกอบด้วยคลาสไลบรารีที่มีพฤติกรรมที่มีเอกสารเท่านั้นคือ "นี่คือแฮ็ก" ไม่เชื่อเหรอ ค้นหา scaladoc สำหรับ scala.xml.Group

  • สุดท้ายไม่น้อย Scala ได้รับการบันทึกไว้ไม่ดี แทบทุกคลาสสกาล่าในเอกสารอย่างเป็นทางการมาพร้อมกับตัวอย่างรหัส สกาล่านั้นยากต่อการเรียนรู้มากกว่าชวาและต้องการความรู้ด้านวิทยาการคอมพิวเตอร์อย่างลึกซึ้ง

เพื่อหลีกเลี่ยงการถูกเข้าใจผิดว่าเป็นผู้เกลียดชังนี่คือสิ่งที่ฉันชอบ:

  • ฉันมีข้อยกเว้นน้อยกว่า ฉันไม่เคยมี ClassCastException และ NullPointerExceptions น้อยมากเมื่อโต้ตอบกับ Java
  • รหัสสั้นและกระชับกว่า Java มาก
  • มันเป็นความท้าทายทางปัญญา Java รู้สึกเหมือนภาษาเด็กเมื่อเปรียบเทียบ

10
nullเป็นตัวชี้โมฆะของ Java Nullเป็น "ประเภท" ของมัน Noneเป็นหนึ่งใน "สถานะ" ที่เป็นไปได้ของOption[T]คอลเล็กชันที่มีองค์ประกอบหนึ่งหรือเป็นศูนย์ Nilเป็นรายการว่างเปล่า ในขณะที่คุณต้องการทำให้มันฟังดูน่ากลัว ประเภทเหล่านั้นไม่สามารถเปลี่ยนได้หรือเปลี่ยนได้ซึ่งกันและกันและประพฤติตนอย่างที่ควรทำ
soc

9

สกาล่ามีความซับซ้อน ไม่มีทางรอบ! ไวยากรณ์ของมันมีความยืดหยุ่นสูงมากและสามารถปรับแต่งได้หลายวิธี (เหนือตัวดำเนินการทั้งหมด / เครื่องหมายมัด) - และระบบประเภทมีคุณสมบัติที่แตกต่างกว่าภาษาอื่น ๆ ที่ฉันรู้จัก

ดังนั้นสิ่งต่าง ๆ ไม่ได้ตรงไปตรงมาเช่นใน Haskell: Typeclasses ที่ครอบคลุมพวกมันทั้งหมด

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

  • ค่าโดยนัย
  • ฟังก์ชั่นโดยนัย
  • Existentials
  • สัญลักษณ์แทน
  • ลักษณะ
  • อินเตอร์เฟซ
  • คลาสนามธรรม
  • คลาสเคส
  • ประเภทโครงสร้าง
  • ข้อ จำกัด ทั่วไป
  • ดูขอบเขต
  • ประเภทนิรนาม

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

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

เขียนสกาล่าอย่างตรงไปตรงมาที่สุดและมันจะใช้ได้ อย่าสับสนกับทุกสิ่งที่เป็นไปได้และใช้สิ่งที่คุณต้องการ และถ้าคุณต้องการบางสิ่งคุณสามารถมั่นใจได้ว่าอย่างใดสกาล่ามีมัน;)

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

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


1
"เหนือตัวดำเนินการทั้งหมด / สัญกรณ์มัด" - เพียงแค่สกาล่าที่ขาดผู้ประกอบการ :) มันเป็นแค่วิธีการ
ผู้ใช้ไม่รู้จัก

6

มันเป็นภาษาที่ยอดเยี่ยมที่ง่ายกว่า Java ในหลาย ๆ ด้าน

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

หากคุณกังวลเกี่ยวกับภาษาที่ซับซ้อนเท่า C ++ ฉันจะหลีกเลี่ยง Clojure เหมือนกับโรคระบาด การคร่ำครวญว่าสกาลานั้นซับซ้อนกว่า Clojure กลายเป็นข้อโต้แย้งทางเลือกสำหรับคนที่ไม่รู้เรื่องภาษาใดภาษาหนึ่งหรือทั้งสองภาษา

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

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


6
ขอบคุณสำหรับอินพุต Scala vs Clojure ของคุณ แต่นั่นคือสิ่งที่ OP ฉันถามเกี่ยวกับจริงเหรอ?
Martin Wickman

จุดที่น่าสนใจ: มาโคร กังวลเล็กน้อยเช่นกัน มาโครหรือคล้ายกันมีอยู่ใน Scala หรือสิ่งที่ "ฟุ้งซ่าน จำกัด " ทั้งหมดเป็นสิ่งที่ทำให้ไขว้เขว?
อาร์มันด์

1
นี่ดูเหมือนจะเป็นความเห็นต่อคำตอบของฉันมากกว่าคำตอบสำหรับคำถามเดิม ฉันเห็นด้วยแมโครให้พลังที่ไม่มีที่สิ้นสุดแก่คุณดังนั้นเมื่อใช้ผิดพวกมันจะดูด ดังนั้นคุณควรใช้มันให้ถูกต้อง (เฉพาะเมื่อจำเป็น) นี่ไม่ได้เปลี่ยนความจริงที่ว่า Clojure ภาษาเป็นหนึ่งในภาษาที่ง่ายที่สุดที่มีอยู่ สกาล่าไม่แน่นอน
Joonas Pulakka

> สิ่งนี้ไม่ได้เปลี่ยนความจริงที่ว่า Clojure ภาษานั้นเป็นหนึ่งในภาษาที่ง่ายที่สุดที่มีอยู่ <นี่ก็เป็นเท็จโดยสมบูรณ์เว้นแต่คุณจะใช้เมตริกบางอย่างเช่น "number of constructs language" หากคุณกำลังใช้สิ่งที่มีประโยชน์เช่นการอ่านและเขียนโปรแกรมในภาษานั้นง่ายเพียงใด Clojure ไม่ใช่หนึ่งในวิธีที่ง่ายที่สุด
Josh

ดังนั้นโปรดดำเนินการต่อและมอบความซับซ้อนทางภาษาให้กับเรา "วิธีง่าย ๆ ในการอ่านและเขียนโปรแกรมในภาษา" เป็นเรื่องส่วนตัวโดยสิ้นเชิงดังนั้นจึงไม่ได้ช่วยที่นี่จริงๆ จริงอยู่ที่การคิดค่าใช้จ่ายที่เป็นประโยชน์และตรงตามวัตถุประสงค์อาจเป็นไปไม่ได้เลย (ตัวอย่างเช่นJörg W Mittag ด้านล่างใช้จำนวนหน้าในการกำหนดภาษาเป็นมาตรการที่ซับซ้อนในขณะที่วัตถุประสงค์ฉันไม่แน่ใจว่ามันมีประโยชน์มาก)
Joonas Pulakka

4

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


2

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.