Хтось знає, чому Scala реалізована в Java та .NET замість C або C ++? Більшість мов реалізовані за допомогою Cor C ++ [тобто Erlang, Python, PHP, Ruby, Perl]. Які переваги для Scala реалізовані в Java та .NET, окрім надання доступу до Java та .NET бібліотек?

ОНОВЛЕННЯ

Чи не отримала би Скала більше користі, якби вона була впроваджена в C, оскільки її можна налаштувати краще, а не покладатися на JVM?

Питання заплутане, оскільки C і C ++ - це мови , тоді як JVM - це віртуальна машина, а .Net - платформа . Scala може бути реалізований в C або C ++, і він може генерувати машинний код замість байт-коду для віртуальної машини.

Відповідаючи на поставлене запитання:

Скала не була реалізована в C або C ++, оскільки Scala, мова, якою вона реально реалізована, є набагато кращою мовою.

Чому краще? Що ж, читайте про цілі Одерського для мови Scala .

Відповідаючи на запитання, яке, можливо, передбачалося:

Scala генерує головним чином байт-код JVM, оскільки це забезпечує велику портативність, а також такі функції, як надійний та ефективний збирач сміття, оптимізація часу роботи та компіляція JVM .

Повторю це останнє: JVM буде компілювати машинні коди гарячих точок у коді, який він працює. Це компіляція так, як це роблять компілятори C і C ++.

Є й інші віртуальні машини, але Одерський, творець Scala, вже був дуже знайомий з JVM. Він мав намір створити CLR в якості альтернативи, але зусилля, щоб досягти цього, поки що не досягли успіху.

Відповідаючи на питання, яке могло / слід було задати:

Компіляція до машинного коду не дає достатньо переваг порівняно з компіляцією в байт-код JVM.

Безумовно, можливо сформувати мікро-показники в C або C ++, які б'ють JVM-еквіваленти. Правда також, що надзвичайно оптимізований код на C або C ++ буде бити надзвичайно оптимізований код на Java або Scala. Однак різниця не все така велика для тривалої програми.

Зауважте, що Scala не є особливо хорошою мовою сценаріїв саме тому, що накладні витрати для короткочасних програм занадто великі.

Однак у більшості випадків швидкість розробки та простота обслуговування важливіші, ніж швидкість виконання . У тих випадках, коли люди більше стурбовані написанням коду дуже високого рівня, який легко зрозуміти та змінити, оптимізація виконання часу, що надається JVM, може легко перемогти оптимізацію часу компіляції, зроблену компіляторами C або C ++, що робить JVM (і CLR ) ціль, яка реально виконає швидше.

Отже, незалежно від того, чи був компілятор Scala машинним кодом, чи програми Scala, які є машинним кодом, потенційні збільшення швидкості не обов'язково перетворюються на реальні збільшення швидкості.

І, до речі,

Наведу вам зустрічний приклад: Haskell. Haskell генерує машинний код, і, тим не менше, програми Haskell стають гіршими на перестрілку Debian, ніж у Scala. Враховуючи це, чи може хто бути впевнений, що програми Scala були б швидшими, якщо їх скласти безпосередньо до машинного коду?

Однією з найважливіших мов, з якими стикаються, при знайомстві з усім світом є наявність бібліотеки. Традиційною відповіддю на це було надання FFI на основі C (іноземний функціональний інтерфейс), що дозволить вам отримати доступ до бібліотек на основі С. Це не ідеально з різних причин, головний з них:

• Існує багато різних способів взаємодії бібліотек, які не сумісні з багатьма мовами вищого рівня. Наприклад, якщо бібліотека хоче вказувати на a struct, як мови з відсутністю покажчиків AND іstruct s не справляються?
• Існують різкі взаємодії між моделями пам'яті різних бібліотек та мовами, які часто не підлягають вирішенню або, якщо вони вирішуються, мають велику помилку та помилки.
• Код клею для багатьох ПФІ нетривіальний і передбачає знання, які насправді можуть бути не універсальними. (Вірите чи ні, не всі програмісти - це гуру С, і ні вони не хочуть бути, ні їх вимагати!)

Це стає ще гірше за допомогою C ++. C ++ навіть не сумісний з C ++ (я маю на увазі на увазі бінарний рівень) від компілятора до компілятора на тій же платформі (!), Не кажучи вже про інші мови.

