Гарне питання :) Поки що невідомо, чи буде взагалі. Слідкуйте за анонсами twitter.com/kyivlambda та twitter.com/kyivhaskell , а також приєднуйтесь до Discord/Slack/Telegram kyivlambda.com

Не пізно, хоч через 10 тижнів. Слідкуйте за розкладом та приходьте в будь-який момент з домашками того тижня!

Я так розумію, мається на увазі щось типу Writer Monad, де ви можете чистий код писати, додаючи операцію log ніби у вас код не чистий, а воно загорнетьсяв по суті повертання всіх лог-записів kseo.github.io/...​7-01-21-writer-monad.html

Звичайно, в реальному житті мало кому це все потрібно, і зазвичай, якщо чистий код потребує логінг, він перестає бути чистим (точніше ділиться на чистий код «до» та «після» логгінгу).

Подивився приклад, він дійсно жахливий, але з трохи інших, більш простих причин. Можливо я просто чогось не розумію та ви їх роз’ясните?

Одже, в першій частині blog.ploeh.dk/...​/02/dependency-rejection має пояснюватись проблема, яку ми вирішуємо. Там наведено http handler, що валідує дані та робить резервацію (або кидає помилку).

Далі автор пише:

> They are dependencies. Could you make the Post method take them as arguments?

Навіщо це робити? Яку це проблему вирішить?

Ну, воно використовується іноді для зручності, але теж не є якоюсь центральною частиною побудови програм, і я досі не розумію значення ось цієї фрази

Как минимум потому что чисто функциональный подход предполагает ручную композицию функций через частичное приминение

В ООП виклик методу не є ручною композицією? Взагалі не розумію що таке ручна композиція і що таке неручна.

Ви можете самостійно проходити матеріал та задавати питання в Slack-каналі, не бачу проблем.

Проблема циклічних залежностей, як правило, виникає, коли два компоненти один від типів іншого, як правило вирішується додатковим модулем «.Types», в якому зберігаються типи, та залежність розбивається на окремо залежність від типів та модулів. ООП-мови страждають, тому що в них дані та методи відділяти важче. На моєму багаторічному проекті цього було достатньо для боротьби з цією проблемою.

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

Ви можете виконувати інший код залежно від типу за допомогою тайп-класів, але знову ж таки, важко сказати що краще використовувати без більш конкретного опису проблеми, більш точними термінами. Більшість DI-проблем в ООП-мовах, які я бачив, в функційних мовах просто не виникає, через те, що тут відділяють типи, дані та функції.

В нас закритий код та продукт в поточній та минулій компанії, ссилку давати нікуди, але принципово не розумію що це змінює. Така ж архітектура, ті ж проблеми. Що ж, шкода що не змогли порозумітись.

Це просто неправда. Карування можете не використовувати якщо не хочете, я за останні шість років функцію curry викликав разів п‘ять. Не розумію звідки у вас настільки хибні уявлення про фп.

Наведіть конкретний приклад проблеми, яку ви вирішуєте. Зазвичай di називають просто передачу функцій в якості параметрів.

На що вам не відповіли? Я попросив уточнити формулювання, що не мають сенсу. З задоволенням на все відповім більш розгорнуто.

Я досі не розумію, чому воно погано на вашу думку працює в більших кодових базах. Мені навпаки, здається що чим більше кодова база, тим більший бенефіт, бо ви менше боїтесь торкатись чужого коду. На Хаскелі, принаймі, в мене саме такий досвід, що я можу взяти чужий код річної давнини та спокійно його рефакторити та змінювати.

А, ну так, більшість коду як правило і є в IO. Якщо хочеться логіювати код не з IO — поверніть дані, які хочете логіювати, в IO, та там його логіюйте.

main = do
let (res, stuffToLog) = myPureComputation
log stuffToLog

На моїй поточній та минулій роботі більше однієї людини)) але архітектура від цього особливо не змінюється.

1. Сколько времени будет занимать процесс «накарирования» и частичного приминения этих самых модулей под нужды в конкретном сервисе?

Що таке «накарирование модулей»? Дуже незрозуміле питання. Нічим подібним займатись не доводиться.

2. Чисто даже теоретически как карирование и частичное приминение (ручное объявление графа зависимостей) может быть сравнимо с DI (автоматическое объявление графа зависимостей)

Граф залежностей визначається тим, яка функція яку викликає. Знову ж таки, буду вдячний за більш доступний опис.

3. Допустим хочется логировать. И хочется делать это в рандомных слоях. Что делать?

Викликати функцію logInfo (або logError). В чому проблема?

4. Инфраструктура и библиотеки?

Все є!

Мм, та ні. Вони замінили DSL (на чому він там реалізований я не знаю), на розробку якого витрачалося багато сил, та який був спеціалізованим для фб, на Хаскел, при цьому отримавши кращу швидкодію, паралелізм, та зробивши так, що люди тепер практикуються на Хаскелі замість закритої спеціалізованої мови.

Ось більш широкий список: github.com/erkmos/haskell-companies

Плюс є такі стартапи типу мого, яких там очевидно поки нема.

Якщо цікаво опенсорс приклад реального веб апп — подивіться на мій meetup.events

Facebook підійде? www.infoq.com/presentations/haxl

З досвіду минулої групи — по різному, студентів майже не було

Дякую за вашу думку, якщо з‘явиться ідея — перефразую щоби виглядало краще.

Ага, автори отримають суму, що приблизно дорівнює половині дня роботи програмістом в США. Скажені гроші!