Мне кажется, впринципе суть парсера в том, что он декларативный — во всех языках. А если нет — то это то, что автор статьи называет "велосипедом". А вот велосипеды уже разные — декларативный в ФП и императивный в ИП)
Если говорить на уровне "серьёзных книг", то после 1994 года, когда вышла "Design patterns" от GoF, реализовывать полиморфизм через наследование, а не через композицию — дурной тон.
Да и впринципе, посмотрите на современные реализации полиморфизма — сперва была мода duck typing во всяких там динамических языках, теперь — полная реализация интерфейса как к примеру в Rust.
Полиморфизм есть — наследования нету. Так что что-то у вас не сходится.
Теоретически такое можно отследить каким-нибудь статическим анализом, но я не встречал реализации пока что. И такие ошибки надо отлавливать в тестах.
А падает в данном случае зацикленный GenServer. Если add_student внутри использует cast — вызывающий процесс ничего не заметит. Если call — зависит от реализации, но если вы не отлавливаете ошибки — упадёт вызывающий процесс тоже.
В любом случае, скорее всего у вас должен быть супервизор который перезапустит или один или оба генсервера.
Мне кажется, что "умные дома" страдают не от отсутствия стандартов, а от отсутствия "стандартов".
Как только появится "ЗверУмныйДом на одном ДВД" — все сразу будут представлять себе "умный дом" именно так.
Если вы написали собственный механизм миграций — то и edeliver у надо будет рассказать как мигрировать.
Если вы используете ecto — то он и сам знает.
Вот что значит "на автомате"
По-моему, нигде в проекте на хранятся пользовательские данные. Если это картинки и файлы — в отдельной папочке, которая даже не обрабатывается beamом, а сервится прямо нгинксом.
Я может быть сейчас от незнания сморожу, но можно ли писать под эту ОС на Rust?
Мне кажется, что аналогичная статья про Rust (если можно конечно), была бы очень интересна (благодаря хайпу), и возможно я (и даже куча других людей) бы даже попробовал свои силы в написании каких нибудь программ под эту ОС.
Статья просто потрясная! Очень коррелирует с моими мыслями по поводу Rails.
Показушная "простота" работает хорошо только до тех пор, пока не надо чуток выйти за рамки. В тот момент когда это происходит, совершенно теряется понимание "что делать", код превращается в макароны из грязных хаков и теряет полностью свою простоту и привлекательность.
ЗА адептами Рельсов очень интересно наблюдать тогда, когда они пытаются написать что-то на… Ruby! ActiveSupport — это по сути новый язык программирования.
По моим ощущениям, создание rails приложения — это сборка камней/гемов — как в лего, только вся сложность начинается в тот момент, когда эти кубики надо собрать вместе. Когда гем подключается одной строчкой и делает кучу вещей — я его просто боюсь! А такие "батарейки" — везде.
Самое главное, API Рельсов не очевидное, не однозначное, и разработчика на Рельсах по сути ничего не заставляет его как то изучать и понимать. Можно создать десяток сайтов на Рельсах и так и не узнать, что скрывается за волшебным словом Rack, и чем middleware гемы отличаются от "не middleware"!
Ничего не имею против ActiveRecord, если чувствовать пределы, его использовать очень удобно. Но когда можно забрать модель из формы через :params и сохранить как есть одной строчкой как в статье — это рождает миллионы вопросов на SO — "Почему сохраняет пустую модель/не сохраняет ничего" которые просто нереально чинить — там всего одна строка!)
Очень бы хотелось обсудить предыдущую статью автора, в которой он осуждает monkey patching: если не ActiveSupport, то как? Если многим это удобно, то писать RFC к самому Руби? 10.years.ago — возможно это должно быть в стандартной библиотеке?
А что касается проблем ООП — мне кажется Руби — не показатель плохости такой парадигмы. Monkey patching и вся рефлексия — это по сути нарушение инкапсуляции. И это то, что самое крутое в руби, с его method_missing, символами и открытиями классов в любом месте вашего кода. А ведь именно на этом строится такая "классная" ActiveRecord, роутинг, ActiveSupport. Оставь в Рельсах "чистое" ООП — и от всей прелести Релься ничего не останется.
Мне кажется, вы всё же немного путаете Реакт с его инфраструктурой. На сегодняшний день webpack-ом собирается react вместе с css в файл мой_апупенный_апп.js, который подключается в тег script и может "хостится на гитхабе". Туда же можно подключить и react-router (хотя это не обязательно). Туда же можно подключить flux библиотеку (хотя это тоже не обязательно). Конечно, этот js и весить будет опупенно, но разговор же не об этом.
Впрочем, что касается бэкэнда, то большинство js spa фреймворков его не требуют. Или Angular, Backbone, Knockout не могут работать только на чужих апи?.
Я честно, не вижу принципиальной разницы между тем и этим. Подходы похожи, функции похожи, выбор определяется только вкусом и модой — кого-то бесит jsx, а меня, например, знак $.
react-router не имеет отношения к react в плане UI. Вы можете использовать react без роутеров. Или использовать react-router вместе с webcomponents. Или использовать react с любым роутером, который вы планируете использовать с webcomponents.
Да и в принципе, если использовать какой-нибудь redux можно не использовать роутинг вообще.
Мне почему-то казалось, что Реакт вот прям так как вы написали здесь и работает.
И отдельно, что касается "raw html"… Мне почему-то кажется, что html вообще должен умереть. С развитием SPA js всё теснее будет интегрироваться с html, и в какой то момент html превратится в xaml — этакое чудо, лежащее только в исходниках. И в этот момент с jsx переехать в новые реалии будет очень просто.
Мне почему-то кажется, что рефлексия сильно замедляет процесс работы кода. Можно, конечно же, накрутить через неё всяких крутых штук, но тогда Вы получите что-то равно по скорости Руби, а ничего круче Руби с такой же скоростью придумать нереально.
Вывод — Го может принимать только не замедляющие его работу фичи, а значит рефлексия это то, что Пайк будет советовать не использовать.
Сравните эти идеи с идеями zero cost abstractions в рантайме — и получите, что Go это плохо спроектированный для функциональщины язык.
Согласен полностью. Отсутствие generics превращает рутину в… рутину. Можно набрать в проект много мяса, и быстро начать разрабатывать, только вот похоже, что БЕЗ мяса на Го не очень то и попишешь…
Мне кажется, впринципе суть парсера в том, что он декларативный — во всех языках. А если нет — то это то, что автор статьи называет "велосипедом". А вот велосипеды уже разные — декларативный в ФП и императивный в ИП)
Если говорить на уровне "серьёзных книг", то после 1994 года, когда вышла "Design patterns" от GoF, реализовывать полиморфизм через наследование, а не через композицию — дурной тон.
Да и впринципе, посмотрите на современные реализации полиморфизма — сперва была мода duck typing во всяких там динамических языках, теперь — полная реализация интерфейса как к примеру в Rust.
Полиморфизм есть — наследования нету. Так что что-то у вас не сходится.
Теоретически такое можно отследить каким-нибудь статическим анализом, но я не встречал реализации пока что. И такие ошибки надо отлавливать в тестах.
А падает в данном случае зацикленный GenServer. Если add_student внутри использует cast — вызывающий процесс ничего не заметит. Если call — зависит от реализации, но если вы не отлавливаете ошибки — упадёт вызывающий процесс тоже.
В любом случае, скорее всего у вас должен быть супервизор который перезапустит или один или оба генсервера.
В принципе да, но мой комментарий не для автора статьи, а для читателей — ещё раз акцентирую внимание и представляю "правильный" кусок кода.
Если вы решите делать такое в реальном коде — функция
newне приветствуется.Мне кажется, что "умные дома" страдают не от отсутствия стандартов, а от отсутствия "стандартов".
Как только появится "ЗверУмныйДом на одном ДВД" — все сразу будут представлять себе "умный дом" именно так.
Если вы написали собственный механизм миграций — то и edeliver у надо будет рассказать как мигрировать.
Если вы используете ecto — то он и сам знает.
Вот что значит "на автомате"
По-моему, нигде в проекте на хранятся пользовательские данные. Если это картинки и файлы — в отдельной папочке, которая даже не обрабатывается beamом, а сервится прямо нгинксом.
mix edeliver migrate
Если экто — то на автомате
А если не пользоваться релизами, тогда как? Каждый раз git pull?
Что насчёт
System.get_envв конфиге?Все непонятные параметры — это синтаксический сахар к понятным параметрам.
Все очень хорошо описано на сайте elixir в разделе basic types
Я может быть сейчас от незнания сморожу, но можно ли писать под эту ОС на Rust?
Мне кажется, что аналогичная статья про Rust (если можно конечно), была бы очень интересна (благодаря хайпу), и возможно я (и даже куча других людей) бы даже попробовал свои силы в написании каких нибудь программ под эту ОС.
Ну а если нет — тогда ждём....
Статья просто потрясная! Очень коррелирует с моими мыслями по поводу Rails.
Показушная "простота" работает хорошо только до тех пор, пока не надо чуток выйти за рамки. В тот момент когда это происходит, совершенно теряется понимание "что делать", код превращается в макароны из грязных хаков и теряет полностью свою простоту и привлекательность.
ЗА адептами Рельсов очень интересно наблюдать тогда, когда они пытаются написать что-то на… Ruby! ActiveSupport — это по сути новый язык программирования.
По моим ощущениям, создание rails приложения — это сборка камней/гемов — как в лего, только вся сложность начинается в тот момент, когда эти кубики надо собрать вместе. Когда гем подключается одной строчкой и делает кучу вещей — я его просто боюсь! А такие "батарейки" — везде.
Самое главное, API Рельсов не очевидное, не однозначное, и разработчика на Рельсах по сути ничего не заставляет его как то изучать и понимать. Можно создать десяток сайтов на Рельсах и так и не узнать, что скрывается за волшебным словом Rack, и чем middleware гемы отличаются от "не middleware"!
Ничего не имею против ActiveRecord, если чувствовать пределы, его использовать очень удобно. Но когда можно забрать модель из формы через :params и сохранить как есть одной строчкой как в статье — это рождает миллионы вопросов на SO — "Почему сохраняет пустую модель/не сохраняет ничего" которые просто нереально чинить — там всего одна строка!)
Очень бы хотелось обсудить предыдущую статью автора, в которой он осуждает monkey patching: если не ActiveSupport, то как? Если многим это удобно, то писать RFC к самому Руби? 10.years.ago — возможно это должно быть в стандартной библиотеке?
А что касается проблем ООП — мне кажется Руби — не показатель плохости такой парадигмы. Monkey patching и вся рефлексия — это по сути нарушение инкапсуляции. И это то, что самое крутое в руби, с его method_missing, символами и открытиями классов в любом месте вашего кода. А ведь именно на этом строится такая "классная" ActiveRecord, роутинг, ActiveSupport. Оставь в Рельсах "чистое" ООП — и от всей прелести Релься ничего не останется.
Мне кажется, вы всё же немного путаете Реакт с его инфраструктурой. На сегодняшний день webpack-ом собирается react вместе с css в файл
мой_апупенный_апп.js, который подключается в тег script и может "хостится на гитхабе". Туда же можно подключить и react-router (хотя это не обязательно). Туда же можно подключить flux библиотеку (хотя это тоже не обязательно). Конечно, этот js и весить будет опупенно, но разговор же не об этом.Впрочем, что касается бэкэнда, то большинство js spa фреймворков его не требуют. Или Angular, Backbone, Knockout не могут работать только на чужих апи?.
Я честно, не вижу принципиальной разницы между тем и этим. Подходы похожи, функции похожи, выбор определяется только вкусом и модой — кого-то бесит jsx, а меня, например, знак
$.react-router не имеет отношения к react в плане UI. Вы можете использовать react без роутеров. Или использовать react-router вместе с webcomponents. Или использовать react с любым роутером, который вы планируете использовать с webcomponents.
Да и в принципе, если использовать какой-нибудь redux можно не использовать роутинг вообще.
Мне почему-то казалось, что Реакт вот прям так как вы написали здесь и работает.
И отдельно, что касается "raw html"… Мне почему-то кажется, что html вообще должен умереть. С развитием SPA js всё теснее будет интегрироваться с html, и в какой то момент html превратится в xaml — этакое чудо, лежащее только в исходниках. И в этот момент с jsx переехать в новые реалии будет очень просто.
Вы точно уверены, что это Go код? В Go лямбды обозначаются не так:
Да и на Ruby это не похоже.
Но, если вы взяли код из C#, то какое это отношение имеет к моему комментарию?
Мне почему-то кажется, что рефлексия сильно замедляет процесс работы кода. Можно, конечно же, накрутить через неё всяких крутых штук, но тогда Вы получите что-то равно по скорости Руби, а ничего круче Руби с такой же скоростью придумать нереально.
Вывод — Го может принимать только не замедляющие его работу фичи, а значит рефлексия это то, что Пайк будет советовать не использовать.
Сравните эти идеи с идеями zero cost abstractions в рантайме — и получите, что Go это плохо спроектированный для функциональщины язык.