История изменений

Почему запрос среди разработчиков есть, но не нужно?

В первых версия JS оператор == работал, как ===,то есть делал строгое сравнение без приведения типов. Угадай, почему это изменили? Потому что это попросили сами разработчики, о которых ты говоришь. Айк был сильно против. То же самое касается множества иных артефактов в языке. Но ввиду того, что тогда не было еще ни коммитетов, ни бюррократии, и все решения принимались с плеча, без какого-либо рисчерча, а сама ЦА этих разработчиков были лишь штатные программисты несткейпа - вышло то, что вышло.

Нет никакого запроса. Это как с оппозицей - есть лишь громкое меньшинство, которое по факту ничтожно.

Касательно статической типизации, каждый такой пропозал начинатся с одного и того же, перетекает в один и тот же рисерч, а заканчивается одни и тем же ВНЕЗАПНЫМ осознанием - это не будет работать (если буквально - оверхед будет неимоверным).

JS - это динамическая объктная система. Здесь нельзя отделить компайл-тайм от райнтама. Куски кода подгружаются динамически. У любого типа структура и поведение может поменяться с течением времени. Нельзя ни закешировать статические проверки и ни точно сказать, что если сейчас типы не валидны, они не окажутся валидными при следующем вызове. JIT в современных движках несет с собой регулярную проверку на возможную деградацию скомпилированного кода, при этом количество триггеров для такой деградации в данный момент минимально, потому как даже внезапно исчезнувшие поля у объектов или их изменившийся тип - это валидное поведение. В случае развесистой системы статических типов полноценный тайпчек должен будет проводиться фактически при каждом вызове, проверяя полностью все шейпы объектов, по всей цепочке прототипов, в том числе Проксированных, каждого значения в каждой незначительной лямбде.

Почему запрос среди разработчиков есть, но не нужно?

В первых версия JS оператор == работал, как ===,то есть делал строгое сравнение без приведения типов. Угадай, почему это изменили? Потому что это попросили сами разработчики, о которых ты говоришь. Айк был сильно против. То же самое касается множества иных артефактов в языке. Но ввиду того, что тогда не было еще ни коммитетов, ни бюррократии, и все решения принимались с плеча, без какого-либо рисчерча, а сама ЦА этих разработчиков были лишь штатные программисты несткейпа - вышло то, что вышло.

Нет никакого запроса. Это как с оппозицей - есть лишь громкое меньшинство, которое по факту ничтожно.

Касательно статической типизации, каждый такой пропозал начинатся с одного и того же, перетекает в один и тот же рисерч, а заканчивается одни и тем же ВНЕЗАПНЫМ осознанием - это не будет работать (если буквально - оверхед будет неимоверным).

JS - это динамическая объктная система. Здесь нельзя отделить компайл-тайм от райнтама. Куски кода подгружаются динамически. У любого типа структура и поведение может поменяться с течением времени. Нельзя ни закешировать статические проверки и ни точно сказать, что если сейчас типы не валидны, они не окажутся валидными при следующем вызове. JIT в современных движках несет с собой регулярную проверку на возможную деградацию скомпилированного кода, при этом количество триггеров для такой деградации в данный момент минимально, потому как даже внезапно исчезнувшие поля у объектов или их изменившийся тип - это валидное поведение. В случае развесистой системы статических типов полноценный тайпчек должен будет проводиться фактически при каждом вызове, проверяя полностью все шейпы объектов, о всей цепочке прототипов, в том числе Проксированных, каждого значения в каждой незначительной лямбде.

Почему запрос среди разработчиков есть, но не нужно?

В первых версия JS оператор == работал, как ===,то есть делал строгое сравнение без приведения типов. Угадай, почему это изменили? Потому что это попросили сами разработчики, о которых ты говоришь. Айк был сильно против. То же самое касается множества иных артефактов в языке. Но ввиду того, что тогда не было еще ни коммитетов, ни бюррократии, и все решения принимались с плеча, без какого-либо рисчерча, а сама ЦА этих разработчиков были лишь штатные программисты несткейпа - вышло то, что вышло.

Нет никакого запроса. Это как с оппозицей - есть лишь громкое меньшинство, которое по факту ничтожно.

