Scala'nın neden Java veya .NET'te C veya C ++ yerine uygulandığını bilen var mı? Çoğu dil Cor C ++ [yani Erlang, Python, PHP, Ruby, Perl] ile uygulanır. Scala'nın Java ve .NET'te uygulanan, Java ve .NET kitaplıklarına erişim vermekten başka avantajları nelerdir?

GÜNCELLEŞTİRME

Scala, C'ye uygulanmış olsaydı, JVM'ye güvenmek yerine daha iyi ayarlanabileceği için daha fazla fayda elde etmez miydi?

C ve C ++ dilleri olduğu için soru kafa karıştırıcı, JVM ise sanal bir makine ve .Net bir platform . Scala, C veya C ++ ile uygulanabilir ve sanal bir makine için bayt kodu yerine makine kodu oluşturabilir.

Sorulan soruyu cevaplama:

Scala C veya C ++ dilinde uygulanmadı çünkü aslında uygulandığı dil Scala çok daha iyi bir dil.

Neden daha iyi Öyleyse git Odersky'nin Scala dili için hedeflerini oku .

Amaçlanan soruyu cevaplamak:

Scala, öncelikle JVM bayt kodunu oluşturur, çünkü güvenilir ve verimli bir çöp toplayıcı, çalışma zamanı optimizasyonları ve JVM tarafından tam zamanında derleme gibi özelliklerin yanı sıra mükemmel taşınabilirlik sağlar .

Son şeyi tekrar edeyim: JVM , çalıştığı koddaki makine kodunu sıcak noktalar için derleyecektir . C ve C ++ derleyicileri gibi derler.

Kullanılabilir başka sanal makineler var, ancak Scala'nın yaratıcısı Odersky, JVM'ye zaten çok aşinaydı. Bir alternatif olarak CLR'ye sahip olmayı hedefliyordu, ancak bunu başarma çabası henüz başarıya ulaşamadı.

Sorulması gereken / cevaplanması gereken soruyu cevaplama:

Makine kodunu derlemek, JVM bayt kodunu derlemekten yeterince fayda sağlamaz.

C veya C ++ 'da JVM eşdeğerlerini geçen mikroböceklerin üretilmesi kesinlikle mümkündür. Ayrıca, C veya C ++ 'da aşırı derecede optimize edilmiş kodun Java veya Scala'da oldukça optimize edilmiş kodu geçeceği de doğrudur. Ancak, uzun süren program için fark o kadar da büyük değil.

Scala'nın tam olarak iyi bir betik dili olmadığını unutmayın; çünkü kısa süreli programlar için ek yük çok fazladır.

Ancak, çoğu durumda geliştirme hızı ve bakım kolaylığı, yürütme hızından daha önemlidir . İnsanların kolayca anlayabilen ve değiştiren çok yüksek seviyeli kod yazma konusunda daha fazla endişe duydukları durumlarda, JVM tarafından sağlanan çalışma zamanı optimizasyonları, C veya C ++ derleyicileri tarafından yapılan derleme zamanı optimizasyonlarını kolayca yenebilir ve JVM (ve CLR) yapabilir. ) aslında daha hızlı yürütülecek hedef.

Dolayısıyla, sorunun Scala derleyicisinin çalıştırılabilir bir makine kodu olması veya Scala programlarının makine kodu olması ile ilgili olması fark etmeksizin , potansiyel hız kazanımları, mutlaka gerçek hız kazanımlarına çevrilmez .

Ve bu arada,

Size bir karşı örnek vereceğim: Haskell. Haskell, makine kodu üretir ve yine de Haskell programları, Debian'ın çatışmalarında Scala'nınkinden daha kötü. Buna bakıldığında, herkes doğrudan makine koduna derlenirse Scala programlarının daha hızlı olacağından emin olabilir mi?

Dünyaya tanıtılırken karşılaşılan büyük engelli dillerinden biri kütüphane mevcudiyetidir. Buna geleneksel cevap, C tabanlı kütüphanelere erişiminizi sağlamak için C tabanlı bir FFI (yabancı fonksiyon arayüzü) sağlamak olmuştur. Bu, çeşitli nedenlerden dolayı ideal değildir, aralarında şef var:

