ไม่มีใครรู้ว่าทำไม Scala ถูกนำไปใช้ใน Java และ. NET แทนที่จะเป็น C หรือ C ++? ภาษาส่วนใหญ่ใช้กับ Cor C ++ [เช่น Erlang, Python, PHP, Ruby, Perl] ข้อดีของ Scala ที่นำมาใช้ใน Java และ. NET นอกเหนือจากการให้สิทธิ์การเข้าถึงไลบรารี Java และ. NET คืออะไร?

UPDATE

สกาล่าจะไม่ได้รับประโยชน์มากขึ้นหากนำไปใช้ใน C เพราะสามารถปรับได้ดีกว่าการพึ่งพา JVM

คำถามคือทำให้เกิดความสับสนเช่น C และ C ++ เป็นภาษาขณะ JVM เป็นเครื่องเสมือนและสุทธิเป็นแพลตฟอร์ม Scala สามารถนำมาใช้ใน C หรือ C ++ และมันสามารถสร้างรหัสเครื่องแทน bytecode สำหรับเครื่องเสมือน

ตอบคำถามที่ถูกถาม:

Scala ไม่ได้ถูกนำมาใช้ใน C หรือ C ++ เพราะ Scala ภาษาที่ใช้จริงเป็นภาษาที่ดีกว่ามาก

ทำไมจะดีกว่า ดีไปอ่านเกี่ยวกับเป้าหมาย Odersky สำหรับภาษา

ตอบคำถามที่อาจมีเจตนา:

Scala สร้างหลัก JVM bytecode เนื่องจากว่าให้พกพาที่ดีเช่นเดียวกับการให้บริการดังกล่าวเป็นของสะสมที่เชื่อถือได้และมีประสิทธิภาพขยะเพิ่มประสิทธิภาพเวลาทำงานและการรวบรวมเพียงในเวลาโดย JVM

ขอย้ำอีกครั้งว่าสิ่งสุดท้าย: JVM จะคอมไพล์ไปยังฮอตสปอตของรหัสเครื่องในรหัสที่กำลังทำงานอยู่ นั่นคือการคอมไพล์เช่นเดียวกับคอมไพเลอร์ C และ C ++

มีเครื่องเสมือนอื่นที่มีอยู่ แต่ Odersky ผู้สร้างของ Scala คุ้นเคยกับ JVM แล้ว เขาตั้งใจที่จะให้ CLR เป็นทางเลือก แต่ความพยายามที่จะทำให้สิ่งนั้นยังไม่ประสบความสำเร็จ

ตอบคำถามที่อาจ / ควรได้รับการถาม:

การคอมไพล์ไปยังโค้ดเครื่องไม่ได้ให้ประโยชน์เพียงพอกว่าการคอมไพล์ใน JVM bytecode

แน่นอนว่ามันเป็นไปได้ที่จะสร้าง microbenchmarks ใน C หรือ C ++ ที่เอาชนะ JVM ได้เทียบเท่า มันเป็นความจริงเช่นกันว่าโค้ดที่ได้รับการปรับให้เหมาะสมที่สุดใน C หรือ C ++ จะเอาชนะโค้ดที่ได้รับการปรับให้เหมาะสมที่สุดใน Java หรือ Scala สิ่งที่แตกต่างนั้นยอดเยี่ยมมากสำหรับโปรแกรมระยะยาว

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

อย่างไรก็ตามในกรณีส่วนใหญ่ความเร็วของการพัฒนาง่ายและการบำรุงรักษามีความสำคัญมากกว่าความเร็วของการดำเนินการ ในกรณีเหล่านี้ที่ผู้คนมีความกังวลในการเขียนโค้ดระดับสูงมากที่เข้าใจและเปลี่ยนแปลงได้ง่ายการปรับให้เหมาะสมแบบรันไทม์ที่จัดทำโดย JVM อาจเอาชนะการปรับให้เหมาะสมแบบคอมไพล์ในเวลาที่สร้างโดยคอมไพเลอร์ C หรือ C ++ ทำให้ JVM (และ CLR ) เป้าหมายที่จะดำเนินการได้เร็วขึ้นจริง

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

และโดยวิธีการ

