Почему концепция байт-кода уже не столь актуальна, как была прежде


    Введение


    Компилируемые языки интерпретируемого типа — это те языки программирования, которые компилируются в некое промежуточное представление (иногда именуемым "байт-кодом"). Самый яркий пример — это JVM (виртуальная машина Java).


    В данной статье изложены мои мысли насчёт концепции виртуальной машины для языков программирования в нынешних реалиях. В реалиях, где большинство сервисов работают в Интернете, а настольные программы постепенно снимаются с производства.


    Причины возникновения


    Во времена зарождения Всемирной паутины появилась технология Java, впервые популяризовавшая использование виртуальной машины в качестве исполняющей среды для языков программирования высокого уровня.


    Sun Microsystems попытались соединить надёжность и высокую скорость работы компилируемых языков с переносимостью и лёгкостью использования интерпретируемых. В определённой степени задуманная идея осуществилась, ведь Java всё же стал наиболее распространённой технологией в построении высоконагруженных серверов.


    Кроме всего прочего, было выдвинуто одно из главных требований платформы, позже ставшее слоганом — "Скомпилируй однажды, запускай везде!". Это означало, что программисту следовало лишь раз скомпилировать исходный код в так называемый байт-код, способный быть запущенным на любой системе, где установлена JVM.


    Это и стало движущей силой технологии, откинув многие языки на задний план. Это было своего рода революцией в мире цифровых вычислений, ведь раньше никому не удавалось достичь подобного уровня кроссплатформенности. Теперь пользователи могли скачивать одну и ту же версию программы на множество операционных систем и архитектур процессоров, и быть уверенными что она непременно будет работать именно так, как это задумывалось разработчиками.


    Но времена меняются, и технологии вместе с ними. Всемирная паутина набирает всё большую популярность, вытесняя некоторые привычные для нас вещи.


    Эпоха удалённых сервисов


    "Зачем поставлять программы пользователям, если можно просто сделать сайт?" — этим вопросом задались крупные предприниматели, что позже вылилось в масштабную эмиграцию услуг во Всемирную сеть. Стандартные настольные программы начали утрачивать свою популярность, ведь намного проще и эффективнее сделать простенький (или не очень) веб-сайт.


    Следовательно, отпала и необходимость так часто скачивать программы с Интернета. Открыть сайт и осуществить необходимые действия намного быстрее, чем скачивать мегабайты бинарных данных.


    А тем временем Java обрела популярность в построении тех самых сайтов, ведь ничего удобнее на тот момент (и по сей день) не существовало. Исходные файлы стали компилироваться лишь под конкретную архитектуру сервера, следовательно, принцип "Скомпилируй однажды, запускай везде!" перестал иметь былое значение. Пользователи перестали скачивать программы, а разработчики стали компилировать лишь под конкретную архитектуру.


    Эволюция языков


    Раньше компилируемые языки программирования обладали довольно скудной функциональностью стандартной библиотеки, из-за чего приходилось использовать массу платформенно-зависимых функций даже для простого приложения, не делающего ничего сверхъестественного.


    Языки программирования тоже не стояли на месте, и на свет вышли такие языки, как Rust и Golang, оба компилируемых, и оба обладают стандартной и множествами сторонних библиотек, предоставляющих независимый от архитектуры и операционной системы функционал. Кроме того, экосистема C/C++ тоже не стояла на месте.


    В итоге оказалось, что современные стандартные библиотеки и виртуальные машины выполняют одну и ту же роль — транслируют кроссплатформенный код в платформо-зависимые функции.


    Оставшаяся часть


    Кто-то может возразить, что спрос на настольные программы всё ещё есть. В основном это закрытые программы, предназначающиеся для внутреннего использования в корпорациях, а также то небольшое количество общедоступных приложений.


    В обоих случаях компиляция под сотню разных платформ не имеет смысла, так как в подавляющем большинстве случаев применяются лишь три всем известные операционные системы (GNU/Linux, Microsoft Windows и Mac OS) и одно семейство архитектур процессоров (x86).


    Заключение


    Итого мы имеем замедляющие работу виртуальные машины (в качестве сред исполнения байт-кода), утратившие свои основные преимущества вследствие двух вышеизложенных факторов:


    1. Необходимость запуска программы на сотне разных архитектур не имеет смысла, так как большинство программ работают на серверах, а пользовательских архитектур и операционных систем не так уж и много.
    2. Компилируемые языки не стояли на месте, и их стандартные библиотеки приобрели необходимый базовый функционал для кроссплатформенного кода.

    Обсуждения в комментариях приветствуются, надеюсь, что статья натолкнула вас на некоторые мысли по поводу выбора подходящего языка для ваших задач.


    Дополнения


    Как отметили в комментариях, управляемый код имеет некоторые преимущества, недоступные компилируемому коду, в том числе рефлексия и аннотации.

    Поддержать автора
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 65

    • НЛО прилетело и опубликовало эту надпись здесь
        –7

        Андроид, работающий на разных архитектурах, программирование встраиваемых систем, конечно, имеют место быть, но их решает пункт 2:


        Компилируемые языки не стояли на месте, и их стандартные библиотеки приобрели необходимый базовый функционал для кроссплатформенного кода.

        Реализации стандартных библиотек можно писать под различающиеся платформы так же, как и виртуальные машины, просто исключается жирный рантайм. Примером могут послужить стандарты C/C++.

          +7
          Андроид, работающий на разных архитектурах, программирование встраиваемых систем, конечно, имеют место быть, но их решает пункт 2:

          Вопрос был не в том, кто что решает. Один из посылов вашей статьи — «все разнообразие на практике свелось к трем ОС и одной архитектуре x86». Вам вполне логично указывают на андроид — наиболее распространенную ОС для смартфонов на данный момент. Если вы не в курсе, разработка на андроид ведется на языке java (или kotlin — он тоже на jvm), а наиболее распространенный процессор в андроидофонах — ARM.
          Все это несколько опровергает ваши предпосылки, из которых вы делаете в статье далеко идущие выводы.
        +3
        Вопрос интересный, но, имхо, не раскрыт. Как быть с примочками, которые дает управляемый код? Та же безопасность доступа к памяти.
          –1

          Безопасность доступа к памяти может быть достигнута синтакистом (Rust, Golang как пример). Какие ещё примочки даёт управляемый код?

            +2
            reflections, annotations на вскидку
              0

              Добавил в секцию "Дополнения".

                +1

                Кмк, это не особенности управляемого кода, ибо такое же реализуют испокон веков на С++.
                Да и на "голом" Си, как пример, можно писать ООП код. Я к чему — эти фичи — вопрос сложности написания конкретного функционала, а не типа языка. Но лучше, конечно, когда они в стандарте — не нужно пилить свои велосипеды

                  +1
                  К слову, в Swift есть вполне полноценная интроспекция, хоть он и компилируется в бинарник. Java тоже может компилироваться в бинарник с помощью GraalVM и вся её рефлексия, при этом, доступна
              • НЛО прилетело и опубликовало эту надпись здесь
                  0

                  Когда в C++ придут метаклассы (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0707r3.pdf), рефлексия станет очень даже неплохой.


                  Аннотации — это почти аттрибуты: https://en.cppreference.com/w/cpp/language/attributes.
                  И особенно контракты: https://en.cppreference.com/w/cpp/language/attributes/contract

                    0
                    В том же Go она есть
                +3
                А в чем проблема? JIT никуда не делся, JVM часто используемые куски байт-кода компилирует уже в нативный код на лету.

                Как по мне — вполне себе разумная модель, когда у тебя парсинг кода и компиляция в нативный код разделена на две части. И вторая происходит уже на целевой платформе. И более того, без участия человека, по необходимости.
                  +2

                  Немного дополню. JIT компиляция может быть эффективнее, чем AOT за счёт спекулятивных оптимизаций. Оптимизируем код под те сценарии, которые действительно происходят, если сценарии меняются — откатываемся и оптимизируется по-другому. Для серверов как раз актуально

                    +1
                    1. Почему тогда вообще не перейти на дистрибуцию полностью в исходных кодах? Боязнь того, что конечный пользователь увидит код? Ну, тот же джаваскрипт обфусцируют, если уж на то пошло, а байт-код сам по себе от декомпиляции и реверса не спасает. Раньше — да, у JIT было преимущество (и уменьшение размера бинарника относительно сырцов, и перенос на большей вычислительной нагрузки по сборке кодов с машины потребителя на специальную сборочную ферму у разработчика).
                    2. Все эти спекулятивные истории могут работать, а могут не работать. До сих пор есть паттерны, которые без оптимизации работают лучше, чем с "не угадали ветку выполнения" и неудачно оптимизировали. К тому же, мы все помним про уязвимости процессоров Интел/АМД — а все из-за реализации спекулятивности. Уверен, что ПО тоже может быть подвержено аналогичным атакам, но они более трудноосуществимы, т.к. целью будет конкретная связка версия ОС — версия виртуальной машины языка
                      0
                      1. Дистрибуция исходников не даст никакой дополнительной информации компилятору в сравнении с байт-кодом. К тому же, в них много лишней информации и их нужно дополнительно предобрабатывать. С байт-кодом проще в инкрементальность потому что добавление комментария не изменит его. Плюс проще с обратной совместимостью. Можно скомпилировать новый код — в старый байт-код. Это проще, чем новый Джаваскрипт — в старый.


                      2. То же самое можно сказать про AOT оптимизации. Только JIT можно откатить, а AOT — нет


                        0
                        Раньше — да, у JIT было преимущество (и уменьшение размера бинарника относительно сырцов, и перенос на большей вычислительной нагрузки по сборке кодов с машины потребителя на специальную сборочную ферму у разработчика).
                        Ну это всё как бы никуда и не делось. Да, машины у потребителей стали мощнее, но и размер исходников вырос, а оптимизации в компиляторе стали сильно умнее и соответственно прожорливее.
                        Не говоря уже о том, что вы никогда не сможете гарантировать, что исходники соберутся одинаково на разных машинах.
                          0
                          Есть же примеры дистрибуции в исходных кодах. Та же фря или гента. Помимо всего прочего добавляется целый пласт проблем у клиента, которые обобщенно можно назвать «не собралось».
                          –1

                          Может быть, но в реальности разработчики работают не хуже JIT, используя профайлеры и другие инструменты для локализации горячих точек. Кроме того, они используют неявные предположения о входных данных, чего JIT делать не может — да, у него есть профиль исполнения, однако он не может строить утвеждения о свойствах программ на его основе.


                          Кроме того, времени у JITа не очень много, он не может себе позволить делать слишком сложный внализ, так что разработчики JIT находятся в сущности между молотом и наковальней и вынуждены искать компромиссы.

                            0

                            Согласен. Я из мира JVM и с полностью компилируемыми языками знаком мало. У разработчиков есть какой-то способ дать компилятору инструкции чтобы он оптимизировал код определённым образом? Не портя при этом сам исходный код. Не хочется жертвовать поддерживаемостью. Да и любую "ручную" оптимизацию в исходном коде компилятор может "сломать", например, при обновлении его версии

                              0

                              Что значит " не портя "? Не внося изменений в исходный код — т.е.? Думаю, что вряд ли. В любом случае нужно будет как минимум хинты для компилятора расставить (я в широком смысле — туда же пойдут всякие #pragma). С другой стороны, компиляторы вроде компилятора С++ стали слишком умны. Но ценой того, что время компиляции большого проекта стремится в бесконечность, а при этом cpu/mem в полку (почитайте про боль разработчиков Chrome)

                                –1
                                Почитал про pragma. Довольно удобно выглядит.

                                А время компиляции — боль даже в JVM. Классно сделали в Dart. Он может и полностью интерпретироваться, безо всякой компиляции вообще, и в AOT тоже может. Это представляют как killer-feature. Что можно мгновенно применять изменения. Надеюсь, другие тоже подтянутся. Hot-reload для Kotlin/Swift без танцев с бубном. Или даже интерпретация С++ в дебаге по-умолчанию, как вам? =)
                                  0

                                  Repl добавили в Java 9 — enjoy

                              0
                              Кроме того, времени у JITа не очень много, он не может себе позволить делать слишком сложный внализ, так что разработчики JIT находятся в сущности между молотом и наковальней и вынуждены искать компромиссы.

                              Не совсем так, если верить, например, этой статье
                              Цитата из статьи
                              Google Engineers have come with a brilliant idea to combine the best: Interpreter, JIT, and AOT:

                              1. There is no any .oat binary in the beginning. When you run an app for the first time, ART executes the code using the Interpreter.

                              2. When HOT Code is detected, it’s compiled using the JIT Compiler.

                              3. The JIT-compiled code + the compilation profile are stored in the cache. Every future run will use this cache.

                              4. Once the device is idle (the screen is turned off or charging), the hot code is recompiled using the AOT compiler and the compilation profile.

                              5. When you run the app, the code in the .oat binary is executed at once with better performance. If there is no code in the .oatbinary, go to step 1.

                              And here comes even bigger optimization — Why not share compilation profiles between similar devices? Done.

                              When a device is idle and connected to a Wi-Fi network, it shares the compilation profile files via Google Play Services. Later, when another user with the same device downloads the app from the Play Store, the device receives these Profiles for AOT to perform the guided compilation. As a result — users get an optimized app from the first use.
                              0
                              IT компиляция может быть эффективнее, чем AOT за счёт спекулятивных оптимизаций

                              в теории может быть. На практике в подавляющем большинстве случаев JIT всё еще не эффективнее. А там, где оптимизация под конкретный профиль дает столь огромный бонус к быстродействию, можно использовать profile-guided optimization. В реальности самый главный ресурс, который экономит JIT — время разработчика.
                            0

                            Посыл интересный, но как насчет самого процесса написания программ? Например, либы appache commons могут компилироваться на ubuntu, tomcat — под windows, hibernate под MacOs, a запускаться все под mint. Я к тому, что принцип 'Скомпилируй однажды, запускай везде!' еще далеко не умер

                              0
                              'Скомпилируй однажды, запускай везде!' еще далеко не умер

                              На этот принцип давит идеалогия CI/CD, когда цепочка хорошо автоматизирована нет большой разницы собирать ли под одну платформу или под две. Собственно, насколько я понимаю в мире игрушек на мобилки именно так.


                              Другой вопрос, что все же не все так радужно с библиотеками и всегда найдется что-нибудь странное и не совместимое.

                              +1

                              А что, про llvm (кажется, наиболее популярная на сегодня "основа" для компиляторов) вы не слышали?
                              Так что байт-код вполне себе жив. А вот от реально действующей виртуальной машины ушли, да. Байткод приятней скомпилировать в нативный.

                                +1

                                Ну, это уже не совсем тот байткод.
                                Он не кроссплатформенный.
                                Он не обратно-совместимый.
                                Он не эффективен с т.з. интерпретации (так как неограниченное число регистров, причем большее, чем переменных в исходной программе.)

                                +2

                                Пять копеек.


                                1. Самые две доминирующие платформы — x86-64, ARM. Почему забыли про последний? Причем у него есть 100500 не совсем полностью совместимых вариантов.
                                2. Действительно, основные операционными система являются Windows и Linux. Но с тем же Линукс можно весело отхватить. Например, в дистрибутиве Alpine библиотека libc заменена на musl, что приводит к неработоспособности части программ, а часть нужно специальным образом перекомпилировать.
                                3. Про мегабайты бинарей — сильно сказано. Но любой мало-мальски серьезный сайт в пересчёте на пользователя тратит трафика в разы больше. Пример. Какое-нибудь стенделоун приложение необходимо обновлять, когда выходят обновления. Либо самого ядра ПО, либо его данных. Типичный пример часто обновляемого ПО — антивирус. Но даже в его случае объем трафика будет сотни МБ в неделю. Скачал — пользуйся. А вот с сайтом — постоянно в фоне будет подгружаться реклама, медиа-контент. Запросто могут быть тяжёлые запросы (на килобайты!) между браузером и сервером. Я уж не говорю, что в джава скрипте могут и майнер запустить.
                                  0
                                  "В обоих случаях компиляция под сотню разных платформ не имеет смысла, так как в подавляющем большинстве случаев применяются лишь три всем известные операционные системы (GNU/Linux, Microsoft Windows и Mac OS ) и одно семейство архитектур процессоров (x86)."

                                  К одному измерению добавить Android и iOS, а к другому — x64, ARM, ARMx64, MIPS и популярные в будущем RISC V, и получим 5 * 6 = 30 платформ, а не 3 как вы посчитали. В свете этого виртуальные машины, LLVM или другие подобные технологии очень даже имеют смысл.

                                    0

                                    А где я противоречу (зачем-то отвечаете на мое сообщение), хотя я говорю про то же самое ?!

                                      0

                                      Ой, промахнулся, надо было в корень.
                                      Прочитал ваш ответ — да, я дублирую ваше утверждение, только ещё добавив RISC V.


                                      Удалить уже не получится, считайте, что то сообщение начинается словами: "Дополню ваш ответ ещё такой арифметикой: ..." :-)

                                      0
                                      Странно добавлять x64 к x86, потому что 32-битных x86-систем я уже давно не видел.
                                        0

                                        Вообще-то у коллег все еще есть ( у кого оборудование 6-летней давности ).
                                        Ну, и Вы недооцениваете масштабы бизнеса — он не будет просто так обновлять железо, которое работает в регионах, например.

                                    0
                                    Стандартные настольные программы начали утрачивать свою популярность, ведь намного проще и эффективнее сделать простенький (или не очень) веб-сайт.
                                    Дальше не читал.
                                      +2

                                      На самом деле в этой фразе есть очень существенная доля правды. 90% приложений на телефоне не автономы, а представляют собой по сути либо браузер, отправляющий запрос на центральный сервер, либо попросту не могут работать без интернета (начиная от игр серии Angry Birds и кончая всякими календарями красных дней)

                                        +1
                                        Ну так 90% приложений на телефоне (подчеркнём, только на телефоне) предназначены для работы с интернетом, или имеют искусственную привязку к нему, как те же Angry Birds. Что не отменяет того факта, что они по-прежнему представляют из себя код, выполняющийся на пользовательском устройстве. (достаточно на размеры всяческих скайпов и вацапов посмотреть)

                                        И да, мой комментарий относится в том числе к утверждению «проще и эффективнее».
                                        +1
                                        Стандартные настольные программы начали утрачивать свою популярность, ведь намного проще и эффективнее сделать простенький (или не очень) веб-сайт.
                                        Т.е. ОС с кучей инструментов от калькулятора и браузера до дисковых утилит больше не нужна? :) А как быть с такими популярными, но небесплатными программами как Фотошоп, 3D и видео редакторы? А всевозможные расчетные программы? Дайте студентам волю — так они все суперкомпы (если такие будут в бесплатном сетевом доступе) своими курсовыми, нпр., по квантовой химии выше потолка загрузят. И т.д. И это только вершина айсберга. (А еще есть майнинг — м.б. и его сделать сетевым и бесплатно для этого мощности выделить? ;))
                                        +5

                                        Очень интересно, что в лагере писателей сайтов тоже решили пойти по пути создания виртуальной машины с байт-кодом: WebAssembly. Так что не думаю, что концепция хоть сколько устарела.

                                          0

                                          Интересно что ГО оказывается местами медленнее джавы. Расходимся

                                            0

                                            ну, вряд ли можно сравнивать бенчмарк "давайте в тупом цикле напечатаем строчку 100000 раз" на любимом языке программирования. Вы сделали достаточно громкое заявление. Поэтому прошу его подтвердить ссылками на тесты.

                                                0

                                                Спасибо, но это именно иллюстрация "давайте в тупом цикле напечатаем строчку 100000 раз" только на другой лад.

                                                  0
                                                  Вот есть бенчмарк с рейтрейсингом на CPU. github.com/Mark-Kovalyov/CardRaytracerBenchmark.
                                                    0

                                                    Да, действительно Go медленнее Java. Теперь остается понять почему так получается....

                                                    0

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


                                                    По ссылке вполне себе задачи из жизни: сетевое взаимодействие, запросы к БД, сериализация. Тестов там тоже больше одного, запускают как в облаке, так и на одном компе. Ниже есть ссылка и на числодробилки.
                                                    И во всех случаях го почему-то не быстрее джавы.

                                                      0

                                                      Я предполагал, что дискуссия зайдет в это русло, поэтому хотелось бы сбавить градус напряженности анекдотом:


                                                      Инженер, физик и математик едут на поезде через Шотландию. Вдруг они замечают чёрную овцу, пасущуюся на поле.
                                                      "Ага!" – восклицает инженер – "Шотландские овцы чёрные!"
                                                      "Хм…" – говорит физик – "Я бы сказал, что некоторые из шотландских овец чёрные"
                                                      "Нет" – возражает математик – "Всё, что мы знаем – это то, что в Шотландии есть как минимум одна овца и как минимум одна сторона этой овцы чёрная"

                                                      А если серьезно, то пока действительно получается, что голанг не быстрее джавы. Возможно, что существуют кейсы, когда они на равных по скорости. Или есть какие-то другие критерии, почему голанг так популярен (скажите еще, что его неосиляторы джавы любят, да и вообще он продукт принципа NIH в переложении Гугла).

                                                        0

                                                        Очевидно потому что не надо тащить за собой виртуальную машину. Хотя есть инструменты которые компилируют джаву сразу в нативный код. Но там свои подвохи

                                              +1

                                              Потому что реализовать общий интерфейс уровня байткода проще, чем каждый компилировать в каждый. Пример c language server в тему:


                                              image


                                              Вместо IDE только если выбирать x86/ARM/MIPS/...

                                                0
                                                ведь Java всё же стал наиболее распространённой технологией в построении высоконагруженных серверов.

                                                а плюсовики обычно говорят что в высоконагруженных серверах царят плюсы. И кому верить?
                                                  +1
                                                  никому не верьте (с)

                                                  ИМХО разница в восприятии, что такое «высоконагруженный»:
                                                  там где сервер хоть немного нагруженный, то энтерпрайз считает это «высоконагруженным сервером» и переходят с ноды\руби\питона\перла\проч на джаву, тем более, что в больших организациях на это все есть и девы и серверы.
                                                  А в тех нечастых случаях, когда это действительно что-то сверхвысоконагруженное — то тогда на плюсы (и не только, но все равно близкое к железу).
                                                  +3
                                                  Во-первых, вы обошли вниманием, что сервера тоже имеют разную архитектуру и разные операционные системы. Мой код, написанный и скомпилированный в 2003-м году, сначала работал на сервере с 32-битными процессорами Xeon Prestonia и FreeBSD на борту, потом переехал на Fujitsu PRIMEPOWER с Solaris, сейчас крутится на IBM'овских блэйдах c AIX'ом, не удивлюсь, если через некоторое время перенесут на что-нибудь с ARM'ами и под Linux или HP-UX.

                                                  Во-вторых, как уже заметили в комментариях, на много проще портировать на новую платформу виртуальную машину или компилятор байткода, чем каждое отдельное приложение.
                                                  image
                                                  image
                                                    +4
                                                    Как-то уж очень, скажем так, поверхностно… к сожалению. Начиная с того, что автор, судя по всему, слабо себе представляет что-такое RTS/RTE, «откуда есть пошла» концепция p-code/byte-code, и когда и зачем таки появились VM для этих вещей :-)

                                                    … это те языки программирования, которые компилируются в некое промежуточное представление (иногда именуемым «байт-кодом»).
                                                    А ничего, что, под это определение, — формально — попадают вообще все *компилируемые* языки? Годов, эдак так, с 70х прошлого века :-) Или когда там Вирт представил свой концепт кросс-платформенной *компиляции*? И это если не принимать во внимание еще более ранние работы Ричардса — которые вообще, емнип, 60ые. Тем не менее, именно из этих вещей, в конце концов появился, например, какой-нибудь C. Который, внезапно, таки тоже «компилируются в некое промежуточное представление» :-)

                                                    В данной статье изложены мои мысли насчёт концепции виртуальной машины для языков программирования в нынешних реалиях.
                                                    К сожалению, ничего «такого», в данной статье, нет :-( Есть некоторый набор рассуждений, который, имхо, ещё как-то можно свести к полемике типа «AOT vs JIT компиляция»… но уж точно не к «концепции байт-кода», и не к «концепции виртуальной машины для языков программирования».

                                                    Во времена зарождения Всемирной паутины появилась технология Java, впервые популяризовавшая использование виртуальной машины в качестве исполняющей среды для языков программирования высокого уровня.
                                                    Это, мягко говоря, не так. Даже если отбросить, какой-нибудь, Форт, то все равно останутся, например, LISP системы, SmallTalk'и с Oberon'ами, да и хоть тот же Erlang :-)

                                                    В итоге оказалось, что современные стандартные библиотеки и виртуальные машины выполняют одну и ту же роль — транслируют кроссплатформенный код в платформо-зависимые функции.
                                                    Да не выполняют они «одну и ту же роль». «Задача» по «трансляции кода» — это именно что «JIT vs AOT»… и только.

                                                    … так как в подавляющем большинстве случаев применяются лишь три всем известные операционные системы (GNU/Linux, Microsoft Windows и Mac OS) и одно семейство архитектур процессоров (x86).
                                                    Ну знаете… лучше бы «во первых строках» так и написать, что речь исключительно о «бытовом» уровне :-)

                                                    Итого мы имеем замедляющие работу виртуальные машины (в качестве сред исполнения байт-кода)…
                                                    Если речь исключительно о *компилируемых* языках, то их VM это не среды для «исполнения байт-кода». Что бы вы под этим не понимали, но именно *исполнением* «байт-кода» они не занимаются.

                                                    .., утратившие свои основные преимущества вследствие двух вышеизложенных факторов:
                                                    1. Необходимость запуска программы на сотне разных архитектур не имеет смысла, так как большинство программ работают на серверах, а пользовательских архитектур и операционных систем не так уж и много.
                                                    2. Компилируемые языки не стояли на месте, и их стандартные библиотеки приобрели необходимый базовый функционал для кроссплатформенного кода.
                                                    Уж коли мы говорим исключительно о «бытовом» уровне, то с п.1 еще можно как-то согласится. Но причем тут «компилируемые языки», их «стандартные библиотеки», я так, к сожалению, и не понял :-( Концепции кросс-платформенной компиляции (и соответствующим компиляторам) уже скоро «полтинник» стукнет… если уже нет.
                                                      0

                                                      Что такое настольная программа?

                                                        0
                                                        буквально «desktop application». Перевод от Гоголь Транслит 9000
                                                          0

                                                          а в чем принципиальное отличие десктопных приложение от других, кстати, что входит в недесктопные приложения

                                                            0
                                                            я думаю, под «десктопными приложениями» как правило подразумеваются приложения под Windows/Linux/MacOS (x86/x64) с GUI, заточенным под клавиатуру/мышь.
                                                              0

                                                              Во-первых мобильные приложения используют виртуальную клавиатуру, а приложения под Windows и другие ОС работают и на тачскринах.
                                                              У меня вопрос был — в чем десктопные приложения принципиально отличются от недесктопных?
                                                              И почему молчит автор — его задача объяснять непонятности в тексте

                                                        0
                                                        Кто будет переписывать заново существующие фреймворки и софт?
                                                        И что конечным бизнес-пользователям даст какой-нибудь Hadoop на Go?
                                                        Кроме опасений, что всё сломается и непонятно как чинить?
                                                          +1

                                                          Как субъективное мнение одного человека — сойдет. Как объективная информация — статья мало полезна, на мой взгляд.
                                                          Виртуальная машина — это часть среды исполнения, а не компиляции. Компилятор просто преобразует исходный код программы во что-то еще. И это может быть, например, исходный код на другом языке.
                                                          Виртуальная машина, как среда исполнения специализированного байт-кода, не важно, будь это java, python, lua, или что — то еще — это только один из вариантов запуска написанной программы. Понятно и почему он появился — это компромисс между гибкостью скриптового языка и скоростью откомпилированной программы.
                                                          На счет того, что лучше — создать сайт или написать программу, это холиварная тема, и я ее затрагивать не хочу. Только напомню: без ОС и браузера все ваши замечательные сервисы так и останутся невостребованными, так что, как минимум, авторы этих двух категорий ПО могут спать спокойно (еще, я за поддержку оффлайн режима в навигаторах, черт с ним, пробки пусть подтягивает из сети).

                                                            +1

                                                            Принцип JVM "скомпилировано (написано) раз — работает везде" куда глубже, чем представлено в статье. Тут акцент не на компилции, а на работе.


                                                            Т.е. смысл JVM что поведение программы никак не зависит от физической платформы, но при этом программа, в отличии от всяких бейсиков, работает с почти "низкоуровневой скоростью". И именно для этого она создавалась (во времена раннего веба) и в этом её сила.


                                                            На практике это не всегда так — но это уже нарушение этого принципа (понятно что идеалов в природе не существует). К тому же сейчас подтянулись конкуренты с тем же принципом — JavaScript, Python, так что Java потихоньку (или не потихоньку) сдаёт позиции. Но сам принцип жив, востребован и развивается.


                                                            Компилируемые под платформу языки тоже востребованы (на чём JVM или NodeJS писать?). Всем своя ниша.
                                                            Причём десктоп-то как раз процентов на 80% (из-за богомерзкого "Электрона" процент падает) написан именно на них, а "вебизация" приложений требует как раз кроссплатформеных технологий.

                                                              –1
                                                              Т.е. смысл JVM что поведение программы никак не зависит от физической платформы

                                                              Так не бывает. Всегда есть фактор окружения. Например, файловая система, которая в одном случае позволяет case sensitive, а в другом нет. Можно говорить о какой-то степени похожести поведения.
                                                              Или физическая платформа подразумевается не ОС+аппаратная часть, а именно процессор-архитектура? Ну, тогда ок. Но все равно есть моменты, когда абстракции протекают (например, быстродействие в типах данных, которые для платформы не нативны).

                                                                +1
                                                                Так не бывает. Всегда есть фактор окружения. Например, файловая система, которая в одном случае позволяет case sensitive, а в другом нет.

                                                                Именно поэтому все имена пактов должны быть в нижнем регистре (жаль это не проверяется на уровне компилятора по умолчанию). Согласен идеала не бывает. Достаточно сложный проект на Java частенько дорастает до нативных библиотек.
                                                                Но цель, принцип, именно в том, чтобы полностью абстрагироваться от "ОС+аппаратная часть". В т.ч. и по файловой системе и по графической и по другому вводу-выводу.
                                                                (Иначе как вы будете запускать апплеты на произвольной клиентской машине? Одна из изначальных целей Java)


                                                                Замечу, что цель и практика, конечно же, вещи разные. Но если нужна программа которая запускается и одинаково работает на Ubuntu, Windows и Android (случай из реальной практики) — Java показывает себя очень хорошо. Нужно только чтобы кроссплатформенность была в голове, а не только в языке.

                                                              0

                                                              Я вот что-то последний год наблюдаю рост интереса к чисто десктопным (правда всеже кросс-платформенным) приложениям, причем речь как раз про приложения без гуи. Может быть это связано с тем, что разработчики "вымываются", может обязательная необходимость интернета не всегда устраивает потребителя. Да и быстрый интернет далеко не везде и не всегда есть.

                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                              Самое читаемое