Программирование без программистов и что мешает ему развиваться

Едут в автомобиле механик, химик и программист.
И вдруг машина заглохла.
Механик: «Наверное, что-то с мотором».
Химик: «Да нет, это бензин плохой».
Программист: «Поднимите мне зарплату».
© Анекдот

Карантин и локдаун вынудил бизнес выйти в онлайн: доставка продуктов, развлечения, покупки, совещания, игры, общение с друзьями и даже секс — всё теперь происходит по интернету. С вакцинацией в США и Европе активизировались офлайн-бизнесы. Их потребности в разработке тоже никуда не делись. Соответственно спрос на программистов, который и так был немалым, увеличился сильно.

Если раньше с целью экономии их набирали в странах третьего мира, сейчас все — разработчики закончились и там. По данным djinni.co, соотношение между специалистами в поиске и вакансиями с ноября 2020 года выросло многократно и не в пользу рекрутеров. Бизнес визжит так, будто его режут: свободных рук и голов на рынке труда попросту нет — приходится переманивать, обязательно с повышением зарплаты (украинская Дия City как раз сделана, чтобы разработчиков закабалить) и дрожать, ожидая, что завтра кто-то даст ещё больше.

Что же делать? Обучать программированию новичков — задача долгая и нет никаких гарантий, что неофит не сбежит на +500 долларов в компанию через дорогу.

А нельзя ли хотя бы в типичных случаях обойтись без этих зажравшихся, капризных и при этом дорогостоящих сволочей? Сделать так, чтобы простые программы можно было создавать без кода или с его минимумом? И, естественно, no-code платформы получают сейчас всё большую популярность. Как они выглядят сейчас, как будут выглядеть в будущем, что мешает их развитию и почему мы не можем отказаться от услуг разработчиков? На эти вопросы я постарался ответить ниже.

Что такое no-code

Когда роботы станут разумными, их деньги будут называться — киловатты.

Сейчас

На самом деле no-code сейчас не более, чем конструктор. Есть компоненты, они связываются с помощью настроек. Логика работы приложения создается с помощью кода (такие платформы называются low-code) либо рисуется в виде графических схем (собственно no-code).

Тема эта не нова, вспомним хотя бы Delphi: натаскав на форму компонентов, можно создать довольно сложное предложение. Таким же примерно образом можно создать сайт, чат-бот, систему документооборота, ERP и многое другое. Конструкторы для игр выглядят несколько по-другому, но всё равно они состоят из редактора и логики. Примеры их Unity3D, Adobe Flex, Unreal Engine. Существуют и бухгалтерские системы: 1С, SAP и так далее, не вижу причины, по которой нельзя придумать такую для любого другого вида человеческой деятельности.

Вопрос: угрожает ли текущее состояние профессии программист? Ответ: нет. Более того, программисты ABAP (входной язык для SAP) считаются одними из наиболее высокооплачиваемых.

И в будущем

Астролябия... сама меряет, было бы что мерить ©
Ильф и Петров. Двенадцать стульев

Как я указывал выше, в данный момент no-code платформы не являются угрозой для рабочих мест ІТ-специалистов. Но, допустим, со временем искусственный интеллект разовьется: сможет, например, создавать программы по текстовому описанию + рисунку от руки. Будет ли это концом высокооплачиваемой работы и рынка труда соискателя? Давайте разберёмся.

Во-первых, чем рисунок принципиально отличается от перетаскивания контролов на форму? Только тем, что для первого нужно уметь хоть как-то рисовать мышкой либо иметь стилус. Во-вторых, текстовое описание хоть и достаточно вольное, всё же не может быть слишком фривольным — оно должно описывать алгоритм работы программы.

Да, сейчас уже существуют экспериментальные средства, позволяющие конвертировать естественный язык в код, но даже на естественном языке нужно внятно описать, что будет делать программа. Вполне возможно, знания современных языков программирования отойдут в прошлое, как это уже случилось с ассемблером, но необходимость описывать алгоритмы не денется в обозримом будущем никуда. Именно возможности человека, не искусственного интеллекта, стоят на пути у прогресса — люди попросту не умеют алгоритмизировать. А как вы думали, алгоритм — это далеко не только умные задачки на олимпиадах. Вот попробуйте, попросите членов вашей семьи написать алгоритм приготовления кофе словами — без всяких языков программирования. Спорим, что с первой попытки выйдет далеко не у всех.

С другой стороны, на языке Lisp уже более полувека можно создавать DSL-и, которые практически не отличимы от естественного языка. Нужно заметить, что прогресс в инструментальных средствах отнюдь не приводит к уменьшению количества программистов — наоборот, с каждым годом задач информатизации всё больше, чем людей, умеющих их решать. А уж согласных программировать за «разумные деньги» вообще в природе уже не осталось. Да и требования только растут: в начале 90-х для работы достаточно было знания какого-то языка программирования, потом понадобились реляционные базы данных, потом программирование веб-приложений и так далее. Мобильные платформы, фронтенд, искусственный интеллект — всё, без чего немыслимо современное ІТ.

Но что же делать, если писать код очень-очень не хочется? Можно ли это, оказывается, можно, ведь существуют....

Блок-схемы, везде блок-схемы

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

И почему они не подходят

Давайте остановимся на недостатках блок-схем подробнее. В качестве иллюстрации будем использовать онлайн-редактор.

Отсутствие обязательной структуры

Блок-схемы можно рисовать как угодно: хоть справа налево, хоть сверху вниз, хоть наискосок. Ни тебе связи с временной шкалой, ни с потоком распространения событий. Не зря их называют «спагетти». Разобраться в этих письменах инков практически невозможно.

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

В качестве иллюстрации на рисунке ниже представлена блок-схема. Фигурами и соединительными линиями изображены буквы «Х» и «У». Третью букву, сообразуясь с мерой своей распущенности, предоставляется мысленно нарисовать читателю в качестве упражнения.

Много пустого места

Давайте посмотрим, как выглядит блок-схема простейшего цикла «for» (рисунок ниже):

При этом на языке C эта блок-схема выглядит вот так:

Понятнее ли блок-схема? Нет! Меньше по размерам? Нет! Зачем же ее использовать?

Избыточная сложность

Посмотрите, сколько фигур предлагается к использованию в популярном онлайн-редакторе www.lucidchart.com

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

В результате блок-схемами программисты-профессионалы, как правило, не пользуются. Можно ли с этим что-то сделать? Да — ввести правила, ограничить свободу творчества таким образом, чтобы из-под мыши или стилуса выходили только компактные, наглядные и понятные схемы. И такие стандарты разработаны ещё в СССР, и, кстати, до сих пор, несмотря на прошедшие тридцать лет, ничего лучшего нигде не придумали, хотя и старались. Одним из таких являются Р-схемы.

Введение в Р-схемы

Нотация Р-схем в СССР доктором физмат-наук Игорем Вячеславовичем Вельбицким в далёком 1975 году, ещё до рождения автора этой статьи, в Киевском институте кибернетики НАНУ. Да, с её помощью создавали программы для посылки ракет на злобных буржуев, из песни слов не выкинешь. Но не сложилось, СССР канул в Лету, оставив нам в наследие Р-технологию (и много чего ещё). Язык этот, во-первых, графический, во-вторых, очень простой, но это только на первый взгляд.

В нём есть:

  • точки, на них не написано ничего;
  • линии их соединяющие: горизонтальные и вертикальные. На горизонтальных можно писать, сверху и снизу.

Этого достаточно для создания программ любой сложности.

С точки зрения теории Р-схемы являются ориентированным графом, нагруженным по дугам — надписи могут быть только на них, не на вершинах. Такая запись продиктована соображениями компактности: на соединительных линиях места гораздо больше, чем внутри точек.

Самая простая программа

Вот самая простая программа, описывающая поведение проголодавшегося человека в зависимости от наличия у него денег:

Как видим, сверху написано условие, снизу — действие.

Программа с переходом

Предположим, некто отправился в магазин за хлебом. Если в этом нет, не беда — зайду в следующий. Как же будет выглядеть Р-схема, описывающая этот процесс?

Это аналог перехода на строку кода. Или в данном случае на развилку. На некоторых из стрелок нет надписей: сверху, снизу или вообще — это нормально. В данном случае это означает безусловное действие, переход по условию или безусловный переход.

Программа с циклом

Можно ли в предыдущем случае обойтись без перехода к началу? Да, воспользоваться циклом.

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

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

На этом с теорией всё. Ниже я разовью идею Р-схем в различных приложениях к реальным задачам.

Преимущества перед блок-схемами

Чем это отличается от десятков реализаций блок-схем в UML? Давайте разберёмся.

Четкие правила построения и простота

Р-схемы состоят только из вертикальных и горизонтальных линий. Это делает картинку проще для восприятия.

Компактность

Р-схемы нагружены только по дугам, где для надписей много места, их вполне можно использовать для программирования с небольшого экрана мобильных телефонов.

В качестве примера посмотрим, как будет выглядеть цикл for из примера выше.

И это всё. По крайней мере не больше, чем написать это кодом.

Использование Р-схем для no-code платформ

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

Чат-боты

Платформ для их создания буквально сотни. Как правило, они представляют собой дизайнер блок-схем + настройки. Ниже скриншот из сервиса Landbot. На нём видно, что даже маленький чат, созданный для тестирования, не помещается на экране:

Посмотрим, как то же самое можно сделать с помощью Р-схем:

Как видим, схема гораздо более компактна. Вверху мы пишем тип элемента, внизу — его конкретные параметры. К примеру, если нужно выдать сообщение вверху линии, мы так и пишем «сообщение», внизу — его текст. В случае выбора вариантов пишем вверху «Select» и под этой линией варианты выбора — всё очень просто.

Игровые платформы

Можно ли создать игру без кода, хотя бы простенькую? Да! Например, платформа flowlab. Это штука, предназначенная для создания 2D-платформеров. В ней и в других похожих у каждого игрового объекта существуют следующие характеристики:

  • Тип объекта: пол, стена, робот, куст, персонаж и так далее.
  • Физические характеристики: координаты, скорость, масса.
  • Поведение, которое зависит от физических характеристик конкретного объекта в данный момент времени и игрового сценария.

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

И это... наши любимые блок-схемы с их недостатками, которые нивелируются введением Р-схем.

Давайте посмотрим, как можно запрограммировать поведение космического корабля в скроллере: он летит по экрану сверху вниз (на самом деле, относительно экрана компьютера он неподвижен — передвигается игровой мир). Стреляет, если нажать пробел. Если столкнулся с препятствием — взрывается. При нажатии клавиш «A» или «D» перемещается по экрану влево вправо.

