Программирование без языков: мир перейдет на low-code-разработку. Но ненадолго

22.06.2021      85517

Первые программисты оперировали машинными кодами, а их последователи – короткими командами ассемблера и других языков низкого уровня. На 60-е годы пришелся расцвет языков высокого уровня, а сейчас мир вступает в новую эру – программирования без кода. Аналитики Gartner заявили, что такие no-code- и low-code-инструменты к 2024 году обеспечат создание 80% всех продуктов и сервисов.

Что такое no-code- и low-code-инструменты

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

К no-code- и low-code-инструментам также относят генераторы кода. Они могут выдать текст программы, используя заранее заготовленные шаблоны и пользовательские настройки. При этом не нужно знать, как это работает изнутри, разбираться в нюансах конкретного языка программирования, типах переменных и взаимосвязи объектов.

Фактически no-code- и low-code-инструменты позволяют создавать программы людям, которые не знают ни одного языка программирования. С ними достаточно иметь базовые навыки работы на компьютере, уметь выстраивать логические схемы и хорошо разбираться в предметной области.

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

Один из примеров таких решений – Intellicode для C# от Microsoft. Это новое поколение IntelliSense, которое обучили на 2 тыс. репозиториев GitHub. Intellicode предлагает разработчикам готовые подсказки, которые повышают эффективность написания кода и снижают число ошибок.

Аналогичные решения внедряют и в no-code- и low-code-системах. Пока они находятся в зачаточном состоянии, но в какой-то момент даже неспециалисты в сфере разработки ПО смогут с ними создавать реальные программные продукты профессионального уровня.

Разработчики, а не кодеры

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

Аналитики Gartner проанализировали динамику использования различных средств программирования и установили, что к 2024 году 80% технологических продуктов и услуг будут создавать люди, которые не являются профессионалами в области технологий. И уже в течение следующего года исследователи ожидают громких анонсов в сфере ИТ от компаний, не связанных с технологиями.

В рамках исследования Gartner опросили специалистов, которые участвуют в создании технологических продуктов и услуг, используя определенные навыки: тестировщиков, DevOps, разработчиков CRM, систем искусственного интеллекта и блокчейн-решений, а также других ИТ-специалистов. Параллельно опрашивали и «нетехнических» сотрудников – например, тех, кто настраивает готовые системы аналитики и работает с их результатами, занимается обработкой данных, решает бизнес-задачи с помощью готовых ИТ-инструментов.

По словам вице-президента Gartner Раджеша Кандасвами, no-code- и low-code-инструменты способны убрать барьеры на пути к производству практически любых сложных технологий. В результате люди, которые разбираются в предметной области, но не умеют программировать, смогут самостоятельно создавать полезные решения узких задач и даже универсальные продукты, которые пригодятся и другим пользователям или компаниям.

Сейчас, по оценкам Gartner, 36% ИТ-бюджета компаний составляют расходы, инициируемые бизнесом. С приходом no-code- и low-code-инструментов сценарии, требующие написания кода, станут необязательными, и издержки сократятся.

При чем здесь пандемия

Во время пандемии мир вынужденно перешел на удаленку. Параллельно все больше компаний из самых разных секторов экономики – от розничной торговли до финансовых услуг – стали активно заниматься цифровой трансформацией бизнеса и внедрением современных ИТ-решений. В отдельных случаях это позволило компаниям освоить новые рынки.

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

В Gartner ожидают, что к 2023 году доходы от цифровых товаров и услуг, которых не существовало до пандемии, достигнет 30 млрд долларов США – это в 5 раз больше объёма российского ИТ-рынка. К 2042 году более трети поставщиков технологий будут конкурировать с нетехнологическими компаниями в рамках одних и тех же продуктовых ниш.

Альтернативное мнение

Разработчик под ником The Hosk раскритиковал исследование Gartner. Он заявил, что для создания хорошего программного продукта недостаточно просто выбрать правильные no-code- и low-code-инструменты. Такие решения – лишь способ быстрее ввести бизнес-приложения в производство. Но они не выдержат реальных нагрузок – останутся на стадии плохо написанных прототипов, которые будет сложно и дорого поддерживать.