ฉันจะให้ตัวอย่างเคาน์เตอร์: Haskell Haskell สร้างรหัสเครื่องและถึงกระนั้นโปรแกรม Haskell ก็ยิ่งแย่ไปกว่าการยิงของ Debian มากกว่า Scala ระบุว่าทุกคนสามารถมั่นใจได้ว่าโปรแกรมสกาล่าจะเร็วขึ้นหากรวบรวมโดยตรงกับรหัสเครื่อง?

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

• มีหลายวิธีที่ห้องสมุดต้องการโต้ตอบที่ไม่เข้ากันกับภาษาระดับสูงกว่ามาก ตัวอย่างเช่นหากห้องสมุดต้องการตัวชี้ไปยังstruct, ภาษาที่ไม่มีพอยน์เตอร์และไม่มีการ structรับมืออย่างไร?
• มีการโต้ตอบอย่างรุนแรงระหว่างรุ่นหน่วยความจำของไลบรารีและภาษาที่แตกต่างกันซึ่งมักจะไม่สามารถแก้ไขได้หรือหากแก้ไขได้จะมีข้อผิดพลาดสูงและมีแนวโน้มที่จะเกิดข้อผิดพลาด
• รหัสกาวสำหรับ FFIs จำนวนมากนั้นไม่ใช่เรื่องไร้สาระและถือว่าเป็นความรู้ที่อาจไม่เป็นสากล (เชื่อหรือไม่ว่าไม่ใช่โปรแกรมเมอร์ทุกคนที่เป็นปรมาจารย์ C และพวกเขาไม่ต้องการและไม่จำเป็นต้องเป็น!)

สิ่งนี้ยิ่งแย่ลงเมื่อใช้ C ++ C ++ ไม่สามารถใช้งานร่วมกับ C ++ (ในระดับไบนารีฉันหมายถึง) จากคอมไพเลอร์ไปยังคอมไพเลอร์ในแพลตฟอร์มเดียวกัน (!) ไม่พูดถึงภาษาอื่น

การกำหนดเป้าหมาย JVM แก้ปัญหาเหล่านี้จำนวนมากในขณะที่ให้คุณเข้าถึงชุดที่ใหญ่ที่สุดของไลบรารีบน Java (มีขนาดใหญ่แค่ไหนขอบเขตของApache Software Foundationมีให้เลือกมากมายสำหรับผู้เริ่ม)

• ระเบียบการเรียกและการเป็นเจ้าของของ Java นั้นปกติมากกว่าของ C
• JVM ยังมีโมเดลหน่วยความจำเดี่ยว (รวมถึงการรวบรวมขยะ) สำหรับภาษาและไลบรารีทั้งสองเพื่อเชื่อมต่อกับ ไม่จำเป็นต้องติดตามว่าใครเป็นเจ้าของอะไรและต้องล้างข้อมูลที่ไหน รันไทม์ทำเพื่อคุณ
• รหัสกาวสำหรับ FFI สำหรับภาษาส่วนใหญ่ที่สร้างขึ้นบน JVM นั้นไม่มีอยู่จริง (ตามที่มีให้ในฐานะกรอบงานเบื้องหลังของภาษา) ไม่จำเป็นต้องเขียนโปรแกรมใน Java ตัวอย่างเช่นในการเข้าถึงไลบรารี Java ใน Scala, Clojure, JRuby เป็นต้นคุณสามารถเข้าถึงออบเจ็กต์ Java ได้เช่นเดียวกับที่คุณเข้าถึง "ออบเจ็กต์ดั้งเดิม" (ตัวอย่างเช่น Clojure ไม่ต้องการ มีวัตถุจริงในความหมาย OOP) และในภาษาของคุณ

นอกเหนือจากข้อได้เปรียบเหล่านี้คุณยังมีข้อได้เปรียบเพิ่มเติมของการทำงานที่ใดก็ได้ที่ Java รันโดยไม่มีการคอมไพล์ใหม่ (แต่ด้วยการทดสอบ!: เขียนหนึ่งครั้งทดสอบทุกที่) และเข้าถึงเทคโนโลยี JIT ที่น่าประทับใจของ Java

