а не, не зло, в последних версиях он одумался (или не автор уже)

он вроде уже ничего не мейнтейнит толком

Разумеется, программист сидит и думает как ему внести побольше сложности в свой проект, ему же с ним работать! Отличный аргумент!

Как ни удивительно, программистам нужны старшие товарищи, тимлиды. Потому что этим ребятам хочется с технологиями поиграться, не думая о том, как другие будут потом с этим кодом работать. У плюсовиков по молодости тоже такое в точности бывает: повальное увлечение шаблонами. Только поговорка не на пустом месте родилась, что как только такой талант увольняется, приходится его код переписывать. Тратить большие ресурсы просто потому, что человек про будущую поддерживаемость кода вообще не думает.

он вроде уже ничего не мейнтейнит толком

но при этом может отдать код только проверенным меинтейнерам

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

Как ни удивительно, программистам нужны старшие товарищи, тимлиды. Потому что этим ребятам хочется с технологиями поиграться, не думая о том, как другие будут потом с этим кодом работать. У плюсовиков по молодости тоже такое в точности бывает: повальное увлечение шаблонами. Только поговорка не на пустом месте родилась, что как только такой талант увольняется, приходится его код переписывать. Тратить большие ресурсы просто потому, что человек про будущую поддерживаемость кода вообще не думает.

Я не понимаю в чем аргумент заключается. В том что все что вам непонятно плохо?

аргумент, наверное в том, что плохо делать так чтобы bus factor был близок к 1

потому что спич о какой-то произвольной черте, выше которой все сложно и комплексити

Я не понимаю в чем аргумент заключается. В том что все что вам непонятно плохо?

Нет, что есть цена, и ее надо плнимать. А в целом это и приводит к тому, что хаскельное сообщество не растет толком.

*понимать

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

bus factor ортогонален typeful дизайну

я же выше говорил, если команде нормально, то все в порядке

и при том что введение нового человека может быть дорого

аргумент, наверное в том, что плохо делать так чтобы bus factor был близок к 1

Интересная метрика

с haskell наверное одна из важнейших

это наистандартнейшая метрика

я не согласен с тем что с haskell важнее

возьми какой-нибудь скриптовый язык

там bus factor == 1 еще хуже

Ребят, а кстати как сейчас у ghc обстоят дела с typed holes? Ещё не так круто как в Агде? Поддержку в емакс не завезли?

это наистандартнейшая метрика

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

Я слоупок просто

код становится вообще иммутабельным

это да

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

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

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

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

в итоге возрастает или уровень требуемый от соискателей или цена введения нового человека

ну это то безусловно

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

или дает более общий код

тут надо оценивать плюс подхода против его минусов в каждом конкретном случае

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

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

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

тут надо оценивать плюс подхода против его минусов в каждом конкретном случае

Разве есть что-то важнее поддерживаемости и понятности кода? Кроме его корректности (может даже неполной), что подразумевается

мало ли чего там в Касперском (если я прав) или IOHK начудили

ну типы <-> корректность

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

т.к. цена слишком высока

мало ли чего там в Касперском (если я прав) или IOHK начудили

Я без понятия, я не видел их код и не работал с этими ребятами. Ксати, они есть в чате?

при этом что-то совершенно чудовищное на вид, вроде schematic, юзается повсеместно

@cblp_su - Касперский, и большая часть Serokell тут есть

Разве есть что-то важнее поддерживаемости и понятности кода? Кроме его корректности (может даже неполной), что подразумевается

разные дизайны ведут к разной степени(вероятности, скорее) корректности, в этом и поинт разных решений

хотя может и не большая, но человека 4 было

@cblp_su - Касперский, и большая часть Serokell тут есть

