Почему разработчики выступают за и против визуального и low-code программирования: причины и ответы на возражения

[panzerfaust]

Что в итоге?

Да всё то же: схоластика. Фактуры применения расчудесного лоукода на серьезных проектах как не было так и нет.

Low-code платформы прошлого поколения и low-code платформы нового поколения — это кардинально отличающиеся истории. Раньше были большие проблемы, но сегодня появляются платформы, которые несут в себе решение тех проблем, с которыми сталкивались предыдущие поколения

Эту фразу вообще можно в Среднюю Азию отправить, чтобы дефицит водных ресурсов восполнить.

[CrushBy]

Фактуры применения расчудесного лоукода на серьезных проектах как не было так и нет.

Ну мы на low-code делаем ERP-системы на lsFusion для розничной торговли (вот демка). Уже 10 лет. И прекрасно все кастомизируем под разных клиентов, имея при этом базовую версию. У самых крупных клиентов 2000 одновременно работающих пользователей, миллиарды записей и базы под 10ТБ. Что мы делаем не так ?

[panzerfaust]

Я ж не говорю, что это невозможно. Я говорю, что конкретно эта статья и множество других статьей про лоукод - просто маркетинговая вода.

[Andreas_Fogel]

Это прикол такой? У вашего lsFusion 130± звезд на гите. Может вы и есть разрабы lsFusion? Что то много рекламы в вашем комментарии, хотя сайт вообще не тянет на enterprise продукт. Рекламный ролик с картинками из нейросети, так откуда эти 10 лет использования, если последние года так 3 только только появились годные граф нейронки?

[CrushBy]

Это прикол такой? У вашего lsFusion 130± звезд на гите.

Не 130, а 180. Но можно купить любое количество. Хоть 10К. Многие индусы так и делают. Непонятно только в чем смысл.

Может вы и есть разрабы lsFusion? Что то много рекламы в вашем комментарии, хотя сайт вообще не тянет на enterprise продукт.

Достаточно зайти в мой профиль и посмотреть мои статьи, чтобы увидеть, что я и есть разработчик.

Рекламный ролик с картинками из нейросети, так откуда эти 10 лет использования, если последние года так 3 только только появились годные граф нейронки?

Какая связь ? Непосредственно разработка lsFusion началась в 2010 - это легко на Github'е и проверить. С 2015 начались серьезные внедрения в крупные розничные сети. Сейчас уже больше 100 клиентов. Некоторые с оборотом выше 1 млрд долларов. И там автоматизированы не боковые процессы, а самые что ни на есть ключевые. Это не enterprise-level ? И все это практически полностью на low-code. Причем большинство написано людьми, которые никогда не программировали на классических языках программирования.

[ALexKud]

Смотря для каких целей используются такие платформы. Все помешаны на web. А для задач работы со сложным измерительным оборудованием и интеллектуальными датчиками та же LabVIEW незаменима, е если еще в связке с сервером SQL то вообще стабильнее системы трудно представить. Задачи можно решать любые. Это конечно не сайты, а МЕS cистемы, тестирование и мониторинг оборудования и т п. Одна из моих систем работает через собственный dsl , другая тестирует платы и работает с изделиями по modbus, взаимодействует через общую БД с другой стстемой. Да, тут проблема в кадрах, и высококвалифицированных. Но на моих глазах программист под микроконтроллеры освоил за полгода ту же LabVIEW и написал крутую программу по работе по протоколу Hart c оборудованием и хранением конфигураций в XML. Поначалу его немного корежило, так как была привычка писать код, но привык. Так и нужно делать, переучивать сложившихся программеров под лоу код. Вторая специальность. Уже может и то и это. Да, это нишевые области, но они тоже нужны, не только один сплошной web.

[apsaharov]

конечно согласен - все должно быть по делу и по месту. Если речт идет о сложном вопросе где требуется ручное управление памятью и потоками, как например на одном из наших проектов мы должны быть научить RFID считыватель считывать 5000наименований за 0,2 сек, то там только руками это можно сделать

[CrushBy]

Любое решение, которое выносится вне компании — это большая зависимость от вендора. Чем больше интеграция происходит с такими платформами, тем больше ресурсов будет завязано: домены, код, процессы масштабирования

Так не используйте облачные low-code платформы с коммерческими лицензиями и закрытым кодом. Только open-source в открытой лицензией (например, как LGPLv3 у lsFusion)

Если и без того сложно найти разработчиков на популярные языки, то для нишевых low-code решений эта проблема становится еще более актуальной

Эта статья писалась сколько лет назад ? Сейчас вообще другая ситуация. Мы вывесили вакансию Программист lsFusion, где черным по белому написано, что нужно будет писать на внутреннем языке lsFusion - 600 откликов. Причем 90% из них программисты. Сейчас другой рынок - желающих писать на чем угодно полно, платили бы деньги.

А за счет low-code можно просто на сжимающемся рынке выигрывать проекты за счет в разы меньшей цены.

 И кто будет разбираться с кодом, который сгенерировала платформа

Так не надо генерировать код. Надо повышать уровень абстрагирования. Чтобы код был близкий к натуральному по типу SQL, а не по типу C++.

По мнению эксперта, LLM убирает необходимость в визуальной прослойке и делает разработку более гибкой.

