Dmitry
свой игрушечный язык написать проще, чем в ghc лезть
Dmitry
даже с HM-типизацией и выводом типов
Denis
Writer тоже, кстати, considered harmful
Dmitry
да это понятно, что всё консайдеред
Dmitry
возможно, когда такое слышишь, надо уже задаться вопросом - а кому хармфул?
Dmitry
да
Dmitry
ну и haskell considered harmul
Dmitry
потому что мы все близки к тому, что бы вместо решения задач бизнеса свалиться в пропасть circular jerking
Alexander
haskellers considered harmful
Dmitry
по краю ходим, я бы сказал
Alexander
потому что мы все близки к тому, что бы вместо решения задач бизнеса свалиться в пропасть circular jerking
Зависит от бизнеса. В больших проектах без Inversion of Control и инжектирования зависимостей трудно обойтись.
Dmitry
это не на языке бизнеса сказано
Alexander
Вот о чем бы я десять раз подумал, - так это "поднимать ли бизнес-логику в типы, когда можно сделать Free-DSL". И выбор здесь явно не в пользу типов
Dmitry
ну я повторю вопрос - мы видим типы для инвойсов в гисте
Denis
Все что вы с фри делаете в своих дсл прекрасно делается без фри.
Dmitry
можно пример применения этих типов с пояснениями (где тут зависимость от контекста и пресловутые IoC и DI)
Dmitry
еще раз спрошу - на самом деле меня вот этот вот IoC вызывает легкую тошноту
Denis
Это. Способ. Получить. Инстанс. Монады.
Dmitry
да чего б его не написать то?
Dmitry
теперь про IoC
Dmitry
тьюринг-полные конфиги - это IoC ?
Dmitry
строенный в программу скриптинг - это IoC ?
Denis
еще раз спрошу - на самом деле меня вот этот вот IoC вызывает легкую тошноту
Это как передачу аргумента называть dependency injection, на мой вкус.
Alexander
Все что вы с фри делаете в своих дсл прекрасно делается без фри.
Любую задачу можно решить несколькими способами. Но не любое решение помогает разделить консерны и удовлетворить тем же SOLID-принципам. Free - позволяет, а также вносит и другие нужные вещи. С Free accidental complexity очень низка
Alexander
@qnikst завтра с Мальты вернётся - спросите ещё раз
Alexander
а то тут с wifi не всегда хорошо и совещаний много
Dmitry
@qnikst гражданство покупаешь, поди?
Alexander
хаха
Dmitry
давайте еще раз. допустим, я совсем тупой.
Alexander
не, собрание компании
Dmitry
встроенный в программу на си скриптинг на самодельном лиспе - это IoC ?
Alexander
можно пример применения этих типов с пояснениями (где тут зависимость от контекста и пресловутые IoC и DI)
Так там же и использование, во втором гисте, функция listInvoices, которая и есть функция, сгенерированная по языку InvoiceL. Если у компании в поле invoicing_service стоит Infakt, используется интерпретатор от Infakt. Если стоит Zoho, то интерпретатор от Zoho. А бизнес-сценарий при этом тот же самый
Denis
Mikhail
прямо на превьюхе этот слайд
Alexander
Я не знаю как у вас, но в моем ФП нет никакого SOLID.
А очень зря, потому что у вас тогда плохой ФП
Alexander
Не надо думать, что SOLID - это про ООП
Dmitry
OO considered nothing
Alexander
Не важно, что там пишут и говорят. Принципы - универсальные
Denis
мне вот тоже не важно что пишут
Denis
и говорят
Alexander
И?
Denis
https://vimeo.com/113588389
я как раз вот этот слайд во время разговора вспомнил, но с телефона было лень искать
Dmitry
кто-то ответит - "внедрение языка скриптования в программу на си это пример IoC или нет" ?
Denis
без понятия
Denis
я в буллшит бинго этом не разбираюсь
Dmitry
потому что любая статья про IoC - это примерно два экрана словоблудия и в качестве примера - огромный xml-ный конфиг, который меняет поведение жабьей программы
Alexander
кто-то ответит - "внедрение языка скриптования в программу на си это пример IoC или нет" ?
Не очень ясен вопрос. Для IoC характерны две вещи: интерфейс и имплементация, разделенные. Клиентский код видит только интерфейс, а в рантайме туда подставляется имплементация
Dmitry
да, а какую имплементацию возвращать решает xml-ный конфиг и абстрактная фабрика
Alexander
На самом деле, все ФП - имеет в своей природе естественный IoC. Ведь мы передаем функции в качестве зависимостей
Dmitry
я умею в булшит бинго
Alexander
Так и что там насчет SOLID? В чем тут ООП? Есть понятие ООП-интерфейса (в Java даже ключевое слово имеется) и есть понятие интерфейса как абстракции. Не надо их путать. Поэтому в SOLID "I" применима к любой парадигме. Впрочем, как и Single Responsibility, и Open-Close, и LSP, и все остальное. Просто в интернетах подавляющее большинство авторов дальше ООП не заглядывали, и для них все эти принципы ничего другого не значат.
Dmitry
вернемся теперь к нашим инвойсам
Dmitry
вот у нас есть инвойс, там есть всякое бла-бла и позиции
Dmitry
нам для инвойса , допустим, надо
Dmitry
1) посчитать total
Dmitry
2) сгенерировать pdf
Dmitry
это примеры разной обработки одной структуры данных в завимости от ?
Dmitry
просто немного напрягает, что в любом упоминании IoC он выступает как самостоятельная ценность. а не те задачи, которые он решает
Denis
это примеры разной обработки одной структуры данных в завимости от ?
в зависимости от вызываемой функции, лол
Alexander
Сгенерировать pdf - это метод для Invoice DSL. У меня такой даже есть, обращается к сервису.
Посчитать total - это сценарий, так как ему требуются данные по инвойсам, которые он может получить, дергая методы DSL. Общее правила для DSL такие:
- Методы должны делать только то, что нельзя выразить через другие методы;
- Методы должны быть настолько абстрактными, насколько возможно;
- Методы должны компоноваться настолько, насколько возможно
Alexander
По сути, это все относится к любому интерфейсу
Alexander
Хоть REST, хоть ООП, хоть еще какому
Alexander
Да, хаскеллистам не помешает посмотреть на практики дизайна корпоративных приложений. Haskell - не более особенный, чем другие языки. К нему тоже это все применимо.
Alexander
И вот как раз этих практик нам не хватает.
Dmitry
дело в том, что часть этих практик растёт от отсутствия примитивов, которые доступны в ФЯ и типов
Dmitry
часть - просто следствие дизайна этих языков
Alexander
Часть - да. Паттерны те же. Но есть универсальные
Dmitry
что-то, причем, есть вполне возможно ценное
Dmitry
вопрос, что
Alexander
Разделение интерфейса и реализации.
Dmitry
делается, хотя методы спорны
Alexander
Для маленьких приложений это несущественно, а большие быстро превращаются в тыкву
Dmitry
спорно