да

ну и haskell considered harmul

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

haskellers considered harmful

по краю ходим, я бы сказал

А есть полный список?

Не веду таких

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

Зависит от бизнеса. В больших проектах без Inversion of Control и инжектирования зависимостей трудно обойтись.

это не на языке бизнеса сказано

Не веду таких

Надо завести X considered harmful

Вот о чем бы я десять раз подумал, - так это "поднимать ли бизнес-логику в типы, когда можно сделать Free-DSL". И выбор здесь явно не в пользу типов

ну я повторю вопрос - мы видим типы для инвойсов в гисте

Все что вы с фри делаете в своих дсл прекрасно делается без фри.

можно пример применения этих типов с пояснениями (где тут зависимость от контекста и пресловутые IoC и DI)

еще раз спрошу - на самом деле меня вот этот вот IoC вызывает легкую тошноту

Это. Способ. Получить. Инстанс. Монады.

да чего б его не написать то?

теперь про IoC

тьюринг-полные конфиги - это IoC ?

строенный в программу скриптинг - это IoC ?

еще раз спрошу - на самом деле меня вот этот вот IoC вызывает легкую тошноту

Это как передачу аргумента называть dependency injection, на мой вкус.

Все что вы с фри делаете в своих дсл прекрасно делается без фри.

Любую задачу можно решить несколькими способами. Но не любое решение помогает разделить консерны и удовлетворить тем же SOLID-принципам. Free - позволяет, а также вносит и другие нужные вещи. С Free accidental complexity очень низка

@qnikst завтра с Мальты вернётся - спросите ещё раз

Это. Способ. Получить. Инстанс. Монады.

Нам нужен CoC

а то тут с wifi не всегда хорошо и совещаний много

@qnikst гражданство покупаешь, поди?

хаха

давайте еще раз. допустим, я совсем тупой.

не, собрание компании

встроенный в программу на си скриптинг на самодельном лиспе - это IoC ?

можно пример применения этих типов с пояснениями (где тут зависимость от контекста и пресловутые IoC и DI)

Так там же и использование, во втором гисте, функция listInvoices, которая и есть функция, сгенерированная по языку InvoiceL. Если у компании в поле invoicing_service стоит Infakt, используется интерпретатор от Infakt. Если стоит Zoho, то интерпретатор от Zoho. А бизнес-сценарий при этом тот же самый

Любую задачу можно решить несколькими способами. Но не любое решение помогает разделить консерны и удовлетворить тем же SOLID-принципам. Free - позволяет, а также вносит и другие нужные вещи. С Free accidental complexity очень низка

Я не знаю как у вас, но в моем ФП нет никакого SOLID.

Я не знаю как у вас, но в моем ФП нет никакого SOLID.

https://vimeo.com/113588389

прямо на превьюхе этот слайд

Я не знаю как у вас, но в моем ФП нет никакого SOLID.

А очень зря, потому что у вас тогда плохой ФП

Не надо думать, что SOLID - это про ООП

OO considered nothing

Не важно, что там пишут и говорят. Принципы - универсальные

мне вот тоже не важно что пишут

и говорят

И?

https://vimeo.com/113588389

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

кто-то ответит - "внедрение языка скриптования в программу на си это пример IoC или нет" ?

без понятия

я в буллшит бинго этом не разбираюсь

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

кто-то ответит - "внедрение языка скриптования в программу на си это пример IoC или нет" ?

Не очень ясен вопрос. Для IoC характерны две вещи: интерфейс и имплементация, разделенные. Клиентский код видит только интерфейс, а в рантайме туда подставляется имплементация

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

+

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

На самом деле, все ФП - имеет в своей природе естественный IoC. Ведь мы передаем функции в качестве зависимостей

я умею в булшит бинго

