Разработка AI‑приложений с Effect

> Вы сами начали

Не соответствует действительности.

Если бы вы в своем первом сообщении не писали "недоделанный" эффект все было бы нормально

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

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

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

Вы это через GPT генерируете что-ли? Столько драматизма! 🤦‍♂️

В результате анализа вашего поведения я был вынужден противопоставить вашей агрессивной демагогии свои объективные возражения

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

На этом рредлагаю закрыть дискуссию.

Вот теперь предлагаю закрыть

Разработка AI‑приложений с Effect

Я выразил благодарность что вы поделились langchain, не понимаю где вы агрессию нашли.

Вы сами начали

Разработка AI‑приложений с Effect

Effect AI не эксперементальный модуль а модуль в альфа версии.

Касательно langchain, последняя версия в npmjs @langchain/openai:0.5.2. у него тоже нет мажорной версии и его тоже можно назвать альфой

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

Вы сами обесцениваете Effect AI когда маркируете его так, будто это эксперемент недостойный внимания.

Разработка AI‑приложений с Effect

_

Разработка AI‑приложений с Effect

Не знал про langchain, спасибо.

Эта статья про работу с AI в экосистеме Effect-ts, где используется effect driven подход.
langchain это обычная либа на промисах, там нет эффектов и никогда не будет тех возможностей, что предоставляет эффект :)

недоделанный Effect AI,

Это вполне рабочая альфа версия на стабильной версии самого Effect.

У меня есть пара side проектов, где я использовал @effect/ai. Этот пакет клевый, я им пользовался, когда еще не было даже никакой документации на сайте.

Так как @effect/ai это экосистема Effect, то никакой сложности в понимании не было, так как это стандартные сервисы, слои, схемы.

Как и почему эффекты помогают писать хороший код

Я больше 13ти лет пишу и вообще никогда никаких проблем, от слова совсем из-за ошибок не было

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

Это всё шутки, и они ошибки не ловят?

Ловят, только все типы ошибок это any

Или если человек намеренно не ловит ошибку, а дает ей подняться на верх он идиот?

Я много видел кода где разработчики пишут await await await и забивают на try catch где то в самом верху. Думаю вы лукавите, когда говорите, что разработчики специально "пробрасывают" ошибки наверх. И я не слышал чтобы разработчики позитивно отзывались про try catch, это ужасно неудобно, лучше уж Promise.catch

код крайней своеобразный и противоестественный.

Своеобразный - наверное да, потому что программа в декларативном стиле получается. Противоестественный - в чем именно?

Плюс генераторы вместо async/await, ну такое себе.

Можно не использовать генераторы, есть pipe

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

Вы (и не только вы), прикладываете код, который я привел для примера и который включает в себя классы ошибок, классы сервисов и еще запуск эффекта. Естественно код будет большой!

Вы тоже всю программу пишете в одном файле и в этом же файле запускаете?

Вы можете не комментировать "все это", пишите на своем Go и пользуйтесь try catch, я вам ничего не навязываю

Как и почему эффекты помогают писать хороший код

Почему функция не могла принимать аргументом HttpExecutor и возвращать результат с обработкой ошибки?

Ну вы не поняли просто смысл эффекта, он позволяет инкапсулировать в себе зависимости и возможные ошибки на уровне типа эффекта.

Решение этой проблемы при помощи библиотеки не делает ни чего что можно было сделать без этой библиотеки

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

Как и почему эффекты помогают писать хороший код

Спасибо!

Синк на уровне типов.

да, типы также гарантируют что эффекты нельзя запустить если не передавать все зависимости (без эффектов на уровне компиляции я не знаю как так сделать)

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

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

Как и почему эффекты помогают писать хороший код

Вся ваша "пиар компания" построена вокруг - обработки ошибок, прям зацикленность на этом.

нет, моя "пиар компания" включает обработку ошибок.

Вам вообще JS и TS не нужны, это языки вообще про другое

Что это за "другое"? JS/TS это полноценные языки. Вы имеете ввиду это про фронтенд?

Почему вы на Golang не пишете? Там проверка ошибок после каждой сточки.

Опять вы про обработку ошибок, еще меня в зацикленности клеймите.

Без повышения когнитивной нагрузки?)))

Приложения любой сложности?)))Писав вот такой код, к которому если вернешься через неделю то уже всё, труба, концы с концами не найдешь, что к чему от чего зачем и почему. Ну что-то как-то похоже на фантастику на самом деле.

Просто я в одном месте показываю как создать эффект и как его запустить. И я показал как создать класс зависимости. Поэтому так много кода получилось.

Эффекты запускаются на "краях" программы. Обычно никто не пишет все функции программы в одном месте, всегда функции разбиваются по группам и каждая группа содержит свои функции.

Эффект снимает когнитивную нагрузку за счет того, что хранит в себе список возможных ошибок и необходимый контекст.

Эффект без запуска

import { Context, Effect } from "effect";