Собственно, всё. Те из вас, кто когда-то писал игры с помощью, скажем, Adobe Flash или Unity, знают, сколько нужно написать кода для создания вышеупомянутой логики. Спойлер для тех, кто не писал — много!

Программы для роботов

Будущее уже стало реальностью, роботы уже проникли в нашу жизнь, в промышленности они появились задолго до рождения автора. К примеру, в программе AutoCAD можно создать эскиз детали, затем передать его на станок с ЧПУ, и она будет создана без участия человека. Но давайте разберём пример более близкий к простому смертному. Предположим, у нас есть кофеварка и она варит кофе к определенному времени по будням, по праздникам в другое время, а если в календаре день отмечен как отпускной — не варит его вообще. Посмотрим, как эта программа будет выглядеть на языке Р.

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

И что же дальше?

Автор в свободное от работы время разрабатывает конструктор, позволяющий использовать язык Р для разнообразных приложений. Язык разработки Type Script 2 + React.
Сделано пока немного, поскольку кушать хочется каждый день, плюс нерабочие активности: поработать побольше не получается. Поэтому к сотрудничеству приглашаются неравнодушные энтузиасты. Это пока не стартап — опенсорс-разработка, но я планирую участвовать и выиграть в конкурсе грантов. Сейчас как раз занимаюсь этим.

p.s. По ссылке моё интервью о no-code платформах Тарасу Роскошному, вицепрезиденту АйТи гильдии

👍НравитсяПонравилось10
В избранноеВ избранном7
LinkedIn

Лучшие комментарии пропустить

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

Черепаха называется «все-таки, как его не назови, это программирование».

А киты соответственно получаются такие :

Кит первый : composability. С ним обычно все где-то между «нет вообще» и «плохо». Либо нет возможности вынести кусок функциональности в отдельную переиспользуемую сущность. Либо reusable components можно писать исключительно на каком-то «настоящем» языке.

Или какая-то беда с параметрами: параметры «нельзя», либо максимум один, либо передавать только константы, или ещё что-то в этом роде.

Отсюда мы плавно переходим к Киту номер два: беда с моделирование данных. Могут быть проблемы с тем, чтобы в рамках процесса что-то посчитать и сохранить результат (чтобы использовать его два раза). Либо такой возможности нет вообще. Либо из типов данных у тебя только строки. Может быть так, что все данные представлены в виде global или local key-value map, и это единственная структура данных, и начинаются пляски с магическим именами ключей, которые ожидаются в той или иной точке процесса.

Отсюда переходим к Киту номер три: discoverability and namespaces. Имена, создаваемых пользователем(имена процессов, переменных, ключей в key value map) , могут жить в одном глобальном плоском неймспейсе, который со временем превращается в помойку. Если вам дают поиск, то он может быть только по имени (которое вы уже должны знать). Если и есть поиск по телу/атрибутам/чему-то подобному, то он может быть странным, так показать контекст, в котором нашлось искомое, тяжело — это ж не текст, из которого можно вырезать сниппет

Отсюда переходим к Киту номер четыре: редактирование. Если нет нормального поиска — не будет и поиска с заменой. Если нет поиска с заменой — плохо придуманные имена сущностей рискую быть с вами навсегда. Контроль версий может быть, а вот сравнение разных версий или что-то типа diff-а — уже нет. Два человека, которые правят одно и то же, либо ограничены каким-то глобальным mutex-ом, либо рискуют затирать правки друг друга.

Я, честно признаться, уже давненько не брал в руки шашки, но вот я открываю упомянутый в комментариях corezoid и вижу там в tutorial вещи, Киту намекаю, что «все как всегда». Передаём json/kv map, можно интерполировать значения оттуда в строки (если я правильно понял), есть галочка «отослать все наши данные в вызываемый процесс» (привет, магические имена keys?)...

Скажите мне, что я застрял в прошлом, прогресс шагнул далеко вперёд, и state of the art выглядит совсем не так :)

В стартапе от Кожаева слова «бороться за гранты», «выбить грант» и «раунд инвестиций» обретают новый смысл 😂

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Долго вчитывался, идея в принципе понятна. Идея Visual Programming Langue (en.wikipedia.org/...​sual_programming_language) не нова, не уникальна и имеет массу успешных реализаций и применений. В основном применяется для разнообразных скриптов, чтобы дать возможность программировать высоко-уровненную логику «уверенному пользователю» — инженерам (не программистам), интернет маркетологам, гейм дизайнерам, маклерам и прочим специалистам. А в случае с ETL то такие средства хороши и для программистов. Для относительно коротких алгоритмов наглядность явно дает преимущество. Идея замены текстовых языков, будь то: императивные, функциональные или логические потерпела фиаско еще в момент первых реализаций визуальных языков, в конце 70-х. Думаю главный вопрос — чем новая система на P-схемах лучше чем скажем Drools www.drools.org которую можно прямо сейчас взять бесплатно готовую и протестированную ? Или встроенного в Unreal Blueprints так же как и FlowGraph из CryEngine ?

Игорь Вячеславович Вельбицкий может и не шизоид полный на всю голову, но точно имел доступ к контрафакту из Германии, копиям статей ведущих университетов мира по каналам КГБ. В этих копиях он узнал, что Бэкус Наур в 1959 году придумал БНФ нотацию, как альтернативу для визуальных блок-схем ALGOL 58 в рамках своего доклада по «Синтаксису и Семантике». Потом Игорь Вячеславович Вельбицкий наверно нашел еще одну статью Дейкстры (автор мема Go-to statement considered harmful в 1968) про структурное программирование«. И это я даже не начинал тролить, если бы я хотил начать тролить, то первый Флоу Чарты придумал Алан Херберт Мoргенсен (Моги), внимание, в 1937 году они вместе Лилиан Гильбрет тренировали бизнес-аналитиков как пользоваться флоу чарт диаграммами. Вполне вероятно, что Игорь Вячеславович Вельбицкий все это почерпнул учась в Пензенском государственном университете, который он закончил уже в позднем 1962 году. А уж p-схемы 1975-го года так вообще..., тогда уже лиспы были, тогда и p-схемы были и m-выражения! Поэтому мы, люди получившие должное образование, считаем, что Игорь Вячеславович Вельбицкий мог удовлетворится результатами в 1975, но сегодня он не выдержит никакой критики ни по каким критериям оценивания, кроме демонстрируемой и регулируемой в целом функции со значениями в области «компактности» и «удобности». Удобности кому, читаемости для кого? Игорь Вячеславович Вельбицкий что предлагает игнорировать международные стандарты, нацеливаясь на Android и iOS как платфому в своих недавних публикациях?

Вообщем в условиях железного занавеса Игорь Вячеславович Вельбицкий мог себе позволить многое (впаривать БНФ нотацию как p-схему и кормиться с аспирантов), но время текло появился Интернет и родился Кожаев! Он не только откопал p-cхемы Игоря Вячеславовича Вельбицкого, но и решил адаптировать их к своему древнему увлечению ANTLR парсерами, по дороге увлекаясь более поздними высерами СССР в виде языка Дракон в 1995 году и другими (Это в то время когда уже была БК0010 и порт MUMPS на нее). Почему мы БНФ схемы по существу называем тут p-схемами? Потому что так диктует Кожаев, больше нет ни одной причины! В нормальном мире если мы пишем генератор парсеров мы говорим мы пишем генератор БНФ парсеров, даже если и называем продукт Menhir, yacc, и т.д. Но тут мы БНФ и флоучарты называем p-схемами! Для «самых умных» у нас еще есть «Конечный Автомат» и «Сети Петри», ведь мы математики! А машина тюринга до сих пор адекватная модель для моделирования вычислений и наш незаменимый инструмент в получении грантов за счет налогоплательщиков, нас с вами.

Я рекомендую выдать Игорю Вячеславовичу Вельбицкому золотой парашют, всем его аспирантам (как Киве) выдать корочки и после этого спокойно начать заниматься реформированием НАН Украины.

На украинской википедии написано, что Р-схемы это ISO 8631. Заходим в источник ватного ИТ-хранилища files.stroyinf.ru/Data/96/9662.pdf там выглядит как заказ Министерства Обороны РФ, но точно неправильно ведь мы читали статьи Игоря Вячеславовича Вельбицкого и там точно не такие картинки, в ISO стандарте нам предлагают все те же диаграммы Насси—Шнейдермана. Куда ни копай — везде омбан!

Т.е. если на это даже ISO стандарта нет, а просто ГОСТ 75-го, и тот является просто перепечаткой существующего стандарта то о чем тут говорить? Откройте доку по Turbo Pascal 5.5 — там форма БНФ-нотации натурально выглядит как Р-схемы! Может мы просто накупим терминалов Геркулес, напишем ERP на Turbo Vision и будет норм диджитализация? А доку в виде БНФ-нотаций НАН Украины будет рисовать.

А я рекомендую топре перестать буддизмом заниматься. Потому, что псевдонаучной чуши в этом опусе больше, чем в биноме объёмного расширения.

Здравствуйте! Ребята, была бы признательна, если бы вы согласились пообщаться со мной на тему перспектив low/no-code в качестве экспертов для нашего небольшого телеграм-канала. Пишите, поставим все ссылки на вас как на эксперта, может, еще куда контент подготовим совместно. t.me/LyubovChi

Да,без проблем. У меня в личке все контакты. Пишите

Внезапно!:
ИНТЕЛЛЕКТУАЛЬНАЯ ВИЗУАЛЬНАЯ 3D+ ПОЛИГЛОТ-КОНЦЕПЦИЯ ПРОГРАММИРОВАНИЯ БЕЗ ЯЗЫКОВ ПРОГРАММИРОВАНИЯ
И.В. ВЕЛЬБИЦКИЙ

Понравилось:

Но программирование стало еще более сложным, дорогим, недоступным и непонятным.

... стало ясно, что причина этому является старая неизменная с 1947 г. и устаревшая неграфическая концепция программирования. В этой концепции используются машинно-ориентированные и неестественные для человека операторы типа: if-then, else, for, while, goto ..., метки, блочные скобки типа begin-end, {-} ..., отступы (лесенки), большинство знаков препинания и т.д.,
...
Такие операторы сложны, маломощны, эмпиричны ( строго не определены) и обеспечивают только примитивно-ремесленническую техно-логию работы.