CLR มีจุดแข็งที่คล้ายคลึงกัน แต่เพิ่มจุดอ่อนของ IMO คือ: มันเป็นสภาพแวดล้อมที่ล็อคผู้จำหน่าย (ใช่ฉันรู้เกี่ยวกับ Mono ฉันยังคิดว่ามันเป็นสภาพแวดล้อมที่ล็อคผู้จำหน่าย)

จากการสัมภาษณ์ครั้งนี้การเข้าถึงโครงสร้างพื้นฐานและห้องสมุด Java ที่มีอยู่เป็นสาเหตุหลัก

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

ดังนั้นผมจึงตัดสินใจว่าถึงแม้ผมอยากจะออกแบบภาษาที่แตกต่างจาก Java ที่มันมักจะเชื่อมต่อกับโครงสร้างพื้นฐาน Java - เพื่อ JVM และห้องสมุด นั่นคือความคิด ...

ภาษาอื่น ๆ ที่คุณพูดถึง, Erlang, Python, PHP, Ruby, Perl - ภาษาเหล่านี้สร้างขึ้นก่อน Java &. NET หากผู้สร้างภาษาเหล่านั้นมีสภาพแวดล้อมรันไทม์ของ Java หรือ. NET ในเวลานั้นอาจเป็นไปได้ว่าพวกเขาอาจใช้ประโยชน์จากภาษาเหล่านั้นเมื่อสร้างภาษา

แน่นอนว่าฉันไม่สามารถพูดกับผู้พัฒนาภาษาเหล่านั้นได้ดังนั้นฉันจึงไม่สามารถพูดได้อย่างแน่นอนว่าพวกเขาจะใช้. NET และ / หรือ Java เมื่อสร้างพวกเขาหากพวกเขาพร้อมให้บริการ แต่ดูเหมือนว่าฉันจะชอบ ความคิดที่ดี. ท้ายที่สุดด้วยการออกแบบภาษาของคุณเพื่อคอมไพล์ Java / .NET bytecode คุณจะได้รับประโยชน์ทั้งหมดของ JIT compilers / optimiziers ภาษาของคุณจะทำงานบนแพลตฟอร์มทั้งหมดที่ Java / .NET ทำงานโดยอัตโนมัติคุณสามารถเข้าถึงได้ทั้งหมด ไลบรารี Java / .NET และอื่น ๆ

รหัส Cถูกรวบรวมแบบคงที่กับรหัสดั้งเดิม (รหัสเครื่อง)

Scala ถูกคอมไพล์แบบคงที่ไปยัง java bytecode แล้วรวบรวมตามความต้องการแบบไดนามิกเพื่อโค้ดเนทีฟที่ปรับปรุงแล้ว กระบวนการ:

โค้ดสคาลา --- รวบรวมแบบสแตติกถึง ---> โค้ดไบต์ JVM --- โค้ดแบบไดนามิกรวบรวมโดย JVM- ฮอตสปอตเพื่อ ---> รหัสเนทีฟ

ตัวเลือกทั่วไปสำหรับการสร้าง / เรียกใช้ภาษาใด ๆ :

• ก) แปลรหัสต้นฉบับโดยตรงผ่านเอ็นจินการแปลระหว่างรันไทม์
• b) คอมไพล์โค้ดแบบสแตติกกับโค้ดเนทีฟ (อาจผ่านขั้นตอนกลางเช่นซอร์ส -> C -> เนทีฟ)
• c) คอมไพล์ซอร์สโค้ดแบบสแตติกกับโค้ดระดับกลางที่ต่ำกว่าและตีความที่รันไทม์
• d) คอมไพล์ซอร์สโค้ดแบบสแตติกเป็นโค้ดระดับล่างระดับต่ำจากนั้นใช้การตีความเริ่มต้นตามด้วยการรวบรวมแบบไดนามิกและเทคนิคการปรับให้เหมาะสมเพื่อแปลงเป็นโค้ดเนทีฟ โค้ดจะถูกตีความจนกว่าจะพบพา ธ การประมวลผลและคอขวดทั่วไปจากนั้นโค้ดจะถูกคอมไพล์เพื่อการประมวลผลที่เร็วที่สุดภายใต้เงื่อนไขทั่วไป คอมไพล์ใหม่ / retuned เมื่อเงื่อนไขการดำเนินการเปลี่ยนแปลงเพียงพอที่จะรับประกันนี้

