Здравствуйте, Эйнсток Файр, Вы писали:

νsb>> Тесты писать всё равно надо.

ЭФ>Но не всем надо. Кому-то надо "раз-раз и в продакшен".

Ну кому так надо, тем такой подход, очевидно, не подойдёт.

νsb>> эдакая мотивация программистам писать тесты

ЭФ>Или мотивация выбирать другие инструменты,
ЭФ>которыми проще пользоваться из-за того, что не надо писать тесты.

Популярность TypeScript при всём геморе, который он привносит, говорит, что "проще пользоваться" это не единственная мотивация, которой руководствуются.

Здравствуйте, νsb, Вы писали:

νsb> assert(f(3) == 6);
А что если я в тест добавлю
assert(f("hello") != "world");
Что произойдёт?

Здравствуйте, νsb, Вы писали:

νsb>Популярность TypeScript при всём геморе, который он привносит, говорит, что "проще пользоваться" это не единственная мотивация, которой руководствуются.
Проще как раз пользоваться TypeScript, так как интеллисенс и проверка кода на этапе проектирования перевешивают прочие неудобства.
Говорю как бывший 1С ник.
Да еще в TS мне нравится указать для object ограничение возможных типов

Здравствуйте, νsb, Вы писали:

νsb>Пришла тут в голову забавная на мой взгляд идея. Берём динамически типизированный язык вроде жаваскрипта. Пишем код. Пишем тесты. Прогоняем тесты. И вот тут запоминаются все типы, которые приходили и уходили в функцию. После этого функцию нельзя вызывать с другими типами. Будет ошибка компиляции.

νsb>Я немного сумбурно это расписал, но постарался выразить главную идею. Типы объявляются опосредованно, через тесты.

νsb>Как вам такая идея — взлетит?

Эх, каких только костылей не придумают, лишь бы типы не писать.

Как забавное упражнение для ума — вполне.
В реальности объявить тип явно гораздо проще и быстрее, чем написать тесты, запустить, отладить и проверить их результат (иначе для чего всё это?)
Про то, что читаемость кода, в котором существенная часть информации вынесена куда-то "внаружу", страдает, а количество кода, нуждающегося в поддержке, растет, уж и говорить не приходится.

Здравствуйте, ·, Вы писали:

νsb>> assert(f(3) == 6);
·>А что если я в тест добавлю
·>assert(f("hello") != "world");
·>Что произойдёт?

При выполнении f вылетит ошибка, что нельзя сравнивать строку и число ("hello" == 0). Примерно как в луа. Тест не пройдёт.

Если функция написана так, что этот код работает, значит добавится строковый тип в параметры (и, вероятно, строковый тип в возвращаемое значение).

Здравствуйте, ltc, Вы писали:

ltc>Эх, каких только костылей не придумают, лишь бы типы не писать.

А то.

ltc>В реальности объявить тип явно гораздо проще и быстрее, чем написать тесты, запустить, отладить и проверить их результат (иначе для чего всё это?)

Почему "чем". Тесты писать так и так надо.

ltc>Про то, что читаемость кода, в котором существенная часть информации вынесена куда-то "внаружу", страдает, а количество кода, нуждающегося в поддержке, растет, уж и говорить не приходится.

Это частности. Можешь представить, что компилятор будет редактировать исходники и всовывать типы куда надо. Или в какие-нибудь кеши IDE их сувать, откуда она их буедт показывать. Или в комментарии сувать.

Здравствуйте, ?sb, Вы писали:

CC>>Например тем, что пока всё тестами не покроешь написанное тупо запустить не получится.
?sb>Ну и хорошо, test driven development и всё такое.
Не взлетит.

?sb>Не, можно сделать опцию запуска с отключенной проверкой типов, раз она для тестов в любом случае будет, для дебага тоже может пригодиться.
Она будет включена постоянно

?sb>Тесты будут синтаксически встроены в язык и в них будет отключена проверка типов.
А чем код теста отличается от другого кода?

Здравствуйте, νsb, Вы писали:

ltc>>В реальности объявить тип явно гораздо проще и быстрее, чем написать тесты, запустить, отладить и проверить их результат (иначе для чего всё это?)

νsb>Почему "чем". Тесты писать так и так надо.

Да, но писать надо лишь необходимое и достаточное количество тестов, как и любого другого кода, не больше. А для того, чтобы компенсировать неопределенность касаемо типов, оставленную в коде, придется написать больше тестов. Поэтому сэкономить тут не получится, наоборот суммарно кода больше получится.