Comments 17
Удачного вайбкодинга!
А ты умеешь в сарказм. Но статья прям хорша, спасибо
Мне всегда хотелось, чтобы остов приложения задавался конфигурацией, а я бы только добавлял бизнес-логику. Буквально, в уже сгенерированные для неё места.
Не кажется ли вам, что вы переоткрыли подход low-code (который ранее переоткрыл Rapid Application Development, который... - и так далее, вглубь истории)?
А вообще, удачи в создании нового фреймворка, может быть - даже первого на ваших изотерических языках. А то фреймворки на JS у всех на слуху, а про ваши изотерические языки, как оно там с фреймворками, я, например, даже не слышал.
А что до вайбкодинга, то для него него вам надо поднакописть кодовую базу. Будет база - будет вам и ваш любимый вайбкодинг, например, чтобы вайбкодить эти самые конфигурации. А потребность в вайбкодинге от смены парадигмы с императивной на декларативную никуда не денется. Потому что декларативный подход сложность, на самом деле, не убирает. Вон, судя по народной любви к ORM, на том же SQL народу программировать работу с БД ничуть не проще, чем с навигационным доступом к БД (типа, как в Clipper).
Не кажется ли вам, что вы переоткрыли подход low-code […]
Нет. Из текста понятно, что ничего общего с low-code в этом решении нет.
про ваши изотерические языки, как оно там с фреймворками, я, например, даже не слышал
Нет там фреймворков, куда уж. Discord, Pepsico, J.P. Morgan, Mozilla, BBVA, да все буквально — прямо в машинных кодах херачат.
А что такое «изотерические», кстати?
фреймворки на JS у всех на слуху
Вы путаете фреймворки и костыли.
Из текста понятно, что ничего общего с low-code в этом решении нет.
Из одного только текста - наверное. Но КДПВ смущает: это интефейс дизайнера или так, чисто для красоты?
А что такое «изотерические», кстати?
Опечатка.
Вы путаете фреймворки и костыли.
Нет. Фреймворк - это почти готовая программа, в которой достаточно в некоторые места подключить свой код, выполняющий полезную работу, не тратя силы на всяки церемонии, чтобы заставить программу работать в той среде, для которой она предназначена. Фреймворки JS (React с обвязкой, Vue, Angular и иже с ними) AFAIK вполне это реализуют.
Вы, кстати, тоже делаете если не low-code, то, по крайней мере, фреймворк.
Дискуссия превращается в теософско-терминологическую, но я всё-таки вижу кардинальное отличие между тем, что делаю я, и целями, которых добились авторы JS-фреймворков.
Я не заметаю нативную реализацию под ковер, наоборот: я её буквально выпячиваю. Действительно, имплементация моей стейт-машины не потребует писать код для проверки консистентности, имплементация моего подписчика — не заставит написать весь пабсаб, «вместе с бананом вы не получите джунгли». Но я не приношу никаких новых абстракций. Буквально вообще: у вас в руках все те же самые примитивы, которые были бы в голом эрланге, просто добрый человек за вас ⅞ уже реализовал (и проверил, что ошибок нет).
Упомянутые библиотеки JS приносят такой же вагон новых примитивов, какой был в ванильном языке. Вы просто вместо Javascript Language используете для написания кода React Language. Который может быть даже лучше, чем ванилька, но это не важно. Это не фреймворк, это новый язык, со своими проблемами, тараканами и скелетами по шкафам.
Если ваш проект на самом деле ничего не привносит - он бесполезен
Это не фреймворк, это новый язык, со своими проблемами, тараканами и скелетами по шкафам.
Новый язык, точнее, расширение существующего, приносит даже не фреймворк, а просто билиотека - обычно библиотека всё же добавляет свой набор примитивов.
Да, это, безусловно, более корректно, но, как всегда, дело в балансе.
Если библиотека принесла функцию $, как сделала в своё время jQuery, или новые (недостаточно вспомненные старые) веб-компоненты, как сделал Polymer — всё в порядке, это действительно просто расширение функциональности. Код понятен, стандарт уважен.
Но Реакт (и в меньшей степени Ангуляр) принес ведь не расширение языка. Если забыть линкануть jQuery — отвалится анимация и (в худшем случае) навигация. Если забыть линкануть Реакт — страница окажется абсолютно неработоспособной.
Тут всё-таки стоит разделять серверный и клиентский рендеринг. Если при клиентском рендеринге без подключения Реакта кина не будет - это абсолютно нормальное поведение (так и было задумано).
Мне в Реакте не хватает, что называется opinionated. Подходы меняются от версии к версии. Next.js - это вообще порождение Сатаны. Возможно, идея пререндера на сервере и гидратации html на клиенте изначально и была относительно неплоха. Но после того, как начали писать в, так называемых, серверных реакт компонентах SQL-запросы в базу, я перестал следить за развитием этого кхм... фреймворка.
На Реакте можно писать сносный код, но это надо специально стараться. Никто не ударит по рукам, если нет. Тайпскрипт немного скрашивает жизнь, однако он тоже есть суррогат и не является панацеей. Sad but true.
С возвращением!
Переведу на раст и шарп, если дело стоящее и не очень длинное. А то задачи на работе скучные
Spring state machine? ))
Спасибо за информацию, есть над чем подумать!
Подскажите какую вашу библиотеку можно взять как основу для изучение толковых практик на elixir-е? Уровень не начальный, полусредний)
Я польщен, если можно так выразиться, но как «основу для изучение толковых практик» лучше брать не мои библиотеки (и не библиотеки Жозе, как ни странно :)) — а то, что пишет Войтек, вот хоть Req, например.
Саша Юрич еще пишет очень elixirish код. Вот, например.
Из моего кода — самый практичный — наверное — в antenna.
Мета-акторы, готовый скелет микросервиса