Флеш и Ява работют не в браузере, а в своих ВМ. На сервере это терпимо, а на клиенте мобильники и планшеты идут лесом. Native Client — он будет работать где-либо кроме Хрома? Как плагин или нативно?
Вспоминаю только демки на canvas с Box2D. Тормоз там как раз физический движок Box2D, а не canvas. Но в целом да, более серьезных примеров, упирающихся в скорость JS я не знаю. Но плюсы статической типизации — это не только скорость, это еще и контроль. На сегодняшний день, кроме костылей типа GWT воспользоватся статической типизацией нельзя.
P.S. Ни в коем случае не защищаю дарт — я сам в него не особо верю. Считаю, что при текущем разнообразии задач, решаемых в браузере, разумнее всего было бы принять стандарт не на еще один высокоуровневый язык, а на байткод. Плюсы:
1. Если вам нужен новый язык, вы пишите транслятор в байткод, а не ждете, пока поддержку вашего языка добавят во все браузеры.
2. Кроме этого мы можем использовать любой уже существующий язык при наличии транслятора
3. Весь код на этих языках совместим с друг другом. Например, код на JS без костылей сможет использовать библотеку, написанную на Python так, как будто она изначально писалась на JS.
4. Поскольку передаем байткод, а не текст, немного экономится трафик
5. По той же причине отсутствует синтаксический и лексический анализ на клиенте
На сервере у вас есть альтернатива. Тот кусок, где вам важна статическая типизация или производительность вы можете переписать на Java или .Net. Если что-нибудь из этого вам понадобилось в браузере вы можете только смирится и писать на JS.
Полностью согласен. С текущем уровнем значимости клиентской части стандарт на байткод+рантайм библиотеку был бы гораздо полезнее, чем стандарт на еще один выскоуровневый язык. Где гарантия, что через 10 лет, браузеру Рамблер.Нихром занимающему 90% рынка на понадобится создать язык Нидарт, чтобы исправить концептуальные ошибки в языке Dart.
unchecked — это немного уже из другой области. Если брошено Unchecked exception — это означает что код некорректен (вызов метода у null, закончилась память, завалился assert). И адекватно продолжить работу после такого исключения мы скорей всего не сможем. Ближайший аналог unchecked exception в C это SIGABRT.
Checked-исключения же могут возникать и при корректном коде, но некорректном окружении(отсутствует файл, соединение с сервером и т.п.). Это как раз аналог error-кодов и невалидных данных в C и подобных языках. Во многих случаях мы можем сообщить об ошибке пользователю и продолжить работу. И такие ошибки в хорошем софте должны обрабатыватся всегда.
В Java например у него нет возможности забить. Он должен или обработать выброшенное исключению сразу же, или перебросить исключение выше, иначе код просто не скомпилируется.
Не совсем так. Раньше же в getPoint() была проверка, возращать null или валидную точку. И еще проверка на null в вызывающем коде. С исключениями результат первый проверки замениться на исключение, а вторая станет не нужна
Не обязательно несвободную. Проблема не в распространении, проблема в конфликте между GPL и проприентарным DRM. С MIT, BSD и даже LGPL таких проблем быть не должно
Ну эта проблема вообще всех длинных серий, не только в видеоиграх.
Вы когда смотрите фильм «Что-то-5» тоже вряд ли увидите там что-то координально новое. А если создатели таки решаться сделать что-то действительно неожиданное с очередной частью легендарной серии, то получат в лицо кучу помидоров от фанатов старых серий. Вспомните HoMM4 например.
С другой стороны, и сейчас появляются новые игры со свежими идеями. То же Portal напрмер, куча инди игр типа Braid и Aquaria.
P.S. Ни в коем случае не защищаю дарт — я сам в него не особо верю. Считаю, что при текущем разнообразии задач, решаемых в браузере, разумнее всего было бы принять стандарт не на еще один высокоуровневый язык, а на байткод. Плюсы:
1. Если вам нужен новый язык, вы пишите транслятор в байткод, а не ждете, пока поддержку вашего языка добавят во все браузеры.
2. Кроме этого мы можем использовать любой уже существующий язык при наличии транслятора
3. Весь код на этих языках совместим с друг другом. Например, код на JS без костылей сможет использовать библотеку, написанную на Python так, как будто она изначально писалась на JS.
4. Поскольку передаем байткод, а не текст, немного экономится трафик
5. По той же причине отсутствует синтаксический и лексический анализ на клиенте
habrahabr.ru/blogs/development/130534/ — в комментариях холивар масштабов «табы vs пробелы».
Checked-исключения же могут возникать и при корректном коде, но некорректном окружении(отсутствует файл, соединение с сервером и т.п.). Это как раз аналог error-кодов и невалидных данных в C и подобных языках. Во многих случаях мы можем сообщить об ошибке пользователю и продолжить работу. И такие ошибки в хорошем софте должны обрабатыватся всегда.
Point getPoint() {
for (Point p: points) {
if (pointMatches(p)) {
return p;
}
}
throw NewPointNotFoundException
}
Google Authenticator
Barcode Scanner
Lastpass
Dolphin HD
Animated Weather
Launcher Pro Plus
Яндекс Карты
Яндекс Маркет
Приват24
Вы когда смотрите фильм «Что-то-5» тоже вряд ли увидите там что-то координально новое. А если создатели таки решаться сделать что-то действительно неожиданное с очередной частью легендарной серии, то получат в лицо кучу помидоров от фанатов старых серий. Вспомните HoMM4 например.
С другой стороны, и сейчас появляются новые игры со свежими идеями. То же Portal напрмер, куча инди игр типа Braid и Aquaria.
en.wikipedia.org/wiki/Google_Music
habrastorage.org/storage1/2310a726/32295316/14d20989/bdac9cdb.png