• Kütüphanelerin birbirleriyle daha üst düzey dillerle uyumlu olmayan etkileşimde bulunmak istediği birçok farklı yol vardır. Kütüphanesi için bir işaretçi istiyorsa Örneğin struct, nasıl hiçbir işaretçiler ile dilleri yok VE hiçbir structs başa?
• Farklı kütüphanelerin bellek modelleri ile çoğu zaman çözülemeyen veya çözülebilirse yüksek derecede hata ve hataya açık diller arasındaki sert etkileşimler vardır.
• Birçok FFI için tutkal kodu önemsiz değildir ve aslında evrensel olamayacak bilgiyi varsayar. (İster inanın ister inanmayın, tüm programcılar C gurusu değiller ve ne olmak istiyorlar ya da olmaları gerekmiyor!)

Bu C ++ ile daha da kötüleşiyor. C ++, derleyiciden derleyiciye , aynı platformdaki (!) ( İkilik seviyede ), diğer dillerden bahsetmeden bile.

JVM'yi hedeflemek, kesinlikle muazzam Java tabanlı kütüphaneler grubuna erişebilmenizi sağlarken, bu sorunların çoğunu çözer . (Ne kadar muazzam? Sadece Apache Yazılım Vakfı'nın yeni başlayanlar için seçtikleri kapsamı genişletin .)

• Java’nın arama ve mülkiyet sözleşmeleri C’lerden daha düzenlidir.
• JVM ayrıca, hem arabirim hem de diller için tek bir bellek modeli (çöp toplama dahil) sağlar. Kimin neye sahip olduğunu ve neyi temizlemesi gerektiğini izlemeye gerek yok. Çalışma zamanı sizin için yapar.
• FFI için yapıştırma kodu, JVM üzerine inşa edilmiş çoğu dilde mevcut değildir (dilde perde arkasındaki çerçeve olarak sağlanmıştır). Örneğin, Scala, Clojure, JRuby, vb. Java kütüphanelerine erişmek için Java'da programlamaya gerek yoktur. OOP anlamında gerçek nesneler var) ve kendi dilinizde.

Bu avantajların ötesinde ayrıca Java çalışır yerde çalışan katma avantajlara sahip olmadan derlemeksizin (ama ile bir kez test !: yazma, her yerde testi) ve Java'nın oldukça etkileyici JIT teknolojisine sahip erişim.

CLR benzer güçlü yönler sağlar, ancak IMO'ya zayıflık ekler: hemen hemen bir satıcı kilitleme ortamı. (Evet, Mono'yu biliyorum. Hala bir satıcı kilitleme ortamı olduğunu düşünüyorum.)

Bu görüşmeye göre , mevcut Java altyapısına ve kütüphanelerine erişim birincil nedendi.

... Java, çok zor kısıtlamaları olan mevcut bir dildir. Sonuç olarak, birçok şeyi yapmayı istediğim gibi yapamadım - ikna olma şeklim onları yapmanın doğru yolu olurdu. Bu saatten sonra, esasen işimin odak noktası Java'yı daha iyi hale getirmek olduğunda, geri adım atmanın zamanı olduğuna karar verdim. Temiz bir sayfa ile başlamak ve Java'dan daha iyi bir şey tasarlayıp tasarlayamayacağımı görmek istedim. Fakat aynı zamanda sıfırdan başlayamayacağımı da biliyordum. Var olan bir altyapıya bağlanmak zorunda kaldım, çünkü aksi halde hiçbir kütüphane, araç ve benzeri şeyler olmadan kendinizi hiçbir şeyden kurtarmak zor olmaz.

Bu yüzden Java'dan farklı bir dil tasarlamak istememe rağmen, her zaman Java altyapısına - JVM'ye ve kitaplıklarına bağlanacağına karar verdim . Fikir buydu ...

Bahsettiğiniz diğer tüm diller, Erlang, Python, PHP, Ruby, Perl - bunlar Java & .NET'ten önce oluşturulmuştur . Bu dillerin yaratıcıları o zamanlar kendileri için Java veya .NET çalışma zamanı ortamına sahipse, dillerini oluştururken bu araçlardan yararlanmış olabilirler.

Tabii ki, bu dillerin geliştiricileri için konuşamıyorum, bu yüzden hazır olduklarında bunları oluştururken .NET ve / veya Java kullandıklarını kesin olarak söyleyemem , ama bana öyle geliyor. İyi bir fikir. Sonuçta, dilinizi Java / .NET bayt kodunu derlemek üzere tasarlayarak, JIT derleyicilerinin / optileriers'ın tüm avantajlarını elde edersiniz, diliniz otomatik olarak Java / .NET'in çalıştığı tüm platformlarda çalışır, hepsine erişirsiniz. Java / .NET kütüphaneleri vb.

