Транспайлить в Lisp на удивление несложно, синтаксиса в языке практически нету 🤷‍♀️ Базовые синтаксические конструкции и все остальное списки символов.

Если хочется узнать больше о структурах данных в функциональном программировании, но не хочется вникать в книгу Окасаки (книга стоящая кстати) https://cs.uwaterloo.ca/~plragde/flaneries/FDS/

Набираю группу на изучение кложескрипта с реактом. Бесплатно, коротко, в скайпе. Пишите в личку здесь @roman01la

Пока что набор приостанавливаем, уже много желающих 😛

React — это язык программирования. Как тебе такое, Илон Маск?

- В реакте программируют в DSL похожем на XML, который компилируется в JS
- В реакте есть свой try..catch через componentDidCatch
- В реакте есть глобальные переменные через Context API
- В реакте можно биндить глобальные переменные (Context) как в Clojure через binding

Я не шутил по поводу языка :D

Просили публиковать сюда материалы/задания, которые используем в курсе. Вот репозиторий с материалами по интро в язык, пользуйтесь https://github.com/roman01la/amsterdamjs-clojurenoscript-workshop

Под Rust сделали персистентные структуры из Clojure https://docs.rs/im/11.0.0/im/ 👏

Чуваки из FB научили Prepack (AOT компилятор для JS) компилить в LLVM и в нативный бинарник 🤔 https://github.com/facebook/prepack/pull/2264

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

Если подумать то AOT как раз больше имеет смысла применять к таким языкам, чтобы упрощать/развертывать их абстракции (например структуры данных) в максимально простой js код на этапе сборки проекта, вместо того, чтобы все это выполнять в рантайме.

Русскоговорящий чатик Clojure Russia переезжает из Clojurians Slack в Telegram 👉 https://news.1rj.ru/str/clojure_ru

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

Делаю прототип визуального редактора с набором простых блоков. Блоки довольно просто описать в стиле Hiccup, по структуре максимально приблежены к доменной области (свойства блоков в визуальном редакторе). Спекой неплохо выходит описать блоки и структуру, потом валидировать и разобрать все это на AST.

Дальше описываем несколько мультиметодов для транслирования в Reagent Hiccup и получаем UI.

(s/def :element/x int?)
(s/def :element/y int?)
(s/def :element/color string?)

(s/def :element/text
  (s/cat
    :tag #{:text}
    :attrs (s/keys :req-un [:element/color])
    :text string?))

(s/def :element/rect
  (s/cat
    :tag #{:rect}
    :attrs (s/keys :req-un [:element/x :element/y])
    :children (s/* :visual/element)))

(s/def :visual/element
  (s/or
    :rect :element/rect
    :text :element/text))

(defmulti -compile-visual first)

(defmethod -compile-visual :rect [[_ {:keys [attrs children]}]]
  (let [{:keys [x y]} attrs]
    `[:div {:style {:left     ~x
                    :top      ~y
                    :position "absolute"}}
      ~@(map -compile-visual children)]))

(defmethod -compile-visual :text [[_ {:keys [attrs text]}]]
  (let [{:keys [color]} attrs]
    [:span {:style {:color color}}
     text]))

(defn visual->hiccup [element]
  (when (s/valid? :visual/element element)
    (-> (s/conform :visual/element element)
        -compile-visual)))

(visual->hiccup
  [:rect {:x 10 :y 100}
   [:text {:color "#000"} "text"]])

(comment
  [:div
   {:style {:top 100, :position "absolute", :left 10}}
   [:span {:style {:color "#000"}} "text"]])

Парное программирование очень клевая штука, особенно для ремоута. Лет 5 назад мы делали pairing на постоянной основе, в офисе.

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

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

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

p.s. Все это imo и индивидуально.

Если планируете в следующем году посетить конференцию в Европе и устали от больших конф, сходите на BOB в Берлине https://bobkonf.de/2019/en/, небольшая конфа про немейнстримное ФП.

Или месяцем ранее на ламповую ClojureD https://clojured.de/

За последние года 3-4 в мир JavaScript пришли функциональное программирование и иммутабельные данные. Но по факту ничего толком не прижилось. Возможно средний разработчик стал более дисциплинированным после прочтения 100500 статей о чистых функциях.

Функциональный стиль. Есть каста фронтендщиков, которые упарываются по Ramda и пишут в pointfree стиле в JS. Остальные используют всем известные функции высшего порядка из стандартной библиотеки языка и всегда используют const.

Иммутабельность. Immutable.js так и остался технологией «сбоку». В большинстве случаев его не используют в JS из-за неидиоматичности по отношению к языку, а не от надуманных проблем с производительностью. По той же причине никто не использует Map и Set из ES2015. Сложно заставить себя писать m.get("key") после короткого m.key.

Поэтому на замену функциональному Redux и неидиоматичному Immutable.js пришли MobX и immer. А для любителей функциональщины Facebook сделал Reason и перетащил туда всех недовольных забагованным тайпчекером Flow (который написан на OCaml).

Кстати, в 2017м было опубликовано предложение ввести иммутабельные коллекции в JS и добавить для них литералы https://github.com/sebmarkbage/ecmanoscript-immutable-data-structures