з прикладом фунції add, не узгодив контракт між іменем функції і тілом

Ну банально: трансформація структури даних. Речі типу map/reduce дають тобі певний інструментарій, щоб думати про data flow в термінах трансформацій одної структури в іншу. Тому тобі доводиться мати набір композабельних абстракцій для кожної структури даних. Оскільки, такі абстракції легко тестувати, їх параметри очевидні, то тобі легше знаходити всі едж кейси. Також їх легко реюзати. Також їх легко замапити на бізнес-домен. Як наслідок - менше багів.

Соррі, якщо я сумбурно пишу, просто досить складна тема, коротко не напишеш.

или контракт подрядчика

как я понимаю баг, и собственно, википедия подтверждает

> A software bug is an error, flaw or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.

https://en.wikipedia.org/wiki/Software_bug

Щодо системи типів, я теж не вірю що вона зменшує кількість багів сама по собі. Але мислення типами таки допомагає. Що цікаво, навіть в динамічних мовах.

для меня баг - это неожиданное поведение софта
а когда у тебя что-то там не собралось из-за контрактов - это не баг

> A software bug is an error, flaw or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.

ну вроде "не работает чекбокс" подпадает под это определение.
А почему он не работает – ошибка там в логике или контракт не соблюдён – это уже причина

но вообще да, я согласен, что define bug интересная задача

То что не собралось – это не баг, правильно. Это инструмент для того, чтоб когда собралось, этого неожиданного поведения софта не было.
Убираем инструмент, получаем баг

да, ты прав, в этой ситуации это всё-таки был бы баг 🤔

если нет тайпчека то валится в рантайме undefined is not a function

что в принципе баг, хотя и несоблюдение контракта

да, я согласен что баг более широкое понятие, чем я изначально себе представлял

причем тут можно им манипулировать)
в зависимости от контекста

В том то и дело что я не уверен. Мне кажется нет. Вот потому мне и нужен сенити чек. коллеги этим горят и говорят что без этого никак мы умрем. напоминаю что мы делаем вьюшку которая получает из графкуэль данные и почти не модифицируя их визуализирует. форму например по конфигу строит или список джамшутов выводит

Я бы в этом случае (если всем очень хочется) дал бы "победить" в этом остальным, тк это не слишком важно (было бы слишком важно, например, там бандл сайз был бы очень важен, то это было бы явно). Зато в какой-то другой раз можно сильней продавливать какое-то решение, которое более важное и таким образом соблюдать какой-то баланс решений

сложно конечно сказать, в общем случае рамда это не оверхед, если команда решила использовать потому что так удобнее, возможно так и есть, всем не угодишь. возможно в твоем случае это овер инжиниринг, у каждого свое понимание «простой вьюхи». у продукт овнеров есть понятие «тут работы на пять минут», возможно это тот случай

твит прям в тему - https://twitter.com/maxsparr0w/status/1288420498645319681?s=20

Типа демократия - проголосовали и сделали выбор )
И этот подход, как мне кажется, лучше сбора голосов по чатикам.

+