Да, но это уже другой язык получается! Нафига наворачивать эти костыли там где их изначально не планировалось. Вот если бы это в стандарт языка включили и было бы что то типа: на те типизацию, хошь пользуйся хошь не пользуйся, тогда другое дело.
Что ну вот? А если модуль без аннотаций? Аннотировать? Или искать модули только с аннотациями, либо же железный аргумент из коммерческой брошюры: «На TypeScript портировано уже все что возможно и даже некоторое из того что в принципе еще не написано а будет написано только через 3 — 4 года».
Светлана Владимировна: Сергей, задержитесь.
Застыв от неожиданности, Сергей чуть не выронил бумажки из рук. Но взял себя в руки, вернулся на тот же стул, сложил руки на столе. Крупный план на руки трясущиеся руки Сергея. За кадром мы слышим шаги Светланы Владимировны.
Средний план, Светлана Владимировна стоит у двери, мы видим ее спину, слышим звук поворачиваемого в замке ключа.
Светлана Владимировна: Сережа, я хотела лишь сказать.
Камера отъезжает назад и мы видим всю комнату целиком.
Сергей: Света я понимаю…
В этот момент раздается страшный треск и дверь выбитая снаружи с грохотом, искрами и дымом падает и прихлопывает Светлану Владимировну — раскатывая ту буквально в блин.
Крупный план на Сергея, он в ужасе, лицо забрызгано кровью.
Крупный план на дверь в дыму. Дым рассеивается и за дверью мы видим КомДира с пулеметом, Марину с гранатометом муха и Татьяну увешенную пулеметными лентами, они злобно улыбаются.
Кадр застывает. Звучит музыка. На экране появляются крупные красные буквы «Корпоративный синдром»
А до TypeScriptа были (и есть) гугловые type — annotations и GCC эту тему тоже решал. А что если я хочу чтобы функция принимала аргументы двух различных типов? Писать две функции с одинаковым именем и перегрузкой по типу аргументов? А что если я хочу чтобы моя функция принимала на вход в качестве аргумента массив массивов — элементами которых являются лишь объекты содержащие в себе строго определенный набор полей? Это тип или еще не тип?
У меня вот к примеру мечта это что нибудь настолько близкое к железу как си но без ручного управления памяти и без сборки мусора, да все чот времени не хватает сделать, а то бы я уже давно )
Так и запилите! Соберите в кучу все, что вы хотели бы реализовать и создайте на основе своих желаний новый язык программирования, который решал бы кажущиеся вам и другим разработчикам, критичными проблемы. Будет круто!
<сарказм>
Третий выпуск назывался «Думаю атомы могли бы быть и побольше, а то их сложно заметить в микроскопе, 10 вопросов физику Карлсбадского технологического университета», но рукопись потерялась.
</сарказм>
Да нееее, запретить делать 1 + '1' в этом вообще никакой проблемы нет, такое можно выловить еще на этапе парсинга, это все фигня, проблемы начинаются когда у нас вместо 1 — переменная уходящая в кусок кода подгруженный хз откуда, а вместо '1' вызов пользовательской функции которая в зависимости от фазы луны может выдать или строку или булеан.
Интересно! А что является критерием нахождения языка в топе? Количество софта который на нем написан? Количество программистов пишущих на нем или же общее значение той или иной разработки (имею ввиду разницу между переключалкой раскладкой клавиатуры на WinAPI и каким нибудь банковским ПО на фортране))?
Ну так работа с памятью в С — это важный его атрибут, как языка, ориентированного на высокую производительность.
Именно! Это не баг, не странный баг, не недокументированная особенность — это просто то как оно есть, а вот вопрос нравится это вам или нет — это уже дело сугубо личное. Не думаю, что человека, который позиционирует себя как разработчика на C, при приеме на работу оценили бы по достоинству если бы он назвал работу с памятью — лишним не нужным никому геммороем.
А отсутствие type-checking в JavaScript какую пользу приносит? Дело ведь не в том, что я хочу type-checking, дело в том, что я мог бы безболезненно его получить ( как минимум я не вижу препятствий ). По мне так это просто самый лютый факап разработчиков языка))
Изначально ES задумывался как интерпретируемый язык программирования (не берем в учет то как его обрабатывают современные JS движки c их JIT'ами и оптимизациями), так вот при такой схеме, иногда бывает весьма сложно (если не невозможно) понять какого конкретно типа значение является операндом того же арифметического выражения. 1 + '1' это очень простой пример, возьмем ситуацию когда вместо литералов у нас переменные:
var left = 1;
var right = '1';
var result = left + right;
Тут нужно уже прогнать весь код через проверку типов для того чтобы понять что за тип у left и right, для того чтобы в итоге проверить существует ли возможность применить оператор "+" к данным типам данных. А что если одна из переменных объявлена за пределами модуля в котором выполняется выражение? Прогнать и этот модуль, а что если этот модуль загружен извне? Загрузить его и прогнать? А что если этот модуль нами не управляется? Благодаря всем этим «а что» и «а если», мы получаем существенный удар по производительности (если говорим о проверке типов в рантайме), если же такую проверку производить до рантайма, то нам нужно скачивать вообще все что имеет отношение к нашему приложению, что в свою очередь не есть плохо или хорошо, просто это уже превращается в другой язык программирования.
Светлана Владимировна: Сергей, задержитесь.
Застыв от неожиданности, Сергей чуть не выронил бумажки из рук. Но взял себя в руки, вернулся на тот же стул, сложил руки на столе. Крупный план на руки трясущиеся руки Сергея. За кадром мы слышим шаги Светланы Владимировны.
Средний план, Светлана Владимировна стоит у двери, мы видим ее спину, слышим звук поворачиваемого в замке ключа.
Светлана Владимировна: Сережа, я хотела лишь сказать.
Камера отъезжает назад и мы видим всю комнату целиком.
Сергей: Света я понимаю…
В этот момент раздается страшный треск и дверь выбитая снаружи с грохотом, искрами и дымом падает и прихлопывает Светлану Владимировну — раскатывая ту буквально в блин.
Крупный план на Сергея, он в ужасе, лицо забрызгано кровью.
Крупный план на дверь в дыму. Дым рассеивается и за дверью мы видим КомДира с пулеметом, Марину с гранатометом муха и Татьяну увешенную пулеметными лентами, они злобно улыбаются.
Кадр застывает. Звучит музыка. На экране появляются крупные красные буквы «Корпоративный синдром»
Третий выпуск назывался «Думаю атомы могли бы быть и побольше, а то их сложно заметить в микроскопе, 10 вопросов физику Карлсбадского технологического университета», но рукопись потерялась.
</сарказм>
Да блин, нет у JS никакого компилятора, он интерпретируемый!
Изначально ES задумывался как интерпретируемый язык программирования (не берем в учет то как его обрабатывают современные JS движки c их JIT'ами и оптимизациями), так вот при такой схеме, иногда бывает весьма сложно (если не невозможно) понять какого конкретно типа значение является операндом того же арифметического выражения. 1 + '1' это очень простой пример, возьмем ситуацию когда вместо литералов у нас переменные:
Тут нужно уже прогнать весь код через проверку типов для того чтобы понять что за тип у left и right, для того чтобы в итоге проверить существует ли возможность применить оператор "+" к данным типам данных. А что если одна из переменных объявлена за пределами модуля в котором выполняется выражение? Прогнать и этот модуль, а что если этот модуль загружен извне? Загрузить его и прогнать? А что если этот модуль нами не управляется? Благодаря всем этим «а что» и «а если», мы получаем существенный удар по производительности (если говорим о проверке типов в рантайме), если же такую проверку производить до рантайма, то нам нужно скачивать вообще все что имеет отношение к нашему приложению, что в свою очередь не есть плохо или хорошо, просто это уже превращается в другой язык программирования.