คำถามของคุณ: "ทำไม Java ใช้ (d) กับ JVM มากกว่า (b) ด้วยรหัสกลาง C"

ตอบ:

ประการแรกให้สังเกตว่าสกาล่านั้นมีมากภาษาระดับสูงกว่า C ให้พลังการเขียนโปรแกรมความง่ายในการเขียนโปรแกรมและความรัดกุม มันเกี่ยวกับ '1 ระดับที่สูงกว่า' Java เนื่องจากฟังก์ชั่นการสั่งซื้อชั้นหนึ่ง & สูงกว่า, ฟังก์ชั่นโดยปริยาย, ฟังก์ชั่นเป็นวัตถุ, การปิดและการ currying, รองรับการเรียกซ้ำหางเพื่อรวบรวมลูป ซึ่งสามารถกำหนด (อีกครั้ง) ในไลบรารีคลาสเคสและการลด (การจับคู่รูปแบบ), การสืบทอดชนิดโดยนัย, polymorphism ที่แข็งแกร่งผ่านลักษณะที่สืบทอดได้หลายแบบขยายและ generics แบบขยาย, ไวยากรณ์ในตัวสำหรับคู่ & tuples & cons (รายการ & ต้นไม้ ) & แผนที่รองรับโครงสร้างข้อมูลที่ไม่เปลี่ยนแปลงการรองรับการคำนวณแบบขนานและปฏิกิริยาพร้อมกันที่มีประสิทธิภาพพร้อมการคัดลอกและส่งข้อความระหว่างนักแสดง การสนับสนุนขั้นสูงสำหรับ DSL เฉพาะโดเมนโดยพลการความสามารถในการเขียนสคริปต์และ REPL Java เกี่ยวกับ '1 ระดับสูงกว่า C เนื่องจากการวางแนววัตถุการจัดการตัวชี้และการรวบรวมขยะการสนับสนุนสตริงการสนับสนุนหลายเธรดและการควบคุมการทำงานพร้อมกันรวมถึงไลบรารี API มาตรฐาน

1. ประสิทธิภาพการทำงาน: สำหรับภาษาระดับสูง (d) ให้ประสิทธิภาพที่เร็วกว่า (a) - (c)
   รหัส C ที่เขียนโดยตรงและเพิ่มประสิทธิภาพด้วยมือนั้นรวดเร็ว อย่างไรก็ตามภาษาระดับสูงกว่าที่รวบรวมแบบสแตติกกับ C นั้นค่อนข้างช้า นักออกแบบจาวารู้เรื่องนี้ดี การออกแบบ "ฮอตสปอต" ในปัจจุบันช่วยเพิ่มประสิทธิภาพได้สูงสุดตามลำดับความสำคัญ ในแกนเดียวโค้ด Java HotSpot นั้นเร็วกว่า '50% เร็วที่สุด 'โดย C ซึ่งเหมาะที่สุดสำหรับมนุษย์ (ในกรณีที่ดีที่สุดคือ' 120% เร็วที่สุด 'ในกรณีที่แย่ที่สุดคือ 30% เร็วที่สุด) แต่แน่นอนว่าเป็นการเปรียบเทียบแอปเปิ้ลกับส้ม - รหัสระดับต่ำ v รหัสระดับสูง และนั่นจะมากยิ่งแย่ลงหากไม่ได้ใช้การเพิ่มประสิทธิภาพฮอตสปอต เพื่อยืนยันเพียงปิดใช้งานการรวบรวมฮอตสปอตผ่านทาง JVM! หรือพิจารณาประสิทธิภาพของ java 1 & 2 เมื่อไม่มีฮอตสปอตหรือยังไม่บรรลุนิติภาวะ หรือลองรวบรวมภาษาอื่นผ่านทาง C - เช่น perlcc ดังนั้นข้างต้นเป็นผลลัพธ์ที่ยอดเยี่ยมสำหรับภาษาที่ทรงพลังและมีประสิทธิผล ด้วยการพัฒนาเพิ่มเติมเป็นไปได้ (หรืออาจเป็นไปได้) ที่ JVM อาจแซงหน้ารหัส C ที่เขียนด้วยมือโดยเฉลี่ย สกาล่าเป็นเพียง 70-80% ช้าที่สุดเท่าที่ java โดยเฉลี่ย แต่สกาล่ามีการขยายอย่างมากในหลายคอร์ ประสิทธิภาพแบบ Single Core สำหรับภาษาระดับสูงดังกล่าวได้รับการจัดอันดับ:

   ตีความ <รวบรวมแบบคงที่ <รวบรวมแบบไดนามิก

   ประสิทธิภาพ / ความยืดหยุ่นของมัลติคอร์ได้รับการจัดอันดับ:

   ตีความรหัสแบบไดนามิก <รหัสความจำเป็นในการคอมไพล์แบบคงที่ <ฟังก์ชันแบบคอมไพล์ / แบบรหัสที่ประกาศแบบคงที่

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

