То есть Вас удовлетворит, к примеру, tan(sqrt(pi^2)) = 1.45291e-16 (число от балды, лишь бы примерно порядок соблюсти)? Тогда что Вы имели в виду под "гарантиями" в самом начале? А то, что тест запросто может не пройти, — факт из практики: в Ruby Math::tan(Math::sqrt(Math::PI * Math::PI)) == -1.2246467991473532e-16 (в версии 1.92, по крайней мере, с которой я работал).
Я всего лишь пытался сказать, что независимо от типизации гарантировать равенство нулю вещественного числа (а тангенс даже целочисленного аргумента, измеренного в градусах, всё-таки не целочисленный) можно только при условии, что этот случай был закоден явно. В любом другом случае нас ждут ошибки округления и прочие весёлости. А если он закоден явно, то у нас де-факто и так есть система типов, только реализованная через прямые проверки. И возвращаясь к изначальному вопросу — как Вы предлагаете писать тест, который проверит, что tan(sqrt(pi^2)) = 0?
Если градусы у нас — целочисленная переменная, то это в крайнем случае можно и таблицей значений выдать (и, да, если совсем упороться — вписать её в систему типов). Если вещественная — опять упираемся в проблему сравнения на равенство чисел с плавающей точкой.
Подсмотренная где-то байка про то, как простая текстовая замена "Злей" => "Снейп" (или какая-то подобная) затронула фразу "Злейшему врагу не пожелаешь". Я к чему: Вы как имена заменяли? Именно что простой заменой, по целому слову, во всех возможных вариантах, или как-то более сложно?
даёт ли гарантии, что для пи в квадрате значение будет 0?
А что вообще даёт такие гарантии (учитывая непредставимость пи в виде любого машинного числа), кроме чисто символьных вычислений? А их в типах вполне можно выразить, просто это самое пи будет подтипом числа, а функции — операциями на типах.
В Rust для этого есть impl Trait и Box<dyn Trait>. Как раз для примера из коммента от 0xd34df00d, когда мы не знаем, что за сущность нам пришлют, но знаем, что она будет уметь некоторую нужную нам функциональность.
В случае достаточно компактного кода — не спорю. Сам писал небольшую строкодробилку на Ruby (извлекал нужные мне данные из LaTeX-овского документа), после того, как задолбался обходить различные краевые случаи в коде на C, и от динамической типизации не сильно страдал. И соглашусь, что в названном вами случае статика действительно может быть излишней. Если же код достаточно большой, а внешняя среда в него попадает через ограниченный интерфейс — вполне логично будет всё вне этого интерфейса типизировать статически, а его самого — валидировать для соответствия этим типам.
То, о чём пишете вы, — не динамическая, а слабая типизация. Динамическая — это когда можно написать let x = 1; processNumber(x); x = 'string'; processString(x); и не выворачивать себе мозг из-за того, что переменная x должна иметь разный тип в разных местах кода.
Не знаю насчёт «общего назначения», но, когда я увидел, как можно вывернуть наизнанку код на Ruby, вмонтированный в RPG Maker (обычный Ruby, только немного урезанный), мысли были в общем и целом схожие.
Это — одно проблемное место во всей кодовой базе. Объект, вышедший из-под JSON.parse<someInterface>, в дальнейшем обрабатывается с учётом всех статических типов. В то время как в динамически типизированном языке он так и останется "чем-то, определённым в рантайме".
В статье же упоминался лифт, специально рассчитанный на пожарных. Вероятно, и часть эвакуации на нём тоже проводится.
Big Hugging Gun же ж.
(Сначала напечатал Bug, подумал, что так даже лучше)
То есть Вас удовлетворит, к примеру, tan(sqrt(pi^2)) = 1.45291e-16 (число от балды, лишь бы примерно порядок соблюсти)? Тогда что Вы имели в виду под "гарантиями" в самом начале? А то, что тест запросто может не пройти, — факт из практики: в Ruby
Math::tan(Math::sqrt(Math::PI * Math::PI)) == -1.2246467991473532e-16(в версии 1.92, по крайней мере, с которой я работал).Подсмотренная где-то байка про то, как простая текстовая замена "Злей" => "Снейп" (или какая-то подобная) затронула фразу "Злейшему врагу не пожелаешь". Я к чему: Вы как имена заменяли? Именно что простой заменой, по целому слову, во всех возможных вариантах, или как-то более сложно?
"Снейпшего врага", надеюсь, не появилось?
А что вообще даёт такие гарантии (учитывая непредставимость пи в виде любого машинного числа), кроме чисто символьных вычислений? А их в типах вполне можно выразить, просто это самое пи будет подтипом числа, а функции — операциями на типах.
Я ж надеюсь, Вы не про этот Zombie?..
В Rust для этого есть
impl TraitиBox<dyn Trait>. Как раз для примера из коммента от 0xd34df00d, когда мы не знаем, что за сущность нам пришлют, но знаем, что она будет уметь некоторую нужную нам функциональность.То, о чём пишете вы, — не динамическая, а слабая типизация. Динамическая — это когда можно написать
let x = 1; processNumber(x); x = 'string'; processString(x);и не выворачивать себе мозг из-за того, что переменнаяxдолжна иметь разный тип в разных местах кода.Это — одно проблемное место во всей кодовой базе. Объект, вышедший из-под
JSON.parse<someInterface>, в дальнейшем обрабатывается с учётом всех статических типов. В то время как в динамически типизированном языке он так и останется "чем-то, определённым в рантайме".