Націленість на JVM вирішує багато з цих проблем, надаючи вам доступ до абсолютно величезного набору бібліотек на базі Java. (Наскільки величезна? Просто застосуйте величезний вибір для початківців програми Apache Software Foundation .)

• Конвенції про дзвінки та власність Java більш регулярні, ніж у C.
• JVM також пропонує єдину модель пам'яті (включаючи збирання сміття) для мов і бібліотек, з якими взаємодіють. Не потрібно слідкувати за тим, кому належить що і що має прибирати де. Виконання робить це за вас.
• Код клею для FFI, для більшості мов, побудованих на JVM, не існує (як це передбачено як рамки за лаштунками мови). Не потрібно програмувати на Java, наприклад, для доступу до бібліотек Java у Scala, Clojure, JRuby тощо. Ви отримуєте доступ до об'єктів Java так само, як і до власних "об'єктів" (лякайте цитати, оскільки, наприклад, Clojure не робить мати фактичні об’єкти в сенсі ООП) та вашою рідною мовою.

Крім цих переваг, ви також маєте додаткові переваги роботи в будь-якому місці запуску Java без перекомпіляції (але з тестуванням !: пишіть один раз, тестуйте скрізь) та отримайте доступ до досить вражаючої технології Java JIT.

CLR забезпечує подібні сильні сторони, але додає, що є IMO слабкістю: це майже середовище блокування постачальника. (Так, я знаю про Mono. Я все ще думаю, що це середовище для блокування постачальників.)

Відповідно до цього інтерв'ю , основною причиною був доступ до існуючої інфраструктури Java та бібліотек.

... Java - це вже існуюча мова з дуже жорсткими обмеженнями. Як результат, я не міг зробити багато речей так, як хотів би зробити їх - так, як я був переконаний, що це правильний спосіб зробити їх. Тому після цього часу, коли по суті в центрі моєї роботи було покращення Яви, я вирішив, що настав час зробити крок назад. Я хотів почати з чистого аркуша і подивитися, чи можу я спроектувати щось краще, ніж Java. Але в той же час я знав, що не можу почати з нуля. Мені довелося підключитися до існуючої інфраструктури, бо інакше завантажувати себе з нічого просто без будь-яких бібліотек, інструментів тощо.

Тому я вирішив, що, хоч і хотів створити мову, відмінну від Java, вона завжди буде підключатися до інфраструктури Java - до JVM та її бібліотек . Така ідея була ...

Усі інші мови, які ви згадуєте, Erlang, Python, PHP, Ruby, Perl - всі вони були створені до Java & .NET. Якби творці цих мов на той час мали доступ до середовища виконання Java або .NET, можливо, вони могли б використовувати їх під час створення своєї мови.

Звичайно, я не можу говорити за розробників цих мов, тому не можу точно сказати , що вони використовували б .NET та / або Java, будуючи їх, якби вони були доступні, але мені здається, що це гарна ідея. Зрештою, проектуючи свою мову для компіляції в байт-код Java / .NET, ви отримуєте всі переваги компіляторів / оптимізаторів JIT, ваша мова автоматично працює на всіх платформах, на яких працює Java / .NET, у вас є доступ до всіх бібліотеки Java / .NET тощо.

Код С статично компілюється до нативного коду (машинного коду).

Scala статично компілюється в байт-код Java, а потім, у міру необхідності, динамічно збирається для оптимізації нативного коду. Процес:

Код Scala --- статично зібраний для ---> байтовий код JVM --- динамічно складений від JVM-Hotspot-to ---> рідний код

Загальні параметри для створення / роботи будь-якої мови:

• а) інтерпретувати вихідний код безпосередньо через двигун інтерпретатора виконання
• b) статично компілювати код до нативного коду (можливо, через проміжні етапи, наприклад, джерело -> C -> нативний)
• в) статично компілювати вихідний код для проміжного коду нижчого рівня та інтерпретувати його під час виконання
• г) статично компілювати вихідний код до проміжного коду нижчого рівня, потім використовувати початкову інтерпретацію з подальшим динамічним методом компіляції та оптимізації для перетворення в початковий код. Код інтерпретується до тих пір, поки не будуть знайдені типові шляхи виконання та вузькі місця, після чого компілюється код для найшвидшого виконання в типових умовах. Він перекомпільований / перезавантажений, коли умови виконання достатньо змінені для того, щоб це зробити

Ваше запитання: "Чому Java використовує (d) з JVM, а не (b) з проміжним кодом C?"

Відповідь:

По-перше, зауважте, що Скала - це багатомова вищого рівня, ніж C, що дає програмування, простоту програмування та стислість. Це приблизно на 1 рівень вище, ніж Java завдяки функціям першого класу та вищого порядку, неявних функцій, функцій як об'єктів, закриттю і currying, підтримці компіляції хвостових рекурсій для швидких циклів збереження стека, все як об'єкти, всі оператори як методи що може бути (повторно) визначено в бібліотеках, класах випадків та скорочення (відповідність шаблону), неявне виведення типів, сильніший поліморфізм через розширені багатонаступні риси та розширені дженерики, вбудований синтаксис для пар & кортежів і мінусів (списки та дерева) ) & карти, підтримка незмінних структур даних, підтримка потужних "реактивних" паралельних і одночасних обчислень з копіюванням повідомлень та передачею між учасниками, вдосконалена підтримка довільних DSL-файлів, доступних для домену, написання та REPL Ява приблизно на "1 рівень вище", ніж на C, завдяки орієнтації на об'єкти, керування вказівниками та збирання сміття, підтримка рядків, підтримка в декількох нитках та контроль одночасності, а також стандартні бібліотеки API.

1. Продуктивність: Для мови високого рівня (d) дає швидші показники, ніж (a) - (c).
   Код C, безпосередньо написаний та оптимізований рукою, швидко. Однак мови вищого рівня, які статично складаються на C, відносно повільні. Дизайнери java це добре знали. Їх нинішній дизайн «Точки доступу» підвищує продуктивність на порядок. Що стосується одного ядра, код Java HotSpot в середньому становить «50% швидше», ніж оптимізований людиною C (в кращому випадку це «120% як швидко», в гіршому - «30% так швидко»). Але звичайно це порівняння яблук з апельсинами - код низького рівня v код високого рівня. І це було б багатогірше, якщо оптимізація точки доступу не використовувалася. Для підтвердження просто відключіть компіляцію точки доступу через аргументи JVM! Або подумайте про ефективність Java 1 і 2, коли гаряча точка не існувала або була незрілою. Або спробуйте скласти іншу мову через C - наприклад, perlcc. Тому вищезазначені чудові результати для потужної та продуктивної мови. З подальшим розвитком можливо (або навіть ймовірно), що незабаром JVM може в середньому випереджати C, кодований рукою. Scala у середньому лише на 70-80% повільніше, ніж java. Але масштаб сильно масштабується через декілька ядер (з подальшими вдосконаленнями, які тривають), тоді як java частково працює, а C - ні. Ефективність Single Core для таких мов високого рівня оцінюється:

   інтерпретується <статично складений <динамічно складений

   Багатоядерна продуктивність / масштабованість оцінюється:

   інтерпретований динамічний код <статично складений імперативний код <статично складений функціональний / декларативний код <динамічно складений функціональний / декларативний код

   Це ставить Scala на виграшне місце, оскільки швидкість процесора досягла його межі, і тепер кількість ядер збільшується за законом Мура. Scala дуже швидко працює на декількох ядрах і в майбутньому може стати в кілька разів швидшим, ніж C або java. Статично компілювати на C явно не найшвидший варіант.

2. Інтероперабельність: мови на широкій підтримці VM мають кращу взаємодію з мовою, ніж "ізольовані" мови. Scala "автоматично грає з" java-класами, інтерфейсами та об'єктами, просто імпортуючи їх та використовуючи їх так, як ніби вони були класами, ознаками та об'єктами Scala. Подібне можливо з іншими мовами JVM, такими як Groovy, Clojure, JRuby та JPython - з легкістю інтероперабельності залежно від того, наскільки чисто кожна мова була зроблена для компіляції до зрозумілих та зручних класів / інтерфейсів / об’єктів Java. Це багато чого припадає на "безкоштовно" (як у "близькому до"). Scala співпрацює з C через JNA, спадкоємця JNI, - що докладає певних зусиль, але інструменти з часом були досить впорядковані. JNA може насправді взаємодіяти зі складеним нативним кодом з будь-якої довільної мови - але ви повинні знати точну структуру компільованих типів даних та функцій. Якщо ні,

