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

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

хм.. 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?

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

жалко только один опрос припинивается

Вот АПИ норм задизайнить это да, это сложно среднему хаскелисту. Ибо нет устоявшихся практик.

Вот АПИ норм задизайнить это да, это сложно среднему хаскелисту. Ибо нет устоявшихся практик.

Да. И нужно эти практики "устаивать". Их много уже в интернетах, только их еще не собрали в единую теорию проектирования ПО в ФП

как их устаивать, когда про accidental complexity тут не договоритьс

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

тут вообще все копья переломают

Сначала нужно, чтобы переломали. А потом найдется банда из четырех, которая все структурирует как надо.

Четыре всадника ФПокалипсиса

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

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

Монада, Стрелка, Категория и Лямбда

какие-то всадницы конечно получаются

хорошо не смерть чума и другие два

Смерть, Чума, Джонс, Снойман

: (

Джонс и Снойман в одном ряду

: (

ушёл рыдать

кто из них хороший, плохой, злой?

SPJ хороший

добрый, работящий

тут однозначно все

лучше армстронга?

армстронг не пилил ghc, так что лучше

+

но это biased

а с паттернами есть проблема вида "*** considered harfmul"

я бы даже сказал forall n : Pattern, n considered harmful

а с паттернами есть проблема вида "*** considered harfmul"

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

*подход

ну в блогах и т.п. и изредка в книжках и так пишут

Сорри, экранные клавиатуры

(о там очепятки были?)

ну в блогах и т.п. и изредка в книжках и так пишут

Книжек пока нету.

А все слышали истинную историю GOTO considered harmful?

Слышали, что GOTO considered harmful

Но это же чушь чистой воды. :D

А все слышали истинную историю GOTO considered harmful?

Трудно найти того, кто не слышал, но может, вы о другой

Ну там Дейкстра написал письмо в Communications of ACM с другим названием, куда более мягким, но Вирт, который был главредом, название поменял и сделал вот это. После этого Дейкстра страшно обиделся.

Слышали, что GOTO considered harmful

Да, как же русский человек без оператора посыла-то будет.

Заменим на jmp

русские не скачут!

> Дийкстра > более мягким ну не знаю

"A Case Against the Goto Statement"

Вирт

Книжек пока нету.

online книжку / сайт бы

> Дийкстра > более мягким ну не знаю

Вот не надо голландские буквы так просто транслитерировать!

проще сделать чтобы устаканилось

У нас, кстати, некоторые преподаватели до сих пор break использовать запрещают, даже в Python