Новая концепция впервые предлагает не писать, а рисовать программы в графах, нагруженных по горизонтальным дугам символами, выражениями и функциями из элементарной математики. Рисовать во много раз проще, быстрее, нагляднее и компактнее, чем писать программу в существующей концепции (в специальных текстовых языках) программирования.
...
Поэтому все специальные языки программирования типа Фортран, С++, JAVA, Python становятся маломощными и ненужными,...
Поэтому все специальные языки программирования типа Фортран, С++, JAVA, Python становятся маломощными и ненужными,...

"Столица переезжает в Нью-Васюки..."

P.S. Текст — агонь зачеркнуто нафталин. Я даже не знаю как можно будучи в здравом уме такое писать в 2017 году (судя по референсам).

Моим научруком был Академик Летичевский. С Игорем Вячеславовичем я лишь имел честь общаться

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

Всё, конаты, перекатываемся с Котлина!

Да с мотивацией в своем питче господин И.В. Вельбицкий явно переборщил, хайпонуть решил.

Интересующимся могу оставить забавное по теме: www.youtube.com/...​cjHTmGY&ab_channel=OpenAI

Вопрос, в том что писать. Каким угодно языком

Эта работа по ссылке — участник oreilly tech radar. Я её не противопоставляю топику. Я просто надеюсь, что здесь есть те, кому этот материал интересен, тем более, что он комплементарен топику.

Цей комікс вже тут був?
www.commitstrip.com/...​hensive-and-precise-spec

— And do you know the industry term for a project specification that is comprehensive and precise enough to generate a program?
— ?
— Code. It’s called code.

Програмування — це не тільки про написання кінцевого результату у вигляді коду. Тому те, в якій формі кінцевій результат — у вигляді коду, чи у якійсь нотаціі з крапок та стрілочок — то вже не так важливо.

Просто так склалося, що коли він у вигляді тексту — це зручніше: діфф з системи контролю версій, пошук по коду, та майже всі зручності які надають сучасні IDE. Та може це все наслідок звички, яка тягнеться вже декілька поколіннь. Але це ні в якому разі не повинно вас зупиняти — що, як не експеримент, є рушиєм прогресу? Якщо буде еффектівна нова нотація — будуть і нові IDE, і нові звички.

Совершенно верно: если ничего не делать точно ничего не выйдет — спасибо за комментарий

эх, ну были же нормальные статьи от Морковки, а тут уже в графоманию и чушь потянуло.
Kучше пиши о DSL, если о техническом.

И и напомню тебе о UML. А когда-то он так дышал, так дышал.

Технические аспекты. DSL мне никак не помогут получить грант. Это может

Понял. В таком я не советчик. Для меня вся эта магия с грантами — просто магия.
Но мне кажется, что нужна какая-то изюминка, чтобы рассказывать всем, чем оное лучше, чем всё прошлое.

Попытки «программирования без программирования», как правило, заканчиваются программированием. Но через зад.

p.s. p-схеме для цикла фор у вас ошибка: «i = 2» и «i += 2» должно быть отдельными дугами.

Спасибо, исправлю или сделаю цикл от x до у с внутренней переменной

А теперь как это будет выглядеть, если на нём зарировать пример из реальной жизни, например эту функцию?
github.com/...​blob/master/huffman.c#L63

Если понадобится, сделаю статью по кодированию алгоритмов. Пока Не надо

...Нотация Р-схем в СССР доктором физмат-наук Игорем Вячеславовичем Вельбицким в далёком 1975 году... Но не сложилось, СССР канул в Лету, оставив нам в наследие Р-технологию (и много чего ещё)

В 1987 Вельбицкий создал.. Технософт — учреждение при Национальной академии наук Украины, которое занимается этими вопросами.
Публикации по этой теме были в девяностые, нулевые и десятые года т.е. полностью abandonware эти Р-схемы не стали.

В более поздних публикациях Вельбицкого и в ранее упомянутом ГОСТ 19.005-85 — Р-схемы подавались как:
1. альтернативный способ подачи алгоритмов
2. альтернативная форма написания программ на уже существующих на тот момент языках.
В ранних реализациях Р-схем — вертикальные/горизонтальные линии, вершины, дуги — записывались в текстовом виде вместе с командами/кодом (например как в приложении 5 к ГОСТ 19.005-85 — выглядит как..ASCII арт вперемешку с привычным операторами ЯП) т.е. никакого намека, на то, что сейчас именуют low/no code там не было.

Если эти Р-схемы — действительно настолько перспективные и инновационные, то почему после 40+ лет работ в этом направлении Вельбицкого и его последователей — о них мало кто знает?

Наверняка существует причина того, после 40+ лет работ эта технология Р-схем — так и не стала распространенной.

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

остальные отечественные разработки

Из «пост советских» разработок. Лексикон (выкуплен Microsoft и использован в Ms. Word), Volkov Comander, 1C, TheBat, WinRar, FAR Manager, Dr. Web, Rambler, Yandex, Mail.ru, Ukr.net, Kaspersky, Flanker, Казаки, IL 2, Сталкер, Kompas Graphics, 7Zip, Intelij IDEA (і все IDE на ее базі), Nginx, DOU, World of Tanks, WarThunder, DCS World, Git Lab. Так же куча библиотек программ и технологий . Есть вещи которые зашли — а есть которые не особо.

Есть говорить честно, то тема в сабже является предметом исследований чуть более чем дофига времени. Я ещё в 90-х годах читал в книгах по SQL, что теперь каждый бухгалтер сможет написать на почти родном английской языке запрос к базе данных, что делает программистов ненужными. И надеяться на то, что кто-то упустил и никто не переотрыл жемчужину очень наивно.

Если эти Р-схемы — действительно настолько перспективные и инновационные, то почему после 40+ лет работ в этом направлении Вельбицкого и его последователей — о них мало кто знает?

Потому что есть UML , который покрывает значительно больше потребностей и более гибок в целом

Что мешает использовать подмножество UML для своих целей и быть совместимым с тысячами других приложений для визуализации?

Потому, что графы нагруженные по дугам с UML ну никак не совместимы

У вас же в статье, как пример, activity diagram, которая часть UML

Вовсе нет. Посмлтри определение активити диаграммы

Вообще это плохо что люди которые программируют не понимают в чем основная проблема программирования.

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

Low code is a new marketing term for DSL.
Если на этом DSL могут писать не программисты, если для него легко построить билдер интерфейс — это же замечательно. Кто тут хочет заниматся однообразным внедрением типа 1С или Salesforce ? Мне кажется что демократизация программирования сделает возможным создание более масштабных проектов, более глубокие специализации и тд.
Тут вот МЛ грозит более серьёзными изменениями в отрасли.

Если на этом DSL могут писать не программисты

Не смогут, если они будут писать на языке программирования, то уже будут программистами.
Да, язык может быть чуть проще, чуть сложнее, то собственно описание алгоритма на этом языке останется. Я привычный нам разговорный слабо приспособлен к описанию алгоритмов. и Вот это «однозначно сформулировать алгоритм на любом языке» — самая сложная часть для людей и именно это и делают программисты.

На тему однозначности есть замечательное видео — расскажи как сделать бутерброд)

Ага. Кстати, я один раз был в подобной ситуации. Был в Германии, зашел в кабак пивка выпить и захотелось бутербродом закусить. Но забыл, что нынче это сендвич и слово «бутерброд» немцы не знают. В общем с трудом я заказал что-то с хлебом, сыром, маслом. И что же мне принесли.
Это была большая деревянная плоская тарелка, на которой лежало:
Два листа салата, на них большой ломоть хлеба. Вокруг этого разрезанный помидор. На хлебе пирамидой сантиметров на 10 лежало около 10 разных сортов сортов сыра. По краям пирамиды выложены кусочки масла. Стоило это, понятно, не 1-2 марки, а 10 марок — это было в 2 раза дороже, чем выпитые мной 3 бокала пива.
А да, готовили долго (официантка в магазин сбегала) и счет для этого бутерброда был отдельный.

такая программа может быть написана любой домохозяйкой.

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

И так как я сталкивался с лоукодом и размышлял на эту же тему, то в итоге пришел к «похожей» схеме )) только слегка вывернутой, точки это — стрелки, а стрелки — прямоугольники, ну и там всякое по мелочи, не стоящее упоминания. О Р-схемах ранее не слышал или было настолько вскользь и давно, что и не вспомнить.

В качестве примера посмотрим, как будет выглядеть цикл for из примера выше.

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

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

Эти все диаграммы еще сложнее, чем программировать на любом современном ЯП.
Даже для домохозяйки.
Потому что в ЯП лексемы (if,else,for...) взяты с человеческого языка, и поток выполнения идет сверху вниз, т.е. аналогия с чтением и письмом человеческим языком.
И что такое функция любой школьник знает.
А тут какие-то разноцветные точки, стрелочки, переходы, всё очень сложно...
Вот если б люди между собой общались диаграммами, тогда был бы шанс.

И у сэра есть доказательства, или «я так вижу»

Ваши доказательства это не доказательства ©?

Кстати, домохозяйкам не нужны ни ЯП ни диагарммы.
Им нужен робот, который будет из продуктов делать готовые блюда и стирку перекладывать.

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

И у сэра есть доказательства, или «я так вижу»

Как минимум есть такое:
ru.wikipedia.org/wiki/ДРАКОН

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

У дракона и Р — разные области применения. Может как-нибудь и о первом статью напишу

На Oracle OSB, Blender, Drools BPM посмотрите. No code для скриптинга уже давно распространенная вещь. Ее вообще не для программистов делают, а для удобства пользователя которому нужна динамическая логика. Скажем мерчандайзеры интернет магазина, SEO и т.п. Можно конечно как в EXEL давать писать код через «формулы» на BASIC, а можно дать возможность накидывать динамический визуальный скрипт. Программисту конечно лучше писать код на ЯВУ. Обычному бизнес пользователю — это вопрос, кому что больше нравится.

Конфигурировать динамическую логику диаграммами в пределах определенного продукта — это вполне логично.
Я и сам такое реализовывал.
У меня реализация вложилась примерно в 100 строк с использованием DFS, когда надо обойти граф и преобразовать его в последовательные команды, вставляя Goto в точках ветвления.
Но тут в статье Владимир описывает программирование диаграммами как альтернативу general purpose ЯП, в отрыве от продукта для которого это используется, а это уже совсем другие вещи.

