Программирование без языков: мир перейдет на low-code-разработку. Но ненадолго
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(3) Возьмите, к примеру, какой-нибудь общий модуль любого типового решения. В нем вы обязательно найдете некоторую экспортную функцию, которая состоит из одной строки, вызывающей функцию из другого модуля, но и эта функция состоит из одной строки, которая вызывает другую функцию и так два-три вложения. Ну не вручную же эти слои абстракции строятся!?! Я бы это делал по шаблону.
Печально, что нет подробной документации по этому поводу. Это значительно усложняет сопровождение.
ЗУП:
УчетСтажаПФР.РесурсыУчетаСтажаПФР()
УчетСтажаПФРВнутренний.РесурсыУчетаСтажаПФР()
УчетСтажаПФРРасширенный.РесурсыУчетаСтажаПФР();
УчетСтажаПФРБазовый.РесурсыУчетаСтажаПФР();
Печально, что нет подробной документации по этому поводу. Это значительно усложняет сопровождение.
ЗУП:
УчетСтажаПФР.РесурсыУчетаСтажаПФР()
УчетСтажаПФРВнутренний.РесурсыУчетаСтажаПФР()
УчетСтажаПФРРасширенный.РесурсыУчетаСтажаПФР();
УчетСтажаПФРБазовый.РесурсыУчетаСтажаПФР();
Бред это всё. Конечно за no-code- и low-code-инструментами будущее - но ближайшее их будущее это только в качестве дополнения - т.е. именно как дополнительные инструменты. Я ожидаю, что AI системы будут активно помогать писать код уже к середине этого века. Так же активно будет продвигаться когенерация и шаблоны кода. Но это никак не освободит от написания алгоритмов - лишь немного упростит этот процесс. Зато будет расти сложность этих алгоритмов и объём выполняемой ими работы. Будет больше времени и возможностей для тестирования - будет расти качество этих алгоритмов, их производительность, безопасность, надёжность, читаемость.
В языках программирования продолжится эволюция - переход через языки 4-го поколения (с весьма условными очертаниями) к языкам 5-го поколения (пока тоже с весьма условными очертаниями) - программирование станет более декларативным, чем похожим на математику (хотя без неё тоже в ряде задач никуда не деться).
И об этом бы архитекторам в компании 1С было бы здорово уже сейчас задуматься. Я бы, в гипотетическую систему 1С Предприятие 8 заложил бы уже сразу два основных языка программирования:
- Один более алгоритмический, математический - как Java, C# и даже как JavaScript или Python (отчасти похожий и на нынешний язык разработки в 1С Предприятие 8), остающийся где-то на стыке 3-го и 4-го поколения языков программирования - зато очень удобный для написания именно чётких алгоритмов обработки данных
- А другой - более высокоуровневый, с зачатками языка программирования 5-го поколения - более ориентированного на описание целей и действий над данными, чем самих деталей операций (они, в случае детальной необходимости описывается на первом языке) - программирование на нём должно быть более похоже на некоторую компоновку операций над данными, чем на кодирование инструкций. Некое подобие данной идеи - это язык River Definition Language. Ну и современные расширения SQL - в общем-то из той же области. Алгоритмы на языуке не компилируются (в инструкции машины выполнения) и не интерпретируются (в рантайм). Операции анализируются на стадии конфигурирования AI-ассистентом, определяются цели и действия - выполняется когенерация на первом языке для достижения этих целей и выполнения нужных действий - потом уже компиляция в инструкции машины выполнения.
На обоих языках уровень абстракции данных и алгоритмов должны быть очень высоким
В языках программирования продолжится эволюция - переход через языки 4-го поколения (с весьма условными очертаниями) к языкам 5-го поколения (пока тоже с весьма условными очертаниями) - программирование станет более декларативным, чем похожим на математику (хотя без неё тоже в ряде задач никуда не деться).
И об этом бы архитекторам в компании 1С было бы здорово уже сейчас задуматься. Я бы, в гипотетическую систему 1С Предприятие 8 заложил бы уже сразу два основных языка программирования:
- Один более алгоритмический, математический - как Java, C# и даже как JavaScript или Python (отчасти похожий и на нынешний язык разработки в 1С Предприятие 8), остающийся где-то на стыке 3-го и 4-го поколения языков программирования - зато очень удобный для написания именно чётких алгоритмов обработки данных
- А другой - более высокоуровневый, с зачатками языка программирования 5-го поколения - более ориентированного на описание целей и действий над данными, чем самих деталей операций (они, в случае детальной необходимости описывается на первом языке) - программирование на нём должно быть более похоже на некоторую компоновку операций над данными, чем на кодирование инструкций. Некое подобие данной идеи - это язык River Definition Language. Ну и современные расширения SQL - в общем-то из той же области. Алгоритмы на языуке не компилируются (в инструкции машины выполнения) и не интерпретируются (в рантайм). Операции анализируются на стадии конфигурирования AI-ассистентом, определяются цели и действия - выполняется когенерация на первом языке для достижения этих целей и выполнения нужных действий - потом уже компиляция в инструкции машины выполнения.
На обоих языках уровень абстракции данных и алгоритмов должны быть очень высоким
(2)Вот как-то вот так выглядит в моём понимании декларативное программирование - ниже пример пустого кода - но, мало, кто сходу поймёт что там делается и как работает (локальные идентификаторы намеренно скрыты за буквенными обозначениями (чтобы не давали подсказку), оставлены только библиотечные, из типов данных, стоящих за локальными идентификаторами; здесь нет ни одного ключевого слова, всё определяется в типах данных и может быть переопределено)
Код простой, и в нём нет большой логики - ниже его вариация в более строгом стиле (универсальная команда undone заменена боле конкретной "empty", более логичная **** оставлена для другой логики, но ниже в примере уже с ней будет написано)
a to
filter(m) to d
undone to n
Код простой, и в нём нет большой логики - ниже его вариация в более строгом стиле (универсальная команда undone заменена боле конкретной "empty", более логичная **** оставлена для другой логики, но ниже в примере уже с ней будет написано)
(e <- a) ->
filter(@m(@e)) -> d(@e)
epmty -> n()
Тоже самое в стиле C# с понятными идентификаторами |
|---|
array.filter(matches).do(do_job_with).else(no_matched_found)
|
Пример на Python с понятными идентификаторами |
|---|
empty = true
for el in array:
if matches(el):
do_job_with(el)
empty = false
if empty = false:
no_matched_found()
Показать |
Пример на 1C с понятными идентификаторами |
|---|
| Так как 1С не поддерживает поиск по предикату функции-высшего порядка - тут matches-Условие - это Отбор
//Вместо Массива применяется ТаблицаЗначений
НайденныеСтроки = ТаблицаИсточник.НайтиСтроки(Условие);
Если НайденныеСтроки.Количество()>0 Тогда
Для каждого Строка из НайденныеСтроки Цикл
ОбработатьСтроку(Строка);
КонецЦикла;
Иначе
НеНайденоСтрок();
КонецЕсли;
Показать |
(5) ну на питоне можно использовать функциональный стиль, что превратит код в ту же одну строку с лямбдой, генератором или даже без них,. То же самое на JS и Java, тем более в Колтлине.
По поводу low-code, а особенно zero-code - эти концепции переносят сложность из одного места в другое. И это плодит неоптимальные решения, тащащие за собой технический долг, который будет очень трудно уменьшить.
Вот в качестве примера я постоянно приводу конвертацию. Практика показывает, что даже хреновый программист сделает обмен в коде быстрее, чем он же на этой самой конвертации. Да, какие-то очень похожие объекты перелетят из точки А в точку Б чуть ли не автоматом, но таких объектов - ноль без палочки. Контрагенты одной только контактной информации и дополнительных свойств/реквизитов потянут тонны, и если нельзя просто так взять, и записать это в Б в том же виде, то сложность сразу вырастает на порядок. Номенклатура - поехала маркировка, штрих-коды, единицы. Даже долбаный склад потащит за собой из ЕРП топологию, и если нужно в Б развернуть эту топологию в виде обычных отдельных складов, то конвертация даже перед гуру поставит очень непросто решаемую задачу, которую обычным обменом даже на хардкоде решить будет куда проще.
Лично наблюдал, когда два человека с франча и эксперт по техвопросам писали правила обмена для сильно модифицированной УТ 11.1 и почти типовой бухни 2.0 целый год, потом овер дохрена времени уходило на поддержку этого г-на с зиро-кодом. Поэтому я очень скептически отношусь к требованиям в вакухах на тему конвертации (2-й еще ладно, а 3-ю толком никто не знает, поддержка ее в наших продуктах даже при почти не меняющихся объектах вызывает первобытный ужас среди большинства разрабов, в итоге переносимость правил трансляции и прочего постоянно отваливается. Я свой механизм сделал кодом - и он не отвалился ни разу, просто дерево, упакованное в XML - написано за два дня, а только создание пакетов XDTO для 3-ки заняло пару месяцев).
По поводу low-code, а особенно zero-code - эти концепции переносят сложность из одного места в другое. И это плодит неоптимальные решения, тащащие за собой технический долг, который будет очень трудно уменьшить.
Вот в качестве примера я постоянно приводу конвертацию. Практика показывает, что даже хреновый программист сделает обмен в коде быстрее, чем он же на этой самой конвертации. Да, какие-то очень похожие объекты перелетят из точки А в точку Б чуть ли не автоматом, но таких объектов - ноль без палочки. Контрагенты одной только контактной информации и дополнительных свойств/реквизитов потянут тонны, и если нельзя просто так взять, и записать это в Б в том же виде, то сложность сразу вырастает на порядок. Номенклатура - поехала маркировка, штрих-коды, единицы. Даже долбаный склад потащит за собой из ЕРП топологию, и если нужно в Б развернуть эту топологию в виде обычных отдельных складов, то конвертация даже перед гуру поставит очень непросто решаемую задачу, которую обычным обменом даже на хардкоде решить будет куда проще.
Лично наблюдал, когда два человека с франча и эксперт по техвопросам писали правила обмена для сильно модифицированной УТ 11.1 и почти типовой бухни 2.0 целый год, потом овер дохрена времени уходило на поддержку этого г-на с зиро-кодом. Поэтому я очень скептически отношусь к требованиям в вакухах на тему конвертации (2-й еще ладно, а 3-ю толком никто не знает, поддержка ее в наших продуктах даже при почти не меняющихся объектах вызывает первобытный ужас среди большинства разрабов, в итоге переносимость правил трансляции и прочего постоянно отваливается. Я свой механизм сделал кодом - и он не отвалился ни разу, просто дерево, упакованное в XML - написано за два дня, а только создание пакетов XDTO для 3-ки заняло пару месяцев).
(6)
Я слышал, что можно, но считается дурным стилем программирования и даже побраняется. Но было бы интересно посмотреть пример. Мне в Python не нравится синтаксис, плохо совместимый с подобной лексикой выстраивания программы.
Но суть была не в Python - а просто показать разные подходы , и пример более декларативного кода (те, что не в спойлерах). У меня уже был спор (не здесь) по поводу его читаемости. Но, мне кажется, тут просто дело привычки, хотя да - более высокоуровневый код не всегда становится более понятным чем более низкоуровневый. Те же лямбды многим не нравятся и в Питоне вообще побраняются.
Конвератция хороший и мощный инструмент, с хорошими задатками. Но - его сильно испортила местами неудачная архитектура. Ну и для почти четверти века его юзабилити сильно устарело (говор о второй, третью конвертацию ещё не щупал) - но это не значит, что её нельзя исправить и довести до ума. Хотя я бы уже перешёл бы на несколько другой подход, но тоже декларативный - хотя для него бы ещё бы платформу расширить было бы неплохо.
Насколько я знаю EnterpriseData как раз и создан был для простого решения такого рода задач, в конвертации 3.0 - но сам ещё не щупал - хотя идея кажется здравой - но возможно опять с реализацией подкачали.
Конвертация - это ка перевод с оного языка на другой. Но в концепции перевода десять лет назад нашли лазейку - перевод через промежуточный язык (реальный но очень древний и уже мёртвый, но потрясающе детализированный). Вот EnterpriseData - как я понял - это и есть этот промежуточный язык но уже для данных. В общем - это уже другая тема. Уверен, что в недалёком будущем AI-ассистенты смогут решать задачи конвертации с небольшим участием программиста, и чуть большим участием Архитектора.
И ещё - проблема обмена между конфигурациями сейчас в их полном "раздрае" - там такой беспорядок в одних и тех же сущностях - мама не горюй - надеюсь рано или поздно в них придёт модульность и гибкое декларативное управление функциональностью - вот тогда настройка обмена стандартными средствами станет куда более надёжной!
А декларативное программирование позволит ещё и алгоритмы упорядочить!
ну на питоне можно использовать функциональный стиль, что превратит код в ту же одну строку с лямбдой,
Я слышал, что можно, но считается дурным стилем программирования и даже побраняется. Но было бы интересно посмотреть пример. Мне в Python не нравится синтаксис, плохо совместимый с подобной лексикой выстраивания программы.
Но суть была не в Python - а просто показать разные подходы , и пример более декларативного кода (те, что не в спойлерах). У меня уже был спор (не здесь) по поводу его читаемости. Но, мне кажется, тут просто дело привычки, хотя да - более высокоуровневый код не всегда становится более понятным чем более низкоуровневый. Те же лямбды многим не нравятся и в Питоне вообще побраняются.
Вот в качестве примера я постоянно приводу конвертацию. Практика показывает, что даже хреновый программист сделает обмен в коде быстрее, чем он же на этой самой конвертации.
Конвератция хороший и мощный инструмент, с хорошими задатками. Но - его сильно испортила местами неудачная архитектура. Ну и для почти четверти века его юзабилити сильно устарело (говор о второй, третью конвертацию ещё не щупал) - но это не значит, что её нельзя исправить и довести до ума. Хотя я бы уже перешёл бы на несколько другой подход, но тоже декларативный - хотя для него бы ещё бы платформу расширить было бы неплохо.
Если нельзя просто так взять, и записать это в Б в том же виде, то сложность сразу вырастает на порядок.
Насколько я знаю EnterpriseData как раз и создан был для простого решения такого рода задач, в конвертации 3.0 - но сам ещё не щупал - хотя идея кажется здравой - но возможно опять с реализацией подкачали.
Конвертация - это ка перевод с оного языка на другой. Но в концепции перевода десять лет назад нашли лазейку - перевод через промежуточный язык (реальный но очень древний и уже мёртвый, но потрясающе детализированный). Вот EnterpriseData - как я понял - это и есть этот промежуточный язык но уже для данных. В общем - это уже другая тема. Уверен, что в недалёком будущем AI-ассистенты смогут решать задачи конвертации с небольшим участием программиста, и чуть большим участием Архитектора.
И ещё - проблема обмена между конфигурациями сейчас в их полном "раздрае" - там такой беспорядок в одних и тех же сущностях - мама не горюй - надеюсь рано или поздно в них придёт модульность и гибкое декларативное управление функциональностью - вот тогда настройка обмена стандартными средствами станет куда более надёжной!
А декларативное программирование позволит ещё и алгоритмы упорядочить!
(7)
1. Ну в питоне функциональный стиль я не сказал бы, что возбраняем. Например, генераторы и итераторы - это повсеместно используемые в питоне механизмы (я в 1С часто вижу код типа Для "А = 0 по Массив.ВГраница() Цикл", а иногда и "0 поМассив.Количество() - 1" - это когда народ перешел с 7.7, но до конца не разобрался в изменениях. Ну и вcе эти [x for x in ...] и прочие фишки вполне применимы.
2. По поводу конвертации, то я сделал механизм обмена по некоторому стандарту: загрузил XSD в пакет, сделал механизм работы с правилами, сделал обработку правил. И вот вроде бы универсальный формат, выгружай-загружай, но для того, чтобы написать правила для конкретного клиента (и это примерно одинаковые отраслевые конфигурации) иногда уходит несколько месяцев, хотя объектов-то кот наплакал. При том первый раз я кодом по этим правилам выгружал данные - да, заняло месяц, но с нуля полного. А тут уже с имеющимися правилами занимает больше месяца.
А вот еще была история... Сливали четыре ЗУПа 2.5 в один. Местный программер месяц писал правила, но типа был занят. В итоге не работало так как надо. Я нарисовал за ЧЕТЫРЕ дня механизм, потом за неделю его исправили, ибо у них там совместители в разных конторвх одни и те же, при том в ряде случаев внешние, в ряде случаев внутренние, поэтому всех совместителей надо было обработать корректно, чтобы их не стало, но если чел только совместитель, то чтобы он им и остался. Вообще как это сделать на конвертации без танцев с бубном вокруг этого всего - хрен просцышь, ибо тут не подходит загрузка трех файлов - тут нужно сначала все загрузить, потом взять самое раннее устройство на работу, и на него все повесить. А люди, напомню, в разных конторах одни и те же.
А по поводу третьей конвертации, то там у тебя есть обработка - менеджер обмена. Вот она и рулит всеми этими ключевыми и дополнительными свойствами объектов. В ней фактически код правил преобразования для каждого объекта. И тоже гемор с ней есть очень часто, но, в основном, скорее оттого, что толком ее никто не знает.
1. Ну в питоне функциональный стиль я не сказал бы, что возбраняем. Например, генераторы и итераторы - это повсеместно используемые в питоне механизмы (я в 1С часто вижу код типа Для "А = 0 по Массив.ВГраница() Цикл", а иногда и "0 поМассив.Количество() - 1" - это когда народ перешел с 7.7, но до конца не разобрался в изменениях. Ну и вcе эти [x for x in ...] и прочие фишки вполне применимы.
2. По поводу конвертации, то я сделал механизм обмена по некоторому стандарту: загрузил XSD в пакет, сделал механизм работы с правилами, сделал обработку правил. И вот вроде бы универсальный формат, выгружай-загружай, но для того, чтобы написать правила для конкретного клиента (и это примерно одинаковые отраслевые конфигурации) иногда уходит несколько месяцев, хотя объектов-то кот наплакал. При том первый раз я кодом по этим правилам выгружал данные - да, заняло месяц, но с нуля полного. А тут уже с имеющимися правилами занимает больше месяца.
А вот еще была история... Сливали четыре ЗУПа 2.5 в один. Местный программер месяц писал правила, но типа был занят. В итоге не работало так как надо. Я нарисовал за ЧЕТЫРЕ дня механизм, потом за неделю его исправили, ибо у них там совместители в разных конторвх одни и те же, при том в ряде случаев внешние, в ряде случаев внутренние, поэтому всех совместителей надо было обработать корректно, чтобы их не стало, но если чел только совместитель, то чтобы он им и остался. Вообще как это сделать на конвертации без танцев с бубном вокруг этого всего - хрен просцышь, ибо тут не подходит загрузка трех файлов - тут нужно сначала все загрузить, потом взять самое раннее устройство на работу, и на него все повесить. А люди, напомню, в разных конторах одни и те же.
А по поводу третьей конвертации, то там у тебя есть обработка - менеджер обмена. Вот она и рулит всеми этими ключевыми и дополнительными свойствами объектов. В ней фактически код правил преобразования для каждого объекта. И тоже гемор с ней есть очень часто, но, в основном, скорее оттого, что толком ее никто не знает.
(8)Ни в коему случае не говорит про то, что Питонщики против функционального стиля программирования. Имел в виду только цепочку лямбда функций - но это по наслышке всё - сам я не являюсь Питонщиком - хотя интересуюсь.
А конвертация просто немного несуразно спроектирована и её трудно отлаживать - в этом вся проблема. Остальное - это уже проблема плохого проектирования самих конфигураций конвертируемых ИБ. Ну и всегда должны быть отложенные алгоритмы выполнения. И в конвертации они есть - но да, не идеально этот спроектировано.
Сама идея декларативной настройки алгоритма конвертации тут ни при чём
А конвертации очень нахватает механизма автономных готовых субправил - когда есть какие-то ситуации учета - и их нужно обрабатывать определённым образом - чтобы можно было выносить их в такие автономные субправила - и, например, выкладывать в Интернет. И должен быть аналитический механизм, который может прощерстить конфигурацию на предмет выявления разных систуаций в учете - и составить список (загрузить) имеющиеся субправила - подключив их потом в общие правила обмена. Естественно, при надобности жти субправила нужно ещё и доработать. А сами субправила должны максимально базироваться на абстрактных определениях, детерминирующийся только в рамках настроек конкретной конвертации -это чтобы не думать о деталях расширенных доработок и включённых опциях.
А конвертация просто немного несуразно спроектирована и её трудно отлаживать - в этом вся проблема. Остальное - это уже проблема плохого проектирования самих конфигураций конвертируемых ИБ. Ну и всегда должны быть отложенные алгоритмы выполнения. И в конвертации они есть - но да, не идеально этот спроектировано.
Сама идея декларативной настройки алгоритма конвертации тут ни при чём
А конвертации очень нахватает механизма автономных готовых субправил - когда есть какие-то ситуации учета - и их нужно обрабатывать определённым образом - чтобы можно было выносить их в такие автономные субправила - и, например, выкладывать в Интернет. И должен быть аналитический механизм, который может прощерстить конфигурацию на предмет выявления разных систуаций в учете - и составить список (загрузить) имеющиеся субправила - подключив их потом в общие правила обмена. Естественно, при надобности жти субправила нужно ещё и доработать. А сами субправила должны максимально базироваться на абстрактных определениях, детерминирующийся только в рамках настроек конкретной конвертации -это чтобы не думать о деталях расширенных доработок и включённых опциях.
ога-ога, тоже самое и про роботов говорили и писали
Разработчики некоего electroNeek здесь тоже славиться пытались.
А по итогу сдулись ?
На ютуб канале публикуют видео с 200 просмотров за месяц => нет настоящего интереса у народа.
Разработчики некоего electroNeek здесь тоже славиться пытались.
А по итогу сдулись ?
На ютуб канале публикуют видео с 200 просмотров за месяц => нет настоящего интереса у народа.
Мыслить про low-code в рамках 1с не эффективно. Для начала 1с должна иметь полноценную BPM конфигурацию. При этом стэк 1с не удобен для реализации low-code технологии. Подходящий стэк именно web. Посмотрите на Террасофт, его возможности формировать логику бизнес процесса с помощью визуального редактора, а где не хватает визуальных инструментов, всегда можно запустить скрипт на JS. Low-code скорее для автоматизации именно бизнес-процессов на высоком уровне. Хотя, например в геймдеве на low-code пишут целые игры.