сервант даёт автогенерацию кода, даёт автотесты, даёт swagger, даёт проверки сериализации всех данных

все что Тим писал жутковато

Что за Тим и можно пример кода?

притаскивает servant-quickchek

Что за Тим и можно пример кода?

Tim Watson он половину distributed-process-platform писал

все эти супервизоры, клиент-серверы и прочее

очень много кода, но очень странного

копировать эрланг - это не тупиковая ли идея вообще?

Я там, например, много косяков вижу. Начиная от отсутствия структуры и заканчивая тестами в папках самих библиотек

Мы работаем над этим.

лучше б до ума довели transient

Мы работаем над этим.

Могу поревьюить, как буду более-менее свободен

что, если не сервант? на чем вебсервисы-то писать?

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

что значит, на хаскелл

у них там целый FP Complete ревьювит код

копировать эрланг - это не тупиковая ли идея вообще?

да

В смысле - кода, который сервит

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

тупиковая

ну патчить сервант сложновато

но как часто вы это делали?

у них там целый FP Complete ревьювит код

FPC уже давно с нами не работают.

да блин через раз

у них там целый FP Complete ревьювит код

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

Ничего подобного.

что значит, на хаскелл

Вам концепция деления на слои понятна?

и?

Когда Джон Хьюз (который из Quviq) посмотрел наши тесты - он прямым текстом сказал, что многие из этих тестов "just suck".

так что никакой излишней толерантности.

FPC уже давно с нами не работают.

а что же тогда делает Kirill

и?

Сервант - лишь небольшой слой взаимодействия с внешним миром. "Писать сервисы" == "писать бизнес-логику", и это никак не Сервант

а что же тогда делает Kirill

не работает :)

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

а что же тогда делает Kirill

Не знаю.

как время-то бежит

но вообще Денис вроде когда-то уже говорил, что у FPCo контракт с Cardano Foundation

не с IOHK

а да точно

именно

но ты же ревьювил какой-то код?

Сервант - лишь небольшой слой взаимодействия с внешним миром. "Писать сервисы" == "писать бизнес-логику", и это никак не Сервант

ну т.е если убрать увиливания - то это означает - смириться с сервантом

не так давно

остальное вполне понятно, слои там и т.п.

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

очень рано

но ты же ревьювил какой-то код?

не по контракту с IOHK, репорты пишутся, что IOHK с ними делает (получая от CF) вопрос к IOHK

я ничего не говорил про контракт с IOHK

а про то, что вы ревьювите тот код

ок

ну т.е если убрать увиливания - то это означает - смириться с сервантом

Я же уже обозначил свою позицию. Если не ожидается сложной логики сервера, Servant можно использовать, он хотя бы ориентирован, чтобы его использовали. В предыдущем проекте я его использовал и писал на нем RPC. Если же ожидается что-то сложное, выбор Серванта рискован.

поправка только, что совсем далеко не ценлый FP Complete :)

договор с компанией значит что она выделяет достатое кол-во ресурсов на решение проблемы и имеет shared knowledge

в каком смысле shared?

между сотрудниками

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

Я же уже обозначил свою позицию. Если не ожидается сложной логики сервера, Servant можно использовать, он хотя бы ориентирован, чтобы его использовали. В предыдущем проекте я его использовал и писал на нем RPC. Если же ожидается что-то сложное, выбор Серванта рискован.

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

и.е. ревью сильной командой часто сильнее ревью сильного человека

Я же уже обозначил свою позицию. Если не ожидается сложной логики сервера, Servant можно использовать, он хотя бы ориентирован, чтобы его использовали. В предыдущем проекте я его использовал и писал на нем RPC. Если же ожидается что-то сложное, выбор Серванта рискован.

например, что сложное сложно сделать на серванте?

учитывая, любое безумие там возможно с помощью Raw

ядро OS? :)

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

Так и есть. Выбор Haskell сейчас - это риск более высокий, чем выбор любого распространенного языка. Но мы-то уже находимся в системе координат Haskell. Хотя можно пообсуждать, да

ну мы вроде про веб сервисы?

например, что сложное сложно сделать на серванте?

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

я патчил там две вещи: 1. авторизацию (уже в апстриме) 2. streaming который был кривой

Так и есть. Выбор Haskell сейчас - это риск более высокий, чем выбор любого распространенного языка. Но мы-то уже находимся в системе координат Haskell. Хотя можно пообсуждать, да

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

ну не смотря на мою ругань я сделал его за пару часов

при этом всегда можно написать Raw и получить чистый Wai

ну не смотря на мою ругань я сделал его за пару часов

Я опирался именно на твои слова. Тогда, видимо, Servant - нормальный выбор

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

ERROR: S client not available

в нашем-то хаскелле. ну-ка ну-ка что это

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

пришлось заменить endpoint на raw

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

В мире Хаскеля говорить о мейнстримных альтернативах можно лишь в ряде ограниченных случаев

учитывая что это заметили в 11 вечера люди сидевшие в офисе

да сервант внутри сложный и плохо документировар

но лазить туда надо не часто, ещё там неплохой апстрим

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

чаще бесплатно

короче, кода меньше = код лучше. но если код работает - то он уже хороший.

но лазить туда надо не часто, ещё там неплохой апстрим

Это очень хорошее качество. Когда есть понятный интерфейс и есть куча примеров, как его использовать так, чтобы его уши не протыкали собой все другие слои. А вот с vinyl-рекордами (у меня на прошлом проекте) так не получилось. Поэтому мы коллегиальным решением загнали эти рекорды только в одну небольшую нишу, чтобы они не лезли в бизнес-логику. Автору (который еще, к слову, навертел поверх своей магии на типах) пришлось с этим смириться

короче, кода меньше = код лучше. но если код работает - то он уже хороший.

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

ну конечно, ведь лучше хороший, но не работающий код

во, в твиттере про понятность заговорили

ну конечно, ведь лучше хороший, но не работающий код

Я не утверждал этого. На мой взгляд, здесь нет черно-белой оценки. Если код хорошо написан, но не работает, то там, возможно, есть какой-то простой баг, который очень легко найти и пофиксать. И все заработает

во, в твиттере про понятность заговорили

А можно ссылку?

да все фигуранты здесь сидят, и в общем ничего нового нет. хорошо/плохо понятно/непонятно много loc/мало loc

всё как всегда

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

т.е вроде точки зрения у них будут одинаковые, но есть нюанс!

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

Точнее, так: за поддерживаемость. Понятность - это другая характеристика

поддерживаемость можно как-то определить?

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

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

да как это вообще возможно?

поддерживаемость можно как-то определить?

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

поддерживаемость можно как-то определить?

Время на внесение изменений

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

русскоязычные обычно самые умные

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

тестируемость как определяется? можно пример теструемого и нетеструемого (это как?) кода?

понятность - кому понятность?