Комментарии 37
В итоге решил полностью отказаться в пользу обычного разбиения на функции.
Самой большой и неразрешённой до конца для меня трудностью стало деление кода на модули.
Полностью поддерживаю, для себя нашел translator pattern , но он довольно усложняет приложение. Может в будущем будут варианты получше.
То что язык можно применять только под фронтенд, не мотивирует тратить время на изучение. Выбрал для себя Clojure/ClojureScript так как позволяет покрыть очень широкий круг задач. Из плюшек дает все тоже самое — функциональщина, иммутабельность, легкий рефакторинг, мощный REPL. Проблем с разделением кода на модули нет никаких, команда пакетного менеджера lein new re-frame <project-name> создаст всю структуру, а документация к re-frame подробно все разжует. Если под задачу не подходит архитектура, то есть масса других шаблонов.
PS я не против Clojure, просто интересно )
Elm обладает развитой системой типов с автоматическим выводом,
В ClojureScript версии 1.9 появился spec, можно очень гибко и удобно покрыть весь код типами если нужно.
Можете пояснить что вы подразумеваете под легким рефакторингом в Clojure.
Можно легко перекраивать приложение, тут множество положительных факторов для этого — иммутабельность, REPL, хот-релоад без потери стейта через figwheel, мощь s-выражений. Попробуйте )
Компиляция на лету в JS https://github.com/bhauman/lein-figwheel
Ну тут сабж о фронтенд разработке а не о серверной, теоретически можно хот релоадить и на сервере, подняв lein repl в докер контейнере на проде, не занимался таким. По фронту, важный момент в ClojureScript hot-reload, в том что не теряется стейт, когда у вас большое SPA терять стейт по F5 при разработке, становится расточительной тратой времени.
Непонятно что вы имеете ввиду под "реализации Elm архитектуры на CS", и как вы себе это представляете. Если вам интересно как на ClojureScript можно работать с WebGL то могли бы воспользоваться гуглом и поковырять исходных код библиотек по типу этой: https://github.com/alexkehayias/chocolatier, обычно там Interop в какую-либо популярную js библиотеку.
По поводу WebGL имею сообщить, что в Elm не просто встроена поддержка данной библиотеки, а компилятор умеет распарсить текст шейдеров на GLSL и проверить согласованность типов между шейдерами и основной программой. Из Вашего утверждения следует, что в CS есть функциональность с аналогичным API и именно её я ожидал увидеть
с чего Вы взяли, что CS дает тоже что и Elm,
Внезапно прочитал статью выше, и ничего не увидел по WebGL.
В любом случае WebGL не мой стек. Поэтому ничего по этому поводу сказать не могу.
Из Вашего утверждения следует, что в CS есть функциональность с аналогичным API и именно её я ожидал увидеть
В моем утверждении я через запятую перечислил что дает ClojureScript. В контексте статьи.
Вы вообще понимаете что пишете? Вы хотите чтобы я изучил Elm, Elm Architecture, написал вам в этой архитектуре (WAT?) пример на ClojureScript в удобном вам стеке WebGL изучив его мимоходом, что бы вам что то доказать?
Так вот это противоречит формальной логике.
Вы на ходу меняете контекст моих доводов, додумываете что то сами, предполагаете что я могу читать ваши мысли. О какой логике может идти речь? Этот диалог потерял всякий смысл, и у меня нет никакого желания его продолжать.
Вы вообще понимаете что пишете?
да. А вы?
Вы хотите чтобы я изучил Elm, Elm Architecture, написал вам в этой архитектуре (WAT?) пример на ClojureScript в удобном вам стеке WebGL изучив его мимоходом, что бы вам что то доказать?
нет. Очевидно, вы не поняли моего вопроса. Сделайте ещё одну попытку, перечитайте внимательно мой вопрос в начале ветки, вдруг на сей раз получится понять.
Вы на ходу меняете контекст моих доводов, додумываете что то сами, предполагаете что я могу читать ваши мысли. О какой логике может идти речь?
О формальной. Я попросил Вас обосновать одно из Ваших утверждений, поскольку считаю его ложным.
«Доказывать обязан тот, кто утверждает, а не тот, кто отрицает.» Положение римского права.
Вы как выяснилось ничего обосновать не можете. Отсюда следует, что Вы спороли фигню, ляпнули не подумав.
Мое высказывание: "Из плюшек дает все тоже самое — функциональщина, иммутабельность, легкий рефакторинг, мощный REPL."
Вы вырезали из него "дает все тоже самое" придумали удобный вам контекст. И далее действовали как троль.
Вам достаточно таких обоснований?
придумали удобный вам контекстэто вы фантазируете сейчас. Вы хорошо понимаете смысл словосочетания «все тоже самое» в русском языке, или мне привести его здесь для Вас?
Вам достаточно таких обоснований?Я несколько раз написал, что именно в Вашем случае является обоснованием. Вы, похоже, ни с первого, ни со второго раза не схватываете.
re-frame интересный, да. Могу ошибаться, похоже subscribe там имеет иную семантику нежели чем сейчас в Elm, что-то типа подписки на FRPшные сигналы.
Про плюсы Elm в статье упоминалось, а вот минусы никак не были освещены.
Как по мне, самая большая проблема с Elm это даже не синтаксис, а интеграция с уже существующими библиотеками. Там как бы 2 пути: либо использовать порты (актуально для библиотек с сайд эффектами), либо переписывать на Elm (возможно есть еще какой-то путь). Было бы интересно если бы Вы как-то затронули эту темы.
А так, спасибо за популяризацию ФП :)
- нет тайп-классов и do-нотации
- асинхронность только через сообщения, нельзя сделать async/await
Он абсолютно недружелюбен ни к верстальщикам, ни к их привычным инструментам.
Та же проблема, что с JSX, но несколько глубже.
Я в курсе про причины, почему так сделано. Но от этого не легче. Мне не настолько нужна компиляция шаблонов с проверкой типов, а вот верстку делегировать выгодно.
module ChildModule exposing (Msg, view, update..) -- экпозить только сам тип событий, а все его конструкторы скрывать
type Msg
= ...
module Main
import ChildModule
type Msg
= ChildMsg Child.Msg
| ..
И далее в Main — Cmd.map ChildMsg… Sub.map ChildMsg… и т.п.
Тоже смотрел на Elm с прицелом на фронтенд-язык на будущие года 3-5. Понравилось:
- Статические типы, хорошие сообщения об ошибках
- Машинная проверка совместимости API по semver
- Очень просто начать
- Инструменты и поддержка редакторов. В Emacs завелось сразу всё (форматирование, автодополнение и т.д.), правда проверка кода на лету сделана своей штукой вместо flycheck и есть некоторые проблемы с интеграцией. elm-reactor тоже порадовал.
- Простой код. 3 вещи, о которых надо заботиться, всё по MVC. Никаких компонентов, биндингов, корней модели и прочей чепухи, которую предлагают в том же Angular 2.
- Подытоживая, "встроенный в язык фреймворк".
Не понравилось:
- В основном, делает 1 человек.
- У проекта 1 хоть сколько-нибудь серьёзный коммерческий пользователь (NoRedInk). Там работает второй заметный участник проекта.
- Никаких гарантий стабильности, не всегда работают инструменты апгрейда версии Elm. Deprecation warning'и делаются недели за 2 до выхода версии.
- Релизы "от балды", нет чёткого расписания и процедура непрозрачна.
- Процесс разработки новых версий в целом не особо прозрачен, непонятно чего ждать.
- При условии использования императивного языка на бэкенде, impedance mismatch между фронтендом и бэкендом. Тяжело переключаться с одной парадигмы на другую, если ты "fullstack".
- Практически невозможно нормально использовать готовые библиотеки на JavaScript.
- Вёрстка через исходный код. Может быть сложно научить вертальщика и деплоить.
- Встроенный в язык фреймворк. Может быть минусом, если хочется гибкости.
Итого:
Очень круто для энтузиастов, но переписывать мир на Elm без серьёзной поддержки коммерческих пользователей никто не будет, а она пока отсутствует.
И ещё пару пунктов вспомнил:
- От стандартной библиотеки ощущение куцести. Например, есть родная поддержка Юникода, но например Core.Char с юникодными символами не работает — только с ASCII
- Официальная документация местами хромает. Например, в Svg куча функций, к которым даже краткое описание не написано. Помимо этого, практически нигде нет примеров того, как пользоваться пакетами. Просто "вот вам API, делайте с ним что хотите".
Как я писал приложение на Elm