Ну, не знаю, процессоры вон, сильно быстрее не становятся. Моему компу уже года 4 наверное, и он всё ещё ok: core2duo 4gb 750gb. — это я не конфигурацией хвастаюсь :), а пытаюсь сказать что таго быстрого роста производительности как раньше уже нет.
Кстати, а есть какое-то каноническое определение термина «модуль»?
Интуитивно я понимаю чем модуль отличается от простого включения текста файла в другой файл, но, возможно есть другие обязательные черты, вроде обязательного наличия конструкторов модулей?
Там большинство замечаний касаются не работы с JS. (Не будем считать за JS реализацию отдельных функций).
Про js написано что «там ужастный GC». Ну так, никто и не обещает его бысторой работы, обещают правильную. Добро пожаловать в web :)
Напомню, изначально говорилось, про то что Opera и IE не поддерживают в JS в той мере, в какой его поддерживает Chrome, при этом в укор ставилось что они не поддерживают фичи ещё не введённые в стандарт. Я уею дорогая редакция.
Про 10мс это, вообще то, platform depended. Собственно, в windows, setTimeout и setInterval, скорее всего, напрямую используют winApi SetTimer, по крайней мере, описание работы setInterval это дословная калька с доки по SetTimer. Отсюда и все особенности их работы.
1) Термин «морально устаревший» как бы субъективен, вы выдаёте ваше отношение за «факт».
2) ES.Next (это который Harmony?) как бы ещё в разработке, его никто не обязан поддерживать. Поправьте если ошибаюсь.
3) Если верить wiki en.wikipedia.org/wiki/ECMAScript см. «Conformance tests», то у Оперы как раз всё очень хорошо.
Что интересно, большинство языков, далеко не отходят от главной диагонали. Это значит или что не получается сделать мощный и простой язык, или, что более вероятно, что каким бы ни был язык, его возможности пытаются использовать «на полную», т.е., можно сказать, гвозди микроскопом забивают.
Как-то неправильно вы линии провели, по логике, самые крутые языки должны быть в правом нижнем углу, т.е. Если проводить линию «треш», то она должна быть вертикальной, или вообще быть областью (сложные, ни кем не используемые).
Чтобы построить такую статистику нужно знать количество запусков и количество крэшей. Если с последним числом понятно откуда они могли его взять, то откуда они берут количество запусков не очевидно.
Скорее всё же противоречивые (хотя и нечёткие тоже). Дело в том, что скорость точки на ободе колеса может совпадать со скоростью точки на ленте только в случае когда самолёт неподвижен относительно платформы (и воздуха). Это легко доказать: если самолёт неподвижен относительно платформы, с какой бы скоростью не двигалась лента скорости точек на ободе и ленте равны. Если самолёт двигается относительно платформы, скорость на ободе равна:
V_колеса = V_ленты + Pi*D_колеса*V_самолёта
Но в условиях делается предположение что лента чудесным образом самоподстраивается, т.е. вышеуказанное уравнение имеет решение при V_самолёта != 0 и V_колеса = V_ленты.
Предпологая что диаметр колеса не равен нулю, попробуем решить уравнение, обозначим:
V_колеса = V_ленты = V
Pi*D_колеса*V_самолёта = K
V = V + K, K != 0
=> 0 = K
Допустим что бога нет, тогда количество богов равно нулю. Но, 0 = K, а K != 0 => бог есть.
Правильный ответ: «как хочешь». Т.к. Задача содержит противоречивые условия, из неё можно сделать какие угодно выводы, можно даже доказать что бог есть.
Это перл конечно: Единственный минус в случае с JS — это слабая типизация. Которая к прототипам не имеет отношения вообще.
Как вы представляете себе язык со статической типизацией и возможностью динамически менять прототип? Такое можно сделать конечно, даже на с++, только тогда статическая типизация никак не поможет работать с таким объектом.
Ну нет, мы говорили о гарантиях. Ну да ладно, соглашусь с вами что: «Любые другие манипуляции с прототипом объекта не меняют контракт на этот объект, ожидаемый в функциях».
Это так, потому что никакого контракта нет, и любые манипуляции с прототипом не приведут к его появлению.
Проверка на наличие методов во время исполнения это не контракт, а ещё один способ ветвления кода, и ещё один способ создавать трудно находимые ошибки.
Контракт не позволяет использовать ваш код неправильным образом, указывая на ошибки до того как программа будет запущена. Этого в JS нет, в Java есть.
Ну и ваш пример:
fun(new OtherPoint(10)); // оппа
Какая оппа? Если не ошибаюсь то «int» это value_type и не может быть null. Если ошибаюсь, то создатель интерфейса ясно дал понять что это значение может быть не актуальным и его надо проверять перед использованием, значит накосячили вы в функции fun() не проверив значение или не поймав исключение.
Интуитивно я понимаю чем модуль отличается от простого включения текста файла в другой файл, но, возможно есть другие обязательные черты, вроде обязательного наличия конструкторов модулей?
Про js написано что «там ужастный GC». Ну так, никто и не обещает его бысторой работы, обещают правильную. Добро пожаловать в web :)
Напомню, изначально говорилось, про то что Opera и IE не поддерживают в JS в той мере, в какой его поддерживает Chrome, при этом в укор ставилось что они не поддерживают фичи ещё не введённые в стандарт. Я уею дорогая редакция.
2) ES.Next (это который Harmony?) как бы ещё в разработке, его никто не обязан поддерживать. Поправьте если ошибаюсь.
3) Если верить wiki en.wikipedia.org/wiki/ECMAScript см. «Conformance tests», то у Оперы как раз всё очень хорошо.
Хороший вброc.
V_колеса = V_ленты + Pi*D_колеса*V_самолёта
Но в условиях делается предположение что лента чудесным образом самоподстраивается, т.е. вышеуказанное уравнение имеет решение при V_самолёта != 0 и V_колеса = V_ленты.
Предпологая что диаметр колеса не равен нулю, попробуем решить уравнение, обозначим:
V_колеса = V_ленты = V
Pi*D_колеса*V_самолёта = K
V = V + K, K != 0
=> 0 = K
Допустим что бога нет, тогда количество богов равно нулю. Но, 0 = K, а K != 0 => бог есть.
При правильном проектировании лихое приведение типов никому видно не будет.
Другое дело ошибки: никто не обещает что их совсем не будет, но очень многие из них можно отловить с помощью системы типов.
Единственный минус в случае с JS — это слабая типизация. Которая к прототипам не имеет отношения вообще.
Как вы представляете себе язык со статической типизацией и возможностью динамически менять прототип? Такое можно сделать конечно, даже на с++, только тогда статическая типизация никак не поможет работать с таким объектом.
Это так, потому что никакого контракта нет, и любые манипуляции с прототипом не приведут к его появлению.
Проверка на наличие методов во время исполнения это не контракт, а ещё один способ ветвления кода, и ещё один способ создавать трудно находимые ошибки.
Контракт не позволяет использовать ваш код неправильным образом, указывая на ошибки до того как программа будет запущена. Этого в JS нет, в Java есть.
Ну и ваш пример:
fun(new OtherPoint(10)); // оппа
Какая оппа? Если не ошибаюсь то «int» это value_type и не может быть null. Если ошибаюсь, то создатель интерфейса ясно дал понять что это значение может быть не актуальным и его надо проверять перед использованием, значит накосячили вы в функции fun() не проверив значение или не поймав исключение.