The Hosk напомнил, что low-code-инструменты создавали и раньше: например, Gramex или Microsoft Dynamics 365, а также язык программирования Power Fx. Но они так и не стали достаточно популярными и не вытеснили традиционные подходы к разработке.

Low-code-инструменты позволяют быстро создавать рабочие прототипы, но в процессе их использования накапливается огромный технический долг. В какой-то момент от такого ПО будет дешевле отказаться и создать новое решение, чем продолжать поддержку существующего.

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

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

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

При этом разработчикам ПО придется получать навыки работы с no-code- и low-code-инструментами. И в конечном итоге эти решения будут генерировать около 50% кода приложений, а остальная часть останется за традиционной разработкой ПО.


Автор:
Обозреватель


См. также

Новость ИТ-Новость

Российский Альянс по искусственному интеллекту обновил требования к специалистам по ИИ: вышла новая модель с основными профессиями и навыками. Теперь базовых профессий в сфере ИИ осталось только четыре.

01.11.2024    670    user1915669    0       

2

Новость ИТ-Новость

Система платежей «Волна» по планам сделает возможной бесконтактную оплату для владельцев IPhone в России, а BRICS Pay позволит совершать безналичные расчеты иностранцам по картам Visa и Mastercard.

23.10.2024    896    AnastasiaKl    0       

3

Новость ИТ-компания ИТ-Новость

Конструктор сайтов Wix уходит из России с 12 сентября 2024 года – перестанут работать все российский аккаунты. Сайты, привязанные к аккаунтам, также перестанут работать.

11.09.2024    945    user1915669    2       

2

Новость Искусственный интеллект ИТ-Новость

ИИ научат разработке цифровых интегральных микросхем – несколько российских научных институтов заявили об участии в проекте. Проект рассчитан на 3 года – с 2024 по 2026.

23.07.2024    600    user1915669    0       

2

Новость Дата-центры Искусственный интеллект ИТ-Новость

Развитие искусственного интеллекта и цифровых сервисов в России стало причиной роста потребности в мощных центрах обработки данных. Эксперты прогнозируют, что дефицит ЦОД, который уже наблюдается сегодня, в ближайшие годы будет только усиливаться.

18.07.2024    720    AnastasiaKl    0       

1

Новость ИТ-Новость

В сентябре 2024 года видеоигры в России начнут маркировать – пока на добровольной основе. Геймерам будут сообщать о семи видах чувствительного (неприятного) контента в игре.

17.07.2024    801    user1915669    0       

1

Новость Законодательство ИТ-Новость

Депутаты Госдумы работают над законопроектом по ужесточению контроля за электросамокатами. Среди мер: обязательная регистрация СИМ (средств индивидуальной мобильности) и разработка системы отслеживания их перемещений.

10.07.2024    769    AnastasiaKl    2       

1

Новость Искусственный интеллект ИТ-Новость

В 2024 году «Сколково» выделит пилотным проектам в сфере искусственного интеллекта гранты на общую сумму 554 млн рублей. В результате отбора финансирование получат проекты с применением ИИ в областях производства, операционной деятельности и в работе предоставляемых сервисов.

12.04.2024    1647    AnastasiaKl    3       

3
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. A1WEB 59 22.06.21 12:38 Сейчас в теме
В типовых решениях 1С уже давно 50% кода генерируется, и это как минимум.
3. tormozit 7229 22.06.21 13:45 Сейчас в теме
(1) Можете подкрепить иллюстрацией?
4. A1WEB 59 22.06.21 14:09 Сейчас в теме
(3) Возьмите, к примеру, какой-нибудь общий модуль любого типового решения. В нем вы обязательно найдете некоторую экспортную функцию, которая состоит из одной строки, вызывающей функцию из другого модуля, но и эта функция состоит из одной строки, которая вызывает другую функцию и так два-три вложения. Ну не вручную же эти слои абстракции строятся!?! Я бы это делал по шаблону.
Печально, что нет подробной документации по этому поводу. Это значительно усложняет сопровождение.

