Введение
Компилируемые языки интерпретируемого типа — это те языки программирования, которые компилируются в некое промежуточное представление (иногда именуемым "байт-кодом"). Самый яркий пример — это JVM (виртуальная машина Java).
В данной статье изложены мои мысли насчёт концепции виртуальной машины для языков программирования в нынешних реалиях. В реалиях, где большинство сервисов работают в Интернете, а настольные программы постепенно снимаются с производства.
Причины возникновения
Во времена зарождения Всемирной паутины появилась технология Java, впервые популяризовавшая использование виртуальной машины в качестве исполняющей среды для языков программирования высокого уровня.
Sun Microsystems попытались соединить надёжность и высокую скорость работы компилируемых языков с переносимостью и лёгкостью использования интерпретируемых. В определённой степени задуманная идея осуществилась, ведь Java всё же стал наиболее распространённой технологией в построении высоконагруженных серверов.
Кроме всего прочего, было выдвинуто одно из главных требований платформы, позже ставшее слоганом — "Скомпилируй однажды, запускай везде!". Это означало, что программисту следовало лишь раз скомпилировать исходный код в так называемый байт-код, способный быть запущенным на любой системе, где установлена JVM.
Это и стало движущей силой технологии, откинув многие языки на задний план. Это было своего рода революцией в мире цифровых вычислений, ведь раньше никому не удавалось достичь подобного уровня кроссплатформенности. Теперь пользователи могли скачивать одну и ту же версию программы на множество операционных систем и архитектур процессоров, и быть уверенными что она непременно будет работать именно так, как это задумывалось разработчиками.
Но времена меняются, и технологии вместе с ними. Всемирная паутина набирает всё большую популярность, вытесняя некоторые привычные для нас вещи.
Эпоха удалённых сервисов
"Зачем поставлять программы пользователям, если можно просто сделать сайт?" — этим вопросом задались крупные предприниматели, что позже вылилось в масштабную эмиграцию услуг во Всемирную сеть. Стандартные настольные программы начали утрачивать свою популярность, ведь намного проще и эффективнее сделать простенький (или не очень) веб-сайт.
Следовательно, отпала и необходимость так часто скачивать программы с Интернета. Открыть сайт и осуществить необходимые действия намного быстрее, чем скачивать мегабайты бинарных данных.
А тем временем Java обрела популярность в построении тех самых сайтов, ведь ничего удобнее на тот момент (и по сей день) не существовало. Исходные файлы стали компилироваться лишь под конкретную архитектуру сервера, следовательно, принцип "Скомпилируй однажды, запускай везде!" перестал иметь былое значение. Пользователи перестали скачивать программы, а разработчики стали компилировать лишь под конкретную архитектуру.
Эволюция языков
Раньше компилируемые языки программирования обладали довольно скудной функциональностью стандартной библиотеки, из-за чего приходилось использовать массу платформенно-зависимых функций даже для простого приложения, не делающего ничего сверхъестественного.
Языки программирования тоже не стояли на месте, и на свет вышли такие языки, как Rust и Golang, оба компилируемых, и оба обладают стандартной и множествами сторонних библиотек, предоставляющих независимый от архитектуры и операционной системы функционал. Кроме того, экосистема C/C++ тоже не стояла на месте.
В итоге оказалось, что современные стандартные библиотеки и виртуальные машины выполняют одну и ту же роль — транслируют кроссплатформенный код в платформо-зависимые функции.
Оставшаяся часть
Кто-то может возразить, что спрос на настольные программы всё ещё есть. В основном это закрытые программы, предназначающиеся для внутреннего использования в корпорациях, а также то небольшое количество общедоступных приложений.
В обоих случаях компиляция под сотню разных платформ не имеет смысла, так как в подавляющем большинстве случаев применяются лишь три всем известные операционные системы (GNU/Linux, Microsoft Windows и Mac OS) и одно семейство архитектур процессоров (x86).
Заключение
Итого мы имеем замедляющие работу виртуальные машины (в качестве сред исполнения байт-кода), утратившие свои основные преимущества вследствие двух вышеизложенных факторов:
- Необходимость запуска программы на сотне разных архитектур не имеет смысла, так как большинство программ работают на серверах, а пользовательских архитектур и операционных систем не так уж и много.
- Компилируемые языки не стояли на месте, и их стандартные библиотеки приобрели необходимый базовый функционал для кроссплатформенного кода.
Обсуждения в комментариях приветствуются, надеюсь, что статья натолкнула вас на некоторые мысли по поводу выбора подходящего языка для ваших задач.
Дополнения
Как отметили в комментариях, управляемый код имеет некоторые преимущества, недоступные компилируемому коду, в том числе рефлексия и аннотации.
Комментарии (63)
codecity
03.06.2019 04:31+2Вопрос интересный, но, имхо, не раскрыт. Как быть с примочками, которые дает управляемый код? Та же безопасность доступа к памяти.
Gymmasssorla Автор
03.06.2019 04:44Безопасность доступа к памяти может быть достигнута синтакистом (Rust, Golang как пример). Какие ещё примочки даёт управляемый код?
artskep
03.06.2019 06:13+1reflections, annotations на вскидку
Gymmasssorla Автор
03.06.2019 06:22Добавил в секцию "Дополнения".
gecube
03.06.2019 08:03Кмк, это не особенности управляемого кода, ибо такое же реализуют испокон веков на С++.
Да и на "голом" Си, как пример, можно писать ООП код. Я к чему — эти фичи — вопрос сложности написания конкретного функционала, а не типа языка. Но лучше, конечно, когда они в стандарте — не нужно пилить свои велосипедыadev_one
03.06.2019 09:33К слову, в Swift есть вполне полноценная интроспекция, хоть он и компилируется в бинарник. Java тоже может компилироваться в бинарник с помощью GraalVM и вся её рефлексия, при этом, доступна
eliasdaler
03.06.2019 10:57Когда в 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
sotnikdv
03.06.2019 06:12+3А в чем проблема? JIT никуда не делся, JVM часто используемые куски байт-кода компилирует уже в нативный код на лету.
Как по мне — вполне себе разумная модель, когда у тебя парсинг кода и компиляция в нативный код разделена на две части. И вторая происходит уже на целевой платформе. И более того, без участия человека, по необходимости.adev_one
03.06.2019 06:33+2Немного дополню. JIT компиляция может быть эффективнее, чем AOT за счёт спекулятивных оптимизаций. Оптимизируем код под те сценарии, которые действительно происходят, если сценарии меняются — откатываемся и оптимизируется по-другому. Для серверов как раз актуально
gecube
03.06.2019 07:58- Почему тогда вообще не перейти на дистрибуцию полностью в исходных кодах? Боязнь того, что конечный пользователь увидит код? Ну, тот же джаваскрипт обфусцируют, если уж на то пошло, а байт-код сам по себе от декомпиляции и реверса не спасает. Раньше — да, у JIT было преимущество (и уменьшение размера бинарника относительно сырцов, и перенос на большей вычислительной нагрузки по сборке кодов с машины потребителя на специальную сборочную ферму у разработчика).
- Все эти спекулятивные истории могут работать, а могут не работать. До сих пор есть паттерны, которые без оптимизации работают лучше, чем с "не угадали ветку выполнения" и неудачно оптимизировали. К тому же, мы все помним про уязвимости процессоров Интел/АМД — а все из-за реализации спекулятивности. Уверен, что ПО тоже может быть подвержено аналогичным атакам, но они более трудноосуществимы, т.к. целью будет конкретная связка версия ОС — версия виртуальной машины языка
adev_one
03.06.2019 08:07Дистрибуция исходников не даст никакой дополнительной информации компилятору в сравнении с байт-кодом. К тому же, в них много лишней информации и их нужно дополнительно предобрабатывать. С байт-кодом проще в инкрементальность потому что добавление комментария не изменит его. Плюс проще с обратной совместимостью. Можно скомпилировать новый код — в старый байт-код. Это проще, чем новый Джаваскрипт — в старый.
То же самое можно сказать про AOT оптимизации. Только JIT можно откатить, а AOT — нет
adictive_max
03.06.2019 09:44Раньше — да, у JIT было преимущество (и уменьшение размера бинарника относительно сырцов, и перенос на большей вычислительной нагрузки по сборке кодов с машины потребителя на специальную сборочную ферму у разработчика).
Ну это всё как бы никуда и не делось. Да, машины у потребителей стали мощнее, но и размер исходников вырос, а оптимизации в компиляторе стали сильно умнее и соответственно прожорливее.
NoRegrets
03.06.2019 21:01Есть же примеры дистрибуции в исходных кодах. Та же фря или гента. Помимо всего прочего добавляется целый пласт проблем у клиента, которые обобщенно можно назвать «не собралось».
nlinker
03.06.2019 08:15Может быть, но в реальности разработчики работают не хуже JIT, используя профайлеры и другие инструменты для локализации горячих точек. Кроме того, они используют неявные предположения о входных данных, чего JIT делать не может — да, у него есть профиль исполнения, однако он не может строить утвеждения о свойствах программ на его основе.
Кроме того, времени у JITа не очень много, он не может себе позволить делать слишком сложный внализ, так что разработчики JIT находятся в сущности между молотом и наковальней и вынуждены искать компромиссы.
adev_one
03.06.2019 08:21Согласен. Я из мира JVM и с полностью компилируемыми языками знаком мало. У разработчиков есть какой-то способ дать компилятору инструкции чтобы он оптимизировал код определённым образом? Не портя при этом сам исходный код. Не хочется жертвовать поддерживаемостью. Да и любую "ручную" оптимизацию в исходном коде компилятор может "сломать", например, при обновлении его версии
gecube
03.06.2019 08:31Что значит " не портя "? Не внося изменений в исходный код — т.е.? Думаю, что вряд ли. В любом случае нужно будет как минимум хинты для компилятора расставить (я в широком смысле — туда же пойдут всякие #pragma). С другой стороны, компиляторы вроде компилятора С++ стали слишком умны. Но ценой того, что время компиляции большого проекта стремится в бесконечность, а при этом cpu/mem в полку (почитайте про боль разработчиков Chrome)
adev_one
03.06.2019 08:56Почитал про pragma. Довольно удобно выглядит.
А время компиляции — боль даже в JVM. Классно сделали в Dart. Он может и полностью интерпретироваться, безо всякой компиляции вообще, и в AOT тоже может. Это представляют как killer-feature. Что можно мгновенно применять изменения. Надеюсь, другие тоже подтянутся. Hot-reload для Kotlin/Swift без танцев с бубном. Или даже интерпретация С++ в дебаге по-умолчанию, как вам? =)
Neikist
03.06.2019 10:33Кроме того, времени у 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.
Antervis
03.06.2019 15:48IT компиляция может быть эффективнее, чем AOT за счёт спекулятивных оптимизаций
в теории может быть. На практике в подавляющем большинстве случаев JIT всё еще не эффективнее. А там, где оптимизация под конкретный профиль дает столь огромный бонус к быстродействию, можно использовать profile-guided optimization. В реальности самый главный ресурс, который экономит JIT — время разработчика.
reforms
03.06.2019 07:05Посыл интересный, но как насчет самого процесса написания программ? Например, либы appache commons могут компилироваться на ubuntu, tomcat — под windows, hibernate под MacOs, a запускаться все под mint. Я к тому, что принцип 'Скомпилируй однажды, запускай везде!' еще далеко не умер
acmnu
03.06.2019 08:51'Скомпилируй однажды, запускай везде!' еще далеко не умер
На этот принцип давит идеалогия CI/CD, когда цепочка хорошо автоматизирована нет большой разницы собирать ли под одну платформу или под две. Собственно, насколько я понимаю в мире игрушек на мобилки именно так.
Другой вопрос, что все же не все так радужно с библиотеками и всегда найдется что-нибудь странное и не совместимое.
aamonster
03.06.2019 07:44А что, про llvm (кажется, наиболее популярная на сегодня "основа" для компиляторов) вы не слышали?
Так что байт-код вполне себе жив. А вот от реально действующей виртуальной машины ушли, да. Байткод приятней скомпилировать в нативный.MikailBag
03.06.2019 10:29Ну, это уже не совсем тот байткод.
Он не кроссплатформенный.
Он не обратно-совместимый.
Он не эффективен с т.з. интерпретации (так как неограниченное число регистров, причем большее, чем переменных в исходной программе.)
gecube
03.06.2019 07:52Пять копеек.
- Самые две доминирующие платформы — x86-64, ARM. Почему забыли про последний? Причем у него есть 100500 не совсем полностью совместимых вариантов.
- Действительно, основные операционными система являются Windows и Linux. Но с тем же Линукс можно весело отхватить. Например, в дистрибутиве Alpine библиотека libc заменена на musl, что приводит к неработоспособности части программ, а часть нужно специальным образом перекомпилировать.
- Про мегабайты бинарей — сильно сказано. Но любой мало-мальски серьезный сайт в пересчёте на пользователя тратит трафика в разы больше. Пример. Какое-нибудь стенделоун приложение необходимо обновлять, когда выходят обновления. Либо самого ядра ПО, либо его данных. Типичный пример часто обновляемого ПО — антивирус. Но даже в его случае объем трафика будет сотни МБ в неделю. Скачал — пользуйся. А вот с сайтом — постоянно в фоне будет подгружаться реклама, медиа-контент. Запросто могут быть тяжёлые запросы (на килобайты!) между браузером и сервером. Я уж не говорю, что в джава скрипте могут и майнер запустить.
nlinker
03.06.2019 08:02"В обоих случаях компиляция под сотню разных платформ не имеет смысла, так как в подавляющем большинстве случаев применяются лишь три всем известные операционные системы (GNU/Linux, Microsoft Windows и Mac OS ) и одно семейство архитектур процессоров (x86)."
К одному измерению добавить Android и iOS, а к другому — x64, ARM, ARMx64, MIPS и популярные в будущем RISC V, и получим 5 * 6 = 30 платформ, а не 3 как вы посчитали. В свете этого виртуальные машины, LLVM или другие подобные технологии очень даже имеют смысл.
gecube
03.06.2019 08:04А где я противоречу (зачем-то отвечаете на мое сообщение), хотя я говорю про то же самое ?!
nlinker
03.06.2019 08:56Ой, промахнулся, надо было в корень.
Прочитал ваш ответ — да, я дублирую ваше утверждение, только ещё добавив RISC V.
Удалить уже не получится, считайте, что то сообщение начинается словами: "Дополню ваш ответ ещё такой арифметикой: ..." :-)
mistergrim
03.06.2019 07:56Стандартные настольные программы начали утрачивать свою популярность, ведь намного проще и эффективнее сделать простенький (или не очень) веб-сайт.
Дальше не читал.gecube
03.06.2019 08:00На самом деле в этой фразе есть очень существенная доля правды. 90% приложений на телефоне не автономы, а представляют собой по сути либо браузер, отправляющий запрос на центральный сервер, либо попросту не могут работать без интернета (начиная от игр серии Angry Birds и кончая всякими календарями красных дней)
mistergrim
03.06.2019 08:08Ну так 90% приложений на телефоне (подчеркнём, только на телефоне) предназначены для работы с интернетом, или имеют искусственную привязку к нему, как те же Angry Birds. Что не отменяет того факта, что они по-прежнему представляют из себя код, выполняющийся на пользовательском устройстве. (достаточно на размеры всяческих скайпов и вацапов посмотреть)
И да, мой комментарий относится в том числе к утверждению «проще и эффективнее».
third112
04.06.2019 06:03Стандартные настольные программы начали утрачивать свою популярность, ведь намного проще и эффективнее сделать простенький (или не очень) веб-сайт.
Т.е. ОС с кучей инструментов от калькулятора и браузера до дисковых утилит больше не нужна? :) А как быть с такими популярными, но небесплатными программами как Фотошоп, 3D и видео редакторы? А всевозможные расчетные программы? Дайте студентам волю — так они все суперкомпы (если такие будут в бесплатном сетевом доступе) своими курсовыми, нпр., по квантовой химии выше потолка загрузят. И т.д. И это только вершина айсберга. (А еще есть майнинг — м.б. и его сделать сетевым и бесплатно для этого мощности выделить? ;))
Falland
03.06.2019 08:08Очень интересно, что в лагере писателей сайтов тоже решили пойти по пути создания виртуальной машины с байт-кодом: WebAssembly. Так что не думаю, что концепция хоть сколько устарела.
zim32
03.06.2019 08:39Интересно что ГО оказывается местами медленнее джавы. Расходимся
gecube
03.06.2019 10:53ну, вряд ли можно сравнивать бенчмарк "давайте в тупом цикле напечатаем строчку 100000 раз" на любимом языке программирования. Вы сделали достаточно громкое заявление. Поэтому прошу его подтвердить ссылками на тесты.
bromzh
03.06.2019 12:25gecube
03.06.2019 12:36Спасибо, но это именно иллюстрация "давайте в тупом цикле напечатаем строчку 100000 раз" только на другой лад.
adictive_max
03.06.2019 15:11Вот есть бенчмарк с рейтрейсингом на CPU. github.com/Mark-Kovalyov/CardRaytracerBenchmark.
gecube
04.06.2019 15:03Да, действительно Go медленнее Java. Теперь остается понять почему так получается....
bromzh
03.06.2019 16:12Ой, ну тогда так можно про любой бенчмарк сказать. Давайте тогда пример бенчмарка, который будет больше соответствовать реалиям.
По ссылке вполне себе задачи из жизни: сетевое взаимодействие, запросы к БД, сериализация. Тестов там тоже больше одного, запускают как в облаке, так и на одном компе. Ниже есть ссылка и на числодробилки.
И во всех случаях го почему-то не быстрее джавы.gecube
03.06.2019 18:02Я предполагал, что дискуссия зайдет в это русло, поэтому хотелось бы сбавить градус напряженности анекдотом:
Инженер, физик и математик едут на поезде через Шотландию. Вдруг они замечают чёрную овцу, пасущуюся на поле.
"Ага!" – восклицает инженер – "Шотландские овцы чёрные!"
"Хм…" – говорит физик – "Я бы сказал, что некоторые из шотландских овец чёрные"
"Нет" – возражает математик – "Всё, что мы знаем – это то, что в Шотландии есть как минимум одна овца и как минимум одна сторона этой овцы чёрная"А если серьезно, то пока действительно получается, что голанг не быстрее джавы. Возможно, что существуют кейсы, когда они на равных по скорости. Или есть какие-то другие критерии, почему голанг так популярен (скажите еще, что его неосиляторы джавы любят, да и вообще он продукт принципа NIH в переложении Гугла).
zim32
03.06.2019 19:11Очевидно потому что не надо тащить за собой виртуальную машину. Хотя есть инструменты которые компилируют джаву сразу в нативный код. Но там свои подвохи
PsyHaSTe
03.06.2019 08:48Потому что реализовать общий интерфейс уровня байткода проще, чем каждый компилировать в каждый. Пример c language server в тему:
Вместо IDE только если выбирать x86/ARM/MIPS/...
Antervis
03.06.2019 09:52ведь Java всё же стал наиболее распространённой технологией в построении высоконагруженных серверов.
а плюсовики обычно говорят что в высоконагруженных серверах царят плюсы. И кому верить?vassabi
03.06.2019 17:59никому не верьте (с)
ИМХО разница в восприятии, что такое «высоконагруженный»:
там где сервер хоть немного нагруженный, то энтерпрайз считает это «высоконагруженным сервером» и переходят с ноды\руби\питона\перла\проч на джаву, тем более, что в больших организациях на это все есть и девы и серверы.
А в тех нечастых случаях, когда это действительно что-то сверхвысоконагруженное — то тогда на плюсы (и не только, но все равно близкое к железу).
sergey-gornostaev
03.06.2019 10:02Во-первых, вы обошли вниманием, что сервера тоже имеют разную архитектуру и разные операционные системы. Мой код, написанный и скомпилированный в 2003-м году, сначала работал на сервере с 32-битными процессорами Xeon Prestonia и FreeBSD на борту, потом переехал на Fujitsu PRIMEPOWER с Solaris, сейчас крутится на IBM'овских блэйдах c AIX'ом, не удивлюсь, если через некоторое время перенесут на что-нибудь с ARM'ами и под Linux или HP-UX.
Во-вторых, как уже заметили в комментариях, на много проще портировать на новую платформу виртуальную машину или компилятор байткода, чем каждое отдельное приложение.
gBear
03.06.2019 10:05+3Как-то уж очень, скажем так, поверхностно… к сожалению. Начиная с того, что автор, судя по всему, слабо себе представляет что-такое 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 еще можно как-то согласится. Но причем тут «компилируемые языки», их «стандартные библиотеки», я так, к сожалению, и не понял :-( Концепции кросс-платформенной компиляции (и соответствующим компиляторам) уже скоро «полтинник» стукнет… если уже нет.
- Необходимость запуска программы на сотне разных архитектур не имеет смысла, так как большинство программ работают на серверах, а пользовательских архитектур и операционных систем не так уж и много.
- Компилируемые языки не стояли на месте, и их стандартные библиотеки приобрели необходимый базовый функционал для кроссплатформенного кода.
sbnur
03.06.2019 10:27Что такое настольная программа?
Antervis
03.06.2019 11:51буквально «desktop application». Перевод от Гоголь Транслит 9000
sbnur
03.06.2019 12:01а в чем принципиальное отличие десктопных приложение от других, кстати, что входит в недесктопные приложения
Antervis
03.06.2019 13:33я думаю, под «десктопными приложениями» как правило подразумеваются приложения под Windows/Linux/MacOS (x86/x64) с GUI, заточенным под клавиатуру/мышь.
sbnur
03.06.2019 13:58Во-первых мобильные приложения используют виртуальную клавиатуру, а приложения под Windows и другие ОС работают и на тачскринах.
У меня вопрос был — в чем десктопные приложения принципиально отличются от недесктопных?
И почему молчит автор — его задача объяснять непонятности в тексте
DrunkBear
03.06.2019 11:04Кто будет переписывать заново существующие фреймворки и софт?
И что конечным бизнес-пользователям даст какой-нибудь Hadoop на Go?
Кроме опасений, что всё сломается и непонятно как чинить?
Zanak
03.06.2019 11:28Как субъективное мнение одного человека — сойдет. Как объективная информация — статья мало полезна, на мой взгляд.
Виртуальная машина — это часть среды исполнения, а не компиляции. Компилятор просто преобразует исходный код программы во что-то еще. И это может быть, например, исходный код на другом языке.
Виртуальная машина, как среда исполнения специализированного байт-кода, не важно, будь это java, python, lua, или что — то еще — это только один из вариантов запуска написанной программы. Понятно и почему он появился — это компромисс между гибкостью скриптового языка и скоростью откомпилированной программы.
На счет того, что лучше — создать сайт или написать программу, это холиварная тема, и я ее затрагивать не хочу. Только напомню: без ОС и браузера все ваши замечательные сервисы так и останутся невостребованными, так что, как минимум, авторы этих двух категорий ПО могут спать спокойно (еще, я за поддержку оффлайн режима в навигаторах, черт с ним, пробки пусть подтягивает из сети).
ksbes
03.06.2019 12:22Принцип JVM "скомпилировано (написано) раз — работает везде" куда глубже, чем представлено в статье. Тут акцент не на компилции, а на работе.
Т.е. смысл JVM что поведение программы никак не зависит от физической платформы, но при этом программа, в отличии от всяких бейсиков, работает с почти "низкоуровневой скоростью". И именно для этого она создавалась (во времена раннего веба) и в этом её сила.
На практике это не всегда так — но это уже нарушение этого принципа (понятно что идеалов в природе не существует). К тому же сейчас подтянулись конкуренты с тем же принципом — JavaScript, Python, так что Java потихоньку (или не потихоньку) сдаёт позиции. Но сам принцип жив, востребован и развивается.
Компилируемые под платформу языки тоже востребованы (на чём JVM или NodeJS писать?). Всем своя ниша.
Причём десктоп-то как раз процентов на 80% (из-за богомерзкого "Электрона" процент падает) написан именно на них, а "вебизация" приложений требует как раз кроссплатформеных технологий.gecube
03.06.2019 12:34Т.е. смысл JVM что поведение программы никак не зависит от физической платформы
Так не бывает. Всегда есть фактор окружения. Например, файловая система, которая в одном случае позволяет case sensitive, а в другом нет. Можно говорить о какой-то степени похожести поведения.
Или физическая платформа подразумевается не ОС+аппаратная часть, а именно процессор-архитектура? Ну, тогда ок. Но все равно есть моменты, когда абстракции протекают (например, быстродействие в типах данных, которые для платформы не нативны).ksbes
03.06.2019 15:10Так не бывает. Всегда есть фактор окружения. Например, файловая система, которая в одном случае позволяет case sensitive, а в другом нет.
Именно поэтому все имена пактов должны быть в нижнем регистре (жаль это не проверяется на уровне компилятора по умолчанию). Согласен идеала не бывает. Достаточно сложный проект на Java частенько дорастает до нативных библиотек.
Но цель, принцип, именно в том, чтобы полностью абстрагироваться от "ОС+аппаратная часть". В т.ч. и по файловой системе и по графической и по другому вводу-выводу.
(Иначе как вы будете запускать апплеты на произвольной клиентской машине? Одна из изначальных целей Java)
Замечу, что цель и практика, конечно же, вещи разные. Но если нужна программа которая запускается и одинаково работает на Ubuntu, Windows и Android (случай из реальной практики) — Java показывает себя очень хорошо. Нужно только чтобы кроссплатформенность была в голове, а не только в языке.
tuxi
03.06.2019 15:35Я вот что-то последний год наблюдаю рост интереса к чисто десктопным (правда всеже кросс-платформенным) приложениям, причем речь как раз про приложения без гуи. Может быть это связано с тем, что разработчики "вымываются", может обязательная необходимость интернета не всегда устраивает потребителя. Да и быстрый интернет далеко не везде и не всегда есть.
kzhyg
Ну то есть андроид, работающий на процессорах самых разных семейств, страдающие роутеры с MIPS за $2 и все одноплатники прошли мимо вас?
Gymmasssorla Автор
Андроид, работающий на разных архитектурах, программирование встраиваемых систем, конечно, имеют место быть, но их решает пункт 2:
Реализации стандартных библиотек можно писать под различающиеся платформы так же, как и виртуальные машины, просто исключается жирный рантайм. Примером могут послужить стандарты C/C++.
berez
Вопрос был не в том, кто что решает. Один из посылов вашей статьи — «все разнообразие на практике свелось к трем ОС и одной архитектуре x86». Вам вполне логично указывают на андроид — наиболее распространенную ОС для смартфонов на данный момент. Если вы не в курсе, разработка на андроид ведется на языке java (или kotlin — он тоже на jvm), а наиболее распространенный процессор в андроидофонах — ARM.
Все это несколько опровергает ваши предпосылки, из которых вы делаете в статье далеко идущие выводы.