2. การทำงานร่วมกัน: ภาษาบน VM ที่สนับสนุนอย่างกว้างขวางมีการทำงานร่วมกันของภาษาได้ดีกว่าภาษาที่แยกได้. Scala "เล่นโดยอัตโนมัติด้วย" คลาส Java, อินเตอร์เฟสและวัตถุโดยเพียงแค่นำเข้ามันและใช้พวกมันราวกับว่าพวกมันเป็นคลาสสกาล่า, ลักษณะและวัตถุ มีความเป็นไปได้ที่คล้ายกันกับภาษา JVM อื่น ๆ เช่น Groovy, Clojure, JRuby และ JPython - ด้วยความง่ายในการทำงานร่วมกันขึ้นอยู่กับการทำความสะอาดแต่ละภาษาเพื่อรวบรวมคอมไพล์รันไทม์จาวา / คลาส / อินเตอร์เฟส / วัตถุที่เข้าใจได้ สิ่งนั้นมาพร้อมกับ 'ฟรี' (เหมือนใน 'ใกล้กับ') สกาล่าทำงานร่วมกับ C ผ่านทาง JNA ซึ่งเป็นตัวตายตัวแทนของ JNI ซึ่งมาพร้อมกับความพยายามบางอย่าง แต่เครื่องมือได้รับการปรับปรุงให้มีความคล่องตัวอยู่ตลอดเวลา JNA สามารถทำงานร่วมกับโค้ดเนมที่คอมไพล์ได้จากภาษาใดก็ได้ - แต่คุณจะต้องรู้โครงสร้างที่แน่นอนของประเภทข้อมูลและฟังก์ชั่นที่รวบรวม ถ้าไม่,

3. ความสามารถในการพกพา: JVM ทำงานบนแพลตฟอร์ม / ระบบปฏิบัติการหลายสิบเวอร์ชัน 'ออกนอกกรอบ' สกาล่าจะถูกส่งไปยังสิ่งเหล่านี้โดยอัตโนมัติ ข้อยกเว้นที่สังเกตได้คือ iOS (iPad / iPhone / iPod) - บล็อก 'เชิงพาณิชย์' แทนที่จะเป็น 'เทคนิค' โดย Apple สิ่งนี้ไม่สามารถคาดการณ์ได้เมื่อ 12 ปีก่อนระหว่างการออกแบบเบื้องต้นของ JVM JVM ทำงานได้ดีบนเซิร์ฟเวอร์เดสก์ท็อปโทรศัพท์มือถือและอุปกรณ์ฝังตัวอื่น ๆ รวมถึงเซิร์ฟเวอร์ที่ไม่รองรับ C - รวมถึง Android ที่มี Google ดัดแปลง Dalvik VM (ขายโทรศัพท์ใหม่ 50% +) แน่นอนว่ารหัส C ทำงานบนแพลตฟอร์มที่หลากหลายดังนั้นอาจได้รับการจัดอันดับ 'ขึ้นไปข้างบนด้วยหรืออาจเกินกว่า' Java (โดยเฉพาะ C คือชุดย่อยของ Objective-C) แต่ C จะมาด้วยราคาของ (1), (2) & (3) แน่นอนชั้นนำเสนอ HTML5 / javascript / webkit (หรือวัตถุประสงค์ -C) บน iOS สามารถทำงานร่วมกับแอปสกาล่าระยะไกลได้ดังนั้นผู้พัฒนาควรทำเช่นนั้น แน่นอนพวกเขาจะมีประสิทธิผลน้อยลง

