>> «а вот если БЫ мы предложили вам икс денег и занятие игрек, приняли БЫ вы предложение вот прямо сейчас?» До сих пор жалею, что в том момент был сильно простужен и на этой почве плохо соображал, поэтому не смог сформулировать соответствующий вопросу ответ…
Интересует, как бы вы ответили, если бы хорошо соображали :)
А нельзя 25-миллиардному покупателю написать какую-нибудь фигню, выложить ее в App Store и купить за $10000?
Ну или завести другой аккаунт и с него купить?
Так можно будет вывести эти деньги :)
JavaScript интерпретируемый язык с неявной типизацией, а в Native Client исполняется нативный x86 код. Соответственно первый никогда не сможет конкурировать со вторым по скорости.
Кстати, а не подскажите вменяемый плагин для хрома (по аналогии с In-place translator для Opera)?
А то у меня сейчас Translator based on google AJAX API стоит и мало того, что он не удобный (приходится к значку переводчика подводить курсор), да еще и глючит (вместо перевода выводится такая фраза: Can't detect language or selected text is too long.)
Жду, когда появится возможность захвата мыши мыши в таких приложениях.
Причем сначала будет запрашиваться разрешение у пользователя (по аналогии с определением местоположения, полноэкранного режима и т.д.).
Честно сказать не знаю: то ли это мои кривые руки, то ли разработчиков libgdx, то ли java. Наиболее вероятнее последнее, т.к. на Win x86 и Win x64 работает.
Еще при разработке мобильных приложений (Android, WP) советуют как можно реже создавать новые объекты, чтобы сборщик мусора работал как можно быстрее и не тормозил систему.
Для решения этой проблемы можно использовать например Объектный пул.
Золотые слова.
Интересует, как бы вы ответили, если бы хорошо соображали :)
Ну или завести другой аккаунт и с него купить?
Так можно будет вывести эти деньги :)
>> а Native Client, насколько я понимаю, альтернатива JS, а не HTML5, т. е. для отображения будут использоваться те же WebGL, canvas и svg
Никакая это не альтернатива — в NaCl же исполняется нативный код. Про WebGL, canvas и svg не в курсе.
>> Так и у флеша с производительностью не фонтан
Зато у NaCl все будет с ней в порядке :)
И NaCl хоть во всех браузерах одинаково работать будет (как и флеш), в отличие от HTML5.
JavaScript интерпретируемый язык с неявной типизацией, а в Native Client исполняется нативный x86 код. Соответственно первый никогда не сможет конкурировать со вторым по скорости.
Ну тут не совсем верно: у HTML5 все-таки недостаточная производительность для игр.
По крайней мере я на это надеюсь.
Я то не против языка D. Мне он даже нравится в качестве замены С++.
Но я имел ввиду то, что не видел, чтобы данный язык использовался где-то в промышленных масштабах. И это самое печальное.
А то у меня сейчас Translator based on google AJAX API стоит и мало того, что он не удобный (приходится к значку переводчика подводить курсор), да еще и глючит (вместо перевода выводится такая фраза: Can't detect language or selected text is too long.)
А я всегда с русскими смотрел и думал, почему же слуховой английский все равно плохо воспринимается :).
И действительно, английские субтитры гораздо лучше понимаются, чем речь.
Причем сначала будет запрашиваться разрешение у пользователя (по аналогии с определением местоположения, полноэкранного режима и т.д.).
За что на хабре обычно минусуют:
Для решения этой проблемы можно использовать например Объектный пул.