Здравствуйте, hrensgory, Вы писали:
H>Да вот куда-то оно не туда идёт по-моему. Применение транспайлеров H>приводит к тому, что в браузере исполняется javascript, связь которого с H>исходниками неочевидна.
197...ые годы. Опытный специалист сетует:
— Применение компиляторов приводит к тому, что на процессоре исполняется код, связь которого с исходниками на алголе неочевидна.
Здравствуйте, sr_dev, Вы писали:
_>Здравствуйте, Ikemefula, Вы писали:
I>>В браузере будет внятно работать только тот язык, который хорошо ложится на рантайм JS. Это, как ни странно, JS и С++
_>Шо?! Почему на "рантайм js" не ложится java, но ложится c++?
Потому, что С++ умеет компилировать свои шаблоны в zero-overhead, а джава так не умеет.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, sr_dev, Вы писали:
_>>Здравствуйте, Ikemefula, Вы писали:
I>>>В браузере будет внятно работать только тот язык, который хорошо ложится на рантайм JS. Это, как ни странно, JS и С++
_>>Шо?! Почему на "рантайм js" не ложится java, но ложится c++?
I>Потому, что С++ умеет компилировать свои шаблоны в zero-overhead, а джава так не умеет.
Ну и что? Джава в ГВт совершенно нормально транслируется в жс со всеми женериками и прочим. Все нормально ложится на рантайм и нормально работает в браузере
Здравствуйте, sr_dev, Вы писали:
I>>Потому, что С++ умеет компилировать свои шаблоны в zero-overhead, а джава так не умеет.
_>Ну и что? Джава в ГВт совершенно нормально транслируется в жс со всеми женериками и прочим. Все нормально ложится на рантайм и нормально работает в браузере
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, sr_dev, Вы писали:
I>>>Потому, что С++ умеет компилировать свои шаблоны в zero-overhead, а джава так не умеет.
_>>Ну и что? Джава в ГВт совершенно нормально транслируется в жс со всеми женериками и прочим. Все нормально ложится на рантайм и нормально работает в браузере
I>Врёшь. Стандартная либа джавы не скомпилируется ни во что. То есть, джава в браузере работает в виде ЭМУЛЯЦИИ рантайма. C++ никакой эмуляции не требует. I>http://www.gwtproject.org/doc/latest/DevGuideCodingBasicsCompatibility.html I>http://www.gwtproject.org/doc/latest/RefJreEmulation.html
По моему ты запутался.
Вопрос был: почему c++ в браузере ок, а java не ок?
Твой ответ: из за дженериков
Я говорю что с дженериками всё ок, ты теперь отвечаешь "джава требует эмуляции рантайма, а с++ не требует". С дженериками то ок теперь?
Какого "рантайма"? JVM? классов JRE? В каком месте C++ то будет лучше?
Здравствуйте, sr_dev, Вы писали:
I>>Врёшь. Стандартная либа джавы не скомпилируется ни во что. То есть, джава в браузере работает в виде ЭМУЛЯЦИИ рантайма. C++ никакой эмуляции не требует. I>>http://www.gwtproject.org/doc/latest/DevGuideCodingBasicsCompatibility.html I>>http://www.gwtproject.org/doc/latest/RefJreEmulation.html
_>По моему ты запутался. _>Вопрос был: почему c++ в браузере ок, а java не ок? _>Я говорю что с дженериками всё ок, ты теперь отвечаешь "джава требует эмуляции рантайма, а с++ не требует". С дженериками то ок теперь?
Не надо передергивать. Я сказал про zero-overhead. В джаве надо пилить слой эмуляции. Про дженерики сказал не я, а ты. Вот эта разница — эмуляция рантайма, — и есть ответ на твой
вопрос.
_>Какого "рантайма"? JVM? классов JRE? В каком месте C++ то будет лучше?
С++ не требует никакой эмуляции. Что именно эмулируется, какие ограничения, издержки, проблемы — всё есть по ссылкам.
_>Короче тема на данный момент не раскрыта.
I>Не надо передергивать. Я сказал про zero-overhead. В джаве надо пилить слой эмуляции. Про дженерики сказал не я, а ты.
Ну как
Потому, что С++ умеет компилировать свои шаблоны в zero-overhead, а джава так не умеет.
Это ты сказал или я?
Шаблоны (темплейты) C++ это дженерики в джаве. Или ты не про темлпейты? Кстати насчет zero overhead ты не совсем прав, по скорости может и да (и то не уверен, что jvm на лету не сможет оптимизировать), но по размеру исполняемого файла нет.
Теперь насчет твоих ссылок по поводу "эмуляции рантайма"
GWT includes a library that emulates a subset of the Java runtime library. The list below shows the set of JRE packages, types and methods that GWT can translate automatically. Note that in some cases, only a subset of methods is supported for a given type
Написано что GWT часть джрешных типов поддерживает не полностью. На практике кстати это большую проблему у меня не представляло.
Ты думаешь всё что есть в c++ (в стандарт кстати входят и такие вещи как std::thread) в браузере будет поддерживаться?
Здравствуйте, sr_dev, Вы писали:
_>Ну как
_>Потому, что С++ умеет компилировать свои шаблоны в zero-overhead, а джава так не умеет.
_>Это ты сказал или я?
Здесь нет ничего про дженерики.
_>Шаблоны (темплейты) C++ это дженерики в джаве.
Разумеется, это разные механизмы.
>Или ты не про темлпейты? Кстати насчет zero overhead ты не совсем прав, по скорости может и да (и то не уверен, что jvm на лету не сможет оптимизировать), но по размеру исполняемого файла нет.
Речь в том числе про перформанс и возможности. Стандартная библиотека — на шаблонах. То есть, zero-overhead, получаем её же в JS без пенальтей. В джаве тебе надо _портировать_ руками весь код. Как минимум — всю библиотеку.
_>GWT includes a library that emulates a subset of the Java runtime library. The list below shows the set of JRE packages, types and methods that GWT can translate automatically. Note that in some cases, only a subset of methods is supported for a given type _>Написано что GWT часть джрешных типов поддерживает не полностью. На практике кстати это большую проблему у меня не представляло. _>Ты думаешь всё что есть в c++ (в стандарт кстати входят и такие вещи как std::thread) в браузере будет поддерживаться?
На практике есть проект Ecmascripten, ты можешь в браузере поиграть в игры написаные двадцать лет назад на C++. Что бы повторить такой перформанс на джаве, тебе надо вместо эмуляции реализовать полноценную JVM поверх JS.
Ну как, сможешь показать аналогичное решение, навроде Ecmascripten, но на джаве ?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, sr_dev, Вы писали:
_>>Ну как
_>>Потому, что С++ умеет компилировать свои шаблоны в zero-overhead, а джава так не умеет.
_>>Это ты сказал или я?
I>Здесь нет ничего про дженерики.
А про что тут есть, какие шаблоны джава не умеет компилить?
I>Речь в том числе про перформанс и возможности. Стандартная библиотека — на шаблонах. То есть, zero-overhead, получаем её же в JS без пенальтей. В джаве тебе надо _портировать_ руками весь код. Как минимум — всю библиотеку.
не надо
I>На практике есть проект Ecmascripten, ты можешь в браузере поиграть в игры написаные двадцать лет назад на C++. Что бы повторить такой перформанс на джаве, тебе надо вместо эмуляции реализовать полноценную JVM поверх JS.
Ну а тут потребовалось реализовать llvm поверх js. Одинаково. Короче дело не в языке
18.01.2017 14:51, Ikemefula пишет:
> Сравни > appModule.service(ServiceFunction, [dependency1,dependency2,dependency3]) > с этим > class Service { > public Service(dependency1 d1,dependency2 d2,dependency3 d3) { > ... > } > }
Ну, мне как джависту конечно больше нравится второй вариант, только вот
с TypeScript отладка получается немного костыльная — только через source
maps и только Хром: https://www.jetbrains.com/help/webstorm/2016.3/debugging-typescript.html
> Собтсвенно не ясно, зачем пилить UI на джаве, если браузер сам обладает > наилучшими возможностями в этом вопросе.
Апплеты уже давно применялись не для "пиления UI", а для обеспечения
дополнительных возможностей браузеру — криптография, взаимодействие с
локальной аппаратурой и т.п. Да и на webassembly я так понимаю
планируется не элементы DOM с места на место переставлять )
> vm, флеш, сервелат зашли в тупик. Сервелат, Джава, Флеш это песочницы, > не позволяют внятную интеграцию с другими частями сайта,
Неясно что за такая "внятная интеграция" с другими частями "сайта".
Связка java <-> js в тех проектах, где применяли апплеты, работала
исправно (это, конечно, были не "сайты", а "веб-приложения").
> имеют проблемы > с перформансом, функциональностью, инсталяцией и тд и тд.
С перфомансом и функциональностью у всех трёх никаких существенных
проблем не встречалось, проблемы с инсталляцией обратно пропорциональны
распространенности плагина, у флэша я не помню никаких проблем с
инсталляцией — он был везде и везде работал.
> Зачем юзеру > пять дополнительных рантаймов для браузера, которые создают проблемы, > если омжно обойтись родным браузером ?
Да, в этом смысле, конечно, должно стать более удобно.
> Насколько я понимаю, нынешний тренд в браузерах — превращение движка в > полноценную платформу, фактически как OS.
По-моему эту тему уже давно пилят, если не забросили. На память приходит
словосочетание "Chrome OS".
18.01.2017 18:38, "Слава" пишет:
> H>Да вот куда-то оно не туда идёт по-моему. Применение транспайлеров > H>приводит к тому, что в браузере исполняется javascript, связь которого с > H>исходниками неочевидна. > > 197...ые годы. Опытный специалист сетует: > > — Применение компиляторов приводит к тому, что на процессоре исполняется > код, связь которого с исходниками на алголе неочевидна.
Транспайлер (в отличие от компилятора) "переводит" между языками
примерно одного уровня.
Здравствуйте, sr_dev, Вы писали:
I>>Здесь нет ничего про дженерики. _>А про что тут есть, какие шаблоны джава не умеет компилить?
Шаблоны != дженерики. В С++ шаблоны, например, тьюринг полные. И на этой полноте основаны библиотеки. Джереники джавы обладают полнотой по тьюрингу ?
Далее, ты можешь на джавовских дженериках запилить __итератор__, который развернется сам собой в честный цикл for ?
Джава так не умеет.
В С++ ты можешь сделать поддержку джаваскриптовых типов и работать с ними как с обычными. Это обойдется в 0 затрат рантайма. Тот самый zero overhead.
Java:
Heavy use of long operations will have a performance impact due to the underlying emulation
I>>Речь в том числе про перформанс и возможности. Стандартная библиотека — на шаблонах. То есть, zero-overhead, получаем её же в JS без пенальтей. В джаве тебе надо _портировать_ руками весь код. Как минимум — всю библиотеку. _>не надо
Окей. Покажи как путем простой перекомпиляции можно джавовскую прогу со внятным GUI запустить в браузере. Спасибо !
I>>На практике есть проект Ecmascripten, ты можешь в браузере поиграть в игры написаные двадцать лет назад на C++. Что бы повторить такой перформанс на джаве, тебе надо вместо эмуляции реализовать полноценную JVM поверх JS.
_>Ну а тут потребовалось реализовать llvm поверх js. Одинаково. Короче дело не в языке
Под этим страшным словосочетанием скрывается всего лишь компилятор в js. В джаве компилятор тебе ничем не поможет — надо пилить слой эмуляции.
Здравствуйте, hrensgory, Вы писали:
>> Собтсвенно не ясно, зачем пилить UI на джаве, если браузер сам обладает >> наилучшими возможностями в этом вопросе. H>Апплеты уже давно применялись не для "пиления UI", а для обеспечения H>дополнительных возможностей браузеру — криптография, взаимодействие с H>локальной аппаратурой и т.п. Да и на webassembly я так понимаю H>планируется не элементы DOM с места на место переставлять )
Сейчас взаимодействие с аппаратурой делается немного иначе. А для всего остального апплеты не нужны.
>> vm, флеш, сервелат зашли в тупик. Сервелат, Джава, Флеш это песочницы, >> не позволяют внятную интеграцию с другими частями сайта, H>Неясно что за такая "внятная интеграция" с другими частями "сайта". H>Связка java <-> js в тех проектах, где применяли апплеты, работала H>исправно (это, конечно, были не "сайты", а "веб-приложения").
И каким чудом твоя джава умела css, что бы ничем не отличаться от остального html ?
>> с перформансом, функциональностью, инсталяцией и тд и тд. H>С перфомансом и функциональностью у всех трёх никаких существенных H>проблем не встречалось, проблемы с инсталляцией обратно пропорциональны H>распространенности плагина, у флэша я не помню никаких проблем с H>инсталляцией — он был везде и везде работал.
Инсталяиця это вечный геморрой, что с флешем, что с джавой. Крик и плач юзеров, которым админы пообрезали всё подряд. Как правило таким оставалось только посочувствовать.
Функциональность это примерно так "вот эти кнопки пусть работают вот там". Кнопки на флеше, "там" — сильверлайт или апплеты.
Вот с подобными хотелками на джаваскрипте проблем никогда не возникает.
20.01.2017 20:14, Ikemefula пишет:
> H>Апплеты уже давно применялись не для "пиления UI", а для обеспечения > H>дополнительных возможностей браузеру — криптография, взаимодействие с > H>локальной аппаратурой и т.п. Да и на webassembly я так понимаю > H>планируется не элементы DOM с места на место переставлять ) > > Сейчас взаимодействие с аппаратурой делается немного иначе. А для всего > остального апплеты не нужны.
Как именно иначе? Из того что я видел — люди пишут нативный, требующий
инсталляции на клиентской машине (WinXX 32/64, Mac & Linux zoo welcomes
u!), сервера для общения с аппаратурой по http и плагин под каждый
поддерживаемый браузер. Чрезвычайно эффектно и очень элегантно )
> H>Неясно что за такая "внятная интеграция" с другими частями "сайта". > H>Связка java <-> js в тех проектах, где применяли апплеты, работала > H>исправно (это, конечно, были не "сайты", а "веб-приложения"). > > И каким чудом твоя джава умела css, что бы ничем не отличаться от > остального html ?
Зачем ей это? UI занимался JS.
> Инсталяиця это вечный геморрой, что с флешем, что с джавой. Крик и плач > юзеров, которым админы пообрезали всё подряд. Как правило таким > оставалось только посочувствовать.
Там где резали флэш — будут резать и webassembly.
Здравствуйте, hrensgory, Вы писали:
>> Сейчас взаимодействие с аппаратурой делается немного иначе. А для всего >> остального апплеты не нужны. H>Как именно иначе? Из того что я видел — люди пишут нативный, требующий H>инсталляции на клиентской машине (WinXX 32/64, Mac & Linux zoo welcomes H>u!), сервера для общения с аппаратурой по http и плагин под каждый H>поддерживаемый браузер. Чрезвычайно эффектно и очень элегантно )
Ты небось драйвера на джаве пишешь и всё такое, да ?
>> И каким чудом твоя джава умела css, что бы ничем не отличаться от >> остального html ? H>Зачем ей это? UI занимался JS.
Кул. UI отпадает. Значит остаётся два кейса — логика, которую тоже умеет JS, и железо, которое Джава умеет далеко не всегда, в силу ряда ограничений.
Так зачем тебе джава в бровзере ?
>> оставалось только посочувствовать. H>Там где резали флэш — будут резать и webassembly.
Нисколько. webassembly это фактически тот же JS, только в профиль. И возможности ровно те же. webassembly добавляет только перформанс и поддержку разных _языков_.
23.01.2017 15:50, Ikemefula пишет:
> Ты небось драйвера на джаве пишешь и всё такое, да ?
Причём тут драйвера? Как именно пообщаться с железом или любым сторонним
не-HTTP сервисом (TCP, UDP) из JS?
>>> И каким чудом твоя джава умела css, что бы ничем не отличаться от >>> остального html ? > H>Зачем ей это? UI занимался JS. > > Кул. UI отпадает. Значит остаётся два кейса — логика, которую тоже умеет > JS,
Дай пример реализации ГОСТ-овской криптографии на JS. Можно
несертифицированную реализацию — лишь бы работало следующее: открыли
файл, посчитали хэш, проверили отсоединенную ЭП. Для экономии времени
скажу сразу что подписанный апплет может открыть файл на компьютере
пользователя и прочесть его содержимое, если пользователь дал ему такие
разрешения.
> и железо, которое Джава умеет далеко не всегда, в силу ряда ограничений.
Да, не всегда. Но шансы часто есть.
>>> оставалось только посочувствовать. > H>Там где резали флэш — будут резать и webassembly. > > Нисколько. webassembly это фактически тот же JS, только в профиль. И > возможности ровно те же. webassembly добавляет только перформанс и > поддержку разных _языков_.
Поживём — увидим. Я думаю, что те кто резали флэш — порежут и
вебассембли. Тем более что наверняка в его VM поначалу будут дыры, а к
ним будут писаться эксплойты.
Здравствуйте, hrensgory, Вы писали:
>> Ты небось драйвера на джаве пишешь и всё такое, да ? H>Причём тут драйвера? Как именно пообщаться с железом или любым сторонним H>не-HTTP сервисом (TCP, UDP) из JS?
Никак, что вобщем то очевидно. И это одна из причин отказа от джавы.
H>Дай пример реализации ГОСТ-овской криптографии на JS. Можно H>несертифицированную реализацию — лишь бы работало следующее: открыли H>файл, посчитали хэш, проверили отсоединенную ЭП. Для экономии времени H>скажу сразу что подписанный апплет может открыть файл на компьютере H>пользователя и прочесть его содержимое, если пользователь дал ему такие H>разрешения.
Такая хрень вообще должна работать вне браузера. Кликаешь ссылку, открывается специализированое приложение.
Расскажи, как ты решишь следующую проблему — что сайтописатели как то забывают внятно обновлять аплеты, либы и тд и тд.
Если этим занимается отдельная софтина, то она контролируется через систему апдейтов. А вот с твоими аплетами как быть ?
>> и железо, которое Джава умеет далеко не всегда, в силу ряда ограничений. H>Да, не всегда. Но шансы часто есть.
Неинтересно. Надо 100% и что бы работало внятно, а не в зависимости от хотения сайтопейсателей.
>> Нисколько. webassembly это фактически тот же JS, только в профиль. И >> возможности ровно те же. webassembly добавляет только перформанс и >> поддержку разных _языков_. H>Поживём — увидим. Я думаю, что те кто резали флэш — порежут и H>вебассембли. Тем более что наверняка в его VM поначалу будут дыры, а к H>ним будут писаться эксплойты.
Это уже давно известно — ровно те же эксплойты, что есть сейчас для JS VM. Wasm это она же и есть.
24.01.2017 13:00, Ikemefula пишет: > Такая хрень вообще должна работать вне браузера. Кликаешь ссылку, > открывается специализированое приложение.
Кому должна?
> Расскажи, как ты решишь следующую проблему — что сайтописатели как то > забывают внятно обновлять аплеты, либы и тд и тд. > Если этим занимается отдельная софтина, то она контролируется через > систему апдейтов. А вот с твоими аплетами как быть ?
Уважаемый, меня, честно говоря, несколько утомляет этот разговор.
Давайте вы сначала ознакомитесь с тем что это вообще были за такие
апплеты (в прошедшем времени, т.к. NPAPI через которую подключался java
plugin стремительно выпиливается), как их встраивали в "сайты" (а их
нормальные люди не встраивали в "сайты", а только в веб-приложения,
исполняемые зачастую в корпоративном интранете) а потом, если будут
конкретные вопросы — зададите их. А то получается разговор ни о чем,
"должна работать вне браузера", "100% и не зависеть", "сайтопейсатели"
хрень какая-то.
Если вам просто из полемического задора хочется оставить последнее слово
за собой — напишите что-нибудь (неважно что) в ответ на этот пост.
Здравствуйте, hrensgory, Вы писали:
>> Такая хрень вообще должна работать вне браузера. Кликаешь ссылку, >> открывается специализированое приложение. H>Кому должна?
Тренд нынче такой. Не хавать, что дают разрабы, а принуждать их поддерживать определенный стандарт. Не готова поддержка — твою классную фичу юзер не сможет юзать.
>> Расскажи, как ты решишь следующую проблему — что сайтописатели как то >> забывают внятно обновлять аплеты, либы и тд и тд. >> Если этим занимается отдельная софтина, то она контролируется через >> систему апдейтов. А вот с твоими аплетами как быть ? H>Уважаемый, меня, честно говоря, несколько утомляет этот разговор. H>Давайте вы сначала ознакомитесь с тем что это вообще были за такие H>апплеты
Ты на вопрос попробуй ответить. Кто гарантирует, что ты в аплете заимплементируешь все необходимые гарантии, актуальные на нынешний день ?
И что делать юзеру, если он хочет юзать прогу, но хочет гарантии посильнее ? Кто ему специальный аплет напишет ?
Вот JS это позволяет решить. А у тебя только общие слова, как всё классно в джаве.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, sr_dev, Вы писали:
I>>>Здесь нет ничего про дженерики. _>>А про что тут есть, какие шаблоны джава не умеет компилить?
I>Шаблоны != дженерики. В С++ шаблоны, например, тьюринг полные. И на этой полноте основаны библиотеки. Джереники джавы обладают полнотой по тьюрингу ? I>Далее, ты можешь на джавовских дженериках запилить __итератор__, который развернется сам собой в честный цикл for ? I>Джава так не умеет.
Осталось выяснить, как это относится к переносимости джавы в js.
_>>Ну а тут потребовалось реализовать llvm поверх js. Одинаково. Короче дело не в языке
I>Под этим страшным словосочетанием скрывается всего лишь компилятор в js. В джаве компилятор тебе ничем не поможет — надо пилить слой эмуляции.
GWT без "слоя эмуляции" и "оверхеда" справляется с конвертацией дженериков и прочего в js.
UPDATE
Прочитай из какого ты это выдрал контекста и объясни как себя в аналогичной ситуации должен вести int64_t в c++. Спасибо)
Heavy use of long operations will have a performance impact due to the underlying emulation