ЗУП:
УчетСтажаПФР.РесурсыУчетаСтажаПФР()
УчетСтажаПФРВнутренний.РесурсыУчетаСтажаПФР()
УчетСтажаПФРРасширенный.РесурсыУчетаСтажаПФР();
УчетСтажаПФРБазовый.РесурсыУчетаСтажаПФР();
2. Darklight 33 22.06.21 13:22 Сейчас в теме
Бред это всё. Конечно за no-code- и low-code-инструментами будущее - но ближайшее их будущее это только в качестве дополнения - т.е. именно как дополнительные инструменты. Я ожидаю, что AI системы будут активно помогать писать код уже к середине этого века. Так же активно будет продвигаться когенерация и шаблоны кода. Но это никак не освободит от написания алгоритмов - лишь немного упростит этот процесс. Зато будет расти сложность этих алгоритмов и объём выполняемой ими работы. Будет больше времени и возможностей для тестирования - будет расти качество этих алгоритмов, их производительность, безопасность, надёжность, читаемость.
В языках программирования продолжится эволюция - переход через языки 4-го поколения (с весьма условными очертаниями) к языкам 5-го поколения (пока тоже с весьма условными очертаниями) - программирование станет более декларативным, чем похожим на математику (хотя без неё тоже в ряде задач никуда не деться).

И об этом бы архитекторам в компании 1С было бы здорово уже сейчас задуматься. Я бы, в гипотетическую систему 1С Предприятие 8 заложил бы уже сразу два основных языка программирования:
- Один более алгоритмический, математический - как Java, C# и даже как JavaScript или Python (отчасти похожий и на нынешний язык разработки в 1С Предприятие 8), остающийся где-то на стыке 3-го и 4-го поколения языков программирования - зато очень удобный для написания именно чётких алгоритмов обработки данных
- А другой - более высокоуровневый, с зачатками языка программирования 5-го поколения - более ориентированного на описание целей и действий над данными, чем самих деталей операций (они, в случае детальной необходимости описывается на первом языке) - программирование на нём должно быть более похоже на некоторую компоновку операций над данными, чем на кодирование инструкций. Некое подобие данной идеи - это язык River Definition Language. Ну и современные расширения SQL - в общем-то из той же области. Алгоритмы на языуке не компилируются (в инструкции машины выполнения) и не интерпретируются (в рантайм). Операции анализируются на стадии конфигурирования AI-ассистентом, определяются цели и действия - выполняется когенерация на первом языке для достижения этих целей и выполнения нужных действий - потом уже компиляция в инструкции машины выполнения.

На обоих языках уровень абстракции данных и алгоритмов должны быть очень высоким
5. Darklight 33 22.06.21 16:32 Сейчас в теме
(2)Вот как-то вот так выглядит в моём понимании декларативное программирование - ниже пример пустого кода - но, мало, кто сходу поймёт что там делается и как работает (локальные идентификаторы намеренно скрыты за буквенными обозначениями (чтобы не давали подсказку), оставлены только библиотечные, из типов данных, стоящих за локальными идентификаторами; здесь нет ни одного ключевого слова, всё определяется в типах данных и может быть переопределено)

a to
     filter(m) to d
     undone to n


Код простой, и в нём нет большой логики - ниже его вариация в более строгом стиле (универсальная команда undone заменена боле конкретной "empty", более логичная **** оставлена для другой логики, но ниже в примере уже с ней будет написано)

(e <- a) ->
     filter(@m(@e)) -> d(@e)
     epmty -> n()


Тоже самое в стиле C# с понятными идентификаторами


Пример на Python с понятными идентификаторами



Пример на 1C с понятными идентификаторами
6. starik-2005 3087 23.06.21 19:05 Сейчас в теме
(5) ну на питоне можно использовать функциональный стиль, что превратит код в ту же одну строку с лямбдой, генератором или даже без них,. То же самое на JS и Java, тем более в Колтлине.

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