Конечно заменить императивные и функциональные языки в общем случае будет крайне сложно. В том же OSB трансформеры, которые только лишь преобразуют входной Rest JSON в выходной SOAP в реальном боевом проекте начинают расти до размеров когда они занимают несколько экранов. Тоесть визуальные скрипты тоже имеют свойство подвергаться энтропии и высокой логической сложности. И нет средств к дискретизации, тоесть нельзя ввести функции или макросы без программирования на обычном Яву и т.д. ООП, мета-программирования и прочих средств борьбы со сложностью программы тоже нет. Тоже самое с шейдерами в блендере. Однако процетировав М. Зубкова из Assembler для DOS и Windows — «не существует языков защищающих от не эффективного программирования». 2. В случае с OSB — менеджеры и бизнес аналисты все равно нанимают программистов заниматься трансформациями, что в прочем и правильно цивилизация начинается с разделения труда.

Эту идею надо развивать в многомерном пространстве.В 2D толк будет если наткнетесь на безграмотного «инвестора»))

Спасибо за идею. Но нужно начинать с чего-то одного, позже подумаем

У меня тоже есть мысли для создания 3-х мерного хранилища связанных знаний.

3-х мерного

У меня тоже есть мысли, я в вашем клубе. Но.
3-х мерное тут излишне. Многомерное — да.

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

Менше коду, менше технічного боргу.

с другой стороны — меньше кода, ближе к regex.

Ламає мозок. Баги легко наробити.

В сложных кейсах может и ломают. В простых кейсах явно проще потратить 1-2 минуты на однострочный регексп или даже нагуглить готовый, чем писать столбиком эдак 100-200 строк кода, в которых будет куда больше багов.
На практике часто используется гибридный метод. Тоесть на регекспах решаются простые кейсы, а потом эти простые кейсы собираются уже в какой-то более сложный алгоритм парсера.

Нагугли регексп на валидный формат почты по RFC.

Глупый вопрос: а разве программирование на настолько базовом уровне не преподаётся в школе? Ты ж не учёл проблему масштабирования. А ещё документация, тесты...

Я бы предложил иной подход: уход от простого текста и переход в более документальный вид. Позволяющий коду быть именно документом. Читаемым человеком. Со страницами, параграфами, гиперссылками, и прочей атрибутикой для замены человеческой памяти и логики. И без необходимости дебильного форматирования краказяблами на кшталт /* коммент хули не ясно */.

Почему твой подход никогда не взлетит: краказяблы и мнемокоды. Мало того, что все их надо вызубрить и помнить, так они ещё и непроизносимы, читай адски тяжёлые объекты для человеческой памяти. И вишенкой на тортик — в таком коде крайне тяжело видеть ошибки.

PS. А тесты тоже графами писать будешь?

разве программирование на настолько базовом уровне не преподаётся в школе?

Де факто — нет

краказяблы и мнемокоды.

нету там

А тесты тоже графами писать будешь?

И автоматизированные тесты писать буду

Дональд Кнут, литературное программирование, не взлетело в продакшн, хотя читать код Д. Кнута приятно.

«Вы, профессор, воля ваша, что‑то нескладное придумали! Оно, может, и умно, но больно непонятно. Над вами потешаться будут.©

Проблему

программирования без программистов

Microsoft решает еще с первых версий своего MS Office. Есть всем известный Excel, где можно лепить довольно кучерявые формулы, формы, диаграммы. Есть Power BI для более продвинутых выборок и анализа данных. Есть (или был) MS Access который совмещал в себе и базу и формы и функции и обработку событий. Для тех, кому этого было мало и все-таки нужно было писать какой-то код — был VBA сo своим IDE, дружественным для новичков.
В настоящее время для бизнеса есть глобальный Power Automate, который позволяет интегрировать почти все продукты MS и решать бизнес задачи без кода. В Dynamics 365 есть редактор workflow, который выглядит не как диаграмма, а как набор предложений: «Если что-то то делать то-то». Был еще Windows Workflow Foundation, который позволял XML диаграммы компилировать в C# код. Есть Microsoft Robotic Studio — там то же рилтаймовая программа собирается из «квадратиков».
Пример, который ты привел с чат-ботами думаю как раз очень показательный. Что бы не-программисту было удобно «программировать» что-либо, ему нужен интерфейс, который работает с сущностнями понятной ему предметной области! То есть нужен либо DSL, либо еще лучше — визуальный «конструктор» с понятными картинками.
Кстати — детей в школе сейчас обучают программированию на программе Scratch. По сути это что-то вроде «визуального BASIC». Но даже не смотря на примитивный набор конструкций (циклы, ветвления и т.д.) — освоение его требует многих часов обучения!
В этом проблема любых универсальных языков или визуальных редакторов для не-программистов: что бы ими пользоваться нужно иметь базовые представления об алгоритмах в принципе! Для программиста это уже в подсознании — он неосознанно разбивает задачу на шаги, видит циклы, условия... А вот для не-программиста очень сложно понять как задачу, описанную словами, можно представит в виде набора доступных элементов. Представьте что у вас есть фото столика, собранного из стандартного набора LEGO, но оно не достаточно четкое что бы рассмотреть каждый кирпичик. В принципе — вы понимаете как такое можно собрать, но начав собирать вы очень много раз будете заходить в тупик и начинать сначала. При этом если бы вам дали именно разобранный столик (как в IKEA) — то скорее всего вы бы смогли его правильно собрать довольно быстро. Потому что там части разные, и можно догадаться какая-зачем. А вот с универсальными «кирпичиками» — все намного сложнее.
По аналогии — вы пытаетесь придумать такое «LEGO» для не-программистов. С одной стороны программистам это не интересно, а с другой — для не-программистов освоить такое будет сложно.
Если вам интересны именно Р-схемы, то думаю имеет смысл применять их именно как DSL в какой-то определенной предметной области. Насколько я понял их и разрабатывали для управления ракетами. Возможно такой «язык Р» будет интересен программистам микро-контроллеров или каких нибудь встроенных систем.
Но как универсальный язык «визуального программирования» это скорее всего не взлетит.

Программированию без программистов мешает развиваться отсутствие программистов.

Программированию без программистов мешает развиваться отсутствие программистов.

Скорее, неравнодушных энтузиастов. Оно же как: если это ты — то тебя волнует только жопа в тепле, а если это кто-то другой — то этот кто-то должен быть неравнодушным энтузиастом.
Странно, что в статье не было про украинизацию, Грузию и «какая разница».
Может повзрослел? Та не, бред какой-то.

Абсолютно не так. Я сам это делаю, абсолютно бесплатно.

Ок, тогда зачем охватывать все сразу? Можно попробовать сделать что-то типа Scratch или, например, аналог www.celigo.com

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

Це не так.
Не обов’язково мати компілятор чи IDE для того щоб написати щось на С та оцінити чи варто взагалі продовжувати.
Коли треба зробити якийсь внутрішній фреймворк/DSL/бібліотеку, я починаю не з реалізації, а з тих місць, де воно буде використовуватись в коді. Просто пишу мнемокодом. А вже потім з цих викликів роблю АПІ. Це економить купу часу на подальших рефакторингах/переробках.

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

Не треба одразу лізти в бутилку, бо ніхто не каже що «не получится». Просто треба починати саме з маркетплейсингу: уявити когось із знайомих, кому це було б корисно, і спробувати вирішити цю проблему.
І почитайте щось про стартапи та як працювати з ідеями, типу

www.paulgraham.com/startupideas.html

When you have an idea for a startup, ask yourself: who wants this right now? Who wants this so much that they’ll use it even when it’s a crappy version one made by a two-person startup they’ve never heard of? If you can’t answer that, the idea is probably bad.

Можливо Ви просто типовий інженер, як я, який не любить усю цю бізнес-туфту і саме тому не зробили цю домашку.

Але саме відповіді на питання хто потенційний користувач та які свої проблеми вони зможуть вирішити будут ключовими під час пітча, а не технічні деталі чи красивий юай мвп. І відповідь «усі» та «будь які» не прокатить.

Просто треба починати саме з маркетплейсингу: уявити когось із знайомих, кому це було б корисно,

Это уже сделано, но невозможно описать в рамках этой статьи. Будут другие

почитайте щось про стартап

Это ещё не стартап

Это ещё не стартап

Стартап — не обов’язково те, на що треба гроші.
В даному випадку це якийсь потенційний продукт, який може бути комусь корисний. І тому підхід той самий.

Это уже сделано, но невозможно описать в рамках этой статьи.

Тоді чекаємо на продовження.

Щодо блок-схем згадалося, як на лабах з мікроконтронтролерів (я не програміст за освітою, в нас один семестр був C++ і один чи два семестри мікроконтролери) я забив малювати блок-схеми і запропонував замість них псевдокод. Викладач був не проти, тим більше, що я і так був єдиним на потоці програмістом і писав той асемблер на колінці усім бажаючим.

Зараз ми їх використовуємо для опису логіки, але якби не геніальне і доступне draw.io, це було б непросто.

Потому мы и не пользуемся блок-схемами, я предлагаю альтернативу

наброшу свои мысли.
1. В примере с чат ботом особой разницы не увидел
2. В UE4 есть Blueprints на котором гуманитарии пишут игровую логику, это выливается в итоге вот в такое адище blueprintsfromhell.tumblr.com/image/182038599491
3. как мержить эти ваши Р-схемы?

2. В UE4 есть Blueprints на котором гуманитарии пишут игровую логику, это выливается в итоге вот в такое адище blueprintsfromhell.tumblr.com/image/182038599491

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

Как говорил Башка из Кремниевой долины: «Осталось это только реализовать».
Есть много сложных вещей, которые невозможно объяснить машине. Как объяснить, что в в какой-нибудь форме в приложении можно загрузить данные параллельно, а в другом месте только последовательно?
Каким-нибудь конструктором сайтов можно склепать какой-нибудь интернет-магазин. Но никто не хочет «какой-нибудь». Все хотят с изюминкой. А этой изюминки нет в стандартных средствах конструктора. И здесь уже проще будет написать интернет-магазин с нуля, чем городить чудовище.
И в конце концов, даже если появятся такие могучие системы, которые распознают ТЗ, то нужно ведь, чтоб эти системы кто-то обслуживал, улучшал. И тут снова нужны будут программисты. Чудес не бывает.

В интернет магазинах главные изюменки это увязать его с ERP, и прикрутить в админке CMS чтобы мерчандайзеры могли без помощи программистов перенастраивать UI как им надо, хоть раз в день. Добрасывать баннеры огромной надписью «скидка 99% только сегодня», «доставка по городу бесплатно» и в том же духе. А системы где они могут динамические цены формировать (цена зависит от клиента, в общем вариант жульничества) вообще торговцами обожаемы.

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

Черепаха называется «все-таки, как его не назови, это программирование».

А киты соответственно получаются такие :

Кит первый : composability. С ним обычно все где-то между «нет вообще» и «плохо». Либо нет возможности вынести кусок функциональности в отдельную переиспользуемую сущность. Либо reusable components можно писать исключительно на каком-то «настоящем» языке.

Или какая-то беда с параметрами: параметры «нельзя», либо максимум один, либо передавать только константы, или ещё что-то в этом роде.

Отсюда мы плавно переходим к Киту номер два: беда с моделирование данных. Могут быть проблемы с тем, чтобы в рамках процесса что-то посчитать и сохранить результат (чтобы использовать его два раза). Либо такой возможности нет вообще. Либо из типов данных у тебя только строки. Может быть так, что все данные представлены в виде global или local key-value map, и это единственная структура данных, и начинаются пляски с магическим именами ключей, которые ожидаются в той или иной точке процесса.

Отсюда переходим к Киту номер три: discoverability and namespaces. Имена, создаваемых пользователем(имена процессов, переменных, ключей в key value map) , могут жить в одном глобальном плоском неймспейсе, который со временем превращается в помойку. Если вам дают поиск, то он может быть только по имени (которое вы уже должны знать). Если и есть поиск по телу/атрибутам/чему-то подобному, то он может быть странным, так показать контекст, в котором нашлось искомое, тяжело — это ж не текст, из которого можно вырезать сниппет

Отсюда переходим к Киту номер четыре: редактирование. Если нет нормального поиска — не будет и поиска с заменой. Если нет поиска с заменой — плохо придуманные имена сущностей рискую быть с вами навсегда. Контроль версий может быть, а вот сравнение разных версий или что-то типа diff-а — уже нет. Два человека, которые правят одно и то же, либо ограничены каким-то глобальным mutex-ом, либо рискуют затирать правки друг друга.

Я, честно признаться, уже давненько не брал в руки шашки, но вот я открываю упомянутый в комментариях corezoid и вижу там в tutorial вещи, Киту намекаю, что «все как всегда». Передаём json/kv map, можно интерполировать значения оттуда в строки (если я правильно понял), есть галочка «отослать все наши данные в вызываемый процесс» (привет, магические имена keys?)...

Скажите мне, что я застрял в прошлом, прогресс шагнул далеко вперёд, и state of the art выглядит совсем не так :)

Спасибо, хоть кто-то написал за меня коммент. Тут на отдельный топик тянет, ибо это мат.часть. Добавлю лишь психологический аспект: писать буквами просто дешевле.

Что на самом деле дорого в программировании, так это «покращення». Потому что за каждым покращенням стоит необходимость его ВЫУЧИТЬ. При этом обучающемуся мало кто поможет: покращень такое количество, что невозможно разобраться, что на самом деле ценно. А по-дефолту ценно всё новое — и это стимулирует не допиливать старые технологии.

Аспект: допиливание языков и фреймворков — это всегда ДОБАВЛЕНИЕ новых свистоперделок. И практически никогда — удаление старых. Это как книги, если бы автор их не перечитывал перед попыткой публиковать, а потом после него ещё и редактор.

Иначе говоря, проблема программирования — МУСОР. Что же делается попытками добавить новое, особенное программирование? Конечно же новый мусор!

PS. Если бы русский язык меняли и покращивали фреймворками так часто, как JavaScript, простой человек, который умеет говорить, стоил бы как программист. И конечно был бы NoCode язык жестов. Вернее, тысячи их.

Я бы добавил ещё 1 поинт: каждое покращення — это ещё и пачка багов, не всегда очевидных. А когда мы плагинами добавляем 10-к таких «покращень», как они будут взаимодействовать между собой — неизвестно никому, даже их авторам. И натолкнуться на граблю, которая в результате зафризит весь процесс разработки, ибо, к примеру, 2 плагина в каком-то специфическом кейсе не смогут состыковаться друг с другом — более, чем реально.

Появился adept и сказал: «low-code/no-code» — как его не назови, это программирование ...

с мышлением «домохозяйки» «low-code/no-code» — сделать ничего не может )

Дорожка скатертью!
Мы и кухарку
каждую
выучим
управлять государством!
В. В. Маяковским в поэме «Владимир Ильич Ленин»:

Та навіть було достатньо і однієї черепахи. Все, що придумано в архітектурі ПЗ, всі оці фреймворки, БД, клауди і все інше аж до SOLID та книжки по паттернам — воно ж нікуди не дінеться ні при діаграмах, ні при кожаєвському підході, та і взагалі ніколи. Бо нам треба, блін, якось запрограмувати 100500 вимог бізнесу, обмежень, зв’язків, проблем і імпрувментів.

Стейт оф зе Арт от Сохацкого

1) Дрочка на блок-схемы и попытка впарить кому то квадраты со стрелками в виде мешка с баблом тянется с тех пор как эти бизнес-процесы придумали, еще начиная с почты и Лотус Ноутсов. Потом было несколько разрозненных стандартов WfMC XPDL, BPEL, паб-саб меши RETE и бектрекинг системы. Все это уже было в 70-х и бизнесс аналитики 70-х это успешно использовали как инструменты. В 2008 году произошел черный лебедь: все стандарты управления бизнес-процессами объеденились вокруг BPMN, и это превратилось в единственный стандартизированый язык ISO 19510.

2) Программисты, которые реализовывают эти стандарты вообще не должны мыслить (это пагубно для их же самих) в терминах сетей петри, конечных автоматов, алгебраических состояний на языке джаваскрипт и т.п. Все попытки писать код используя эти модели видятся мне фатальными. Выжила только система линейных типов Жирара и линейные логики для моделирования конкурентных и паралельных систем типа CCS, CSP, пи-калкулус. Процессы — это бесконечные пооследовательности событий, каждое из которых полностью типизированная MLTT программа. Сравнение процессов — их бисимуляция, а темпоральные свойства моделируются с помощью переменных времени.

3) Кроме бизнес-аналитиков [1] и программистов [2] есть еще пуско-наладчики, поддержка пользователей, конфигураторы. Вот ключ к успешной продажи ваших «квадратиков» лежит как раз через них, если у вас есть конструктор то подразумевается что программисты раз написали и все уволены (размышляют над улучшениями), дальше должны делать все конфигураторы. Конфигураторы и внедренцы стоят денег и их тоже нужно минимизировать. Успех внедрения зависит от принятия вашего продукта конфигураторами, внедренцами, заказчиком.

4) За пределами дискуссии лежит вопрос о проверке свойств программ. Если допустим мы можем предоставить в конструкторе рисовать аналитиками квадратики, то писать теоремы о свойствах этих процессов кто будет? Аналитики? Программисты? Математики? На каком языке они это будут делать, так как пока нет консенсусного языка моделирования, такой как Агда например или библиотеки для Агды. Здесь до сих пор еще актуальны модел чекеры (TLA+, Promela, CSPM).

5) Еще одна тема про которую все забывают это нормативно-правовые акты. Украинский КЗЗ не хуже, а может и лучше NIST, так как в нем написано на каком уровне нужно доказывать корректность. В отличии от NIST, где слова math вообще нет, в украинском КЗЗ слово математика встерачается десятки раз! Уровень Г7 — это автоматическая верификация пруверами или модел чекерами и полное доказательство преобразований любых даных любой функции (кванторы и логики высших порядков). Подумайте сколько имплементаций ваших систем управления квадратиками или ORM вьетнамского компьютер саенса написаных на говно-языках сразу отсеится!

Это тот Сохацкий, что хотел раскулачить всех нас?

Да, это тот Сохацкий, которому ты прислал вместо тестового задания демо от Turbo Pascal 5.5 с рендомными прямоугольниками разных цветов на флеше в 2011 году и который не взял тебя на работу. Он :-)

И именно тот, о котором мне сказали: он получает меньше, чем хочешь ты :D предложив работу на 2.5 штуки вместо 3.5

Я вижу ты дофига бабла срубил за 10 лет, что курсовую 19.005-85 дописать не можешь.

Я бесплатно и с кровати не встану в отличии от задротов

Гениальная инвестиция для тех кто любит деньги. Инвестиция в кровать!

Отличная: делаю за что платят помогая тем самым заработать другим

На работы можно посмотреть, кроме p-схем что за 10 лет написал? Сколько заработали на твоих продуктах? Сколько получил за работу? Я так чисто спрашиваю, инвест-климат пронюхать, чтобы бы люди знали куда деньги инвестируют на MVP. А то мы тебе счас насыпем на Патреон на p-схемы, а ты в кровать пойдешь дрочить как Головач. АТАТА

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

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

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

Цель — кровать, я понимаю. Успехов дружище, держись!

И сиськи! Я понимаю, что на красивых женщин к тебя аллергия, но так уж вышло что у меня — нет

И нож еще, нож. Ты ведь забыл, что ты спортсмен-атлет, а я задрот, нужно это подчеркнуть! Кровать-Сиськи-Нож, осенняя коллекция 2021 тенденций в ватной ИТ-сфере Украины. «Саша Белый, блоггер и один из неформальных лидеров ватного IT-сообщества Украины на вписке пишет ГОСТ 19.005-85 используя донаты через Патреон». Мышь и Абрикосы.

Чувак, меня интересует под этот проект получить грант.

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

Что значит «срубить»? Гранты дают на разные проекты, в том числе на такие. Я его реально буду делать и сделаю, потом может и получится даже с этого бизнес

Гранты дают на разные проекты, в том числе на такие.

Гранты дают на реализацию идей. А у тебя красной нитью проходит ровным счетом одна идея — срубить бабла. То есть грант для тебя не средство достижения цели, а сама цель. Я хз ловится ли щас жирный лещ на такое... Может и да, но как-то слишком прямолинейно имхо.

Так вот идея: сделать р-нотацию. Чем плоха?

Тебе на ДОУ заплатили за эту статью?

Походу ДОУ заплатило Кожаеву, чтобы он написал статью как он пилит гранты с помощью ГОСТ 19.005-85 :-) Вдумайтесь, Максим Ищенко вынул деньги из своего кармана и дал бабосики от рекламы с ЕПАМ и Люксофт на этот контент! Вот это сериал! Жду, когда Кожаев защитится и начнет объяснять Витязю как писать системы графического управления людьми. Возможно ему нужно устроиться в corezoid!

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

Ну і який це no-code? Це те саме програмування, вид збоку.
Просто нова мова. Можливо, з меньшим вхідним порогом. А відходження від представлення коду у вигляді неформатованого тексту дозволяє вам казати, що це НЕпрограмування.

У цьому і фішка, можна зробити редактор де бізнес юзери можуть будувати бізнес правила, не кодуючи. Можна зробити редактори шейдерів, де користувачі будують послідовність текстурування і бамп-мапінгу. Див. Drools і Blender.