Так и что там насчет SOLID? В чем тут ООП? Есть понятие ООП-интерфейса (в Java даже ключевое слово имеется) и есть понятие интерфейса как абстракции. Не надо их путать. Поэтому в SOLID "I" применима к любой парадигме. Впрочем, как и Single Responsibility, и Open-Close, и LSP, и все остальное. Просто в интернетах подавляющее большинство авторов дальше ООП не заглядывали, и для них все эти принципы ничего другого не значат.

вернемся теперь к нашим инвойсам

вот у нас есть инвойс, там есть всякое бла-бла и позиции

нам для инвойса , допустим, надо

1) посчитать total

2) сгенерировать pdf

это примеры разной обработки одной структуры данных в завимости от ?

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

это примеры разной обработки одной структуры данных в завимости от ?

в зависимости от вызываемой функции, лол

Сгенерировать pdf - это метод для Invoice DSL. У меня такой даже есть, обращается к сервису. Посчитать total - это сценарий, так как ему требуются данные по инвойсам, которые он может получить, дергая методы DSL. Общее правила для DSL такие: - Методы должны делать только то, что нельзя выразить через другие методы; - Методы должны быть настолько абстрактными, насколько возможно; - Методы должны компоноваться настолько, насколько возможно

По сути, это все относится к любому интерфейсу

Хоть REST, хоть ООП, хоть еще какому

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

И вот как раз этих практик нам не хватает.

дело в том, что часть этих практик растёт от отсутствия примитивов, которые доступны в ФЯ и типов

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

Часть - да. Паттерны те же. Но есть универсальные

что-то, причем, есть вполне возможно ценное

вопрос, что

Разделение интерфейса и реализации.

делается, хотя методы спорны

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

спорно

Single Responsibiltiy

спорно

Вовсе нет.

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

low coupling, high cohesion

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

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

Модульность - это важно. Но этого недостаточно для приложения, общающегося с внешним миром.

Сгенерировать pdf - это метод для Invoice DSL. У меня такой даже есть, обращается к сервису. Посчитать total - это сценарий, так как ему требуются данные по инвойсам, которые он может получить, дергая методы DSL. Общее правила для DSL такие: - Методы должны делать только то, что нельзя выразить через другие методы; - Методы должны быть настолько абстрактными, насколько возможно; - Методы должны компоноваться настолько, насколько возможно

про тотал: если его делать сценарием, то нужно в dsl делать ряд геттеров, а есть такое мнение, что геттеры и сетеры - ересь, поэтому total может уехать в api

В clojure есть прекрасный принцип, примерно такой: - First, program with data - Second, program with functions

То есть, если можно - программируем данными

Если нет - функциями

@kana_sama а еще есть мнение, что если этот инвойс - просто ADT, то всё это достигается без применения клеточек из буллшит бинго, а просто обходом этого ADT

правда в кложе это превращается в жонглирование хешмапами

про тотал: если его делать сценарием, то нужно в dsl делать ряд геттеров, а есть такое мнение, что геттеры и сетеры - ересь, поэтому total может уехать в api

Каких геттеров? Дергание методов, обращающихся за инвойсами в сервис - не есть геттер. Такой метод вернет просто ADT Invoice, и все данные доступны

Нету никаких геттеров в смысле ООП

сеттеры. геттеры

правда в кложе это превращается в жонглирование хешмапами

Да, но не единственная реализация принципа

я точно всё еще в чате про хаскель?

ну окей, пусть total считается с неким коэфицентом, который зависит от интерпретатора

Нету никаких геттеров и сеттеров. Но в Haskell как таковом они есть в виде линз

в total у нас будет геттинг этого коэфицента из api

линзы это просто сахар

ну окей, пусть total считается с неким коэфицентом, который зависит от интерпретатора

Э-э, нет, вот еще одно правило для интерпретатора: - в интерпретаторе не должно быть бизнес-логики

линзы это просто сахар

Сахар - это do-нотация. А линзы - это, скорее, eDSL

окей. но неважно, есть он или нет

наличие линз или их отсутствие ничего не изменит.