За жабу и плюсы деньги плотют, так что ни нада

За все плотют.

За задротство не плотют

<инсерт чарт из стэковерфлова про языки и деньги>

За кложу больше

Вотета вот

Что-то не припомню подобного поведения.
Вроде числа совсем не фантастические.

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

Оттуда вроде удалили кложу или я путаю?

public Yylex(java.io.Reader in)

Спасибо! Все заработало.

Очередной вопрос, наверное больше по lein и емакс.  
Есть файл со спецификацией лексера, он с помощью jflex превращается в код на java
Сейчас после изменеия flex файла приходиться в буфере eshell вызывать jflex, закрывать repl, открывать снова и только так подхватываются изменения в
Как все это упростить? В идеале хочется что бы по С-с С-k в буфере с кложа файлом пересобирался весь проект (вызывался jflex, перекомпилировались java фалы)

разобрался.
Если кому потребуется -
1. на основании lein-ragel сделал свой плагин lein-flex
2. в проект добавил lein-virgil
3. в емакс доустановил elein
Запуск через lein repl, подключаюсь из емакса, после редактирования flex файла вызывается elein-run-task jflex, С-с С-k в буфере с core.clj - и все работет как хотелось.
Круть

Привет
Интересная библиотека, уже несколько раз возвращаюсь к описанию и пытаюсь понять как это можно применять. А чем данный подход лучше того что используется в manifold/promesa - там ведь тоже можно разделить ф-ции на чистые и с I/O - и потом соединить их в пайплайн с помощью chain/then. И обработка ошибок там решена удобно - если какой-то промис фейлится - остальная часть цепочки не выполняется.
Или это нужно только для случаев когда надо вернуться в контекст при котором  возникла ошибка и перезапустить операцию с подмененным значением ?

Привет.

> как это можно применять
Это можно применять для программирования логики программы.
Может быть я не те слова подбираю, но вы можете без программирования деталей проверить предложенную заказчиком/аналитиком логику
и найти там несостыковки. Дешево найти. Быстро найти.
Я ее использую в проекте:
https://github.com/darkleaf/publicator/tree/3.1/src/publicator/core/use_cases/interactors/user
https://github.com/darkleaf/publicator/tree/3.1/test/publicator/core/use_cases/interactors/user

> А чем данный подход лучше того что используется в manifold/promesa - там ведь тоже можно разделить ф-ции на чистые и с I/O
Суть в том,  что не нужно разделять функцию на много чистых фукнций.
У вас есть один процесс, например, регистрация пользователя, и в коде она моделируется одной сущностью - функцией с эффектами.
Принципиально то, что аналитика в голове одна сущность и у вас в голове одна сущность. Нет лишней нагрузки на смену "языка".

> И обработка ошибок там решена удобно
У меня используются обычные исключения для исключительных ситуаций.
Если нужно сделать ранний возврат, даже из другой функции, ниже по стеку, то это возможно
https://github.com/darkleaf/publicator/blob/3.1/src/publicator/core/use_cases/interactors/user/register.cljc#L50
предполагается, что эффект ::->already-logged-in последний и дальше вычисление не продолжается.
вот как это работает https://github.com/darkleaf/effect/blob/master/test/darkleaf/effect/middleware/reduced_test.cljc

> Или это нужно только для случаев когда надо вернуться в контекст при котором  возникла ошибка и перезапустить операцию с подмененным значением ?
это нужно, чтобы тестировать код с эффектами без боли и императивных? моков/стабов
https://github.com/darkleaf/publicator/blob/3.1/test/publicator/core/use_cases/interactors/user/register_test.cljc#L43-L54

Господа, приветствую. Вопрос по datomic/datalog.

Допустим, есть сущности с атрибутами (атрибутов значительно больше чем в примере)

;; user
{:user/name :db.type/string
 :user/department :db.type/ref}

;; department
{:department/id :db.type/integer
 :department/name :db.type/string}

Мне нужно заполучить список пользователей в виде

[{:user/name "Ikram"
  :department/name "Space Force"} ... ]

Я делаю следующим образом (выглядит некрасиво):

(d/query {:query '{:find [(pull ?u [:user/name]) ?dep-name]
                    :keys [user
                           dep-name]
                    :where [[?e :user/name]
                            [?e :user/department ?d]
                            [?d :department/name ?dep-name]]}})

А затем уже постфактум я маппирую полученные значения, придаю им нужную форму.
Можно сделать без pull, но тогда придется перечислять все поля в where, коих множество.
Как красивей реализовать подобное?

надо что получить? список пользователей по именам с департаментами?

Ого ) Спасибо, буду разбираться. Но пока выглядит как более применимое для областей со сложной доменной моделью, видимо я с такими еще не сталкивался - пока большинство профита давало избавление от исключений и блокирующего кода, оптимизации пулов/запросов и т.п.
Видимо это немного не для такого - больше вспомнилось java и DDD при просмотре

Моя библиотека определенно не нужна, если у вас какой-то сетевой сервис. Или апишка складывающая json в базу.
А если есть какая-то бизнес логика, аналитики, ТЗ  и вот это все, то она нужна

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