что угодно, лишь бы код не писать

Что угодно, лишь бы программистам не платить

Все фигня. И не блоки и не Р-схемы и даже не «дракон-схемы» Паранджанова. Рулят графы:
-«Everything is a graph» © corezoid.com
А штука, которую пилит автор уже есть с Node.js под капотом и называется Node-RED (советую поклацать) она проигрывает Корезоиду мягко говоря «за обе щеки» говорю как чел с 10 лет работы в этом :) И по юзабилити и по спектру решаемых задач
+ это же подтверждается растущей аудиторией корезоида, половиной укр. Банков, несколькими зарубежными, Ворлд оф танкс, нова пошта, Варус, доставки, куча всего западного )

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

ок ) но про конечный автомат все-равно подумайте :)
Если будет фряшная альтернатива Корезоиду Вы порвете огромный сегмент рынка :)

если вдруг понадобятся бета-тестировщики — пишите ;) успехов так или иначе

мм интересно, а где почитать про применение в World of tanks, очень интересен кейс

вероятно нигде. Это инсайдерская инфа с мохнатых времен )
Более новые кейсы внедрения можно найти в Линке у людей упомянутых на самом же сайте ПО

Выглядит интересно. Можно ссылку на github?

Мне кажеться все эти схемы-конструкторы, это все допотопное прошлое, умрло во времена вижл бейсика и будущего у него нет. Реальный «но-коде» будет выглядеть как аи, который получает текстовое описание задачи на входе, а на выходе отдает готовый к деплою докер-контейнер. А задача инжинера будет проверить прально ли контенер работает, и если нет, то отдать на переработку с уточняющими инструкциями. В будущем, конечно, даже этот инжинер не нужен будет...

Мне кажеться

Тебе кажется, 100%

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

Я джва года хочу такую игру

Я джва года хочу такую игру

первые нанчинаня уже тут. copilot.github.com

кажется )))

Реальный «но-коде» будет выглядеть как аи, который получает текстовое описание задачи на входе

+1 yet another конструктор который суть другая форма императивной программы, скорее всего не взлетит. Нечто распознающее неформальные сентенции (natural language-like) имеет больше шансов, в несложных кейзах это уже реальность (та же алекса амазона). Search-like интерфейсы тоже используются в нишевых вещах — вроде Q&A в PowerBI, или более AI-шный Thoughtspot.

Топорное «текстовое описание на входе» звучит также слишком утопично, а knowledge base который само-организуется через диалог м\б реалистичнее, с каким-то вариантом computational graph под капотом.

Це складно. no-code solution має розпізнавати п’яну балаканину на криворізько-миколаївському суржику і видавати на виході url на сайт та залиту на Play Market аплікушку.

Ну... в Haskell уже есть derivnig который позволяет компилятору выводить некоторые методы. Тут другой вопрос: чем сложнее и деликатнее инструмент, тем сложнее найти и обучить людей с ним работать.

Все це дуже цікаво, хоч і не ново. І, як і в попередників, впирається рогом в один концептуальний момент.

Намалювати FSA, хоч з пам’яттю, хоч без, та нехай навіть зробити стуктурну та функціональну декомпозицію системи — це навичка, якій все одно треба навчатися. І зовсім не у всіх воно виходить, навіть у 23-річних архітектів. А зважаючи, що інтелектуальна більшість здатна ефективно блукати у трьох соснах, передбачаю обмеженість застосування пропонованого середовища системами з двох сосен, що не дуже привабливо для великих грошей.

Як хобійний пет-проект для саморозвитку — дуже ок. Як потенційна годівничка... Ну, таке, я б не заклався.

Учить нужно всё, кроме сосать сиську, ссаться в штаны и хватать ручками — биология такая. Но согласись: разные инструменты занимают разное время на обучение

Нема і не буде ніколи інструменту, що дозволив би будь-кому калапуцати якісний код після тижня інструктажу.

Тому що розв’язок будь-якої задачі на 3/4 міститься у її постановці. Для постановки ж задачі потрібні мізки, а не інструмент. Треновані мізки з досвідом, навичками та іншим, що не заміняється діаграмками та мишкотиком.

youtu.be/cDA3_5982h8

за неделю нет. за три месяца да )
читайте просвещайтесь: corezoid.com/blog/pumb-begunov :)

О_о похоже на обмен несвязанными англоязычными ресурсами )) я пас

Хвилиночку, у вас же ж є потужний інструмент для розрулювання бізнес-комунікацій? Нє?

у меня есть «потужный» инструмент оценки кпд и трудозатрат в черепной коробке :)
оперировать англоязычными видео без ссылок на тайм-коды и комментариев к чему они я не готов. Я Вам скинул историю внедрения того, что по Вашему мнению невозможно.
+ я де факто с этим проработал 7 лет и сейчас дальше косвенно работаю как ВА уже.

Вы в ответ скидываете какую-то извините «шляпу» с рисованными штуками для чайников. Как она перекрывает или соотносится со ссылкой выше? В чем собственно аргумент этого видео в данной дискуссии? И какая к лешему это бизнес-коммуникация? :) Бизнес начинается там где ясны интересы сторон и каждому есть что предложить. Что именно Вы предлагаете я пока не понял :)

По вашій ссилці я не побачив нічого конкретного, лише простирадло з баззвордів. У відповідь я запропонував всі ті самі баззворди, тільки перекладені на музику.

Вважаю, ми квити :)

лол..
во-первых у нас не было никакого соревнования, чтобы быть «квитами»
во-вторых используйте опцию Хром с переводом на родной язык, если с английским проблемы :)
ну и последнее — то с чего начинали:

Вы закинули фразу не имеющую ничего общего с действительностью:

Нема і не буде ніколи інструменту, що дозволив би будь-кому калапуцати якісний код після тижня інструктажу

собственно на нее я и отвечал. С поправкой, что неделя нет, три месяца — легко. Вы не начнете ничего программировать полезного для бизнеса на чисто традиционном подходе не важно с какой архитектурой. JS который считается лёгким — 3-6 месяцев на он-бординг базовый, потом еще с пол годика стажировка или какой-то пет-проект. И уже потом возможно будет джун маломальски перевешивающий пользой вред и отжираемое время.
С Корезоидом за три месяца начать автоматизировать бизнесовые таски начиная с рассылок и чат-ботов — легко. А за год человек въедет в серъезные тяжелые микросервисные проекты по какому-нибудь корп. кредитованию и будет их вести.. без тех. образования и предварительного опыта в программировании. Я точно знаю это потому что сам подготовил такого человека до того как покинул прошлое место работы )

Собственно все что я хотел сказать. Вы утверждаете какие-то предположения с потолка, я отвечаю с позиции опыта. В какой области мы «квиты» ябез понятия. Не нравится история ПУМБ — по ссылке клацните выше там историй вагон и маленькая тележка. Blue Finance Mamboo и даже знакомые вещи вроде Новой Почты и АТБ. То что Вы утчерждаете было актуально в 2001 двадцать лет спустя это огромный рынок с мощными капитализациями и своими единорогами. Поэтому говоря Вашим языком «не меліть дурниць» и не утверждайте о чем-то в чем Вы не имеете компетенций. Хорошего вечера!

У людей других специальностей есть эти навыки, но нет знаний программистов

Самое забавное в том, что идея low-code совершенно не новая. Когда-то давным давно придумали запросы SQL, чтоб менеджеры и бухгалтеры смогли работать с информацией без операторов. К чему это привело?

Совершенно правильно, прогресс он есть

А привело к тому, что появились вакансии для работы с SQL, но не появились бухгалтеры со знанием SQL. Так и у тебя — будет вакансия на среду программирования Кожаева.

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

Можем написать статью совместную, почему нет

может. но мне интересно сотрудничество другого рода )
статьи я больше на другие темы пишу. С ИТ в основном не связанные

Я с удовольствием узнаю как и кому это продать. А если у сера есть идеи где взять денег на MVP, так вообще отлично.
Ты постучись пожалуйста в личку

они уже есть) только на среду Витязя

Совсем для другого SQL придумали

Low code и low code это тупиковая ветвь эволюции, мне например в Azure Logic Apps которые вообще рассчитаны на гуманитариев было сложнее разобраться чем в новом языке программирования.
Не представляю как Logic Apps будут использовать гуманитарии, которые не всегда в интуитивно понятном UI могут понять какую кнопку нажимать.
С P-схемами мне кажется такое же будет:

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

По опыту Р-схемы легко осваиваются не программистами

вы не представляете как далеко вы от истины ))
corezoid.com мотайте вниз читайте саксесс стори внедрения :)
в прошлом году бизнес чат apple подключился еще :)

оставьте в покое гуманитариев, они нас хантят, у них мы учим английский. Не все что технарь = писать код :) Есть те кто его тестит, деплоит, конструирует и так далее. А есть еще те кто язык бизнеса понимает и переводит в то, что вам писать. И когда у таких людей появляются подобные инструменты это чистый growth :)

Без образ. А є посилання «саксесс» сторі за межами сайту корезоїда?

да. а гуглить умеете?
www.linkedin.com/...​4/detail/recent-activity
думаю это открытая инфа раз ей делится СМО
и не думаю, что он «приукрашивает» я собеседовался во многие компании, которые Вы найдете по ссылке если будете очень долго скроллить в года 15-17 :)

Все гораздо интересней чем Вы представляете. Я фрилансил на Сz на чувака в Лондоне, а вакансии есть в Испании, Финляндии и даже в США видел (Атланта). В первые две страны я даже собесился, но релок пока не интересен :) Более того у чуваков уже своя сертификация, на манер Microsoft или Сisco сожно подтвердить навыки сертификатом. И апрув интеграции с Apple Business Chat :) Никаких образ, просто хватит жить в каменном веке ))
Это давно большой рынок со своими нюансами. Автор статьи вряд ли придумает что-то новое «не велосипед» — там очень мощная алгоритмическая база под капотом, а архитектура вообще искусство, но это уже другая история :) Если что и получится, а я искренне желаю успеха, конкурировать придется с гениями и акулами бизнеса :)

Ваш Сorezoid это аналог Azure Logic Apps, может чуть упрошенный, интересно посмотреть, как обычный пользователь, а не технарь на нем сделает цикл, под технарями и не имел в виду только разработчиков. Тестировщики, девопсы, и может даже бизнес аналитики тоже смогут Сorezoid и Azure Logic Apps использовать, а вот те пользователи, кто далеки от IT, нет.
Upd: А учитывая уровень знания английского вне IT, то тем более мало кто поймет.
Те элементы что нам кажутся простыми и самоописуемыми: Condition, Deley, API Call, Waiting For Callback, и тп, обычного пользователя только напугают.