Касательно статической типизации, каждый такой пропозал начинатся с одного и того же, перетекает в один и тот же рисерч, а заканчивается одни и тем же ВНЕЗАПНЫМ осознанием - это не будет работать (если буквально - оверхед будет неимоверным).

JS - это динамическая объктная система. Здесь нельзя отделить компайл-тайм от райнтама. Куски кода подгружаются динамически. У любого типа структура и поведение может поменяться с течением времени. Нельзя ни закешировать статические проверки и ни точно сказать, что если сейчас типы не валидны, они не окажутся валидными при следующем вызове. JIT в современных движках несет с собой регулярную проверку на возможную деградацию скомпилированного кода, при этом количество триггеров для такой деградации в данный момент минимально, потому как даже внезапно исчезнувшие поля у объектов или их изменившийся тип - это валидное поведение. В случае развесистой системы статических типов полноценный тайпчек должен будет проводиться фактически при каждом вызове, проверяя полностью все шейпы объектов, каждого значения в каждой незначительной лямбде.

Почему запрос среди разработчиков есть, но не нужно?

В первых версия JS оператор == работал, как ===,то есть делал строгое сравнение. Угадай, почему это изменили? Потому что это попросили сами разработчики, о которых ты говоришь. Айк был сильно против. То же самое касается множества иных артефактов в языке. Но ввиду того, что тогда не было еще ни коммитетов, ни бюррократии, и все решения принимались с плеча, без какого-либо рисчерча, а сама ЦА этих разработчиков были лишь штатные программисты несткейпа - вышло то, что вышло.

Нет никакого запроса. Это как с оппозицей - есть лишь громкое меньшинство, которое по факту ничтожно.

Касательно статической типизации, каждый такой пропозал начинатся с одного и того же, перетекает в один и тот же рисерч, а заканчивается одни и тем же ВНЕЗАПНЫМ осознанием - это не будет работать (если буквально - оверхед будет неимоверным).

JS - это динамическая объктная система. Здесь нельзя отделить компайл-тайм от райнтама. Куски кода подгружаются динамически. У любого типа структура и поведение может поменяться с течением времени. Нельзя ни закешировать статические проверки и ни точно сказать, что если сейчас типы не валидны, они не окажутся валидными при следующем вызове. JIT в современных движках несет с собой регулярную проверку на возможную деградацию скомпилированного кода, при этом количество триггеров для такой деградации в данный момент минимально, потому как даже внезапно исчезнувшие поля у объектов или их изменившийся тип - это валидное поведение. В случае развесистой системы статических типов полноценный тайпчек должен будет проводиться фактически при каждом вызове, проверяя полностью все шейпы объектов, каждого значения в каждой незначительной лямбде.

Почему запрос среди разработчиков есть, но не нужно?

В первых версия JS оператор == работал, как ===,то есть делал строгое сравнение. Угадай, почему это изменили? Потому что это попросили сами разработчики, о которых ты говоришь. Айк был сильно против. То же самое каается множества иных артефактов в языке. Но ввиду того, что тогда не было еще ни коммитетов, ни бюррократии, и все решения принимались с плеча, без какого-либо рисчерча, а сама ЦА этих разработчиков были лишь штатные программисты несткейпа.

Нет никакого запроса. Это как с оппозицей - есть лишь громкое меньшинство, которое по факту ничтожно.

Касательно статической типизации, каждый такой пропозал начинатся с одного и того же, перетекает в один и тот же рисерч, а заканчивается одни и тем же ВНЕЗАПНЫМ осознанием - это не будет работать (если буквально - оверхед будет неимоверным).

JS - это динамическая объктная система. Здесь нельзя отделить компайл-тайм от райнтама. Куски кода подгружаются динамически. У любого типа структура и поведение может поменяться с течением времени. Нельзя ни закешировать статические проверки и ни точно сказать, что если сейчас типы не валидны, они не окажутся валидными при следующем вызове. JIT в современных движках несет с собой регулярную проверку на возможную деградацию скомпилированного кода, при этом количество триггеров для такой деградации в данный момент минимально, потому как даже внезапно исчезнувшие поля у объектов или их изменившийся тип - это валидное поведение. В случае развесистой системы статических типов полноценный тайпчек должен будет проводиться фактически при каждом вызове, проверяя полностью все шейпы объектов, каждого значения в каждой незначительной лямбде.