Про Serokell ничего не знаю :( И почему о них говорят, тоже

Serokell ~= IOHK

это разные фирмы, но Serokell пишут очень много (весь) Haskell код

serokell ⊂ iohk

я починил

ничего мы не чудили

разные дизайны ведут к разной степени(вероятности, скорее) корректности, в этом и поинт разных решений

Но корректность кода не стоит на первом месте в дизайне ПО. На первом месте стоит уменьшение accidental complexity, тем более если essential complexity, неотъемлемая от предметной области, высока сама по себе.

сделать accidental complexity объективной метрикой тяжело

Но корректность кода не стоит на первом месте в дизайне ПО. На первом месте стоит уменьшение accidental complexity, тем более если essential complexity, неотъемлемая от предметной области, высока сама по себе.

С какой стати такие обобщения? Мне бы не хотелось жить в мире, где у медицинского оборудования и софта корректность не была бы на первом месте. Также я не фанат поломанного софта в космонавтике и авиации, self-driving cars, дронах, финансах etc

оказывается что дофига всего нуждается в корректном софте

насколько это важно для каждого конкретного проекта - вопрос

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

на самолетах тоже не летайте кстати

и в больницы не ходите

сделать accidental complexity объективной метрикой тяжело

Объективных метрик, конечно, здесь не придумать. Или если придумать, то получится какая-нибудь "цикломатическая сложность". Но нужно стремиться к тому, чтобы код бизнес-сценариев был понятен тем, кто работает с предметной областью.

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

чем больше веток, тем выше сложность была!

С какой стати такие обобщения? Мне бы не хотелось жить в мире, где у медицинского оборудования и софта корректность не была бы на первом месте. Также я не фанат поломанного софта в космонавтике и авиации, self-driving cars, дронах, финансах etc

А в процентах сколько такого софта? Супротив внб-сервисов, корпоративного ПО, и прочих сайтиков?

надо в отдельную функцию выделять, говорит!

А в процентах сколько такого софта? Супротив внб-сервисов, корпоративного ПО, и прочих сайтиков?

я к тому что это все вдумчивого разбора требует для конкретного случая. Я вполне представляю ситуацию где в проекте 1% критичнейшего кода, где ошибка очень дорогая и 99% всего остального.

ERROR: S client not available

поэтому и дизайн этих частей логично представлять разным

поэтому и дизайн этих частей логично представлять разным

Это нормальный подход. Применять то, что нужно, там, где нужно по объективным требованиям предметной области.

хм.. ghc стал перечитывать файл перед выдачей ошибки? действия 1. let unused = () 2. запустисть сборку (стеком) 3. закомментировать: — let unused = () 4. получить error (при -Werror) о неиспользованной переменной unused в строке -- let unused = () закомментированная строка в теле сообщения

у меня вчера похожее было!

только там мне во время тайпчекинга неправильный тип в дырке выводился

когда я его поменял

В плане type level magic нужно разделять: желание создать типобесопасный тулинг (что часто бывает полезным) и желание писать бизнес-логику в типах. Второе - от лукавого.

не вижу причин для справедливости того, что второе утверждение от лукавого

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

не вижу причин для справедливости того, что второе утверждение от лукавого

Считайте частным мнением, потому что пруфов не будет

В плане type level magic нужно разделять: желание создать типобесопасный тулинг (что часто бывает полезным) и желание писать бизнес-логику в типах. Второе - от лукавого.

“Make illegal state unrepresentable” – это бизнес-логика?

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

“Make illegal state unrepresentable” – это бизнес-логика?

Нет, это принцип дизайна, который не имплицирует магию на типах.

читать типы человеку знающему предметную область может быть проще

т.к. в них логики существенно меньше, и нету implementation details

так же оно всегда чекается

читать типы человеку знающему предметную область может быть проще

Это очень зависит от дизайна. Читать типы servant на порядок проще, чем opaleye

дальше уже вопрос, а нужно ли это и что привнесение такой логики принесёт

общего ответа тут уже нету

Просто потому что Servant - это своеобразный, но DSL, а opalyeye... НедоDSL

с большим развесистым API в серванте можно пожалеть что ты на свет родился

удачи при мердже

с большим развесистым API в серванте можно пожалеть что ты на свет родился

Я с этим не спорю. Если бы я выбират технологию, то никакой магии на типах в продакшне у меня бы не было. Простые, кондовые, но понятные решения.

"Понятные" с точки зрения среднестатистического разработчика.

Ну опять. Что такое “среднестатистический разработчик”? Как мне пользоваться этой метрикой?

Заметьте, кстати, разницу. Линзы, - вот уж сложная внутри библиотека, чего только там нет. Но они отличные, их использовать легко. В этом и смысл дизайна. Дизайн компонента не должен вести к тому, чтобы его было трудно использовать.

спорное заявление, мягко говоря

Средний программист, мальчик молодой.

Ну опять. Что такое “среднестатистический разработчик”? Как мне пользоваться этой метрикой?

Это уже другой вопрос. Я бы скащал, что можно априори предположить, что среднестатистический хаскеллист не умеет в type families и прочие подобные штуки.

спорное заявление, мягко говоря

Их там несколько. Какое из них?

А чего сложного в type families?

А чего сложного в type families?

А это третий вопрос, мало относящийся к распределению скиллов среди нашего брата.