Ваш Сorezoid это аналог Azure Logic Apps

не уверен, но вот именно с этим инструментом я знаком мало. Из ВPM cистем или Intelligence Automation (так претендует называться новый сектор, ранее была статья ДОУ на тему с этой фразой) у корезоида лучшая стейт-машина, скорость, масштабируемость и много других параметров

и может даже бизнес аналитики тоже смогут Сorezoid и Azure Logic Apps использовать, а вот те пользователи, кто далеки от IT, нет.

да, тут вы правы. Но этот концепт был откинут как несостоятельный еще во времена Привата. Сейчас у ребят своя сертификация и Вы можете заапрувить навыки и стать более востребованным Сorezoid Developer со своей линейкой от джун до лид и вполне достойными вилками :) Этим и не должен заниматься «пользователь» — к чему эти утопии :)
Может на такие мысли наталкивает статья автора, но он только начинает, что-то ресерчить и по сути набрасывать, на этапе «канарейки» будет набивать все теже шишки, что уже набиты Сz и в итоге придет к тому же. Дело не в пользователях становящихся за неделю разрабами, в профитах вроде скорости изменений, деливеренса, более низком пороге входа и заменяемости :) Может Вам как разрабу эти профиты не очевидны. но поверьте обилие фанфаро-постов о внедрении на страничке СМО показывает что бизнесу они понятны и дороги ))

Upd: А учитывая уровень знания английского вне IT, то тем более мало кто поймет.

это тоже лишнее. вся дока, обучение и поддержка есть на родных для СНГ языках и мовах :)

обычного пользователя только напугают.

и правильно. ОБЫЧНОМУ пользователю, кто бы это ни был там нечего ловить. ОБЫЧНЫЙ пользователь может выступать потребителем, на края бетатестером тех ИТ или бизнес-продуктов где используется Сz но никак не заменой разработчикам. Вам нечего бояться :)

Тогда получается вместо Java/.NET Developer-а надо нанимать Сorezoid Developer-а на ту же ЗП,
и какая ксатомеру от этого польза?
Плюс еще вам платить за использование платформы.
Ну и на Java/.NET/JS/e.t.c намного проще найти разработчиков же.
Ну и смысл от разработчика, если он все равно упрется в ограничения платформы?
Каким бы он крутым разработчиком не был.
Если писать на бесплатных Java/.NET/JS никаких ограничений не будет, и платить никому не надо.

Сомневаюсь, попробуй написать foreach на любом языке программирования, и на Сorezoid или другой nocode платформе, и засеки время там и там.

Не пробовал Coresoid, пробовал Р — легко

foreach это такая простота ... даже говорить неочем. Попробуйте написать чтото сложнее, например банальный парсер этой страницы на P. Размеры диаграммы сильно удивит. Ее читаемость — тоже.

Тут вообще есть ловушка для ума. Поскольку человечество не зря придумало ЯП и его аналог — математическую запись. Выражения «1+1=2» читаются быстрее человеком чем «если один прибавить к один будет два».

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

Я зато напишу парсер кода я.п. с помощью Р — легко

Для парсера яп есть другие инструменты.
ANTLR например. И это не блоксхемы.

Спасибо, что ты рассказал мне о ANTLR :) Вот прямо очень я тебе благодарен. Но так случилось, что у грамматик есть графическое представление и оно(о ужас) очень похоже на Р — диаграммы.

Можно увидеть эти диаграммы ? Особенно когда речь идёт не о каком нибудь Lisp а грамматики C++ regex или perl ?

Легко. Ставишь ANTLR — плагин для иклипс и вуаля. Сумеешь, или тебе помочь? Можно у меня посмотреть на машине, во время видеозвонка

Диаграмма это же вроде картинка ? Можешь сделать скрин и прислать сюда. Грамматика с++

Вот кстате погуглил
stackoverflow.com/...​-c-grammar-file-for-antlr

История вопроса.
Сам по себе ANTLR не очень то и подходит для описания такой сложной грамматики. Про картинки и блок схемы и говорить не приходится. Наверно тем кто этим занимается десятилетие не хватало P диаграмм.

Сколько ты используешь ANTLR, какие задачи решал? Проблема в том, что это стандарт. Как спринг для Энтерпрайз

Да постоянно попадаются задачи с парсерами. На разные языки. Сейчас например натягиваю SQL на key/value.
И надо сказать что разбить запрос на токены и построить АСТ дерево это самое простое в этой задаче и без antlr (по крайней мере покрыв подмножество грамматики на 80% самых распространенных случаев). Сложнее отправить это АСТ и выполнить в интерпретаторе, хотябы с базовыми оптимизациями. Вот сейчас думаю как джоины с группировками прокручивать. Не то что это сильно сложно, но точно в неск. раз сложнее чем запрос конвертнуть в аст

По-моему ты плохо прочитал. Всю твою специализацию по конвертированию синтаксиса в аст я написал вручную за дня три в достаточном для своих нужд объеме и доволен. Зачем мне какой-то Кожаев со своими р диаграммами, который будет делать тоже самое месяц ?
Лучше вот там на Энтерпрайз пасись. Там не денег не времени не считают. Там должно прокатить.

Так я тебя лично вроде-бы ни о чём не просил.

Тогда получается вместо Java/.NET Developer-а надо нанимать Сorezoid Developer-а на ту же ЗП

не на ту же. Вилки ниже гораздо.

Плюс еще вам платить за использование платформы.

я не работаю на Middleware. Я просто теку от их продукта :)

Если писать на бесплатных Java/.NET/JS никаких ограничений не будет, и платить никому не надо.

не надо и тут. Корезоид не единственная штука. Есть и open source BPMки вроде того же Node-RED они послабее возможностями, но зато клево кастомизируются и насыщаются оными силами тех же программистов. У Привата есть вполне себе неплохой опыт перехода CZ -> NR

Вопрос в том, что рынок есть и он растет. Не так ярко спрос как на чистый кодинг, но вполне себе рынок. Это не какие-то зачатки вроде ARPANET а уже вполне себе рыночек

и какая ксатомеру от этого польза?

cмотря кто кастомер. Если это условный СПД то там может и Wix/Wordpress всю автоматизацию закроет. Если это крупная финансовая установа вроде Банка, с кучей бизнес-направлений и регулярным обилием инициатив и изменений — профит существенный. Очень меньше нужно разрабов, очень менше времени занимают изменения, дешевле, мобильней. Сложно на пальцах объяснить, но оно перекрывается даже с учетом выплат за платформу )

«Интуитивно понятный UI» — такой вещи нет. Есть интерфейс, который соответсвтвует представлениям и модели окружающего мира и который не соответствует. Который соответствует — тот «интуитивно понятный». Но модели мира у всех разные, а в ИТ важны детали и чтобы они совпадали у двух разных людей... Поэтому стараются интерфейсы в бизнес приложениях делать как минимум похожими и не изобретать новые названия для документа, файла, папки. Психология и физиология

Спасибо за статью!

Писати код об’єктивно не складно. Принаймні після декількох тисяч строк написаного коду це стає просто, навіть на новій технології писати код не так вже й складно і не так вже й довго.
Писати хороший і «чистий» код трохи складніше, але це вже нюанси.

А от що важко, так це примусити написаний тобою код працювати правильно і працювати в принципі.
Інфраструктура і оточення, ось що складно, а не заміна чергового циклу чи автомату з однієї технології на іншу.
І чим старше і досвідченніше я стаю, тим більше інфраструктурних проблем я бачу.
І мова навіть не про скейлинг на тисячі серверів якоїсь розподіленої системи, з лоад балансерами, звичайні десктопні програми в яких є БД і вихід в інтернет вже створюють чимало проблем, якщо відсутня чітка і конкретна інструкція як з нею працювати і як підтримувати.

Коли я бачу починання з новою технологією або тим, що описано тут в статті, в мене відразу виникає питання про інфраструктуру і підтримку написаних таким чином програм.
Якщо оточення буде легко і просто конфігурувати, простіше ніж з існуючим софтом — я двома руками ЗА і навіть готовий стати ентузіастом-волонтером.
Якщо ж виявиться, що програму з блоків зможе написати кожна хозяйка, а для запуску і підтримки треба буде Науково-дослідний інститут на чолі з Кожаєвим... Ну навряд на таке хтось дасть грант.

Якщо оточення буде легко і просто конфігурувати, простіше ніж з існуючим софтом — я двома руками ЗА і навіть готовий стати ентузіастом-волонтером.
Якщо ж виявиться, що програму з блоків зможе написати кожна хозяйка, а для запуску і підтримки треба буде Науково-дослідний інститут на чолі з Кожаєвим... Ну навряд на таке хтось дасть грант.

Не попробуешь — не узнаешь

Так це не мені треба пробувати, ця інформація повинна бути доступною вже до того, як я вирішу завантажити умовний тулчейн для малювання блоків в редакторі.

Те, що скріпити декілька десятків блоків лініями буде не супер складно це очевидно, тут доводити нічого не потрібно.

Мені потрібно знати, що додавання кожного нового блоку не вимагатиме танців із БД, драйверами, конфігами, різноманітними конекшенами і т.д.
Ну і само собою, наскільки легко це буде деплоїти, розповсюджувати, накатувати патчі і т.д.
Якщо у мене не буде всієї вичерпної інформації, то мені таке в принципі не буде цікаво ні як розробнику ні як клієнту ні як інвестору, бо я розумію, що ви не продумали більшу половину всього процесу і це все разом не буде працювати.

Для начала я делаю что-то, потом что-то чтобы работало, потом чтобы правильно

Інколи треба починати з кінця. Наприклад скласти таку діаграму для чогось більш реального ніж кава та магазин. Уявіть 3-4 реальних юзкейса для «домогосподарок», складіть діаграми та уважно подивіться до якої складності вони реально читабельні. І як їх зробити такими після цього рівня (структурування, навігація...)
А вже потім робити юай та компілятор.
Якщо Ви вже цей етап пройшли, то було б цікаво побачити такі діаграми.
І, доречі, корисно було б для порівняння вирішити ті ж проблеми у, наприклад, дитячому скретчі.

Ще одна проблема — де провести лінію між складністю/функціональністю фреймворка/мови та «програм». Тобто, чим простіше буде «запрограмувати» взаємодію з периферією або інтеграцію з сторонніми сервісами, тим більш громіздким і менш гнучким буде фреймворк/мова. І от тут вже немає срібної кулі.

