> расстояние и в метрах и в километрах - числа с плавающей запятой..
> решит ли проверка типа проблему ?Нет, километры и километры -- это не числа с плавающей запятой. Это километры и метры. И это решает пробелму.
> Самое забавное, что наилютейший гомнокод в жс получается бывших проггеров на жабе/шарпе
> или плюсах и, да, без типизации оно практически нечитаемо и неподдерживаемо.
Нет. Если проггер не умеет программировать -- он сделает говно на любом языке. Но на статически строго типизированном языке -- говна будет немного меньше, а на яваскрипте -- это будет первосортное говно.
> Попадались такие проекты. Они и с типами то нередко неподдерживаемые:
> Чего, казалось бы, проще, запилить простую асинхронную функцию-помощник для обращения
> к бэкенду, функция навешивает нужные заголовки на запрос, генерирует адрес на
> основе хоста и проч, форматирует тело запроса, выдаёт стандартный вывод в
> т.ч если запрос падает.
Нет. Это не просто. Асинхронщина имеет тонны побочных эффектов. С асинхроном надо уметь работать (нет, это не кодить).
> Однако, с полтора десятка файлов, разбросанных по всему проекту со вложенностью порядка
> восьми( каталог -> каталог -> итд ), каждый являет собой свой
> класс, наследуется от предыдущего, в своём составе имеет экземпляры других классов,
> каждый - на многие сотни строк кода.
Вы только что описали проблемы сочинённых языков (т.е. нарисованы художниками, а не сконструированы инженерами).
> Хост, промежуточные фрагменты адреса, структура тела запроса итд разбросаны по всему этому,
> что тупо не разобрать итоговый адрес и тело запроса к бэкенду
> без навешивания тонн выводов в консоль или пошаговой отладки.
Ещё раз тезис о сочинительстве.
> Будто этого мало, самые начальные элементы импортируются из настроек, ведь на основе
> этого шаблонного, не работающего проекта генерируется НЕСКОЛЬКО проектов с разным функционалом(
> только истинный гений до такого додумался бы ), разумеется, с многоэтапной
> генерацией, ломающейся почти при каждом обновлении пакетов и с первого раза
> на новой машине вообще не отрабатывающей до конца, обычно день-два надо
> было чтобы оживить.
Управление зависимостями. Опять отсутствие инженерного подхода.
> Самое забавное, что авторизация периодически отваливалась - где-то что-то не так было
> с автообновлением ключей, запросы иногда падали, но ни сам прогер, ни
> пришедшие за ним, отловить и исправить тот баг так и не
> смогли.
Управление логикой. Опять отсутствие инженерного подхода. Недостаток строгой типизации и контроля ошибок.
> Но, зато всё сверху донизу обмазано типизацией, вообще подчистую, ни единого предупреждения
> по итогам валидации.
Это подход художника. Инженеры так не делают.
> Но проггеры, даже любители ts, на том проекте больше пары недель не
> выдерживали. Запилить подобное осилил бывший проггер на джаве.. только на жс
> запилил как на джаве.. очень был рад, что есть TS без
> которого он бы подобное едва ли смог.
Ещё раз смотрим тезис, про сочиняющих художников. Типизация (на конкретно этом примере) помогла.
> Кстати, кто-то, кто хотя бы минимально прогает на жс, обычно в курсе,
> что за помещение значений разных типов данных( скажем, число и массив
> ) и разных по смыслу в одну и ту же переменную,
> можно запросто получить по башке и так практически не делают
Да, так инженеры не делают. Казалось бы, какое это имеет отношение к типам. как семантике? Километры и метры?
> Хотя при "типизации" ничто не мешает просто добавить соотв пометку к полю
> - и валидатор всё посчитает всё корректным )
Нет. Это решается строгой статической типизацией.
Много слов, #ниачём #нувыпонили.