export const makeHeyEffect = (
  arg: number
): Effect.Effect<boolean, Error, MyLogger> =>
  Effect.gen(function* () {
    if (arg == 2) yield* Effect.fail(Error("boom"));
    const logger = yield* MyLogger;
    logger.log(arg)
    return true;
  });

class MyLogger extends Context.Tag("MyLogger")<MyLogger, {
  log: (message: unknown) => void
}>() { }

Как и почему эффекты помогают писать хороший код

Если обработка ошибки не происходит непосредственно в месте ее возникновения, это не значит, что разработчик ее игнорирует

Да, он может ее не игнорировать а просто забыть обработать

Если это знание вам важно, возможно, стоило взять какой-то другой язык, нежели Typescript?

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

В golang, на уровне языка нужно всегда проверять что функция не вернула ошибку, по сути все вызовы функций всегда возвращают Result type, и постоянно нужно проверять, ошибка это или успех.

Обмазывать ради этого весь код таким густым бойлерплейтом - переусложненное решение

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

Как и почему эффекты помогают писать хороший код

Так и не надо писать этого. Для выражения мыслей вы используете ТС. В ТС все это просто функции. Вы подумайте, вы уже выбрали инструмент для своих мыслей. Поэтому выражать в терминах этого инструмента - это нормально.

Вероятно вы правы, в статье я не хотел делать упор на конкретный ЯП, поэтому TS прятал в спойлеры. Но, похоже, что я сам себе усложнил задачу и сам себя обманывал, потому что в статье был код на TS в любом случае.

Вы же именно с этой стороны рассматриваете функцию? Т.е. как базовый строительный блок.

Да, строительный блок.

Вот если посмотреть на вводную статью Why effect? Там огромногое количепство воды и основной посыл, что эффекты имеют мощную богатую экосистему для решения различных задач.

Да, поэтому я хотел раскрыть идею эффектов а не рассказывать сразу про экосистему. У Effect-ts классная точечная документация, но нужно пройтись по отдельным главам, чтобы пазлы сложились в голове.

Иными словами, стоит сначала сформулировать задачу, которую хотите решить и дать решение на эффектах и без них.

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

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

Вы правы

----

Спасибо вам за помощь!

Как и почему эффекты помогают писать хороший код

Согласен с вами что на Rust можно делать много чего. На мой взгляд, он сложнее чем Java/TypeScript, нужно понимать значение указателей, как выделять память под структуры, не бояться макросов и тп. В языках с GC как то попроще.

Какая разница почистит переменную gc или автоматом при выходе из scope?

вы правы

Как и почему эффекты помогают писать хороший код

Спасибо за констуктивный фидбек, постраюсь ответить на часть ваших вопросов

Вы пишете статью про языки программирования. Программисты не говорят "ООП-функция", мы говорим просто "функция"

Я не писал статью про ЯП, а про эффекты. Я упоминаю ФП и ООП потому что эффект это симбиоз двух парадигм.

Программисты не говорят так, да. Я сказал про это в начале статьи что имеется ввиду под этим термином. Вероятно, это была не лучшая идея.

Сразу вопрос по форме, а где в вашей статье далее будут ситуации, когда можно перепутать о какой функции идет речь?

В статье я сравниваю обычную функцию/метод с эффектом. Чтобы не писать "классическая функция/метод класса".

Вопрос по форме, вы имеете в виду, что это "знание" помогает только "функцинальщикам" или мне оно тоже поможет? Или даже так, а не поможет ли это знание вообще любому "абстрактному" программисту?

Это знание поможет любому абстрактному программисту.

Куда запустить? Как вы себе это представляете? Я не очень понял, что вы имеете в виду

Когда программа запускается, то начинается выполнение с ее главной функции. Эта функция запускает/выполняет/передает управление другой функции и так далее.

Функция это именованый фрагмент кода, которому передается управление в момент вызова.

Это я все к тому, что, по моему, вы выбрали крайне странную форму, что бы просто рассказать о пользе чистых функций.

Статья не про пользу чистых функций, а про эффект, который является чистой функцией.

Вот вы назвали раздел "Проблема ООП-функции". Ввели это обозначение, а потом... а где проблема? Где-то кто-то что-то проигнорировал, ООП-язык что-то скрыл. Вот у меня такое впечатление сложилось.

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

Мы сейчас говорим про JS? Если про JS то никаких проблем поменять реализацию console для любого вызова hey у нас не будет. Причем данное свойство широко используется в разработке. За примерами далеко ходить не надо. Например, есть MSW, который позволяет мокать fetch в браузере, тестах.

Да, можно изменить глобальный контекст а потом запустить код.

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

И если с обработкой ошибок еще туда сюда, то почему вы так старнно обошли работу с MyConsole в певрмом примере не ясно.

Вы абсолютно правы, это моя ошибка что примеры немного разные. Нужно было сервис пробрасывать аргументом функции, в первом примере (который без эффектов).

Это привело к тому, что кода с эффектами стало чуть больше.

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

Я не знал как лучше донести эту мысль, остановился на варианте который оформил в статью

