Có ai biết tại sao Scala được triển khai trong Java và .NET thay vì C hoặc C ++ không? Hầu hết các ngôn ngữ được triển khai với Cor C ++ [tức là Erlang, Python, PHP, Ruby, Perl]. Những lợi thế cho Scala được triển khai trong Java và .NET ngoài việc cấp quyền truy cập vào các thư viện Java và .NET là gì?

CẬP NHẬT

Scala sẽ không nhận được nhiều lợi ích hơn nếu nó được triển khai trong C bởi vì nó có thể được điều chỉnh tốt hơn thay vì dựa vào JVM?

Câu hỏi khó hiểu, vì C và C ++ là ngôn ngữ , trong khi JVM là máy ảo và .Net là một nền tảng . Scala có thể được triển khai trong C hoặc C ++ và nó có thể tạo mã máy thay vì mã byte cho máy ảo.

Trả lời câu hỏi đã được hỏi:

Scala không được triển khai trong C hoặc C ++ vì Scala, ngôn ngữ mà nó được thực hiện, là ngôn ngữ tốt hơn nhiều.

Tại sao nó tốt hơn? Chà, hãy đọc về các mục tiêu của Oderky cho ngôn ngữ Scala .

Trả lời câu hỏi có thể đã được dự định:

Scala tạo ra mã byte JVM chủ yếu vì nó cung cấp tính di động cao cũng như các tính năng như trình thu gom rác đáng tin cậy và hiệu quả, tối ưu hóa thời gian chạy và biên dịch đúng lúc bởi JVM .

Hãy để tôi nhắc lại điều cuối cùng: JVM sẽ biên dịch thành các điểm nóng mã máy trong mã mà nó đang chạy. Đó là trình biên dịch giống như trình biên dịch C và C ++.

Có sẵn các máy ảo khác, nhưng Oderky, người tạo ra Scala, đã rất quen thuộc với JVM. Ông dự định có CLR như một giải pháp thay thế, nhưng nỗ lực để đạt được điều đó vẫn chưa đạt được thành công.

Trả lời câu hỏi có thể / nên được hỏi:

Biên dịch mã máy không cung cấp đủ lợi ích so với biên dịch sang mã byte JVM.

Chắc chắn có thể tạo ra các dấu hiệu vi mô trong C hoặc C ++ để đánh bại các tương đương JVM. Cũng đúng là mã cực kỳ tối ưu hóa trong C hoặc C ++ sẽ đánh bại mã cực kỳ tối ưu hóa trong Java hoặc Scala. Sự khác biệt không phải là tất cả, tuy nhiên, đối với chương trình dài hạn.

Lưu ý rằng Scala không phải là một ngôn ngữ kịch bản đặc biệt chính xác vì chi phí cho các chương trình chạy ngắn quá lớn.

Tuy nhiên, trong hầu hết các trường hợp, tốc độ phát triển và dễ bảo trì quan trọng hơn tốc độ thực hiện . Trong những trường hợp đó, khi mọi người quan tâm nhiều hơn đến việc viết mã mức rất cao dễ hiểu và thay đổi, các tối ưu hóa thời gian chạy do JVM cung cấp có thể dễ dàng đánh bại các tối ưu hóa thời gian biên dịch được tạo bởi các trình biên dịch C hoặc C ++, tạo ra JVM (và CLR ) mục tiêu sẽ thực sự thực hiện nhanh hơn.

Vì vậy, cho dù câu hỏi là về trình biên dịch Scala là mã thực thi hay chương trình Scala là mã máy, thì tốc độ tăng tiềm năng không nhất thiết phải chuyển thành tăng tốc độ thực .

Và, nhân tiện,

Tôi sẽ cho bạn một ví dụ ngược lại: Haskell. Haskell tạo mã máy, và, tuy nhiên, các chương trình của Haskell tệ hơn trong vụ xả súng của Debian so với Scala. Cho rằng, bất cứ ai cũng có thể chắc chắn các chương trình Scala sẽ nhanh hơn nếu được biên dịch trực tiếp thành mã máy?