C kodu statik olarak yerel koda (makine kodu) derlenmiştir .

Scala statik olarak java bytecode'a derlenir ve daha sonra gerektiğinde, optimize edilmiş yerel koda dinamik olarak derlenir. Süreç:

Ölçek kodu --- statik olarak derlenmiş --- için JVM bayt kodu --- dinamik olarak derlenmiş JVM-Hotspot---- ---> yerel kod

Herhangi bir dili oluşturmak / çalıştırmak için genel seçenekler:

• a) kaynak kodu doğrudan bir çalışma zamanı tercüman motoru aracılığıyla yorumlamak
• b) kodu yerel kodla statik olarak derleyin (muhtemelen ara aşamalar aracılığıyla örn. kaynak -> C -> yerel)
• c) kaynak kodu daha düşük seviyedeki ara koda statik olarak derleyin ve çalışma zamanında yorumlayın
• d) kaynak kodu daha düşük seviyedeki ara koda statik olarak derleyin, ardından ilk yorumu kullanın, ardından yerel koda dönüştürmek için dinamik derleme ve optimizasyon teknikleri kullanın. Kod, tipik uygulama yolları ve darboğazları bulununcaya kadar yorumlanır, daha sonra tipik koşullar altında en hızlı uygulama için kod derlenir. İcra şartları bunu garantilemek için yeterince değiştiğinde yeniden derlenir / iade edilir

Sorunuz: "Java neden (d) (b) yerine C ara kodunu kullanarak bir JVM ile kullanıyor?"

Cevap:

İlk olarak, Scala'nın çok fazla olduğunu gözlemleC'den daha yüksek dil, programlama gücü, programlama kolaylığı ve özlülük verir. Birinci sınıf ve daha üst düzey işlevler, örtük işlevler, nesne olarak işlevler, kapaklar ve kurutma işlemleri, hızlı yığın koruyucu döngülere göre kuyruk özyinelemesi için destek, nesneler için her şey, tüm operatörler gibi yöntemler nedeniyle Java'dan '1 seviye daha yüksek' kütüphanelerde, vaka sınıflarında ve reddedilme (desen eşleştirme), örtük tip türetme, genişletilmiş çok kalıtsal özellikler ve genişletilmiş jenerikler yoluyla daha güçlü polimorfizm, çiftler ve gruplar ve eksiler için yerleşik sözdizimi (listeler ve ağaçlar) (yeniden) tanımlanabilir ) ve haritalar, değişken veri yapılarını destekleme, mesajların kopyalanması ve aktörler arasında geçiş ile güçlü ve 'reaktif' paralel ve eşzamanlı hesaplama desteği, rastgele etki alanına özgü DSL'ler, yazılabilirlik ve REPL için gelişmiş destek. Java, nesne yönelimi, işaretçi yönetimi ve çöp toplama, string desteği, çoklu iş parçacığı desteği ve eşzamanlılık kontrolü ve ayrıca standart API kütüphaneleri nedeniyle C'nin yaklaşık 1 seviyesinden daha yüksek.