Я дальше уже глазами просто по теме пробежался. Все это очень интересно и полезно. Но, по моему, вы зря пытаетесь изобретать велосипеды и придумывать объяснения и определения, которые уже даны и являются известными.

Я хотел объяснить, какая проблема есть и почему, что такое эффекты и как они решают эту проблему.

Как и почему эффекты помогают писать хороший код

Почему вы такое хамло?

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

Желаю сил людям, которые с вами работают. На ваши комментарии отвечать не буду

Как и почему эффекты помогают писать хороший код

Haskell?

Я имел ввиду язык, который в топе 10-15 языков. Haskell чистый ФП язык который использует узкий круг компаний

Наличие эффектов не гарантирует что вы их правильно описали логику.

Эффекты гарантируют что вы ошибки все обработали и передали правильный контекст

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

Это самопально-библиотечное скачивается по 2 миллиона раз в неделю

Ярчайший пример это имплементация ФП, как это элегантно и минималистично смотриться в Haskell/F# или на худой конец Scala и в какой плохо читаемый бойлерплейт превращается в JS/TS/Java/Kotlin.

Я не буду с вами спорить и не понимаю предмет того, что в чем вы хотите меня убедить. У вас такой большой опыт в языках, и Rust и Haskel и плохая Scala, и в Котлин все очень плохо с бойлерплейтом. Спасибо за активность

Как и почему эффекты помогают писать хороший код

Тест1: передаем 2, проверяем бросит ли исключение.

Тест2: передаем любое число кроме 2, проверяем вернет ли true.

Функция полностью протестирована.

А почему вы тогда код этих тестов не написали когда приводили пример кода из статьи? Зачем вы вообще пишете такие тесты если вам нужно быстро написать код и задеплоить?

Использование эффектов избавляет от написание подобных тестов.

а Вы предлагаете это все еще сверху обмазать еще одним толстым слоем вспомогательного бойлерплейта который еще и работает абсолютно не явно

Я не понимаю про какой слой бойлерплейта вы говорите. Я приводил пример из Effect-ts чтобы было понятно как это работает.

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

Языки развиваются долго, годами, потому что новые фичи проходят несколько этапов от draft версии до in progress.

JS когда-то поддерживал только callback, не было async/await. Сейчас можно использовать await но у него другая проблема теперь, разработчики не использую try catch и пишут небезопасный код.

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

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

У меня нет большой практической экспертизы в Rust, но знаю что он для системного программирования. Я любой язык назову прекрасным, если у него функции будут возвращать Result тип. А еще у него все переменные по умолчанию неизменяемые, есть pattern matching, круто!

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

Как и почему эффекты помогают писать хороший код

Вместо тысячи слов.

...

Можно оценить все прелести такой реализации.

Первый пример кода, без эффектов, небезопасный к выполнению и плохо тестируемый. Просто черный ящик.

Этот код естественно меньше, потому что мы "забили" на то, что у вызывающей стороны будут проблемы.

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

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

Естественно быстрее и проще написать небезопасный код, но у этого есть цена. Эффекты дают возможность писать надежный код когда это необходимо.

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

Если язык не поддерживает такой подход (как к примеру Haskell/Rust) то вы получаете накладные расходы по памяти и производительности на ровном месте, плюс из-за отсутствия синтаксической поддержки, это почти всегда выглядит многосложно громоздко, не понятно и неестественно.

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

Вот специально для таких комментариев я посветил пару абзацев в статье (Использование эффектов делает программы медленнее).

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

Как и почему эффекты помогают писать хороший код

пишите правильно

так не работает. у всех разработчиков разный уровень знаний и не получится всех заставить писать "правильно".

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

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

Так же с эффектами. Роль рантайма эффектов такая же важная как и компилятора, эффекты позволяют на уровне компилятора не забывать обрабатывать ошибки и подставлять используемые зависимости.

Как сделать красивое резюме используя JSON

Да, это рабочий вариант

мой инструмент делает по сути тоже самое что и ваш, просто человеку требуется заполнить JSON по схеме а не верстать самому и потом самому искать еще сервис, который сконвертирует в PDF. Достаточно открыть страницу и сделать все не от ходя от кассы

Плюс в том что вся власть над стилизацией в ваших руках

Вы правы, сейчас я сделал все в один стиль, цветовая схема stack overflow. Можно сделать еще тему и версту и дать возможность пользователю выбирать еще тему

Как сделать красивое резюме используя JSON

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

У меня и не было такой задачи. Моя задача была максимально быстро и просто дать возможность создать резюме в PDF формате, без приседаний 🤣

Для меня это hh.ru, habr.ru, linkedin.com

Там нет резюме, на этих площадках есть заполненный профиль. Вы хотите что бы linkedin автоматически синхронизировался с habr.ru, когда вы добавили место работы в аккаунте в habr.ru? 😀 Если да, то могу вам сразу сказать что это очень сложно.

Если вы хотите держать свое резюме в актуальном состоянии, то единственный вариант это хранение в файле

Опять же портфолио для фронтендера... 

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