Một trong những rào cản lớn mà các ngôn ngữ phải đối mặt khi được giới thiệu với thế giới nói chung là tính sẵn có của thư viện. Phản ứng truyền thống về vấn đề này là cung cấp FFI (giao diện chức năng nước ngoài) dựa trên C để cho phép bạn truy cập vào các thư viện dựa trên C. Điều này không lý tưởng vì nhiều lý do, chủ yếu trong số đó:

• Có rất nhiều cách khác nhau mà các thư viện muốn tương tác mà không tương thích với nhiều ngôn ngữ cấp cao hơn. Ví dụ: nếu thư viện muốn một con trỏ tới a struct, làm thế nào để các ngôn ngữ không có con trỏ VÀ không có structđối phó?
• Có các tương tác khắc nghiệt giữa các mô hình bộ nhớ của các thư viện và ngôn ngữ khác nhau thường không thể phân giải được hoặc, nếu có thể phân giải được, rất dễ bị lỗi và dễ bị lỗi.
• Mã keo cho nhiều FFI là không tầm thường và giả định kiến ​​thức mà trên thực tế có thể không phổ biến. (Dù bạn có tin hay không, không phải tất cả các lập trình viên đều là những bậc thầy về C, và họ cũng không muốn trở thành họ cũng không cần phải như vậy!)

Điều này thậm chí còn tồi tệ hơn với C ++. C ++ thậm chí không tương thích với C ++ (ở cấp độ nhị phân, ý tôi là) từ trình biên dịch sang trình biên dịch trên cùng một nền tảng (!), Không đề cập đến với các ngôn ngữ khác.

Nhắm mục tiêu JVM giải quyết được nhiều vấn đề này trong khi cho phép bạn truy cập vào bộ thư viện dựa trên Java hoàn toàn khổng lồ . (Lớn đến mức nào? Chỉ cần tìm ra sự lựa chọn khổng lồ của Quỹ Phần mềm Apache cho người mới bắt đầu.)

• Các quy ước về quyền sở hữu và gọi vốn của Java thường xuyên hơn so với C.
• JVM cũng cung cấp một mô hình bộ nhớ duy nhất (bao gồm cả bộ sưu tập rác) cho cả ngôn ngữ và thư viện để giao tiếp với. Không cần phải theo dõi xem ai sở hữu cái gì và cái gì phải dọn sạch ở đâu. Thời gian chạy làm điều đó cho bạn.
• Mã keo cho FFI, đối với hầu hết các ngôn ngữ được xây dựng trên JVM, là không tồn tại (như được cung cấp dưới dạng khung phía sau hậu trường trong ngôn ngữ). Chẳng hạn, không cần phải lập trình bằng Java để truy cập các thư viện Java trong Scala, Clojure, JRuby, v.v. Bạn truy cập các đối tượng Java giống như cách bạn truy cập vào các "đối tượng" gốc có các đối tượng thực tế theo nghĩa OOP) và bằng ngôn ngữ mẹ đẻ của bạn.

Ngoài những ưu điểm này, bạn còn có các lợi thế bổ sung khi chạy bất cứ nơi nào Java chạy mà không cần biên dịch lại (nhưng với thử nghiệm!: Viết một lần, thử nghiệm ở mọi nơi) và có quyền truy cập vào công nghệ JIT khá ấn tượng của Java.

CLR cung cấp các điểm mạnh tương tự, nhưng thêm vào điểm yếu của IMO: đó là môi trường khóa của nhà cung cấp. (Vâng, tôi biết về Mono. Tôi vẫn nghĩ đó là môi trường khóa nhà cung cấp.)

Theo cuộc phỏng vấn này , truy cập vào cơ sở hạ tầng và thư viện Java hiện có là lý do chính.

