Alexander
Нету такой задачи - чтобы компилятор код писал. Это прогоаммист придумал. А есть задачи предметной области.
Anonymous
Хотите typed holes –– типы.
Anonymous
🙂
Denis
когда тайпклассами пользуетесь - вам компилятор код пишет, подбирая функции
Alexander
И статические проверки тоже - придумал программист. Ему показалось, что ошибки надо поисключать, и давай для этого вносить неоправданную сложность в проект. Хотя, может, ту же задачу проще и много понятнее было можно тестами решить.
Aliester
да и языки высокого уровня тоже программисты придумали
Denis
дженерики в духе sop опять же для того, чтобы код не программист писал
Aliester
не хотят ироды на асемблере код писать по проекту на архитектуру
Denis
Разумеется, программист сидит и думает как ему внести побольше сложности в свой проект, ему же с ним работать! Отличный аргумент!
Alexander
блин библиотеки bos зло :/
Andrei
не хотят ироды на асемблере код писать по проекту на архитектуру
или сишечьке православной, миллионами человеко-часов и миллиардами денег осиянной (не то, чтобы в коня корм пошёл, но они стараются!)
Alexander
а не, не зло, в последних версиях он одумался (или не автор уже)
Denis
он вроде уже ничего не мейнтейнит толком
Alexander
Разумеется, программист сидит и думает как ему внести побольше сложности в свой проект, ему же с ним работать! Отличный аргумент!
Как ни удивительно, программистам нужны старшие товарищи, тимлиды. Потому что этим ребятам хочется с технологиями поиграться, не думая о том, как другие будут потом с этим кодом работать. У плюсовиков по молодости тоже такое в точности бывает: повальное увлечение шаблонами. Только поговорка не на пустом месте родилась, что как только такой талант увольняется, приходится его код переписывать. Тратить большие ресурсы просто потому, что человек про будущую поддерживаемость кода вообще не думает.
Alexander
он вроде уже ничего не мейнтейнит толком
но при этом может отдать код только проверенным меинтейнерам
Alexander
Но если плюсовики вылечиваются со временем, то у хаскеллистов этот вид недуга вообще имеет тенденцию к ухудшению.
Alexander
аргумент, наверное в том, что плохо делать так чтобы bus factor был близок к 1
Denis
потому что спич о какой-то произвольной черте, выше которой все сложно и комплексити
Alexander
Я не понимаю в чем аргумент заключается. В том что все что вам непонятно плохо?
Нет, что есть цена, и ее надо плнимать. А в целом это и приводит к тому, что хаскельное сообщество не растет толком.
Alexander
*понимать
Alexander
причем где 1 относится к любому человеку из продвинутых в команде
Denis
bus factor ортогонален typeful дизайну
Denis
я же выше говорил, если команде нормально, то все в порядке
Alexander
и при том что введение нового человека может быть дорого
Alexander
с haskell наверное одна из важнейших
Denis
это наистандартнейшая метрика
Denis
я не согласен с тем что с haskell важнее
Denis
возьми какой-нибудь скриптовый язык
Denis
там bus factor == 1 еще хуже
Anonymous
Ребят, а кстати как сейчас у ghc обстоят дела с typed holes? Ещё не так круто как в Агде? Поддержку в емакс не завезли?
Alexander
это наистандартнейшая метрика
Ну что сказать, нельзя знать всего. Пойду гуглить про метрику
Anonymous
Я слоупок просто
Denis
код становится вообще иммутабельным
Alexander
это да
Denis
Ну что сказать, нельзя знать всего. Пойду гуглить про метрику
bus factor - количество человек, которое должно попасть под автобус, чтобы не осталось никого, кто понимает как работает
Alexander
но в общем скорее всего смысл утверждений в том, что неожиданно на ровном месте человеку становится сложно разбираться
Denis
поэтому любые решения хороши, если команда в них сечет
Alexander
в итоге возрастает или уровень требуемый от соискателей или цена введения нового человека
Denis
ну это то безусловно
Denis
но typeful дизайн обычно дает какие-то бенефиты, позволяет убрать какие-то классы распостраненных ошибок
Denis
или дает более общий код
Anonymous
Denis
тут надо оценивать плюс подхода против его минусов в каждом конкретном случае
Denis
у меня есть отличный пример из нашей кодобазы
Alexander
accidental - тут конечно субьективно, но в целом насколько много решает по сравнению с тем насколько хуже писать код
Alexander
спорить там тяжело, особенно не видя кодобазы друг друга
Alexander
тут надо оценивать плюс подхода против его минусов в каждом конкретном случае
Разве есть что-то важнее поддерживаемости и понятности кода? Кроме его корректности (может даже неполной), что подразумевается
Alexander
мало ли чего там в Касперском (если я прав) или IOHK начудили
Alexander
ну типы <-> корректность
Denis
в общем у нас мозгодрыжни всякие штуки используются, но валюту в типе денежных значений мы не осилили
Denis
т.к. цена слишком высока
Alexander
мало ли чего там в Касперском (если я прав) или IOHK начудили
Я без понятия, я не видел их код и не работал с этими ребятами. Ксати, они есть в чате?
Denis
при этом что-то совершенно чудовищное на вид, вроде schematic, юзается повсеместно
Alexander
@cblp_su - Касперский, и большая часть Serokell тут есть
Denis
Разве есть что-то важнее поддерживаемости и понятности кода? Кроме его корректности (может даже неполной), что подразумевается
разные дизайны ведут к разной степени(вероятности, скорее) корректности, в этом и поинт разных решений
Alexander
хотя может и не большая, но человека 4 было
Alexander
@cblp_su - Касперский, и большая часть Serokell тут есть
Про Serokell ничего не знаю :( И почему о них говорят, тоже
Alexander
Serokell ~= IOHK
Alexander
это разные фирмы, но Serokell пишут очень много (весь) Haskell код
Denis
serokell ⊂ iohk
Denis
я починил
Cheese
ничего мы не чудили
Alexander
разные дизайны ведут к разной степени(вероятности, скорее) корректности, в этом и поинт разных решений
Но корректность кода не стоит на первом месте в дизайне ПО. На первом месте стоит уменьшение accidental complexity, тем более если essential complexity, неотъемлемая от предметной области, высока сама по себе.
Alexander
сделать accidental complexity объективной метрикой тяжело
Denis
Но корректность кода не стоит на первом месте в дизайне ПО. На первом месте стоит уменьшение accidental complexity, тем более если essential complexity, неотъемлемая от предметной области, высока сама по себе.
С какой стати такие обобщения? Мне бы не хотелось жить в мире, где у медицинского оборудования и софта корректность не была бы на первом месте. Также я не фанат поломанного софта в космонавтике и авиации, self-driving cars, дронах, финансах etc
Denis
оказывается что дофига всего нуждается в корректном софте
Denis
насколько это важно для каждого конкретного проекта - вопрос
Alexander
ой не парься, в мед софте проблемы начиная с физ модейлей бывают
Denis
на самолетах тоже не летайте кстати
Denis
и в больницы не ходите
Alexander
сделать accidental complexity объективной метрикой тяжело
Объективных метрик, конечно, здесь не придумать. Или если придумать, то получится какая-нибудь "цикломатическая сложность". Но нужно стремиться к тому, чтобы код бизнес-сценариев был понятен тем, кто работает с предметной областью.
Denis
я никогда не забуду как тулинг мне мерял цикломатическую сложность по количеству веток в case
Denis
чем больше веток, тем выше сложность была!
Denis
надо в отдельную функцию выделять, говорит!
Denis
А в процентах сколько такого софта? Супротив внб-сервисов, корпоративного ПО, и прочих сайтиков?
я к тому что это все вдумчивого разбора требует для конкретного случая. Я вполне представляю ситуацию где в проекте 1% критичнейшего кода, где ошибка очень дорогая и 99% всего остального.
Denis
поэтому и дизайн этих частей логично представлять разным