нормальные по сравнению с чем?

По сравнению с другими продуктами у JetBrains. То есть раст плагин пишет пара человек (или даже один) и он уже на порядок лучше подсказывает и даёт навигацию, чем пайчарм, которому куча лет.

потому что llvm. а плагин к OCaml например беспомощен как младенец, хотя ведь статика тоже?

а как быть продуктивным в скодобазе со скриншота Айрата представляешь?

где там иде к хаскелю? когда завезут?

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

хз, я че-то скептически настроен к hashmap driven development. раньше нормально было, щас че-то захотелось больше

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

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

то есть пайчарм - это "нет иде", а "сносный плагин для хаскеля" - это эргономика и UX? очень интересно получается

У меня, увы, опыта реальных проектов на кложуре или подобном нет, так что точного мнения тоже нет. Clojure.Spec опять же есть.

Речь про то, что "плагин для хаскеля" написанный сплошными костылями, одним чуваком в свободное время, работает на порядок лучше в плане навигации, поиска и рефакторинга, чем пайчарм, который пишет команда чёрт знает сколько лет

@eglyph Элементарный сценарий: ты решил добавить/поменять входные аргументы в существующую функцию, которая используется по всему проекту. Как ты в динамическом языке убедишься, что все использования теперь правильно работают с аргументами?

точно так же, как и в статике: тестами. только тестить мы будем не типы аргументов.

лол. В статике компилятор ошибки кидает, тестов не надо

точно так же, как и в статике: тестами. только тестить мы будем не типы аргументов.

только плз не надо про "скомпилировалось - значит работает"

у тебя нет тестов?

Ну почему. Вот в плюсах сборка бы упала. А в некомпилируемой динамике можно что-то прошляпать и обосраться на проде.

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

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

есть, но они проверяют логику, а не типы

Очевидно, что общего решения на все случаи нет.

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

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

Очевидно, что нужно пользоваться по возможности как можно большим числом инструментов не допустить факапа на бою.

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

ну где ты раньше был-то?

бля, ну ты угараешь что ли? Тебе надо убедиться, что в обновленную функцию передаются правильные аргументы. Как ты сделаешь это в динамике?

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

Так тут же та же история, что и c иерархией тестов. Тебе важно поймать наибольшее число ошибок наиболее дешевыми тестами. Компилятор - это по сути ещё один слой тестов под юнит тестами, который ловит достаточное число ошибок автоматом за небольшую цену.

никак не делаю, это дефолтное поведение - падать при нарушении type soundness

как показывает исследование выше, он практически ничего не ловит

потому что соответствие статической системе типов никак не равно корректности поведения

т.е. в статике это упадет на стадии компиляции, а в динамике в рантайме. И ты хочешь мне сказать, что бонусов от статики нет? И что команда напишет "так же хорошо"?

ну если ты не тестируешь код - то да, упадет в рантайме на проде. а в практических условиях он упадет на юнит-тестах, которые, внезапно, ты и в статике напишешь

это отдельный вопрос

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

на что "на это"? никто не пишет тесты на проверку типов аргументов в динамике, не понимаю откуда вы это взяли

Ооо static vs dynamic срач,ололо

Речь тут про другое. Речь про то, как в динамике надежно найти все вызовы данного метода.

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

не, дело не в типизации. дело в том, что моделирование на словарях и методах не скейлится выше определенного уровня.

Вопрос, насколько я понял, был к этому

Написал код @ Коноплятор сказал, что ты вот тут обосрался с логикой @ Пошёл исправлять

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

Не знаю, у меня нет рефлексии и позднего связывания.

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