... Java là một ngôn ngữ hiện có với các ràng buộc rất khó khăn. Kết quả là, tôi không thể làm nhiều thứ theo cách mà tôi muốn làm chúng theo cách mà tôi tin chắc sẽ là cách đúng đắn để làm chúng. Vì vậy, sau thời gian đó, về cơ bản, trọng tâm công việc của tôi là làm cho Java trở nên tốt hơn, tôi quyết định rằng đã đến lúc phải lùi lại một bước. Tôi muốn bắt đầu với một bảng sạch và xem liệu tôi có thể thiết kế thứ gì đó tốt hơn Java không. Nhưng đồng thời tôi biết rằng tôi không thể bắt đầu lại từ đầu. Tôi đã phải kết nối với một cơ sở hạ tầng hiện có, bởi vì nếu không thì việc tự khởi động bản thân mà không có thư viện, công cụ và những thứ tương tự là không thực tế.

Vì vậy, tôi đã quyết định rằng mặc dù tôi muốn thiết kế một ngôn ngữ khác với Java, nhưng nó sẽ luôn kết nối với cơ sở hạ tầng Java - với JVM và các thư viện của nó . Đó là ý tưởng ...

Tất cả các ngôn ngữ khác mà bạn đề cập, Erlang, Python, PHP, Ruby, Perl - tất cả các ngôn ngữ này đều được tạo trước Java & .NET. Nếu người tạo ra các ngôn ngữ đó có sẵn môi trường thời gian chạy Java hoặc .NET cho họ, thì có thể họ đã tận dụng những ngôn ngữ đó khi xây dựng ngôn ngữ của họ.

Tất nhiên, tôi không thể nói cho các nhà phát triển các ngôn ngữ đó, vì vậy tôi không thể nói chắc chắn rằng họ đã sử dụng .NET và / hoặc Java khi xây dựng chúng có sẵn, nhưng dường như tôi thích ý tưởng tốt. Rốt cuộc, bằng cách thiết kế ngôn ngữ của bạn để biên dịch sang mã byte Java / .NET, bạn có được tất cả các lợi thế của trình biên dịch / tối ưu hóa JIT, ngôn ngữ của bạn sẽ tự động chạy trên tất cả các nền tảng mà Java / .NET chạy, bạn có quyền truy cập vào tất cả các thư viện Java / .NET, v.v.

Mã C được biên dịch tĩnh thành mã gốc (mã máy).

Scala được biên dịch tĩnh thành mã byte java và sau đó, theo yêu cầu, được biên dịch động thành mã gốc được tối ưu hóa. Quá trình:

Mã Scala --- được biên dịch tĩnh-to ---> Mã byte JVM --- được biên dịch động bởi-JVM-Hotspot-to ---> mã gốc

Tùy chọn chung để xây dựng / chạy bất kỳ ngôn ngữ nào:

• a) giải thích mã nguồn trực tiếp thông qua một công cụ thông dịch thời gian chạy
• b) biên dịch tĩnh mã thành mã gốc (có thể thông qua các giai đoạn trung gian, ví dụ nguồn -> C -> gốc)
• c) biên dịch tĩnh mã nguồn thành mã trung gian cấp thấp hơn và giải thích nó khi chạy
• d) biên dịch tĩnh mã nguồn thành mã trung gian cấp thấp hơn, sau đó sử dụng giải thích ban đầu, tiếp theo là kỹ thuật biên dịch và tối ưu hóa động để chuyển đổi sang mã gốc. Mã được diễn giải cho đến khi tìm thấy đường dẫn thực thi điển hình và các nút cổ chai, sau đó mã được biên dịch để thực thi nhanh nhất trong các điều kiện điển hình. Nó được biên dịch lại / trả về khi điều kiện thực thi thay đổi đủ để đảm bảo điều này

Câu hỏi của bạn: "Tại sao Java sử dụng (d) với JVM, thay vì (b) với mã trung gian C?"