3. Переносність: JVM працює на десятках платформ / версій операційної системи "поза коробкою". Scala автоматично переноситься на них. Визначений виняток - iOS (iPad / iPhone / iPod) - блокується "комерційно", а не "технічно" від Apple. Цього не можна було передбачити 12 років раніше, під час первинного проекту JVM. JVM працює чудово на десятках інших серверів, настільних комп’ютерів, мобільних пристроїв та вбудованих пристроїв, включаючи ті, що не підтримують C - включаючи Android з адаптованою Dalvik VM Android з Google (50% + проданих нових телефонів). Звичайно, код C працює на безлічі платформ, тому його можна оцінювати «там, де є, або, можливо, поза» Java (зокрема, C - це підмножина Objective-C). Але C прийшов би ціною (1), (2) & (3). Звичайно, презентаційний шар HTML5 / javascript / webkit (або об’єктивний-C) в iOS може взаємодіяти з віддаленим додатком scala - тому розробники повинні дуже сильно це робити. Звичайно, вони будуть менш продуктивними.

4. Інструменти та бібліотеки : Очевидно, є тисячі комерційних і відкритих джерел Java-бібліотек та інструментів, за допомогою яких Scala може використовувати / використовувати їх більше - ніж на C.

5. Безпека: - робота на керованому сервері додатків або середовищі JVM надає більш сильну підтримку політики та обмежень безпеки, що може бути дуже цінним у корпоративному середовищі.

JVM / CLR

JVM (і CLR) надають унікальні переваги з точки зору оптимізації та мобільності коду.

Наскільки мені відомо, актуальною залишається лише версія JVM Scala, версія .NET - ні.

Схоже, ви змішуєте дві незв’язані речі.

По-перше, яка мова програмування використовується авторами Scala для впровадження Scala?

На що відповідь, сама Скала. І це єдино прийнятна відповідь, адже якщо ви придумали цю нову мову, але не використовуєте її самостійно для її впровадження - для чого це корисно?

Друге, що це цільова платформа для запуску програм, написаних у Scala?

Тут вибір стає цікавішим, але поки що єдиною ціллю, яка працює на 100%, є JVM. Підтримка .NET все ще працює. Також деякі люди працюють над тим, щоб змусити Scala компілювати до javacsript. Теоретично, ніщо не заважає комусь додати більше "програмних засобів" для компіляції в C, C ++, LLVM, нативний код чи інше.

Чому JVM був обраний основним майданчиком? Я здогадуюсь тому

• всі хочуть збирання сміття
• велика кількість хороших бібліотек, готових до використання
• велика кількість програмістів, які нудьгують з Java, готові перейти до чогось нового, але залишатися поза межами JVM (ніхто не хоче перенести свій існуючий код на іншу платформу)

Перш за все - те, що я думаю, ви насправді хотіли запитати, чому Scala не є чітко складеною мовою. Я скажу вам, що не знаю. Але я вам також скажу, що немає причин віддавати перевагу JVM над власним кодом.

Чому? Причина проста: будь-яка технологія віртуалізації голодна по пам'яті, створює зайві накладні витрати та ще один шар непрямості. Це не питання їх реалізації - це питання фактично логіки, яка лежить в основі основної концепції віртуалізації. Незалежно від того, що ви робите, ВИНАГО вийдете з нижчими характеристиками. Особливо JVM голодний пам'яті. Це вже не так повільно, тому що у нього є власний компілятор виконання, який працює за спиною, але все ж - він повинен запустити процес компілятора, щоб мати можливість виявити найбільш перевантажені частини коду та перетворити їх у двійковий код.

Сказав, що - єдиною причиною, на яку я думаю, була можливість створення Scala на базі JVM, - це, мабуть, популярність мови. Я також здогадуюсь, що за цим рішенням лежала якась лінь, тому що простіше реалізувати мову через JVM, ніж зрозуміти, як повинні виглядати речі, зібрані для роботи на крос-платформі - і навіть використання існуючих програм C вимагає набагато більше роботи через те, що що все не так добре стандартизовано, як у JVM.

Це є причиною, про яку я можу подумати, але майте на увазі, що можуть бути й інші причини - як, наприклад, видача ліцензій та політика, пов’язана з цим (які є брудними речами, у які я ніколи не хотів би потрапляти).

Незрозуміло, що можливість покращити налаштування було б гарним компромісом. JVM можуть робити оптимізацію під час виконання, і це, як правило, досить добре, якщо не перевершує те, що зазвичай відбувається при статичній компіляції. (Очевидно, що в принципі для конкретного додатка та навантаження потрібно мати можливість перемогти JIT статичними оптимізаціями, але практично у вас часто немає точного навантаження чи навіть усього додатка.)