Типы-моки можно принудительно кастовать к интерфейсам. А интерфейсы — не испортят.

Но заставить нас писать вам тесты у вас всё равно никак не получится. Не писали и писать не будем.

ЭФ>А в живых надо оставить только адептов доказательного программирования.

Адепты доказательного программирования — это типа вот эти ребята, которые не осилили тесты писать?

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

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

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

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

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

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

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

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

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

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

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

Не взлетит, в тестах типы-моки всё испортят.

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

ЭФ>Но заставить нас писать вам тесты у вас всё равно никак не получится. Не писали и писать не будем.

Расстрелять всех к чёртовой матери

R> Расстрелять всех к чёртовой матери

Расстрелять надо проповедников тестирования.
А в живых надо оставить только адептов доказательного программирования.

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

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

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

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

Не то? https://clojure.org/guides/spec

Ранее мы упоминали, что clojure.spec.test.alpha
предоставляет инструменты для автоматического тестирования функций.
Когда у функций есть спецификации, мы можем использовать проверку,
чтобы автоматически генерировать тесты, которые проверяют функцию
с использованием спецификаций.

R> Адепты доказательного программирования — это типа вот эти ребята, которые не осилили тесты писать?

Разные. Но поскольку расстреливать вы собрались всех, то начнём это делать с проповедников тестирования.

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

R>> Адепты доказательного программирования — это типа вот эти ребята, которые не осилили тесты писать?

ЭФ>Разные. Но поскольку расстреливать вы собрались всех, то начнём это делать с проповедников тестирования.

О, наверно просто контекста не хватило. Я против тех, кто не пишет тесты, прикрываясь теорией. Если кто-то вместо "иди в жопу со своим тестированием" скажет: "иди в жопу со своим тестированием, я сейчас всё на типах выведу" — я только за. Обычно против тестов гонят убогие, которые просто не осилили.

νsb>Как вам такая идея — взлетит?
Зачем такие сложности?
Проще сразу типы писать.
Берем Dart — и пишем

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

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

Так функция и не вызовется с другими типами, если код не менять.
А если код менять, то и типы могут поменяться, и предыдущие типы нам не важны.

Ну и непонятно, что дальше-то что с этими типами делать, какая задача решалась?

Похожий подход используется в тестировании — сравнение результатов предыдущих и последующих запусков (канонизация тестов, сравнение скриншотов).

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

Б>Так функция и не вызовется с другими типами, если код не менять.

Не понял. У нас типы выводятся в момент компиляции файла.

Грубо говоря у нас есть файл, в нём код и в нём же тесты. Мы сначала запускаем интерпретатор, который игнорирует типы. Этот интерпретатор прогоняет все тесты в этом файле и во время каждого вызова функции запоминает типы значений, которые эта функция принимала и возвращала. А также, видимо, типы переменных.

Эта запомненная информация где-то сохраняется и представляет из себя типизированную сигнатуру функции.

Простой пример:

function f(n) {
  let result;
  if (n == 0) {
    result = 1n;
  } else {
    const f1 = f(n - 1);
    result = BigInt(n) * f1;
  }
  return result;
}
tests {
  assert(f(0) == 1);
  assert(f(3) == 6);
}

Тут мы прогнав тесты видим, что функция вызывается с параметром типа number и возвращает BigInt при всех выполнениях. То бишь после выполнения куда-то записывается что-то вроде

function f(n: number): BigInt {
  let result: BigInt;
  if (n == 0) {
    result = 1n;
  } else {
    const f1: BigInt = f(n - 1);
    result = BigInt(n) * f1;
  }
  return result;
}

и теперь её из другого файла нельзя будет вызвать со строкой или null-ом, будет ошибка компиляции.

Наверное можно даже не просто number выводить, а что-то вроде uint8. Или вообще конкретный тип, от 0 до 3 в данном примере. Типа нужен факториал со значениями побольше — пиши тесты на значения побольше.

Б>Ну и непонятно, что дальше-то что с этими типами делать, какая задача решалась?

Проверять при использовании в других файлах.

Тебе надо мотивацию выписать.
Зачем это нужно, и какие преимущества даст.

Программного кода придётся писать больше,
потому что размер тестов больше, чем размер указания типа.
И это плохо. Чем-то это должно компенсироваться.

Чем же?

νsb>Типы объявляются опосредованно, через тесты.
Погодите-ка, это разве не очередная вариация design by contract?

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

Лучше всего сделать кодогенерацию на TS. Вернее заглушки, которые внутри вызывают метод JS

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

ЭФ>Тебе надо мотивацию выписать.
ЭФ>Зачем это нужно, и какие преимущества даст.

ЭФ>Программного кода придётся писать больше,
ЭФ>потому что размер тестов больше, чем размер указания типа.
ЭФ>И это плохо. Чем-то это должно компенсироваться.

ЭФ>Чем же?

Тесты писать всё равно надо. Поэтому в данном случае это влияния не имеет.

Чем хорошо: меньше писанины. А также для уточнения типов придётся писать больше тестов, эдакая мотивация программистам писать тесты на все возможные значения на входе и на выходе.

Чем плохо — пока не знаю. Есть вероятность, что тестов придётся писать слишком много.

Если тесты недетерминированные, то будут недетерминированные типы. Но в принципе это в любом случае нехорошо. Плюс можно тесты сделать детерминированными, убрав любые источники случайности.

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

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

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

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

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

vaa>Не то? https://clojure.org/guides/spec

Здесь по функциям генерируют тесты — это у много кого есть. ТС предлагает по тестам генерировать типы параметров функций (сигнатуры подставлять).

Идея забавная, но утопичная. Хотя, для TypeScript подошла бы, там и так типы держатся на хрупком компиляторе.

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

?sb>Чем плохо — пока не знаю. Есть вероятность, что тестов придётся писать слишком много.
Например тем, что пока всё тестами не покроешь написанное тупо запустить не получится.
Кстати а сами тесты как будут определять что в них куда передавать можно? Курица и йайцо вырисовывается.

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

CC>?sb>Чем плохо — пока не знаю. Есть вероятность, что тестов придётся писать слишком много.
CC>Например тем, что пока всё тестами не покроешь написанное тупо запустить не получится.

Ну и хорошо, test driven development и всё такое.

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

CC>Кстати а сами тесты как будут определять что в них куда передавать можно? Курица и йайцо вырисовывается.

Тесты будут синтаксически встроены в язык и в них будет отключена проверка типов.

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

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

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

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

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

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

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

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

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

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

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

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

ν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>Почему "чем". Тесты писать так и так надо.

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