Câu trả lời:

Đầu tiên, hãy quan sát rằng Scala rất nhiềungôn ngữ cấp cao hơn C, mang lại sức mạnh lập trình, dễ lập trình và tính đồng nhất. Nó cao hơn '1 cấp' so với Java do các hàm bậc nhất & bậc cao hơn, các hàm ẩn, các hàm như các đối tượng, các bao đóng và curry, hỗ trợ biên dịch đệ quy đuôi thành các vòng lặp bảo toàn ngăn xếp nhanh, mọi thứ như các đối tượng, tất cả các toán tử như các phương thức có thể được định nghĩa lại trong các thư viện, lớp trường hợp và mức giảm (khớp mẫu), dẫn xuất kiểu ẩn, tính đa hình mạnh hơn thông qua các đặc điểm đa kế thừa mở rộng và cú pháp mở rộng, cú pháp tích hợp cho cặp & tuples & cons (danh sách & cây ) & bản đồ, hỗ trợ cho các cấu trúc dữ liệu bất biến, hỗ trợ tính toán song song và phản ứng mạnh mẽ với khả năng sao chép và chuyển thông điệp giữa các tác nhân, hỗ trợ nâng cao cho các DSL cụ thể theo miền cụ thể, khả năng tạo script và REPL. Java cao hơn '1 cấp' so với C do hướng đối tượng, quản lý con trỏ và thu gom rác, hỗ trợ chuỗi, hỗ trợ đa luồng và kiểm soát tương tranh, cộng với các thư viện API tiêu chuẩn.

1. Hiệu suất: Đối với ngôn ngữ cấp cao, (d) cho hiệu suất nhanh hơn (a) - (c).
   Mã C được viết trực tiếp và tối ưu hóa bằng tay rất nhanh. Tuy nhiên, các ngôn ngữ cấp cao hơn được biên dịch tĩnh thành C tương đối chậm. Các nhà thiết kế java biết rõ điều này. Thiết kế "Hotspot" hiện tại của họ giúp tăng hiệu suất lên tới mức độ lớn. Trên một lõi đơn, mã Java HotSpot trung bình '50% nhanh nhất 'như C được tối ưu hóa cho con người (trong trường hợp tốt nhất là' 120% nhanh nhất ', trong trường hợp xấu nhất là '30% nhanh nhất'). Nhưng tất nhiên đó là so sánh táo với cam - mã cấp thấp v mã cấp cao. Và đó sẽ là nhiềutệ hơn nếu tối ưu hóa Hotspot không được sử dụng. Để xác nhận, chỉ cần vô hiệu hóa trình biên dịch hotspot thông qua JVM args! Hoặc xem xét hiệu suất java 1 & 2, khi hotspot không tồn tại hoặc chưa trưởng thành. Hoặc thử biên dịch ngôn ngữ khác qua C - ví dụ: perlcc. Vì vậy, trên đây là kết quả tuyệt vời cho một ngôn ngữ mạnh mẽ và hiệu quả. Với sự phát triển hơn nữa, trung bình có thể (hoặc thậm chí có khả năng) rằng JVM có thể sớm vượt xa C được mã hóa trung bình. Scala chỉ chậm 70-80% như java trung bình. Nhưng scala có quy mô mạnh mẽ trên nhiều lõi (với những cải tiến tiếp theo sẽ được tiếp tục), trong khi java thì một phần và C thì không. Hiệu suất lõi đơn cho các ngôn ngữ cấp cao như vậy được xếp hạng:

   diễn giải <biên dịch tĩnh <biên dịch động

   Hiệu năng / khả năng mở rộng đa lõi được đánh giá:

   giải thích mã động <mã bắt buộc được biên dịch tĩnh <mã khai báo chức năng / mã khai báo tĩnh <mã được biên dịch động / mã khai báo

   Điều này đặt scala vào vị trí chiến thắng vì tốc độ bộ xử lý đã đạt đến giới hạn và giờ đây số lượng lõi đang tăng theo luật Moore. Scala rất nhanh trên nhiều lõi và trong tương lai, có thể trở nên nhanh hơn nhiều lần so với C hoặc java. Biên dịch tĩnh thành C rõ ràng không phải là lựa chọn nhanh nhất.