1. Performans: Üst düzey bir dil için (d), (a) - (c) işaretlerinden daha hızlı performans verir.
   Doğrudan yazılmış ve elle optimize edilmiş C kodu hızlı. Ancak, statik olarak C'ye göre derlenmiş yüksek seviyeli diller nispeten yavaştır. Java tasarımcıları bunu iyi biliyordu. Mevcut "Hotspot" tasarımı, büyüklük sırasına göre performansı artırır. Tek bir çekirdekte Java HotSpot kodu, insan tarafından optimize edilen C (ortalama olarak% 120, en kötü durumda '% 30 hızlı') durumunda ortalama '% 50 kadar hızlı' şeklindedir. Ama elbette elmaları portakallarla karşılaştıran - düşük seviye kod v yüksek seviye kod. Ve bu olurdu çokHotspot optimizasyonu kullanılmamışsa daha da kötüsü. Onaylamak için, sıcak nokta derlemesini JVM args üzerinden devre dışı bırakmanız yeterlidir! Veya sıcak nokta bulunmadığında ya da olgunlaşmamışken java 1 ve 2 performansını düşünün. Veya başka bir dili C - örneğin perlcc aracılığıyla derlemeyi deneyin. Bu yüzden yukarıdakiler güçlü ve üretken bir dil için mükemmel sonuçlar. Daha da gelişmekle birlikte, JVM'nin ortalama olarak elle kodlanmış C'yi kısa süre sonra geride bırakması mümkündür. Scala, yalnızca ortalama% 70-80 java kadar yavaş. Ancak scala, birçok çekirdeği (hala devam eden geliştirmelerle birlikte) kuvvetle ölçeklendirirken, java kısmen yapılıyor ve C ise yok. Bu gibi üst düzey diller için Tek Çekirdekli performans derecelendirilmiştir:

   yorumlanmış <statik olarak derlenmiş <dinamik olarak derlenmiş

   Çok Çekirdekli performans / ölçeklenebilirlik derecelendirilmiştir:

   yorumlanmış dinamik kod <statik olarak derlenmiş zorunlu kod <statik olarak derlenmiş işlevsel / bildirimsel kod <dinamik olarak derlenmiş işlevsel / bildirimsel kod

   Bu, skalayı kazanan koltuğa oturtur çünkü işlemci hızı sınırını aşmıştır ve artık çekirdek sayısı Moore kanununa göre artmaktadır. Scala'nın çoklu çekirdeklerde ve gelecekte çok hızlı olması, C veya java'dan birkaç kat daha hızlı olabilir. Statik olarak C'ye derlemek açıkça en hızlı seçenek değildir.

2. Birlikte çalışabilirlik: Yaygın olarak desteklenen bir VM'deki diller, 'yalıtılmış' dillerden daha iyi bir dil birlikte çalışabilirliğine sahiptir. Scala "java sınıfları, arayüzleri ve nesnelerini basitçe içe aktararak ve scala sınıfları, özellikleri ve nesneleriymiş gibi kullanarak kullanarak otomatik olarak oynatılır. Groovy, Clojure, JRuby ve JPython gibi diğer JVM dilleri ile benzer şekilde mümkündür - her dilin anlaşılabilir ve kullanılabilir java çalışma zamanı sınıfları / arayüzleri / nesneleri için ne kadar net bir şekilde derlendiğine bağlı olarak birlikte çalışabilirlik kolaylığı. Bu, 'özgür' ('yakın' gibi) için gelir. Scala, JNI'nin halefi olan JNA üzerinden C ile birlikte çalışır - bu da biraz çaba gerektirir, ancak araçlar zaman içinde oldukça iyi düzenlenmiştir. JNA, herhangi bir isteğe bağlı dilden derlenmiş yerel kodla birlikte çalışabilir - ancak derlenmiş veri türlerinin ve işlevlerinin tam yapısını bilmelisiniz. Değilse,

