Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, lpd, Вы писали:

lpd>>Но мне кажется идея создания промежуточного кода избыточной. Возможно, что это вопрос вкуса, однако в IT простые инструменты нередко выигрывают у сложных(unix) и монструзоных(Windows и .NET).

_>Не избыточна. Вот смотри пример. Сейчас при разработке на C++ приложения под Андроид приходится пихать в дистрибутив (apk) от 2 (самые распространённые) до 6 (теоретический максимум в данный момент, охватывающий точно всё) версий приложения, под разные процессорные архитектуры. Если бы вместо этого мы компилировали приложение в llvm, а потом при инсталляции приложения на устройство перекомпилировали в машинные коды процессора данного устройства (кстати, в современном Андроиде именно так и происходит с Java кодом), то можно было бы класть только одну версию приложения в дистрибутив, что гораздо удобнее и экономнее. Причём это всё было бы без малейших потерь в производительности.

Конкретно для Android необходимость поддержки разных процессоров, на мой взгляд, сомнительна.
Более значительным преимуществом является безопасность кода по сравнению с C, однако эту проблему можно решить и без байткода.
Сейчас же Java и C# популярны в основном из-за наличия более проработанных фреймворков и средств сборки по сравнению с C++, а не из-за принципиальных преимуществ, которые дает байткод.
Хотя идея перенести часть процесса компиляции в рантайм или на этап инсталляции интересна. Однако портабельность сужает круг задача, которые код может решить. А портабельность как раз больше нужна в embedded системах. Вообщем, субъективно я бы предпочел, чтобы программа была представлена ввиде привычных машинных инструкций, а не скармливалась JVM-монстру. Но допускаю, что у других людей мнение может быть отличное.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, lpd, Вы писали:

lpd>>Но мне кажется идея создания промежуточного кода избыточной. Возможно, что это вопрос вкуса, однако в IT простые инструменты нередко выигрывают у сложных(unix) и монструзоных(Windows и .NET).

_>Не избыточна. Вот смотри пример. Сейчас при разработке на C++ приложения под Андроид приходится пихать в дистрибутив (apk) от 2 (самые распространённые) до 6 (теоретический максимум в данный момент, охватывающий точно всё) версий приложения, под разные процессорные архитектуры. Если бы вместо этого мы компилировали приложение в llvm, а потом при инсталляции приложения на устройство перекомпилировали в машинные коды процессора данного устройства (кстати, в современном Андроиде именно так и происходит с Java кодом), то можно было бы класть только одну версию приложения в дистрибутив, что гораздо удобнее и экономнее. Причём это всё было бы без малейших потерь в производительности.

Конкретно для Android необходимость поддержки разных процессоров операционной системой, на мой взгляд, сомнительна.
Более значительным преимуществом является безопасность кода по сравнению с C, однако эту проблему можно решить и без байткода.
Сейчас же Java и C# популярны в основном из-за наличия более проработанных фреймворков и средств сборки по сравнению с C++, а не из-за принципиальных преимуществ, которые дает байткод.
Хотя идея перенести часть процесса компиляции в рантайм или на этап инсталляции интересна. Однако портабельность сужает круг задача, которые код может решить. А портабельность как раз больше нужна в embedded системах. Вообщем, субъективно я бы предпочел, чтобы программа была представлена ввиде привычных машинных инструкций, а не скармливалась JVM-монстру. Но допускаю, что у других людей мнение может быть отличное.