4. เครื่องมือและไลบรารี : เห็นได้ชัดว่ามีห้องสมุดและเครื่องมือ Java เชิงพาณิชย์และโอเพนซอร์สหลายพันแห่งที่สามารถใช้ประโยชน์ / ถูกยกระดับโดย Scala - มากกว่าสำหรับ C.

5. ความปลอดภัย: - ทำงานบนเซิร์ฟเวอร์แอพที่มีการควบคุมหรือสภาพแวดล้อม JVM ให้การสนับสนุนที่แข็งแกร่งสำหรับนโยบายและข้อ จำกัด ด้านความปลอดภัยซึ่งอาจมีค่าสูงในสภาพแวดล้อมขององค์กร

JVM / CLR

JVM (และ CLR) มอบข้อได้เปรียบที่ไม่ซ้ำกันในแง่ของการเพิ่มประสิทธิภาพและการพกพาโค้ด

เท่าที่ฉันรู้เฉพาะ Scala รุ่น JVM เท่านั้นที่จะถูกเก็บเป็นปัจจุบันเวอร์ชัน NET ไม่

ดูเหมือนว่าคุณกำลังผสมสองสิ่งที่ไม่เกี่ยวข้อง

คนแรกคือซึ่งการเขียนโปรแกรมภาษาจะถูกใช้โดยผู้เขียนสกาล่า (s) ที่จะใช้สกาล่า?

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

สิ่งที่สองคือแพลตฟอร์มเป้าหมายสำหรับโปรแกรมที่เขียนใน Scala คืออะไร

ตัวเลือกที่นี่น่าสนใจยิ่งขึ้น แต่สำหรับตอนนี้เป้าหมายเดียวที่ใช้งานได้ 100% คือ JVM การสนับสนุน. NET ยังคงดำเนินการอยู่ นอกจากนี้บางคนกำลังทำงานเพื่อให้ Scala รวบรวมไปยัง javacsript ในทางทฤษฎีไม่มีอะไรที่ป้องกันไม่ให้ใครบางคนเพิ่ม 'แบ็กเอนด์' เพิ่มเติมสำหรับการคอมไพล์ใน C, C ++, LLVM, เนทีฟหรืออะไรก็ตาม

เหตุใดจึงเลือก JVM เป็นแพลตฟอร์มหลัก ฉันเดาว่าเพราะ

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

ก่อนอื่น - สิ่งที่ฉันคิดว่าคุณอยากถามคือทำไมสกาล่าไม่ได้รวบรวมภาษาอย่างเข้มงวด ฉันจะบอกคุณว่าฉันไม่รู้ แต่ฉันจะบอกคุณด้วยว่าไม่มีเหตุผลที่จะสนับสนุน JVM เกี่ยวกับรหัสภาษา

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

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

นั่นคือเหตุผลที่ฉันนึกถึง แต่โปรดจำไว้ว่าอาจมีเหตุผลอื่น ๆ - เช่นการออกใบอนุญาตและการเมืองที่เกี่ยวข้อง (ซึ่งเป็นสิ่งสกปรกที่ฉันไม่อยากเข้าไป)

ไม่ชัดเจนว่าการมีความสามารถในการปรับแต่งที่ดีกว่าจะเป็นการแลกเปลี่ยนที่ดี JVM สามารถเพิ่มประสิทธิภาพที่รันไทม์และอย่างน้อยก็ดีพอหากไม่ดีกว่าสิ่งที่เกิดขึ้นกับการคอมไพล์แบบสแตติก (เห็นได้ชัดว่าในหลักการสำหรับแอปพลิเคชันและเวิร์กโหลดที่เฉพาะเจาะจงมันควรจะเป็นไปได้ที่จะเอาชนะ JIT ด้วยการเพิ่มประสิทธิภาพแบบสแตติก แต่ในทางปฏิบัติคุณมักจะไม่ได้มีเวิร์กโหลดที่แม่นยำ