3. Taşınabilirlik: JVM, 'kutudan çıkarılmış' düzinelerce işletim sistemi platformunda / sürümünde çalışır. Scala otomatik olarak bunlara taşınır. Not edilen istisna, iOS'tur (iPad / iPhone / iPod) - Apple tarafından 'teknik olarak' değil, 'ticari olarak' engellenir. Bu, JVM'nin ilk tasarımı sırasında 12 yıl önceden beklenemezdi. JVM, C uyarlamayanlar da dahil olmak üzere düzinelerce diğer sunucularda, masaüstlerinde, cep telefonlarında ve gömülü cihazlarda çalışıyor - Google uyarlanmış Dalvik VM'li Android dahil (satılanların% 50'si +). Elbette, C kodu çok sayıda platformda çalışır, bu nedenle Java ile 'yukarıda veya muhtemelen ötesinde' olarak derecelendirilebilir (özellikle C, Objective-C'nin bir alt kümesidir). Fakat C, (1), (2) & (3) maliyetine ulaşacaktır. Elbette, iOS üzerindeki HTML5 / javascript / webkit (veya objektif-C) sunum katmanı uzak bir scala uygulamasıyla birlikte çalışabilir - bu nedenle geliştiricinin bunu yapması gerekir. Tabii daha az üretken olacaklar.

4. Araçlar ve Kütüphaneler : Açıkçası, Scala'dan yararlanabilecek / kaldıraç sağlayabilecek binlerce ticari ve açık kaynaklı Java kütüphanesi ve aracı var.

5. Güvenlik: - Kontrollü bir uygulama sunucusunda veya JVM ortamında çalışmak, şirket ortamında çok değerli olabilecek güvenlik politikaları ve kısıtlamaları için daha güçlü destek sağlar.

JVM / CLR

JVM (ve CLR), optimizasyon ve kod taşınabilirliği açısından benzersiz avantajlar sağlar.

Bildiğim kadarıyla Scala'nın sadece JVM versiyonu güncel tutuluyor, .NET versiyonu değil.

İki alakasız şeyi karıştırıyor gibisin.

Birincisi, Scala yazar (ları) tarafından Scala'yı uygulamak için hangi programlama dilini kullanıyor?

Cevabın hangi olduğu, Scala'nın kendisi. Ve bu gerçekten kabul edilebilir tek cevap, çünkü eğer bu yeni dili icat ettiyseniz, fakat onu uygulamak için kendiniz kullanmayın - bunun faydası nedir?

İkincisi , Scala'da yazılmış programları çalıştırmak için hedef platform nedir?

Burada seçim daha ilginç hale geliyor, ancak şimdilik% 100 çalışan tek hedef JVM. .NET desteği hala devam ediyor. Ayrıca, bazı insanlar Scala'yı javacsript'e derlemek için çalışıyor. Teoride, hiçbir şey birisinin C, C ++, LLVM, yerel kod ya da her neyse derleme için daha fazla 'arka uç' eklemesini engellemez.

Neden JVM birincil platform olarak seçildi? Tahminim çünkü

• herkes çöp toplama istiyor
• Çok sayıda iyi kitaplık kullanıma hazır
• çok sayıda programcı Java ile sıkılmış, yeni bir şeye atlamaya hazır, ancak JVM'nin sınırlarını koruyamıyor (kimse mevcut kodunu başka bir platforma taşımak istemiyor)

Her şeyden önce - gerçekten sormak istediğim tahminim, Scala'nın neden katı bir şekilde derlenemediğidir. Sana bilmediğimi söyleyeceğim. Fakat size ayrıca JVM'yi yerel kod yerine tercih etmenin bir nedeni olmadığını söyleyeceğim.

Niye ya? Sebep basittir: Herhangi bir sanallaştırma teknolojisi hafızada açtır, gereksiz ek yük ve başka bir dolaylı katman oluşturur. Bu onların uygulanması meselesi değil - bu sanallaştırma temel kavramının arkasında yatan mantık meselesidir. Ne yaparsanız yapın, HER ZAMAN daha düşük özelliklere sahip olursunuz . Özellikle JVM hafızada aç. Artık o kadar yavaş değil, çünkü arkada çalışan kendi çalışma zamanı derleyicisine sahip, ancak yine de - kodun en sıkışık bölümlerini görebilmek ve bunları ikili koda dönüştürmek için derleyici işlemini çalıştırması gerekiyor.

Scala JVM tabanlı yapmak için orada olduğunu düşünüyorum tek nedeni muhtemelen dilin popülaritesi olduğunu söyledi. Ayrıca, biraz tembelliğin bu kararın arkasında olduğunu tahmin ediyorum, çünkü JVM'ye bir dil uygulamak daha kolay hale getirilirken işler nasıl bir araya getirilmiş gibi görünmesi gerektiğini bulmaktan daha kolaydır - ve hatta mevcut C arka uçlarını kullanmak bile gerçeğinden dolayı çok daha fazla iş gerektirir bu şeylerin JVM'de olduğu gibi standartlaştırılmadığını.

Düşünebilmemin nedeni bu, ancak başka nedenlerin de olabileceğini aklınızda bulundurun - lisans veren kuruluş ve oradaki politika gibi (içine girmekten hiç hoşlanmayacağım pis şeyler).

Daha iyi ayarlama kabiliyetine sahip olmanın iyi bir değişim olacağı açık değildir. JVM'ler çalışma zamanında optimizasyon yapabilir ve bu genellikle statik derleme ile olanlardan üstün değilse, en azından yeterince iyidir. (Açıkçası, belirli bir uygulama ve iş yükü için prensipte JIT'i statik optimizasyonlarla yenmek mümkün olmalıdır, ancak pratikte çoğu zaman kesin iş yüküne veya hatta tüm uygulamaya sahip olmazsınız.)