Комментарии 10
Да, IDE семейства IDEA шикарны, говорю как бывший vim'ер, умеющий из vim-а сделать все что угодно. (IdeaVIM плагин, конечно, мне все равно строго необходим :-)
Может, напишете статью о разработке плагина? Было бы очень интересно!
+1
Да, напишем, я думаю. Мы на самом деле реализовывали плагин не на голой IDEA, а с использованием их же GrammarKit и JFlex. Это как я понял считается стандартом для custom made языков у них (хотя точно не уверен), поэтому в статье и говорили что практически из коробки. И если с GrammarKit и JFlex набить руку, поддержку любого относительно несложного языка можно сделать за пару месяцев. Хотя конечно тот же GrammarKit нам пришлось немного подпиливать в части автоподстановки.
0
НЛО прилетело и опубликовало эту надпись здесь
Но вообще похоже что ваш язык можно, было бы заменить DSL-ем на Kotlin.
0
как сделал в свое время 1С
1С уже тоже уже отказывается от велосипеда. Сейчас уже есть IDE для 1С на базе Eclipse.
0
Спасибо за цикл статей, очень познавательно. А вы могли бы в одной из своих будущих статей затронуть проблемы, которые могут встретиться при разработке на вашей платформе, ограничения, подводные камни? Что можно решить, обойти, а с чем придётся смириться? Мы же тут все понимаем что за всё приходится в какой-то момент платить — пишем на низком уровне, большие объёмы кода, который невозможно поддерживать, пишем на высоком уровне — ограничения платформы — и вам как никому должны быть известны все ваши слабые стороны.
0
Да, была мысль, после статей Почему не…, написать Почему не lsFusion.
Хотя если вкратце, есть три основных нюанса:
1. Из-за высокой декларативности и сложных оптимизаторов, есть вопросы к Hot Deploy и холодному старту. Для Hot Deploy при небольшом изменении логики по сути необходимо сбрасывать абсолютное большинство кэшей, которые есть в системе, плюс обновлять некоторые данные, которые технически кэшами не являются, но зависят от логики в целом (скажем изменение графа классов, потребует обновление практически половины данных сервера приложений). Плюс для ускорения первоначального старта внутри построена архитектура на многопоточный запуск сервера и это тоже определенным образом усложняет реализацию Hot Deploy. Что важно, фича Hot Deploy важна не столько для продакшна, а сколько для разработки (чтобы быстро можно было посмотреть результат). Изначально предполагалось что разработчики будут стартовать только разрабатываемый модуль, но тут проблема, что при переключении модуля платформа считает что все существующие элементы в базе удалились и чистит данные. Поэтому по факту разработчики все равно стартуют всю логику (что может занимать до минуты). В будущем возможно удастся решить эту проблему (или заставить платформу не удалять данные, или действительно дореализовать Hot Deploy, сбросом кэшей / псевдокэшей), но пока проблема существует. Плюс с холодным стартом — так как невозможно предугадать действия пользователя, по сути программа дописывается на лету, а значит многие сложные оптимизаторы работают уже на рабочей базе. Как правило пропорция где-то такая: первый проход по ветке раз в 7 медленнее второго. На 3-м где-то все становится уже хорошо.
2. Из-за оптимизаторов и кэшей достаточно большой memory footprint. То есть грубо говоря ERP сервер приложений может зажрать сразу 8-10 гб, и это будет независимо от числа пользователей. То есть даже для 10. Конечно на средних / больших проектах это не критично, на как микросервис lsFusion пока плохо подходит.
3. «Большая сила — большая ответственность». Никто не мешает построить свойство из 1000 операторов (например прибыль всего предприятия), а потом материализовать (не материализуя ни одно из промежуточных свойств). Сложность инкрементального обновления при этом будет мягко говоря большая. Там внутри сотни оптимизаторов, которые будут бороться за жизнь до последнего и возможно справятся, но при нормальном уровне изоляции база все равно будет в вечном update conflict'е.
Ну и document(DocumentDetail d) < — NULL; никто не мешает написать. Правда в таком случае, такое действие будет выполняться очень долго, с огромной вероятностью приведет к нарушению каких-либо ограничений, так что к разрушительным последствиям очень вряд ли приведет (в нашей практике были локальные только инциденты, после чего мы сделали максимальные подсветки в IDE которые только можно + разнообразные защиты). Та же ситуация может быть когда администратор включит логирование каких-то очень больших данных (против этого тоже есть ряд защит). Ну и так далее в таком духе.
Хотя если вкратце, есть три основных нюанса:
1. Из-за высокой декларативности и сложных оптимизаторов, есть вопросы к Hot Deploy и холодному старту. Для Hot Deploy при небольшом изменении логики по сути необходимо сбрасывать абсолютное большинство кэшей, которые есть в системе, плюс обновлять некоторые данные, которые технически кэшами не являются, но зависят от логики в целом (скажем изменение графа классов, потребует обновление практически половины данных сервера приложений). Плюс для ускорения первоначального старта внутри построена архитектура на многопоточный запуск сервера и это тоже определенным образом усложняет реализацию Hot Deploy. Что важно, фича Hot Deploy важна не столько для продакшна, а сколько для разработки (чтобы быстро можно было посмотреть результат). Изначально предполагалось что разработчики будут стартовать только разрабатываемый модуль, но тут проблема, что при переключении модуля платформа считает что все существующие элементы в базе удалились и чистит данные. Поэтому по факту разработчики все равно стартуют всю логику (что может занимать до минуты). В будущем возможно удастся решить эту проблему (или заставить платформу не удалять данные, или действительно дореализовать Hot Deploy, сбросом кэшей / псевдокэшей), но пока проблема существует. Плюс с холодным стартом — так как невозможно предугадать действия пользователя, по сути программа дописывается на лету, а значит многие сложные оптимизаторы работают уже на рабочей базе. Как правило пропорция где-то такая: первый проход по ветке раз в 7 медленнее второго. На 3-м где-то все становится уже хорошо.
2. Из-за оптимизаторов и кэшей достаточно большой memory footprint. То есть грубо говоря ERP сервер приложений может зажрать сразу 8-10 гб, и это будет независимо от числа пользователей. То есть даже для 10. Конечно на средних / больших проектах это не критично, на как микросервис lsFusion пока плохо подходит.
3. «Большая сила — большая ответственность». Никто не мешает построить свойство из 1000 операторов (например прибыль всего предприятия), а потом материализовать (не материализуя ни одно из промежуточных свойств). Сложность инкрементального обновления при этом будет мягко говоря большая. Там внутри сотни оптимизаторов, которые будут бороться за жизнь до последнего и возможно справятся, но при нормальном уровне изоляции база все равно будет в вечном update conflict'е.
Ну и document(DocumentDetail d) < — NULL; никто не мешает написать. Правда в таком случае, такое действие будет выполняться очень долго, с огромной вероятностью приведет к нарушению каких-либо ограничений, так что к разрушительным последствиям очень вряд ли приведет (в нашей практике были локальные только инциденты, после чего мы сделали максимальные подсветки в IDE которые только можно + разнообразные защиты). Та же ситуация может быть когда администратор включит логирование каких-то очень больших данных (против этого тоже есть ряд защит). Ну и так далее в таком духе.
+2
Из-за оптимизаторов и кэшей достаточно большой memory footprint. То есть грубо говоря ERP сервер приложений может зажрать сразу 8-10 гб, и это будет независимо от числа пользователей. То есть даже для 10. Конечно на средних / больших проектах это не критично, на как микросервис lsFusion пока плохо подходит.
Микросервисы — это «побитые на маленькие по функционалу компоненты».
Количество оперативки — ничуть не является фактором, что ограниничивает применимость в микросервисах. Если использование локального диска еще является ограничивающим фактором (горизонтальное масштабирование не работает), то память нет. Упомянутые цифры для современности не являются проблемой.
«Микро» в названии микросервисов — не значит мало ресурсов.
«Микро» в названии микросервисов — значит малый функционал компонента (сервиса).
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вся мощь IntelliJ IDEA на примере одного языка (в картинках)