Плагин для Elixir бесполезен чуть менее, чем полностью. Pure Elixir проектов не бывает, а сосуществовать с erlang-плагином нормально elixir-плагин не умеет толком.
И что, для него есть production-ready реализации для Java, ObjC/Swift и какого-нибудь серверного языка?
Не говоря уже о том, что он текстовый и наверняка не имеет кодогенерации.
У меня есть смутные подозрения, что это все вызвано некими особенностями OSX, с которыми столкнулись разработчики клиента Dropbox.
Вообще не вижу других причин тратить столько сил.
> «Если ты не можешь объяснить что-то шестилетнему ребенку, то ты сам этого не знаешь.»
Это раз.
Два — я не вижу в объяснениях никакой проблемы — мне ничто не мешало рассказывать своей девушке про абсолютно технические вопросы, когда я занимался, например, доработкой упаковщика MPEG TS.
Конечно, приходилось говорить много и с большими экскурсами, но если вам не нравится рассказывать, чем вы занимаетесь — вы занимаетесь чем-то не тем.
Не нужно лепить баззворды без необходимости, вот в чем дело.
Вообще, «ООП» это очень расплывчато определенное понятие, которое после многих лет странных трактовок лучше перестать употреблять.
Что такое «инкапсуляция» и «полиморфизм» по отдельности, как работает наследование в C++ или Java или .NET или Python — понятно. Особенности JS или Smalltalk тоже можно изучить. Зачем нужны паттерны проектирования в определенных языках — тоже более менее понятно. То есть, все практически-значимые вопросы не вызывают у меня вопросов.
Вот только это все почти не имеет отношения к собственно ООП. Что такое ООП в целом — мне непонятно, и, честно говоря, не очень хочется это «понимать». Есть практические реализации ООП как его поняли авторы конкретных языков, это важно понимать. А сферическое ООП в вакууме, о котором тут куча камментов, как минимум ненужно, а то и вредно.
А вот про продуманность я бы очень сильно поспорил, в языке, stdlib и plug есть достаточно просто абсурдных вещей, про которые авторы считают, что все ок. Я когда-нибудь напишу пост о них, когда не лень будет.
Все там нормально работает. Там есть пара странностей в духе «если в конфиге nil, Application.get_env :app, :var_name, 123123 вернет nil, а не 123123», но никакого кеширования конфигов между запусками нет и не может быть by design.
Другой дело, если у вас значения из ENV через конфиг используются в макросах, тогда да, нужно будет перекомпилировать проект. Где в Phoenix макросы я точно не знаю, но в этом случае точно ничего удивительного нет. В этом случае рекомендую делать touch config/config.exs перед каждым запуском.
Вам лично — «двойка» за умение формулировать проблемы.
Конфиги в Elixir — небольшой сахар для application env в Erlang, в котором хранятся статические значения. Так что, ничего удивительного в этом нет.
Ну и вообще, вы что, хотели, чтобы в application env лежали thunk-и, которые вычислялись про каждом вызове Application.get_env?
Нет, из коробки ничего подобного нет и не будет. Хотя бы потому, что это невозможно нормально подружить с hot code reload как он реализован в BEAM.
Ну и вообще, моя обычная рекомендация — не пользуйтесь релизами, это непростая в использовании и очень специфичная фича, она категорически не для всех.
Все перечисленное из мира clojurescript нормально работает с реактом. Om — react-based framework, атомы — это абсолютно библиотечная фича для синхроницированного доступа к данным, datascript — это библиотека предоставляющая упрощенную in-memory версию известной в узких кругах БД Datomic.
Итого, один фреймворк поверх реакта и две библиотеки, которые ничто не мешает с ним использовать.
Для JS есть куча разного качества реализаций Flux, но в детали я не вдавался. На redux я посмотрел на волне хайпа, понял, что ничего не понимаю и не очень хочется, и закрыл этот вопрос для себя.
Добавлю, что redux, например, феноменально сложный для такого небольшого количества кода.
Реакт сам по себе простой. Фичи для хранения стейта из clojurescript(не интересовался чистым JS, увы) — атомы из clojure.core, курсоры из om, datascript — простые и понятные.
Redux — невыносимо непонятный, и почему его все так форсят для меня загадка. Непонятнее его для меня только cycle.js, наверное.
Плагин для Elixir бесполезен чуть менее, чем полностью. Pure Elixir проектов не бывает, а сосуществовать с erlang-плагином нормально elixir-плагин не умеет толком.
Не говоря уже о том, что он текстовый и наверняка не имеет кодогенерации.
Вообще не вижу других причин тратить столько сил.
> нарушения кровоснабжения конечностей после травматического нарушения целостности вен
Как про это может быть неинтересно слушать?..
> «Если ты не можешь объяснить что-то шестилетнему ребенку, то ты сам этого не знаешь.»
Это раз.
Два — я не вижу в объяснениях никакой проблемы — мне ничто не мешало рассказывать своей девушке про абсолютно технические вопросы, когда я занимался, например, доработкой упаковщика MPEG TS.
Конечно, приходилось говорить много и с большими экскурсами, но если вам не нравится рассказывать, чем вы занимаетесь — вы занимаетесь чем-то не тем.
Вообще, «ООП» это очень расплывчато определенное понятие, которое после многих лет странных трактовок лучше перестать употреблять.
Что такое «инкапсуляция» и «полиморфизм» по отдельности, как работает наследование в C++ или Java или .NET или Python — понятно. Особенности JS или Smalltalk тоже можно изучить. Зачем нужны паттерны проектирования в определенных языках — тоже более менее понятно. То есть, все практически-значимые вопросы не вызывают у меня вопросов.
Вот только это все почти не имеет отношения к собственно ООП. Что такое ООП в целом — мне непонятно, и, честно говоря, не очень хочется это «понимать». Есть практические реализации ООП как его поняли авторы конкретных языков, это важно понимать. А сферическое ООП в вакууме, о котором тут куча камментов, как минимум ненужно, а то и вредно.
Ну есть у вас сущность и набор операций над ней, причем тут ООП?
Другой дело, если у вас значения из ENV через конфиг используются в макросах, тогда да, нужно будет перекомпилировать проект. Где в Phoenix макросы я точно не знаю, но в этом случае точно ничего удивительного нет. В этом случае рекомендую делать touch config/config.exs перед каждым запуском.
Вам лично — «двойка» за умение формулировать проблемы.
Вообще говоря, ничего подобного происходить не должно, но я пока не могу найти, где там ошибка.
Вообще, конечно, разработчики Elixir меня удивляют все больше и больше.
Ну и вообще, вы что, хотели, чтобы в application env лежали thunk-и, которые вычислялись про каждом вызове Application.get_env?
Нет, из коробки ничего подобного нет и не будет. Хотя бы потому, что это невозможно нормально подружить с hot code reload как он реализован в BEAM.
Ну и вообще, моя обычная рекомендация — не пользуйтесь релизами, это непростая в использовании и очень специфичная фича, она категорически не для всех.
Итого, один фреймворк поверх реакта и две библиотеки, которые ничто не мешает с ним использовать.
Для JS есть куча разного качества реализаций Flux, но в детали я не вдавался. На redux я посмотрел на волне хайпа, понял, что ничего не понимаю и не очень хочется, и закрыл этот вопрос для себя.
Иммутабельность к вашим примерам не имеет никакого отношения.
Реакт сам по себе простой. Фичи для хранения стейта из clojurescript(не интересовался чистым JS, увы) — атомы из clojure.core, курсоры из om, datascript — простые и понятные.
Redux — невыносимо непонятный, и почему его все так форсят для меня загадка. Непонятнее его для меня только cycle.js, наверное.
Чистыми — являются.