2. Khả năng tương tác: các ngôn ngữ trên VM được hỗ trợ rộng rãi có khả năng tương tác ngôn ngữ tốt hơn các ngôn ngữ 'bị cô lập'. Scala "tự động chơi với" các lớp, giao diện và đối tượng java bằng cách nhập chúng và sử dụng chúng như thể chúng là các lớp, đặc điểm và đối tượng scala. Tương tự như vậy với các ngôn ngữ JVM khác như Groovy, Clojure, JRuby và JPython - với khả năng tương tác dễ dàng tùy thuộc vào mức độ mỗi ngôn ngữ được tạo ra để biên dịch thành các lớp / giao diện / đối tượng java có thể hiểu được. Điều đó đến với 'miễn phí' (như trong 'gần với'). Scala tương tác với C thông qua JNA, người kế nhiệm JNI - đi kèm với một số nỗ lực, nhưng các công cụ đã được sắp xếp khá tốt theo thời gian. JNA thực sự có thể tương tác với mã gốc được biên dịch từ bất kỳ ngôn ngữ tùy ý nào - nhưng bạn phải biết cấu trúc chính xác của các kiểu dữ liệu và hàm được biên dịch. Nếu không,

3. Tính di động: JVM chạy trên hàng chục nền tảng / phiên bản hệ điều hành 'ngoài luồng'. Scala được tự động chuyển đến. Ngoại lệ đáng chú ý là iOS (iPad / iPhone / iPod) - bị chặn 'về mặt thương mại', thay vì 'về mặt kỹ thuật' của Apple. Điều này không thể được dự đoán từ 12 năm trước, trong quá trình thiết kế ban đầu của JVM. JVM chạy tốt trên hàng chục máy chủ, máy tính để bàn, điện thoại di động và thiết bị nhúng khác, bao gồm cả những máy chủ không hỗ trợ C - bao gồm cả Android với Dalvik VM được Google điều chỉnh (50% + điện thoại mới được bán). Chắc chắn, mã C hoạt động trên vô số nền tảng, do đó, có thể được xếp hạng 'trên đó có hoặc có thể vượt ra ngoài' Java (đáng chú ý, C là tập con của Objective-C). Nhưng C sẽ có giá (1), (2) & (3). Tất nhiên, lớp trình bày HTML5 / javascript / webkit (hoặc object-C) trên iOS có thể tương tác với một ứng dụng scala từ xa - vì vậy, các nhà phát triển nên làm điều đó rất nhiều. Tất nhiên, họ sẽ làm việc kém hiệu quả hơn.

4. Các công cụ và thư viện : Rõ ràng có hàng ngàn thư viện và công cụ Java thương mại và nguồn mở có thể tận dụng / được Scala tận dụng - nhiều hơn cho C.

5. Bảo mật: - chạy trên máy chủ ứng dụng được kiểm soát hoặc môi trường JVM cung cấp hỗ trợ mạnh mẽ hơn cho các chính sách và hạn chế bảo mật, có thể có giá trị cao trong môi trường doanh nghiệp.

JVM / CLR

JVM (và CLR) cung cấp các lợi thế độc nhất về tối ưu hóa và tính di động của mã.

Theo tôi biết, chỉ có phiên bản JVM của Scala đang được giữ nguyên, phiên bản .NET thì không.

Có vẻ như bạn đang trộn lẫn hai thứ không liên quan.

Đầu tiên là, ngôn ngữ lập trình nào được sử dụng bởi tác giả Scala để thực hiện Scala?