Так в том и проблема, что LLM по мере роста сложности проекта испытывает те же проблемы, что и если отдать проект джуну. Накапливается технический долг за счет говнокода и дальше просто потолок. Если же поднять уровень абстрагирования, то технический долг уже будет накапливаться гораздо меньше.

Галлюцинации и несуществующие библиотеки

Опять же. LLM надо дать узкую песочницу. Иначе на таком "просторе" LLM имея доступ и память к огромному числу информации будет делать то же самое, что и джун.

Если понимаем, что проект действительно уникальный — не стоит использовать платформу. Пытаться решить нестандартную задачу стандартным инструментом — это как открывать дверь отвёрткой вместо ключа. Технически возможно, но зачем

Так наоборот же. Если задача типовая, то зачем вообще low-code ? Нужно брать готовую коробку под эту типовую задачу. Low-code как раз часто нужен, когда нужно сделать что-то уникальное, когда нет игрока на рынке, которому есть смысл вкладываться в коробку.

[apsaharov]

про узкую песочницу в точку! такой же подход у нас

[TimurZhoraev]

Лоукод хорош там где для него создана инфраструктура. То есть для него уже должны быть инструменты не из разряда терминала 60-х и гипертекстовой разметки 80-х как надстройка над ними а изначально заточенные WYSIWYG обладающие ёмкостью консоли и удобства графики, вбирающие синхронизацию фронта с бекендом на более-менее единой платформе без зоопарка, дошедшего до того что CSS/HTML/JS/WASM уже почти взаимозаменяемые по функционалу. Вопрос ещё в точке входа - учить свежий специализированный редактор или море литературы, об одном и том же на протяжении вот уже 40 лет. Плюс "Закон Мура для тактовой частоты" уже стоит на месте. Как летал условный Матлаб на машине 20-ти летней давности так до сих пор +- одно и тоже. Это создаёт ограничение для новых инструментов. Поэтому пока не будет всё сведено к стандарту уровня W3C/IEEE/ISO/ИТД/ИТП, сложно говорить о появлении такого рода инструментов. Конечно есть UML, но не для восьмибиток, и вот таких разрывов огромное множество. В ту же оперу среды разработок ПЛК или схематики на ПЛИС с блоками на HDL - тоже микс между визуалом и кодом. Или интеграция Python во FreeCAD, AutoLISP в AutoCAD, или наоборот OpenSCAD как некие мета-языки.

[nektopme]

Потому что привычка.
Живем в лесу, молимся колесу.
Часть программировавших на машинных кодах, не хотела переходить на ассемблер.
Часть программировавших на ассемблере, не хотела переходить на Fortran ...

По привычке рассказывают:
«получается здоровенное полотно из соединённых блоков. Связи становятся настолько запутанными, вложенные структуры настолько многоуровневыми, что охватить это взглядом уже невозможно».

Догадываюсь чем они "охватывают".
В голове крутят код.

У них может и карта метро есть кодом?

Вместо задействования "видеокарты головного мозга" - увидел и понял, привычка не даёт им перейти на следующий уровень владения сложностью проекта.

Отсутствие привычки думать естественно (визуально) порождает избытки абстракций - некому подсказать простой путь.

После привыкания к визуальному проектированию программ - глядеть в сгенерированный код хочется всё меньше и меньше - его же нужно понимать, а это гораздо сложнее чем понимать его схему.
Привычка!

Визуальное мышление человеу выгоднее и естественнее скриптового компьютерного.

"Привычка свыше нам дана: Замена счастию она".

Привычка не даёт вспомнить, что программист может менять, перепрограммировать привычки на более выгодные.

Некоторые пути не доступны, если их не увидеть.

"Многое в искусстве, в творении — это открытия, и Вы не сможете ничего открыть, если не видите того, что делаете." Виктор Брет.

Большая часть зрячих может увеличить удовольствие от программирования, скорость работы, надёжность программ, привыкнув использовать визуальные средства разработки программ, генерирующих код.

Это биологически выгодно.

[code07734]

Эта же статья без воды - "Смотря какой fabric смотря сколько details"

[Asterris]

То же самое и с BI, например. Красивая диаграмма нужна, чтобы быстро очертить проблему. А изучать её можно только по полотнам экселевских табличек - и никакой серьезный стратег или аналитик никогда не будет испытывать дискомфорта, глядя на лист А2, заполненный цифирками 9 шрифтом - для них они гораздо информативнее любой инфографики.

[apsaharov]

ну все же иногда, очень редко конечно, но визуально многое становится более понятным. Например, видны локальные эксьтремумы, видны пересечения графиков, можно анализировать связность и похожесть графиков, а также многие вещи которые смотря просто на цифры сложно понять. Хотя конечно у многих экспертов уже так набит глаз, что они и так все прекрасно видят=)

[jakobz]

Почему разработчики протестуют? Да потому что нам на этом потом «писать». Сколько я видел проектов, где какая-нибудь Camunda приделывается с идеей «мы сейчас BA посадим самих процессы строить». А заканчивается всегда тем, что всё это пилят те же разработчики, в 5 раз дольше, и которым еще доплачивать надо за вредность.

DSL, любой - визуальный или нет, почти всегда плохая идея. По той же причине, что и «давайте все перепишем» - почти никогда не работает. Если хочется поднять уровень абстракции надо строить поверх готового - идти в eDSL, или вообще делать обычные библиотеки.