Вот в качестве примера я постоянно приводу конвертацию. Практика показывает, что даже хреновый программист сделает обмен в коде быстрее, чем он же на этой самой конвертации. Да, какие-то очень похожие объекты перелетят из точки А в точку Б чуть ли не автоматом, но таких объектов - ноль без палочки. Контрагенты одной только контактной информации и дополнительных свойств/реквизитов потянут тонны, и если нельзя просто так взять, и записать это в Б в том же виде, то сложность сразу вырастает на порядок. Номенклатура - поехала маркировка, штрих-коды, единицы. Даже долбаный склад потащит за собой из ЕРП топологию, и если нужно в Б развернуть эту топологию в виде обычных отдельных складов, то конвертация даже перед гуру поставит очень непросто решаемую задачу, которую обычным обменом даже на хардкоде решить будет куда проще.

Лично наблюдал, когда два человека с франча и эксперт по техвопросам писали правила обмена для сильно модифицированной УТ 11.1 и почти типовой бухни 2.0 целый год, потом овер дохрена времени уходило на поддержку этого г-на с зиро-кодом. Поэтому я очень скептически отношусь к требованиям в вакухах на тему конвертации (2-й еще ладно, а 3-ю толком никто не знает, поддержка ее в наших продуктах даже при почти не меняющихся объектах вызывает первобытный ужас среди большинства разрабов, в итоге переносимость правил трансляции и прочего постоянно отваливается. Я свой механизм сделал кодом - и он не отвалился ни разу, просто дерево, упакованное в XML - написано за два дня, а только создание пакетов XDTO для 3-ки заняло пару месяцев).
7. Darklight 33 24.06.21 09:32 Сейчас в теме
(6)
ну на питоне можно использовать функциональный стиль, что превратит код в ту же одну строку с лямбдой,

Я слышал, что можно, но считается дурным стилем программирования и даже побраняется. Но было бы интересно посмотреть пример. Мне в Python не нравится синтаксис, плохо совместимый с подобной лексикой выстраивания программы.
Но суть была не в Python - а просто показать разные подходы , и пример более декларативного кода (те, что не в спойлерах). У меня уже был спор (не здесь) по поводу его читаемости. Но, мне кажется, тут просто дело привычки, хотя да - более высокоуровневый код не всегда становится более понятным чем более низкоуровневый. Те же лямбды многим не нравятся и в Питоне вообще побраняются.

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

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

Если нельзя просто так взять, и записать это в Б в том же виде, то сложность сразу вырастает на порядок.

Насколько я знаю EnterpriseData как раз и создан был для простого решения такого рода задач, в конвертации 3.0 - но сам ещё не щупал - хотя идея кажется здравой - но возможно опять с реализацией подкачали.
Конвертация - это ка перевод с оного языка на другой. Но в концепции перевода десять лет назад нашли лазейку - перевод через промежуточный язык (реальный но очень древний и уже мёртвый, но потрясающе детализированный). Вот EnterpriseData - как я понял - это и есть этот промежуточный язык но уже для данных. В общем - это уже другая тема. Уверен, что в недалёком будущем AI-ассистенты смогут решать задачи конвертации с небольшим участием программиста, и чуть большим участием Архитектора.

И ещё - проблема обмена между конфигурациями сейчас в их полном "раздрае" - там такой беспорядок в одних и тех же сущностях - мама не горюй - надеюсь рано или поздно в них придёт модульность и гибкое декларативное управление функциональностью - вот тогда настройка обмена стандартными средствами станет куда более надёжной!
А декларативное программирование позволит ещё и алгоритмы упорядочить!
8. starik-2005 3087 24.06.21 11:43 Сейчас в теме
(7)
1. Ну в питоне функциональный стиль я не сказал бы, что возбраняем. Например, генераторы и итераторы - это повсеместно используемые в питоне механизмы (я в 1С часто вижу код типа Для "А = 0 по Массив.ВГраница() Цикл", а иногда и "0 поМассив.Количество() - 1" - это когда народ перешел с 7.7, но до конца не разобрался в изменениях. Ну и вcе эти [x for x in ...] и прочие фишки вполне применимы.

2. По поводу конвертации, то я сделал механизм обмена по некоторому стандарту: загрузил XSD в пакет, сделал механизм работы с правилами, сделал обработку правил. И вот вроде бы универсальный формат, выгружай-загружай, но для того, чтобы написать правила для конкретного клиента (и это примерно одинаковые отраслевые конфигурации) иногда уходит несколько месяцев, хотя объектов-то кот наплакал. При том первый раз я кодом по этим правилам выгружал данные - да, заняло месяц, но с нуля полного. А тут уже с имеющимися правилами занимает больше месяца.

А вот еще была история... Сливали четыре ЗУПа 2.5 в один. Местный программер месяц писал правила, но типа был занят. В итоге не работало так как надо. Я нарисовал за ЧЕТЫРЕ дня механизм, потом за неделю его исправили, ибо у них там совместители в разных конторвх одни и те же, при том в ряде случаев внешние, в ряде случаев внутренние, поэтому всех совместителей надо было обработать корректно, чтобы их не стало, но если чел только совместитель, то чтобы он им и остался. Вообще как это сделать на конвертации без танцев с бубном вокруг этого всего - хрен просцышь, ибо тут не подходит загрузка трех файлов - тут нужно сначала все загрузить, потом взять самое раннее устройство на работу, и на него все повесить. А люди, напомню, в разных конторах одни и те же.

А по поводу третьей конвертации, то там у тебя есть обработка - менеджер обмена. Вот она и рулит всеми этими ключевыми и дополнительными свойствами объектов. В ней фактически код правил преобразования для каждого объекта. И тоже гемор с ней есть очень часто, но, в основном, скорее оттого, что толком ее никто не знает.
9. Darklight 33 24.06.21 15:11 Сейчас в теме
(8)Ни в коему случае не говорит про то, что Питонщики против функционального стиля программирования. Имел в виду только цепочку лямбда функций - но это по наслышке всё - сам я не являюсь Питонщиком - хотя интересуюсь.
А конвертация просто немного несуразно спроектирована и её трудно отлаживать - в этом вся проблема. Остальное - это уже проблема плохого проектирования самих конфигураций конвертируемых ИБ. Ну и всегда должны быть отложенные алгоритмы выполнения. И в конвертации они есть - но да, не идеально этот спроектировано.
Сама идея декларативной настройки алгоритма конвертации тут ни при чём
А конвертации очень нахватает механизма автономных готовых субправил - когда есть какие-то ситуации учета - и их нужно обрабатывать определённым образом - чтобы можно было выносить их в такие автономные субправила - и, например, выкладывать в Интернет. И должен быть аналитический механизм, который может прощерстить конфигурацию на предмет выявления разных систуаций в учете - и составить список (загрузить) имеющиеся субправила - подключив их потом в общие правила обмена. Естественно, при надобности жти субправила нужно ещё и доработать. А сами субправила должны максимально базироваться на абстрактных определениях, детерминирующийся только в рамках настроек конкретной конвертации -это чтобы не думать о деталях расширенных доработок и включённых опциях.
10. Steelvan 306 27.06.21 22:16 Сейчас в теме
ога-ога, тоже самое и про роботов говорили и писали

Разработчики некоего electroNeek здесь тоже славиться пытались.
А по итогу сдулись ?
На ютуб канале публикуют видео с 200 просмотров за месяц => нет настоящего интереса у народа.
11. denny_dv 5 25.09.21 11:30 Сейчас в теме
Мыслить про low-code в рамках 1с не эффективно. Для начала 1с должна иметь полноценную BPM конфигурацию. При этом стэк 1с не удобен для реализации low-code технологии. Подходящий стэк именно web. Посмотрите на Террасофт, его возможности формировать логику бизнес процесса с помощью визуального редактора, а где не хватает визуальных инструментов, всегда можно запустить скрипт на JS. Low-code скорее для автоматизации именно бизнес-процессов на высоком уровне. Хотя, например в геймдеве на low-code пишут целые игры.
Оставьте свое сообщение