Câu trả lời là Scala. Và đó thực sự là câu trả lời chấp nhận được, bởi vì nếu bạn đã phát minh ra ngôn ngữ mới này, nhưng đừng tự mình sử dụng nó để thực hiện nó - nó có ích gì?

Điều thứ hai là, nền tảng đích để chạy các chương trình được viết bằng Scala là gì?

Ở đây sự lựa chọn trở nên thú vị hơn, nhưng hiện tại, mục tiêu duy nhất hoạt động 100% là JVM. Hỗ trợ cho .NET vẫn đang hoạt động. Ngoài ra, một số người đang làm việc để Scala biên dịch thành javacsript. Về lý thuyết, không có gì ngăn cản ai đó thêm nhiều 'phụ trợ' để biên dịch sang C, C ++, LLVM, mã gốc hoặc bất cứ thứ gì.

Tại sao JVM được chọn làm nền tảng chính? Tôi đoán là bởi vì

• ai cũng muốn thu gom rác
• số lượng lớn các thư viện tốt đã sẵn sàng để sử dụng
• số lượng lớn lập trình viên chán Java đã sẵn sàng để chuyển sang một thứ mới, nhưng vẫn tuân theo các giới hạn của JVM (không ai muốn di chuyển mã hiện có của họ sang nền tảng khác)

Trước hết - điều tôi đoán bạn thực sự muốn hỏi là tại sao Scala không được biên dịch ngôn ngữ theo cách nghiêm ngặt. Tôi sẽ nói với bạn tôi không biết. Nhưng tôi cũng sẽ nói với bạn rằng không có lý do gì để ưu tiên JVM hơn mã gốc.

Tại sao? Lý do rất đơn giản: bất kỳ công nghệ ảo hóa nào đều bị đói bộ nhớ, tạo ra chi phí không cần thiết và một lớp không xác định khác. Đây không phải là vấn đề thực hiện của họ - đây là vấn đề thực tế, về logic nằm sau khái niệm cốt lõi của ảo hóa. Không có vấn đề gì bạn sẽ LUÔN LUÔN kết thúc với các đặc điểm thấp kém. Đặc biệt là JVM là bộ nhớ đói. Nó không còn quá chậm nữa, bởi vì nó có trình biên dịch thời gian chạy riêng chạy phía sau, nhưng vẫn phải chạy quy trình biên dịch để có thể phát hiện ra các phần mã bị tắc nghẽn nhất và biến chúng thành mã nhị phân.

Nói rằng - lý do duy nhất tôi nghĩ là có để tạo Scala dựa trên Jala có lẽ là sự phổ biến của ngôn ngữ. Tôi cũng đoán rằng một số sự lười biếng đã đứng sau sự phân rã này bởi vì việc triển khai một ngôn ngữ qua JVM dễ dàng hơn so với việc tìm ra cách mọi thứ trông giống như được lắp ráp để hoạt động đa nền tảng - và thậm chí sử dụng các phụ trợ C hiện tại đòi hỏi nhiều công việc hơn do thực tế rằng mọi thứ không được ổn định như với JVM.

Đó là lý do tôi có thể nghĩ ra, nhưng hãy nhớ rằng có thể có những lý do khác - như cấp phép và chính trị liên quan ở đó (đó là những điều bẩn thỉu tôi sẽ không bao giờ muốn vào).

Không rõ ràng rằng có khả năng điều chỉnh tốt hơn sẽ là một sự đánh đổi tốt. Các JVM có thể thực hiện tối ưu hóa trong thời gian chạy và điều đó ít nhất là đủ tốt, nếu không vượt trội so với những gì thường xảy ra với quá trình biên dịch tĩnh. (Rõ ràng về nguyên tắc đối với một ứng dụng cụ thể và khối lượng công việc, có thể đánh bại JIT bằng tối ưu hóa tĩnh, nhưng thực tế bạn không thường có khối lượng công việc chính xác hoặc thậm chí toàn bộ ứng dụng.)