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

0. Infostart 19892 22.06.21 11:38 Сейчас в теме
Сейчас мир вступает в новую эру – программирования без кода. Аналитики Gartner заявили, что такие no-code- и low-code-инструменты к 2024 году обеспечат создание 80% всех продуктов и сервисов.

Перейти к новости

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

ЗУП:
УчетСтажаПФР.РесурсыУчетаСтажаПФР()
УчетСтажаПФРВнутренний.РесурсыУчетаСтажаПФР()
УчетСтажаПФРРасширенный.РесурсыУчетаСтажаПФР();
УчетСтажаПФРБазовый.РесурсыУчетаСтажаПФР();
2. Darklight 30 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 30 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 2832 23.06.21 19:05 Сейчас в теме
(5) ну на питоне можно использовать функциональный стиль, что превратит код в ту же одну строку с лямбдой, генератором или даже без них,. То же самое на JS и Java, тем более в Колтлине.

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

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

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

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

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

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

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

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

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

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

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

А по поводу третьей конвертации, то там у тебя есть обработка - менеджер обмена. Вот она и рулит всеми этими ключевыми и дополнительными свойствами объектов. В ней фактически код правил преобразования для каждого объекта. И тоже гемор с ней есть очень часто, но, в основном, скорее оттого, что толком ее никто не знает.
9. Darklight 30 24.06.21 15:11 Сейчас в теме
(8)Ни в коему случае не говорит про то, что Питонщики против функционального стиля программирования. Имел в виду только цепочку лямбда функций - но это по наслышке всё - сам я не являюсь Питонщиком - хотя интересуюсь.
А конвертация просто немного несуразно спроектирована и её трудно отлаживать - в этом вся проблема. Остальное - это уже проблема плохого проектирования самих конфигураций конвертируемых ИБ. Ну и всегда должны быть отложенные алгоритмы выполнения. И в конвертации они есть - но да, не идеально этот спроектировано.
Сама идея декларативной настройки алгоритма конвертации тут ни при чём
А конвертации очень нахватает механизма автономных готовых субправил - когда есть какие-то ситуации учета - и их нужно обрабатывать определённым образом - чтобы можно было выносить их в такие автономные субправила - и, например, выкладывать в Интернет. И должен быть аналитический механизм, который может прощерстить конфигурацию на предмет выявления разных систуаций в учете - и составить список (загрузить) имеющиеся субправила - подключив их потом в общие правила обмена. Естественно, при надобности жти субправила нужно ещё и доработать. А сами субправила должны максимально базироваться на абстрактных определениях, детерминирующийся только в рамках настроек конкретной конвертации -это чтобы не думать о деталях расширенных доработок и включённых опциях.
10. Steelvan 281 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 пишут целые игры.
Оставьте свое сообщение
Вакансии
Консультант 1С
Москва
зарплата от 80 000 руб. до 150 000 руб.
Полный день

Программист 1С (ERP, УХ, КА 2, УТ 11), удаленно
Москва
зарплата от 160 000 руб.
Полный день

Аналитик 1С
Москва
зарплата от 200 000 руб.
Полный день

Консультант 1С / Специалист поддержки 1C
Екатеринбург
зарплата от 70 000 руб.
Полный день

Технический архитектор 1С
Екатеринбург
зарплата от 200 000 руб.
Полный день