Обновить

Комментарии 10

Почему именно текстовой декларативный язык, а не визуальная low-code среда

Все-таки это тяжело - работать с текстовым представлением pipeline-ов. Мне например (да и многим) нужна визуализация. В этом направлении, например, идут разработчики Apache Camel (стандарт для интеграции разнородных источников данных, не смотрели его?) - Camel Caravan.

да, я в курсе практически всех средств интеграции.

apache camel и его сопроекты использовал более 14 лет, так же аналоги pentaho, бизталковых серверов итд

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

" после некоторого уровня сложности " - как часто встречается такой уровень сложности, что визуальная low-code среда начинает путать?

Было бы здорово, наверное, предусмотреть разные варианты:
90% - визуальное построение, так как пайплайн простой
10% - язык для сложных случаев

а зачем что тот"рисовать", если сейчам проще агенту дать отписание словами и он сгенерил намного быстрее чем это отрисуется мышкой.

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

Вчера написал SQL на 2,5 тыс строк.

Насколько проще и быстрее было бы это сделать на SAP Hana CalcView, где выборки и обработки графически делаются...

а что заняло большую часть строк? перечисление полей?

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

ведь среда разработки уже давно не notepad.

сам ораклист с 90х, все время toad использовал, нормальные подсказки и форматирование - вот ключ.

зато, можно прекрасно отслеживать различия в разных версиях запросов

вдогонку, ранее ведь redhat выпускала fuse и там были плагины для эклипса с визуалтным построением маршрутизации, но что то все это не прижилось.

AI меняет весь IT ландшафт просто какими-то невообразимыми темпами. Для меня это очевидно.Примеров тому масса и тут и на других ресурсах.

Какие-то нишевые решения останутся, которые являются де-факто стандартами и поверх них накрутят разных интеллектуальных ассисентов (если чего-то нет) и все - задача решена. Ну, там делать по большому счету нечего - двигаться надо дальше (отдельная и большая тема - куда).

redhat выпускала fuse

Значит кривое было и неудобное для использования и в далеком прошлом (по меркам IT). Вот и весь сказ. Такого полно, в части визуальной работы с pipeline-ами (и не только) мало действительно удобных приложений. Но сейчас время другое, удобно и функционально с помощью AI можно сделать достаточно быстро и не тратить годы и месяцы на разработку (если что - опыт в этом деле в наличии).

поэтому я и выбрал именно язык, а не визуальную нотацию, так как прикрутить к языку ai сейчас не является проблемой.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации