Здравствуйте, Shtole, Вы писали:

S>Потрясающие mad skillz. Только вот какое отношение это имеет к no-code/low-code?

Потому что MS Word ты можешь потрогать ручками и представить, как примерно сейчас разрабатывают алгоритмы обработки сигналов или как алгоритмически порождают графические (в т.ч. строительные) объекты нетривиальной конструкции.

А пробовал шейдеры визуально проектировать?
Оно примерно так же (можно в блендере попробовать).
Т.е., вполне себе алгоритм, составленный из неких базовых "кубиков".

"Настоящие программисты" в этом деле разрабатывают сами кубики и способы управления ими из САПР.


S>Давайте я приведу пример того, чем занимаюсь я.
S>Представьте себе таблицу. Но не таблицу «Тебе, дебилушка!», как в Excel. Во-первых, её колонки типизированы, а во-вторых имеют имена. О да, это требует указать типы (число, строка, дата, флаг, ссылка) и немыслимо напрячься, вбивая имена колонок.

Да понятно, но в БД тоже имена, типы...
А GUI утилиты-менеджеры БД позволяют конструировать таблицы визивинг, т.е. знать SQL не обязательно.
Многие такие менеджеры еще позволяют графически конструировать запросы.


S>Зато можно в свойствах таблицы указать размеченный шаблон документа (с маркерами {Имя1}, {Имя2}) и при добавлении/изменении строки в таблице по этому шаблону будет сгенерирован документ, заполнен актуальными значениями и положен в саму же эту таблицу в виде ссылки в колонку с именем шаблона документа.

А современные конструкторы сайтов смотрел?

А в том же MS Access можно и таблицы, и формы, и отчёты, и соотв. запросы, и вложенные сколь-угодно master-child представления (в т.ч. в отчётах), и всё без единой строчки кода.
В крайнем случае можно записать "макрос" — код исполнения макроса сгенерируется автоматически, его можно присвоить какой-нить кнопке или пункту меню, в т.ч. контекстного, т.е. в тело макроса (это просто код на VBA) заглядывать не обязательно.

Или системы для моделирования электронных схем — накидываешь "алгоритм", задаёшь входные данные (например, кнопки в GUI этой же системы-симулятора, или нетривиальные входные сигналы), запускаешь, отлаживаешь. Отладил — можно паять. ))


S>Простой бухгалтер может из такого инструмента сделать «2B:Платёжные документы», с любыми печатными образцами, не написав ни одной строчки кода и не задумываясь ни об одном алгоритме. И P-схемы ему не нужны. И редактор форм. Причём, с моей стороны я вообще не знаю ни о геометрии документа для печати, ни о прикладном смысле строк и таблиц.

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

Этой идее даже в реальном воплощении уже скоро лет 30 (когда там MS Access вышел и 1С 6.x?)
А первые графические симуляторы электронных схем (в т.ч. аналоговых!) вышли еще в конце 80-х.

======================
В общем, моё ИМХО последние лет 20 неизменно — современные программисты слишком много заняты сугубо в прикладных вещах.
Такое ощущение, что это от неумения описывать прикладные вещи параметрически, пригодным для комбинирования извне способом, от недостаточности в индустрии накопленных таких повторно-используемых подходов-фреймворков.

Оно понятно почему так — такие вещи являются строгой ноу-хау конкретной коммерческой конторы.
Т.е., циркулирования знаний по этой области в индустрии нет.

Масла в огонь подлило еще то, что UML, по-сути, не взлетела, а привычные схемы алгоритмов до этого предали анафеме проповедники UML.
Т.е., эдакая самоанигиляция вышла. ))

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

Вот эти люди что могут в деле САПР?
Они могут только вредить узколобыми лозунгами из разряда "нормальному программисту текста достаточно".

В итоге, сегодняшние системы САПР в своих возможностях не сильно убежали от аналогичных 20-тилетней давности, увы.

Кое-какой приличный экстенсивный рост есть (в тех же 3D САПР), но они топтались на месте пару десятилетий, пока не догадались сделать, например, BIM в строительстве — совместить структуру объекта с базой знаний о нём. Но там пока что даже форматы данных и их семантика находятся в стадии устаканивания. Причём, обычным для IT способом — форматы продуктов-победителей стараются поддерживать для импорта-экспорта "остальные", вот тебе создаётся стандарт де-факто.

Например, P-CAD когда-то ввёл несколько форматов, которые за пару лет буквально стали де-факто стандартом для интеропеработности данных м/у различными САПР проектирования электроники.

Одно плохо — сегодня этот фокус повторить не удастся, т.к. иннерционность у индустрии не как в начале-середине 90-х.
Т.е., когда-то быстрые эти процессы сегодня растягиваются на много-много лет.

Здравствуйте, Shtole, Вы писали:

S>Потрясающие mad skillz. Только вот какое отношение это имеет к no-code/low-code?

Потому что MS Word ты можешь потрогать ручками и представить, как примерно сейчас разрабатывают алгоритмы обработки сигналов или как алгоритмически порождают графические (в т.ч. строительные) объекты нетривиальной конструкции.

А пробовал шейдеры визуально проектировать?
Оно примерно так же (можно в блендере попробовать).
Т.е., вполне себе алгоритм, составленный из неких базовых "кубиков".

"Настоящие программисты" в этом деле разрабатывают сами кубики и способы управления ими из САПР.


S>Давайте я приведу пример того, чем занимаюсь я.
S>Представьте себе таблицу. Но не таблицу «Тебе, дебилушка!», как в Excel. Во-первых, её колонки типизированы, а во-вторых имеют имена. О да, это требует указать типы (число, строка, дата, флаг, ссылка) и немыслимо напрячься, вбивая имена колонок.

Да понятно, но в БД тоже имена, типы...
А GUI утилиты-менеджеры БД позволяют конструировать таблицы визивинг, т.е. знать SQL не обязательно.
Многие такие менеджеры еще позволяют графически конструировать запросы.


S>Зато можно в свойствах таблицы указать размеченный шаблон документа (с маркерами {Имя1}, {Имя2}) и при добавлении/изменении строки в таблице по этому шаблону будет сгенерирован документ, заполнен актуальными значениями и положен в саму же эту таблицу в виде ссылки в колонку с именем шаблона документа.

А современные конструкторы сайтов смотрел?

А в том же MS Access можно и таблицы, и формы, и отчёты, и соотв. запросы, и вложенные сколь-угодно master-child представления (в т.ч. в отчётах), и всё без единой строчки кода.
В крайнем случае можно записать "макрос" — код исполнения макроса сгенерируется автоматически, его можно присвоить какой-нить кнопке или пункту меню, в т.ч. контекстного, т.е. в тело макроса (это просто код на VBA) заглядывать не обязательно.

Или системы для моделирования электронных схем — накидываешь "алгоритм", задаёшь входные данные (например, кнопки в GUI этой же системы-симулятора, или нетривиальные входные сигналы), запускаешь, отлаживаешь. Отладил — можно паять. ))


S>Простой бухгалтер может из такого инструмента сделать «2B:Платёжные документы», с любыми печатными образцами, не написав ни одной строчки кода и не задумываясь ни об одном алгоритме. И P-схемы ему не нужны. И редактор форм. Причём, с моей стороны я вообще не знаю ни о геометрии документа для печати, ни о прикладном смысле строк и таблиц.

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

Этой идее даже в реальном воплощении уже скоро лет 30 (когда там MS Access вышел и 1С 6.x?)
А первые графические симуляторы электронных схем (в т.ч. аналоговых!) вышли еще в конце 80-х.

======================
В общем, моё ИМХО последние лет 20 неизменно — современные программисты слишком много заняты сугубо в прикладных вещах.
Такое ощущение, что это от неумения описывать прикладные вещи параметрически, пригодным для комбинирования извне способом, от недостаточности в индустрии накопленных таких повторно-используемых подходов-фреймворков.

Оно понятно почему так — такие вещи являются строгой ноу-хау конкретной коммерческой конторы.
Т.е., циркулирования знаний по этой области в индустрии нет.

Масла в огонь подлило еще то, что UML, по-сути, не взлетела, а привычные схемы алгоритмов до этого предали анафеме проповедники UML.
Т.е., эдакая самоанигиляция вышла. ))

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

Вот эти люди что могут в деле САПР?
Они могут только вредить узколобыми лозунгами из разряда "нормальному программисту текста достаточно".

В итоге, сегодняшние системы САПР в своих возможностях не сильно убежали от аналогичных 20-тилетней давности, увы.

Кое-какой приличный экстенсивный рост есть (в тех же 3D САПР), но они топтались на месте пару десятилетий, пока не догадались сделать, например, BIM в строительстве — совместить структуру объекта с базой знаний о нём. Но там пока что даже форматы данных и их семантика находятся в стадии устаканивания. Причём, обычным для IT способом — форматы продуктов-победителей стараются поддерживать для импорта-экспорта "остальные", вот тебе создаётся стандарт де-факто.

Например, P-CAD когда-то ввёл несколько форматов, которые за пару лет буквально стали де-факто стандартом для интеропеработности данных м/у различными САПР проектирования электроники.

Одно плохо — сегодня этот фокус повторить не удастся, т.к. иннерционность у индустрии не как в начале-середине 90-х.
Т.е., когда-то быстрые эти процессы сегодня растягиваются на много-много лет.