Для начала я ищу грант, если дадут — нужно делать

Якщо ціль — це тільки грант, то ок. Але сумніваюсь, що і його дадуть без нормальної презентації та аналізу проблеми.

если дадут — нужно делать

Є робота, яку треба зробити ДО того як виносити свою ідею на загальне обговорення. У свій вільний час і за свої. Якщо Ви самі не розумієте чи вийде з цього щось путнє, то навряд чи хтось буде робити це за Вас, а тим більше дасть на це гроші. Я б точно не дав.

Більше ніж на це можна отримати грант — точно є, вибач.
А ті, в кого є більше, точно на тебе не будуть витрачати час, бо вони такого дитячого садочку давно вже надивились.
І якщо ти ще досі не побачив це, то перечитай коменти: твій пітч просто бездарно завалено.
Якщо вистачить розуму побачити тут конструктивну критику — добре.
Якщо ні — то тут нічого не допоможе. Навіть ніж за паском.

В стартапе от Кожаева слова «бороться за гранты», «выбить грант» и «раунд инвестиций» обретают новый смысл 😂

Ага, если не дадут я к ним приду с молодыми исследователями с тренировки. Они даже читать умеют — учёные!

Они даже читать умеют

Рэп наверное какой-то?

Инструкцию к паяльнику для инвесторов.

Владимир, а про ДРАКОН статьи не будет случайно?

Я правильно понял, что в нотации два элемента: switch/case и goto? Или кроме того, что в ГОСТ, есть дополнения ради удобства?

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

PS если кто надумает искать детали по этой нотации, то гуглите «Р-схемы» или «ГОСТ 19.005-85»

как отдельный шаг? или в рамках действия, что-то вроде «загрузить список и сохранить его в переменную А»?

Можно как отдельный шаг, можно в рамках действия — зависит от контекста

Чочо? Там якраз, все структуровано до краю.

От тільки легше від того не стало :)

Потому, что нет четких правил построения UML

Вова, ты что, предлагаешь другим людям поработать БЕСПЛАТНО???!!!111 Не верю :D

Не бесплатно, а потому что интересно.

Это пока не стартап — опенсорс-разработка

Таки бесплатно.

Ок, ты получаешь грант и славу.
А что получат энтузиасты?

Работу над грантом, за деньги. Опционы если до этого дойдёт

Работу над грантом, за деньги. Опционы если до этого дойдёт

Давай до мене в стартап, будеш працювати за долю в бізнесі!

Проект хоть интересный? Коллектив дружный?

Проект хоть интересный? Коллектив дружный?

Головне, що працювати там Велика честь!

У меня не стартап, пока. Будет стартап — буду платить

Хорошо, насколько я понимаю, юрлицо которое примет грант — Гильдия?

Зачем? ФОП — Кожаев Владимир Викторович. Но до гранта как до луны

Ну во-первых, как правило гранты персонам не дают, а дают только юрлицам.
А во-вторых, если дадут — то могут истребовать обратно, а ФОП отвечает своим имуществом.

Лучше посоветуйся с юристом, тем более он же для вас дает бесплатные консультации. Ну и вообще — концепт измени в целом. Потому что ты был всегда против общественности и за индивидуализм и тут внезапно — развернулся на 180.

во-первых, как правило гранты персонам не дают, а дают только юрлицам.

Не правда

всегда против общественности и за индивидуализм и тут внезапно — развернулся на 180.

Я за деньги и на 360 развернусь. С другой стороны, я против лапши на уши. Покажи в статье лапшу

Я написал «как правило», соотвественно ответ «не правда» не может быть применим, ибо мой тезис — не аксиома а ряд наблюдений. Например — как правило, зимой идет снег и мороз.

Лапша в том, что предлагаешь внести сторонний результат интеллектуальной деятельности в свой продукт, публично обещая разделение будущего уставного фонда с повышением капитализации без предоставления договора-оферты и самого фонда. Еще раз — у ФОП нет такого. Он отвечает своим личным имуществом.

Ты готов подписать такой договор от лица ФОП, в котором будет зафиксирована планируемая капитализация, сроки и долевое участие сторон?

договор от лица ФОП, в котором будет зафиксирована планируемая капитализация, сроки и долевое участие сторон?

А в случае гранта такого условия не выдвигается

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

не дойдет. чтобы конкурировать с такими типами как Витязь и Лаверов нужно быть Джобсом и Возняком ))

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

Це щось дуже нове для Кожаєва.
Улюблене Кожаєва ж запитання — а гроші тут де?)

Если человек публично занят в проекте OS, то это может принести ощутимые выгоды фин. плана
начиная от упрощения поиска работы — мы видели ваш публичный код, идете к нам до повышенной ставки.

Це щось дуже нове для Кожаєва.
Улюблене Кожаєва ж запитання — а гроші тут де?)

Нічого нового, все старе, при тому старше самого вована:
— За «ентузіазм» працюють лохи
— Вова не лох (йому теж десь 42)
— Роботу робити треба
Тому потрібні ентузіасти.
Це називається розподілення праці, глобалізація:
Хтось працює, а хтось отримує бабло.

Я где-то сказал, что сам получу деньги за это?

А разве ты сказал, что откажешься от них, если тебе их предложат?

Богдан просто неровно ко мне дышит

Какую проблему ты пытаешься решить? О ней кто-то знает? В чем смысл?

Написать код быстрее и проще, чем рисовать схемы мышкой на экране.

Владимир описал цель:

такая программа может быть написана любой домохозяйкой.

Н+1 инструмент для визуального программирования в руки не разработчиков
Ведь сейчас ИТ платформами пользуются многие ...

аналогия:
Подготовить с помощью terraform описание окружения для облака куда проще.
Но многие пользуются GUI для работы с сервисами облака.
И так далее.

такая программа может быть написана любой домохозяйкой

BPMN. Будь-який манагер зможе описати флоу, але по факту наймаємо 20-50 джавістів на аутсорсі.
SQL. Будь-який манагер зможе робити запити до даних та аналітику, от тільки всеодно наймають спеціально навчених людей.

аналогия:
Подготовить с помощью terraform описание окружения для облака куда проще.
Но многие пользуются GUI для работы с сервисами облака.

Аналогія не вірна, бо порушені причинно-наслідкові зв’язки:
Тераформ вирішував проблему автоматизації налаштування сервісів, які раніше конфігурувались лише руками через графічний інтерфейс.
Те що ви описали (про домогосподарок) — це протилежна проблема. І для простих випадків вона вже вирішена давно (є 100500 візуальних редакторів), а для складних вона ніяк не вирішується значно кваліфікованішими людьми вован, який не зміг кандидатську захистити (Чи вже захистив?).

Сорян, я не совсем понял зачем домохозяйкам тераформ? :-)
Это кстати намек на то что условным «домохозяйкам» даже блок схемы с логикой это п**ц как сложно и не потому что они «тупые», а потому что они нихиба не знаю о программировании в целом, а главное — не используют блок схемы.
Так что вся эта система кажется простой только для программистов, обычные домохозяйки не разбирают абстрактную систему и ее поведение на кейсы и не пишут по кейсам логику и тем более не разделяют логику, данные и интерфейс...

Даже для меня блок-схемы, это сложнее чем код написать)
Особенно если эти блок-схемы должны корректно выполняться, и отдебажить как это всё)

Хоть и не получаю 5к но вы сильно переоцениваете себя этим «даже для меня» :)
Это абсолютно разный майндсет. Также как говорить например, что там эти дизайнеры сидят прототипы в фигме переставляют. А попробуйте запилить рабочий дизайн с достойным UX
Каждый хорош в своем. Знаю не одного и наверное не десяток ребят кто скажут по-другому и приносят реальную ценность бизнесу и поболе чем на 5к ))

понял зачем домохозяйкам тераформ?

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

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

Сорян, я не совсем понял зачем домохозяйкам тераформ? :-)
Это кстати намек на то что условным «домохозяйкам» даже блок схемы с логикой это п**ц как сложно и не потому что они «тупые», а потому что они нихиба не знаю о программировании в целом, а главное — не используют блок схемы.
Так что вся эта система кажется простой только для программистов, обычные домохозяйки не разбирают абстрактную систему и ее поведение на кейсы и не пишут по кейсам логику и тем более не разделяют логику, данные и интерфейс...

Люто, бешено плюсую. Обычно для 99% домохозяек экселя/гугл-таблиц более чем достаточно. Ну или один из 100500 готовых сервисов по планированию бюджета/подсчету калорий/you name it, если даже эксель сложен. Картина же целеустремленной домохозяйки рисующей блок-схемы конечно возможна в принципе, но совсем сильно уж выбивается из картины мира :)

Подготовить с помощью terraform описание окружения для облака куда проще.

Чушь какаято. Тераформ не проще чем ручками, он сложнее. Но он автоматизирует и абстрагируеццо от конкретного провайдера.

Terraform абстрагируется от провайдера? Серьезно? Ну попробуйте поднять такое-же окружение как в AWS в гугле или ажуре, без переписывания кода ;)

Автоматизирует — да. Поэтому если объектов много — то быстрее, чем ручками, и надежнее — не забудешь ничего. Позволяет масштабировать решение — цикл все-же проще будет, чем руками поднять сотню виртуалок...

Написать код быстрее и проще, чем рисовать схемы мышкой на экране.

Не скажи. Для написания кода нужен квалифицированный и высокооплачиваемый кодер.

А сбацать алгоритмик, может и всякий некодящий аналитик — которые всё одно есть на проекте. Если алгоритмик закодит программа — кодеры не нужны.

Написать код быстрее и проще, чем рисовать схемы мышкой на экране.

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

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

Так оно даже с простыми начинает проблемы создавать. Кто хоть раз пробовал через zapier настроить флоу, а потом его немного поменять или добавить ветвление меня пойемет. Такая же борода имеет место быть и во всяких визардах сейлсфорса. Оно либо совсем простое либо надо писать код. Промежуточные варианты по моим ощущениям скорее всего поднимут порог входа, но при этом для вещей посложнее все еще будут не достаточно гибкими.

нет) в ентерпрайзе не быстрее)
с точки зрения разраба может и то в узком скоупе кейсов
с точки зрения взаимодействия бизнес — ИТ не забываем про полный цикл разработки от кода до деливеренс еще куча этапов ))

тема проверенная не одним и не десятком проектов в банковском секторе. Скорость изменений по сравнению с монолитом на джава /пыхе и даже микросервисами просто космическая ))

разрабы бэка пишут ресты, фронты пишут фронт — вся логика выносится в корезоид и начинается магия ;)

Подписаться на комментарии