Блог компании Edison
Программирование
Учебный процесс в IT
Комментарии 388
+5
Есть такой инструмент как node-red который совмещает лучшее обоих миров — позволяет писать маленькие куски программы, а сложное межмодульное соединение делать визуально.
+18

Как раз таки "сложное" лучше писать в коде, который обмазывается тестами и кладется в CVS.
Особенно межмодульное соединение.

0
То что сторонние инструменты (cvs) работают с текстами лучше, чем с визуальщиной это проблемы интеграции сторонних инструментов и ide. просто, имхо, пока никто не ставил такую задачу, поэтому и cvs для визуальщины это cvs на основе копирования неархивных файлов в архив.
И обмазывание тестами межмодульное взаимодействие тоже из той же серии. Сделать и поддерживать DI для визуальщины даже проще, чем в коде. Пример — Unity Shader Graph который в режиме online использует облегченные ноды, а на этапе «рендринга» подсовывает нормальные классы.
0
Еще есть NoFlo и еще куча всего. Это кажись было всегда и зовется Workflow Engine/BPMS в зависимости от области применения и навороченности. Но я бы не назвал это визуальным программированием. Эти инструменты избавляют нас от рутинного написания пайплайнов (которые в коде бы выглядили громоздко и немного уродливо) + добавляют всякие плюшки по мониторингу и т.д
0
Никогда 8-ки не делали? Это когда есть два нода расположенных один над другим, выходы которых заведены на входы друг друга. Выглядит забавно, но не думаю, что добавляет понимания.
Вот пример: flows.nodered.org/flow/720044a3c587a310813a9326ed3cb08a
+6
Любые способы хороши, если они формируют у человека алгоритмическое мышление, способность постановки задачи и способность разбивать сложные задачи на совокупность простых. А как потом из умных мыслей составить программу человек уже сам разберётся.
+3
Однако это не повод учить плохому.

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

Большинство же средств визуального программирования ни на чем не основаны. Как тут резонно пишут, есть области, где визуальные средства хорошо прижились. Но при этом очевидно есть и такие, где эти средства делают только хуже. То о чем автор пишет, к сожалению очень и очень типично, даже если он местами излишне обобщает.
0
Я смотрю на это иначе. Представим себе человека не знакомого с программированием, ему можно с помощью визуального программирования создать навык составления алгоритмов и быстро научить решать сложные задачи или долго топтаться на месте объясняя синтаксис, где и сколько надо ставить кавычек, скобок, пробелов, заглавных или прописных и долго ещё ждать момента когда человек станет способен ставить и решать задачи, ибо ещё синтаксис не изучил.
Среда визуального программирования накладывает много ограничений и любому кто хочет решать сложные задачи придётся из неё выйти и изучить ЯП, но до этого уровня надо сначала дорасти
+1

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

-2
Предполагаю, что этот человек сейчас воюет в Сирии на стороне запрещенной организации?
0

Или проходит срочную службу где-нибудь в артиллерийском дивизионе.

+2
Любую сложную вещь можно объяснить достаточно простыми словами, опуская детали, что б сначала человек осознал общую картину, а потом усложнять модель снижаясь на уровень деталей. Этот принцип вполне подходит к программированию, если начать с визуального, то обучение ускорится
+3

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

+1
Или баллистический калькулятор, в который нужно вбить какие-то данные. Только этот процесс не относится к программированию никак.
+2
>когда человек станет способен ставить и решать задачи, ибо ещё синтаксис не изучил.
Вы так говорите, как будто ставить и решать задачи — это проще, чем синтаксис, и синтаксис только этому и мешает :)

Ну да, я согласен (наверное частично), что при обучении детали синтаксиса могут мешать. Для первого-второго языка. Но вообще говоря, этому тоже надо научиться — потому что в профессиональном применении этих языков за много лет все равно будет десятки, если не сотни, и научиться приспосабливаться к синтаксису, понимать его — тоже полезно.
0
При первоначальном обучении (особенно детей) важно обеспечивать короткий цикл «действие-результат». «Классическое обучение» (особенно «директивное», типа «Тебе сказали учить — значит, учи и не расссуждай») с этим справляется гораздо хуже.
Визуальные инструменты типа Скратча — по максимуму отвязаны от деталей. Для детей (первоначального обучения алгоритмам) это замечательно. Дальше — можно уже учить языку (где-то видел толи плагин, толт нечто подобное для Скретча — показывает «нацарапанное» в виде Java). Это как раз этап роста программ, и то, что в визуальном виде занимает огромный объем — в текстовом получается весьма компактно. и этим переход от визуального к текстовому представлению (со всеми минусами типа бОльшего объема работы с клавиатурой, изучения синтаксиса) хорошо объясняется. Ну а обучение профессиональному применению — это уже отдельная тема.
+1
А ничего, что стреч — текстовый. Просто как во времена синклер бейсика управляющие конструкции зашиты, чтобы нельзя было получить ошибку компиляции из-за опечатки.
+1
И где он текстовый? если детишки, которые гоняли этого персонажа по полю, не использовали язык? И они не знали, что там за словеня такие импортные — while да until? цифры они использовали, это было.
+3
Я до института не знал, что за словеня такие импортные — while да until, но это не мешало мне использовать их в качестве команд QBASIC.
Точно так же дети стремительно осваивают англоязычные менюшки в играх — потыркался и запомнил.
0
моя на русском программировала. А как вы им эти вайлы объясняли? Переводили наверное просто.
А текстовый он прямо на скриншоте:
when flag clicked
say Hello world
stop this script
+1
Ну, я преподавал детишкам старшего школьного возраста, причем в те времена, когда таких инструментов как скрэтч не было. а то, что видел — детишкам примерно 4 класса объясняла учительница информатики.
наксолько я помню, объяснение были типа «вот когда нажмешь на флажок такого же цвета», «если тут числа равны, то выполняются шаги в этой части, а если не равны, то в этой», «сначала выполняются шаги, потом проверяется условие», «а вот сюда мы пишем то, что нам скажет кот в этом случае» (только мне кажется, что там был пес а не кот)
+1
Еще раз, для ясности — я в целом согласен, что для начального обучения визуальные средства могут быть полезны. Просто они, как правило (то есть, я не видел исключений) описывают именно алгоритм, и совершенно забывают при этом про данные. А данные, их типы, и все что с этим связано — это очень важная часть. Настолько же важная, как алгоритмы.

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

Ну и второе — это обмен знаниями. Если мы про текстовое представление — то я могу вам прямо вот тут написать фрагмент кода:

a= 2*2

И вы его сможете применить (если не выполнить, то скопипастить). Расскажите, как это выглядит в визуальной среде? Многие ли из таких инструментов вообще хоть чего-то стоят без своей IDE?
0
a= 2*2 без текстового редактора (чем не IDE?) тоже немного стОит ;)
Скретч, действительно, на самом деле ничего не визуальный. Древний basic, положенный на пазл.
+2

Такой подход рекомендуют для детей 8 лет. Это вышеупомянутый Scratch или IDE для лего.
Обучение взрослых людей имеет такой контекст, что им нужно сразу давать промышленный язык программирования. Если бы им было целесообразно давать сначала визуальное программирование, то в интернете не было бы такого количества курсов по конкретным языкам.
Для алгоритмических задач весь синтаксис промышленных языков и не нужен. Объявление переменных, условия, циклы, массивы — не такой уж огромный объем. А вот исключения, абстрактные классы, интерфейсы и т.п. в концепцию визуального программирования хоть и вписываются (UML), но проще не становится.

+5
Представим себе человека не знакомого с программированием, ему можно с помощью визуального программирования создать навык составления алгоритмов и быстро научить решать сложные задачи или долго топтаться на месте объясняя синтаксис,

Зачем представлять? Мы все были когда-то людьми, не знакомыми с программированием. Тяжко было начинать? Не очень, согласитесь?
«Долго топтаться на месте» — это минут 15, чтобы объяснить, как устроен хеллоуворлд. После этого можно писать простые алгоритмы, этого достаточно.
-2
Мы все были когда-то людьми, не знакомыми с программированием. Тяжко было начинать? Не очень, согласитесь?

Верите — не помню! Девушка просит «научи», а я не знаю как, потому что кто бы мне рассказал, как я сам научился!
+2
Зачем представлять? Мы все были когда-то людьми, не знакомыми с программированием. Тяжко было начинать? Не очень, согласитесь?

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

«Долго топтаться на месте» — это минут 15, чтобы объяснить, как устроен хеллоуворлд. После этого можно писать простые алгоритмы, этого достаточно.

Для того, чтобы «писать простые алгоритмы» нужно, чтобы человек понимал, что такое алгоритмы, как они строятся и как разбить элементарную операцию на алгоритм. А это не 15 минут времени. Далеко не 15 минут. Это такой же навык, который со временем нарабатывается.
Дальше — алгоритм, который есть в голове нужно изложить в программном коде. Это тоже не «15 минут ознакомления с синтаксисом и погнали». Этот самый синтаксис будет долго въедаться в память и человек будет учиться излагать свой алгоритм в программном языке.

Не помните, как вы или ваши одногруппники не знали, как выразить чётность числа?
Банальное if (num % 2 == 0)… не писалось, потому что не было понимания, что и как работает. Алгоритм в голове был(делится на 2 — чётное). По отдельности человек примерно понимал, как синтаксис выглядит. Но вот сесть и написать — ступор.

Не стоит недооценивать сложность входа в программирование. Это не так легко, как вам кажется.
+1
Для того, чтобы «писать простые алгоритмы» нужно, чтобы человек понимал, что такое алгоритмы, как они строятся и как разбить элементарную операцию на алгоритм.

Нужно. Но разве есть какая принципиальная разница, на чём учиться плести алгоритмы, на цветных квадратиках, или на словах и математических знаках?
0
Разница лишь в сложности входа и количеству одновременно усваиваемых знаний.
В случае визуалки — ты просто строишь алгоритмы из простых блоков, которые ты просто читаешь и видишь перед глазами. Если это какая-то игровая визуалка, то у тебя ещё и ограничены варианты блоков. Основной акцент идёт на алгоритм.
В случае ЯП — у тебя нет готовых простых блоков перед глазами, есть куча непонятных конструкций, которые нужно запомнить(!), нужно проассоциировать с своей логической моделью(чтобы, если грубо, знать, что условие когда\если — это if) и не забыть применить, когда требуется, не перепутать. Акцент с алгоритма смещается на борьбу с собой и языком и процесс идёт немного сложнее.

И в целом, я не защищал визуальный подход. Он при обучении может быть хорошим инструментом, которым можно пользоваться, но это всё зависит от человека, педагога и пр.
Меня зацепило ваше непонимание сложности обучения программированию.
0
Есть одна принципиальная, я детей алгоритмам учил, когда они ещё читать не умели. В scratch и других подобных вещах. Лень искать видео, как у меня трехлетний ребёнок по линолеуму по квадратикам ходит и яблоки собирает слушая команды по алгоритму написанному самим же в какой-то программе с визуальным программированием. В три года он легко въехал в цикл.

У меня есть сотрудники, как дети, очень далёкие от программирования, алгоритм бизнес-процесса в текстовом виде не могут написать, а вот нарисовать его в draw.io у них получается. Если бы мне от них требовался алгоритм более сложный, я бы наверное им дал scratch и заставил там его описать.

Всему своё время и место.
0

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

+1
Именно так. Слова мы тоже учимся в детском саду собирать из кубиков с картинками. И блок-схемы не зря народ рисовал раньше — а сейчас перестал.

Графические схемы очень помогают в понимании, пока всякие ключевые слова и паттерны проектирования не выучены.

Но рассказывать про то, что на них можно хорошо и удобно сделать что-то сложное… ну не стоит.
0
in.mathworks.com/matlabcentral/mlc-downloads/downloads/submissions/35781/versions/4/screenshot.JPG

Попробуйте на досуге хорошо и удобно закодировать это. (Именно закодировать — потому, что кодогенератор реально даст оптимальный код, для конкретной целевой системы с учетом оптимального способа хранения весов и наличия-отсутствия FPU, чему не будет отвечать ни одна возможная реализация, кроме опять-же, вдруг написанных для целевой системы). Ну это конечно, если вы понимаете насколько прост серенький кубик… Хотя чего там понимать — простейшая моделька. 1 лист всего.

Визуализацию не забудьте закодировать — которая «MSE View», в 3 щелчка мышки там появилась — ибо средство языка.

И конечно ваш код должен быть столь же понятен, как эта картинка для
программиста на скажем — фортране…
+1
Тяжко было начинать? Не очень, согласитесь?

Ошибка выжившего. То что не было тяжело мне или вам вовсе не означает, что не будет тяжело кому-то другому. Это не в защиту визуальных языков, если что.
0
Люди есть очень разные. С разным стилем мышления. С разной мотивацией. Одним начинать было очень легко. Другим очень сложно. Хелловорлды тоже бывали разными, на разных языках. Преподаватели, которые объясняли основы (хотя бы как набрать текст этого хелловорлда, и как запустить набранное на исполнение) — тоже разные, с разным подходом (на ФЮПе нас начинали учить программированию с исчисления предикатов и правил вывода. сбежало очень много народа. Впрочем, через пару лекций лектору объяснили, что перед ним не студенты второго-третьего курса, а школьники-старшеклассники. Перешли к решению квадратного уранения. На фортране, естественно). Я учил — уже подход был несколько другим. Не столько «математическим», сколько «информационным» (правда, тут между контингентами была большая разница)
0
О, я бы посмотрел как вы после простого hello world сделали какой-нибудь простой поиск пути в графе дийкстрой на Python, JS, Rust и Prolog. #15minchallenge
0
Не сказать что они и сильно сложные. Хотя, я б и варианты задач послушал.
+1
Каждой задаче нужен свой инструмент, если можно забить гвоздь микроскопом, это не значит, молоток следует выбросить, более того, молотком даже удобнее и легче будет. После хеллоуворлда придётся ещё интенсивно много часов объяснять всё остальное и если Вы учите программированию, а не особенностям программирования на конкретном языке, человеку придётся запомнить много не нужного, а так как время и способность мозга усвоить какой-то объём информации в единицу времени ограничены, можно не достичь цели в рамках заданного количества занятий.
0
Ну совсем незнакомых всё меньще — какому-нибудь Турбо Паскалю учат почти во всех школах страны. И тех кто к обучению способен, учать более менее неплохо с учётом квалификации самих учителей.
+9
Например, в 3Д/2Д редакторах (да и многих других видах приложений), ИМХО, очень неплохо реализована та или иная разновидность визуального программирования. Это разнообразные стеки модификаторов, всякие node editor'ы, управление анимациями кривыми и ключевыми кадрами и т.п. Да, они решают довольно специфические задачи, но я не представляю, как можно обойтись без такого визуального программирования, даже если использовать доступные невизуальные скрипты и плагины.
Тем не менее, хочу отметить, что по моим наблюдениям, те же редакторы на базе узлов и связей заметно сложнее для освоения пользователями, чем просто стеки модификаторов, ну а про текстовые скрипты и речи нет. Это логично, что, чем универсальнее и гибче инструмент, тем сложнее он в освоении.
+1
Мне кажется, что программировать можно только на чем-то Тьюринг-полном. Скажу честно, node editorы видел только во обучащих видео на ютубе, но у меня что-то не сложилось впечатления, что на них можно написать программу. Задать сложный граф зависимостей, с обработкой данных — да. А вот написать программу — нет.
+2
Не хотелось бы отвлекаться на спор об определениях, в поисках границы между программами, недопрограммами, совсем не программами и т.п. Например, MS Acсess с ранних версий позволял широкому кругу лиц не имеющих представления о «текстовом» программировании очень быстро создавать вполне себе рабочие приложения. А Houdini от SideFX со своей нодовой системой, хоть и не прост в освоении, но настолько гибок и универсален в своей области процедурного моделирования, что я даже не знаю, что в нем нельзя запрограммировать (в рамках предназначения пакета, разумеется).
Да, большинство нодовых систем в редакторах графики скорее ближе к функциональному программированию, но разве это плохо? Думаю ощущения от конструирования функции готовыми нодами, а не кодом весьма схожи и приятны программисту, по крайней мере это не зазорнее, чем «вешать на кнопки» короткий текстовый код, вызывающий мощные методы готовых объектов, фреймворков, библиотек и т.п. Ведь именно этим занимается приличная доля вполне себе достойных звания программиста людей? )
0
Мне кажется, что программировать можно только на чем-то Тьюринг-полном.

Конечные алгоритмы и регулярные выражения не являются тьюринг полными. однако специализированные языки для конечных автоматов и, особенно, регулярные выражения используются в IT постоянно.
+4
Для меня программирование в первую очередь понимание
Способ реализации – кто как хочет.
Удобна нодовая структура – окей, нравится много печатать – вперед, поизвращаться на пустом месте – есть Brainfuck и иже с ним )
На самом деле плевать.
Программист – человек понимающий суть процесса, в первую очередь!
+6
Как непрограмиссту, Blockly очень помог с домашней автоматизацией, без необходимости изучать какой либо программный код.
Всеми лапами за блочное программирование, для простых вещей (сценариев, алгоритмов)
+4
Так и не понял, почему это настолько плохая идея, что достойна отдельной статьи. Даже сам автор говорит о том, что существует некоторые области, где визуальные средства используются весьма интенсивно. Например, можно вспомнить промышленную автоматизацию, где визуальные инструменты достаточно востребованы — LD, FBD, SFC, которые спокойно (как правило) траслируются в IL/ST, что вполне решает проблему контроля версий, упомянутую автором статьи. Визуальные средства программировани имеют богатую историю, они проверены временем и они дают на выходе стабильно функционирующие ТП, уменьшая количество ошибок, которые могут быть допущены в процессе разработки, фактически сводя их только к логическим ошибкам. Но видимо эта сфера очень далека от автора, раз в пример от приводит Scratch.
+3
>Так и не понял, почему это настолько плохая идея, что достойна отдельной статьи.
Потому что плохих примеров применения в других областях к сожалению навалом. Большую часть того, о чем автор пишет, я лично наблюдал многократно.

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

>Но видимо эта сфера очень далека от автора, раз в пример от приводит Scratch.
Ну я могу привести в пример BPMN и/или Информатику. На которых предлагается программировать бизнес-процессы, или ETL.

И пытаясь применять которые вы очень быстро натыкаетесь на ограниченность выразительных средств графического языка. Эта проблема решается как правило просто — добавляется второй (третий, пятый) язык, более обычный — Java, Javascript или что-то еще. На выходе получаем гибрид, который выглядит как результат визуального программирования, но процентов на 90 состоит из кода на более привычном языке. Профита от визуальных средств при этом что-то около нуля, а мешает он знатно.
+5
Кстати, было бы очень интересно понять, почему в промышленной автоматизации визуальные средства так востребованы, чем именно эта область отличается от множества других.

1. Тематика. В автоматике рулит релейка. Все IL/STL, LD и прочие являются их прямым воплощением в контроллере.
2. Относительно низкий порог вхождения. Человек, знающий, как сделать запуск двигателя с самоподхватом на 1 контакторе и 2-х кнопках, сможет эту же схему воплотить и на контроллере (для примера) после изучения самых основ.
3. Лёгкость понимания. Почти везде в автоматике идут дискретные сигналы. И их проще отслеживать визуально в отладке — «ага, вот тут у нас сигнал дальше не идёт, надо посмотреть причину… а вот и она — один из входов в 0!». С аналоговыми величинами абсолютно аналогично — на входе блока X и Y, на выходе имеем Z как результат какой-либо мат. операции. Поищите в интернете ролики об отладке FBD/LAD ;)
+3
Зависит, на самом деле от конкретной задачи и конкретной команды.
Я, например, замечал, что LD и FBD обычно любят и используют родовые КИПовцы и электрики, а молодое поколение, особенно кто имеет опыт программирования под ПК, предпочитают ST, который как раз текстовый и похож на Паскаль.
+1
ST даёт послледовательный алгоритм.
FBD LAD — это условно параллельный порядок выполнения.
Пишут на ST скорее всего какие-нибудь функции обработки сигналов (ПИД регулятор тот же самый, разбор пакетов при организации протоколов связи). Но потом, на верхнем уровне, это всё упаковывается в FBD LAD.
Молодёжь в институтах учит С++ и Джаву по большей части. Может быть по началу (от неопытности или с непривычки) им легче в алгоритмической форме паскаля писать. Я думаю, потом перестроятся.
0
Ну я могу привести в пример BPMN и/или Информатику. На которых предлагается программировать бизнес-процессы, или ETL.

ETL на BPMN? Я знаком с обоими, но вот такая комбинация выглядит странно. Может быть вы имели в виду ETL на DFD?


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

0
Там было написано «или». ETL это информатика (с ее кубиками и стрелочками), а BPMN тут сам по себе.

>Функционал по воспроизведению диаграмм BPMN в коде и их запуску — фичи конкретных инструментов, а не нотации.
Разумеется. Но вполне конкретные вендоры преподносят BPMN как язык для разработки. Забывая при этом упомянуть, что без второго языка эта разработка реально невозможна.

-3
Как уже писали выше, автор видимо очень далёк от реального понимания термина «программирование». Он почему то считает программированием только написание игрушек и сайтов. Но ведь есть огромная сфера промышленного программирования, где основными языками как рази являются визуальные языки, которые проверенны и отработаны уже в течении десятков лет. Причём там решены все вопросы и с контролем версий, и с созданием функциональных блоков конечным пользователем, да и вообще практически все «проблеммы» описанные автором. Я бы очень порекомендовал ему изучить матчасть, и не позорится написанием подобного бреда.
+8
Не путайте, пожалуйста, «промышленную разработку ПО» и «разработку ПО для промышленных систем и автоматики», это все-таки совершенно не тождественные понятия. Вы, как я понял, имеете в виду второе, и да, там действительно в ходе МЭКовские языки, часть из которых являются графическими.
Вот только даже в этом случае с системами контроля версий, например, до недавнего времени вообще все было очень плохо, в средах разработки под PLC, как и SCADA, нормальная интеграция с CVS начала появляться относительно недавно в приемлемом виде, да и сами бинарные и закрытые форматы файлов к их использованию мало располагали.
+3
В Honeywell есть встроенная CVS, если в лицензии была приобретена эта опция ;)
Работает по принципу бэкапа — у каждого контура можно создать версию с описанием, к которой потом можно откатиться.
+5

В TIA Portal новом, как я слышал, тоже нечто подобное есть.
Только вот нормальная CVS — это не только откат к старым версиям, это ещё и наглядное отображение различий между ними и удобное разрешение конфликтов при командной работе. И как раз с этим у граф. языков проблемы: классические системы заточены на текстовые языки, а графический дифф требует соответствующего подхода и поддержки от разработчика среды. Как у Honeywell с этим?

+6

А учитывая, что под промышленной разработкой обычно считается именно работа по какой-нибудь методологии управления проектами, активное использование подходов CI для регулярных билдов, автоматического развертывания и автоматического тестирования, написание кода в строгом соответствии с установленными конвенциям кодирования, разработка читаемого кода и расширяемой архитектуры, основывающихся на общепринятых паттернах проектирования… то, зная, как по факту обстоят дела у многих АСУТПшных разработчиков, можно сказать, что разработка ПО для промышленности часто на самом деле очень далека от промышленного программирования :)

+2
Все эти визуальные языки созданы лишь для того, чтобы ограничить конкурентов. Если бы все программировалось даже на банальном Бейсике, как бы Сименс тот же зарабатывал на сертифицировании специалистов, без которого в той же Германии тебя на пушечный выстрел не подпустят к решению задач на абстрактном контрактном предприятии?
+4
Зачастую в школе основная проблема — скорость набора учениками текста программы. Любые помощники набора или блочные построители нивелируют данный аспект.
+5

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

+1
Всё так, хороший пример: Dynamo BIM — написать там что то более менее сложное, полный трешь
+4

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


Например, простейшая модель освещения:


color = diffuseColor * (ambient + light * min(0, -dot(lightDir, normal)));

Эта строчка легко читается, быстро печатается и занимает мало места: на экране без проблем поместится ещё 50-100 таких же. Если я захочу добавить зеркальное отражение — допишу ещё одну строчку.
А в нодах — выщеописанная функция уже содержит 5 операций и использует 5 переменных и одну константу. Т.е., в граф придётся добавить ещё 6 новых вершин и потом соединить их друг с другом и с пятью внешними вершинами. Это уже громоздко выглядит, не говоря уж о чём-то реально сложном.

+4
Да. Это, что называется, «для гуманитариев».
Такой инструмент сильно снижает порог входа, но получается это за счёт ОЧЕНЬ сильного опускания потолка возможностей.
+7

Автор, похоже, не знаком не только с промышленной автоматизацией, как указали выше, но и не в курсе, что с помощью Model-Based Design — тоже одного из видов визуального программирования, создается софт, который управляет автомобилями, самолетами, садит ракеты SpaceX, обрабатывает информацию с сонаров и радаров и передает гигаваты электричества на тысячи километров. В общем эти товарищи, похоже, выбрали плохую идею.
Ну а те, кто клепает проекты на Labview, вообще дети, наверное.

+1
На Labview пишут не из-за широты возможностей, а из-за низкого порога вхождения и поддержки инструментов NI. Ну и по старой памяти, потому что тут так заведено, а менять руководство ничего не хочет. Как только задача выходит за рамки — все превращается в закат Солнца вручную. Говорю как человек, который писал на Labview и сейчас по необходимости часто пользуется CVI.
0
Это хороший инструмент для непрофессионалов (точнее, профессионалов в других областях)
+1
Читайте — низкий порог вхождения. Плюс возможность быстрой интеграции измерительных инструментов. Но снова же — как только проект вырастает, проще все стереть и переписать в нормальной невизуальной среде, чем пытаться что-то понять в этой бесконечной картинке.
0
Но снова же — как только проект вырастает, проще все стереть и переписать в нормальной невизуальной среде

Если бы это автоматически могло происходить…
0
Но снова же — как только проект вырастает, проще все стереть и переписать в нормальной невизуальной среде,

Для многих проектов он не вырастает никогда, а вот наоборот, когда через несколько лет надо бы что-то подправить — Labview дает очень хороший результат

+2
В SpaceX вроде бы как C/C++ используют, откуда информация про MBD?
0
На выходе из MBD все тот же родной C/C++ который встраивается в бОльший проект.
Намного проще посадить теоретиков с PhD в зарегулированную песочницу и встраивать результат их труда в системную обертку нежели пытаться найти людей с теми же скилами в прикладной области да плюс еще умеющих в C/C++.
+1
Я сильно извиняюсь — а что нынче есть визуальное программирование?
LabView?
C++Builder/Delphi?
Ничего другого не знаю.
+3
Я сильно извиняюсь — а что нынче есть визуальное программирование?

В отрасли embedded и микроконтроллеров это все, что позволяет получить исполняемый код из графических моделей.


Для Си кода у меня такой список:
MATLAB Embedded/Simulink Coder http://www.mathworks.nl/products/embedded-coder/
Gene-Auto http://geneauto.gforge.enseeiht.fr/
SCADE http://www.esterel-technologies.com/products/scade-suite/
dSPACE TargetLink http://www.dspace.com/en/inc/home/products/sw/pcgs/targetli.cfm
PLECS Coder http://www.plexim.com/products/plecs_coder
Synphony Model Compiler http://www.synopsys.com/Systems/BlockDesign/HLS/Pages/default.aspx
Evidence E4 Coder — http://www.e4coder.com/
National Instruments Labview — Z-brain — http://www.schmid-engineering.ch/de/151/ZBrain_System.htm
IMACS GmbH radCASE www.radcase.de
AdaCore QGen http://www.adacore.com/qgen


Для ПЛИСов — т.е. генерация VHDL/Verilog:
MATLAB HDL Coder http://www.mathworks.nl/products/hdl-coder
Xilinx System Generator for DSP http://www.xilinx.com/products/design-tools/vivado/integration/sysgen/index.htm
Altera DSP Builder http://www.altera.com/products/software/products/dsp/dsp-builder.html
Synphony Model Compiler http://www.synopsys.com/Tools/Implementation/FPGAImplementation/Pages/synphony-model-compiler.aspx
National Instruments LabView — only on LabView Hardware — http://www.ni.com/labview/fpga/
Altera Quartus II/prime (provides block diagram editor, Altera only) https://www.altera.com/products/design-software/fpga-design/quartus-prime/overview.html
Lattice Diamond(provides block diagram editor, Lattice only) http://www.latticesemi.com/en/Products/DesignSoftwareAndIP/FPGAandLDS/LatticeDiamond.aspx
Microsemi Libero SOC (provides block diagram editor, Microsemi only) http://www.microsemi.com/products/fpga-soc/design-resources/design-software/libero-soc
Xilinx Vivado IP integrator (provides block diagram editor, Xilinx only series 7 and up) http://www.xilinx.com/products/design-tools/vivado/integration.html
Mentor Graphics HDL Designer (provides block/state diagram editor) https://www.mentor.com/products/fpga/hdl_design/hdl_designer_series/
Aldec Active-HDL (provides block/state diagram editor) https://www.aldec.com/en/solutions/fpga_design/graphical_text_design_entry
HDL Works Ease (provides block/state diagram editor) https://www.hdlworks.com/

+2
Ну так визуально програмирование хорошо устроено в UE4 правда производительность немного хуже чем нативный код, а про всякие програмирования шейдеров это не заменимая вещь.
+6
Визуальные языки — почему это хорошая идея

Языки программирования, такие как С, С++ и прочие, могут быть написаны в блокноте, где фон одним цветом, текст другим, контрастным с первым. Все. Это текстовые языки.
Но дальше мы визуализируем. Визуализация происходит статически и динамически. Статичная визуализация на самых верхних уровнях затронута у автора статьи. Что же динамичная визуализация и статическая визуализация на нижних уровнях?
Рассмотрим статическую визуализацию на нижних уровнях. О, чудо — это банальные отступы строк! И заметим, что отступы практически не влияют на работоспособность кода! Да простят меня программисты на Python, у которых отступы могут повлиять на работу их скрипта. Зачем нужны блоки? Они «визуализируют» блоки, выделяя псевдографическими средствами. И этим пользуются уже очень давно и доступно даже в ч/б режиме. Статическая — сохраняется в исходном коде.
С появлением цветных мониторов появилась динамическая визуализация — подсветка слов разными цветами в зависимости от предназначения. Динамическая, т.к. в исходный текст не сохраняется и каждый раз высчитывается заново. Конечно, некоторые могут пойти на ухищрения, чтобы сохранить разметку в отдельный файл, но мощности современных компьютеров хватает высчитывать это динамически, поэтому большинство не заморачивается.
И наступают еще два вида визуализации, одна статическая — специальным образом оформленные комментарии вначале процедуры, и одна динамическая — гипертекстовая с переходом к логически связанной области кода (например, объявление процедуры) с вариантом «отобразить в виде всплывающей подсказки».
И если первые два варианта доступны издавна и нынче доступны даже в продвинутых блокнотах (geany, notepad++ и т.д.), то следующие две стали распространены позже и требуют поддержки на уровне IDE и наличия исходного кода, на который ссылаться (хотя бы заголовочных файлов и/или комментариев/справки).

Можно даже представить развитие языков в виде линии 1D->2D->3D
Текст без отступов и переносов — это чистая 1D (одна длинная строка)
Отступы и переносы — 1,25D (условное деление, дабы 2D отдать полностью визуализированным языкам первого уровня)
Цвет текста (подсветка синтаксиса) — 1,5D
Гипертекстовые переходы и подсказки — 1,75D
Сверх-юникодная поддержка и Drag&Drop — 1,9D
Графическая автозамена — 2D
Поддержка слоев — 2,5D
… и т.д. вплоть до 3D и 4D!

Вышло много текста, поэтому остальное описание про 1,9D-4D с подробностями под спойлером!
тут подробности
Я упомянул такую строчку «Сверх-юникодная поддержка и Drag&Drop — 1,9D». Что это? Это не просто поддержка Юникода, а поддержка каких-то графических элементов. Например, языку Pascal ставят в недостатки длину операторных скобок — begin/end против сишных скобочек. Это вы не видели имена ООП-объектов/интерфейсов у Java, JS, C#, С++ и других ЯП! А ведь вполне можно объект Smile заменить смайликом, объект Tree заменить изображением дерева, auto — автомобиля, и т.д. Даешь эмодзи в программировании! Причем не обязательно делать подобное на уровне ключевых слов (иногда даже вредно), а вот вместо подсветки текста отобразить картинку — вполне можно. У той же OpenGL переменные именуются с префиксами (принадлежность к библиотеке) и суффиксами (тип переменной). Проблема будет в том, что у нас у многих в старом (Legacy) коде не проставлялись ни префиксы, ни суффиксы для переменных, если проект не связан с OpenGL. Но заменой на картинку можно вместо префикса отобразить иконку модуля, а вместо типа — иконку типа, даже если ни префикса, ни суффикса. Многие IDE это уже умеют делать, но покажут только в всплывающей подсказке и только текстом. А есть разработчики, которые с простановкой типов в названии переменной не парятся и сейчас, особенно на скриптовых, где статические типы могут и отсутствовать.
Но как проставлять значки? На клавиатуре таких символов нет! Ответ: Drag&Drop поможет! Из готовых библиотек. Как значки, так и готовые куски текста — названия переменных, процедуры и т.д. Да хоть скопировать код, который находится чуть выше! Мне часто приходится копировать названия переменных, а так — навел, нажал клавишу мышки и перетащил куда надо, с зажатым Ctrl оно скопировалось. Но чаще привычка срабатывает Ctrl+C и Ctrl+V. Пока что надо предварительно выделять, нет возможности связать два названия переменной с указанием «это одно и то же» вплоть до одновременного редактирования (вместо пункта диалога — «заменить») и прочее.
Меня интересовала больше возможность заменить текст не на символьные примитивы, а на графические.

Как видим — сегодня мы пользуемся 1,75D языками, которые ближе к «чисто визуальным», нежели «чисто текстовым». И это считается нормой и является промышленным стандартом для многих серьезных проектов. В одну строчку код нынче не пишут, даже переносов людям стало нехватать! Поэтому и движутся по пути максимальной визуализации языка — отступы, подсветка синтаксиса и т.д.

А что же Scratch и прочие? Они сейчас больше похожи на ту одежду, которую демонстрируют на показах мод. Выглядят революционно, но в большинстве случаев имеют проблемы с применением в быту или вообще могут быть исключительно демонстрационными материалами (в мире визуальных языков — «для обучения»). Конечно, существуют и те языки, которые также используются в промышленном применении, но все же не стали всеобщим стандартом для большинства программистов.

Ах, да — визуальные языки еще помогут избавиться от наследия текстовых файлов — «все в один столбик». И если встречается ключевое слово «IF» («ЕСЛИ»), тогда дальше уже будет в 2 столбца, причем правый столбец — код, который записан в ветке «ELSE» («ИНАЧЕ»).
Но об этом уже на уровне 2D из представленной схемы.

Я для себя уже расписывал идеи по визуальному языку вплоть до 3D и 4D, но если 3D действительно в трех измерениях, то 4D — скорее маркетинг, нежели доп.измерение, и имеет интересные для меня свойства, которые «сделают этот жестокий мир программирования лучше» и позволят писать даже на машинных языках, т.е. нет необходимости компилировать код :D
Уточню про написание на машинных языках — 2D подготовит почву, благодаря замене машинного кода на граф.знаки, а вместо компиляции будет 2 файла — машинный код (готовый к исполнению) и файл привязки машинных кодов к граф.символам (нужен для IDE).
3D — упростит написание сложного кода на порядки, как это произошло с переходом от ассемблера на языки высокого уровня.
4D — позволит писать код тем, кто до этого не умел. И не обязательно что-то учить или даже знать как работает процессор для написания машинного кода!


Просматривая комментарий — надо было опубликовать как статью! Но я перфекционист и как-то не привык делиться концептами (описание у меня на уровне концептов), особенно для 3D и 4D, когда тут даже 2D подразумевает революционный подход (либо долгий эволюционный путь). Хотя, может кто-то согласится такое помочь реализовать или подсказать где искать? Тогда ради подсказок можно будет и попытаться поделиться своим видением «Next Gen» ЯП, которые будут визуальные на уровне IDE, но при этом все те же привычные С, Java, JS, C++, C# и любой другой текстовый язык, ассемблер или даже машинный код! Под спойлером я расписывал, но без подробностей и как оно так функционирует.
+4
Э-э-э…
Вы забыли принцип «мухи отдельно, котлеты отдельно».
Т.е., для обычных ЯП (не визуальных), код и его «визуальное» представление отделены и не зависимы.
При этом как выглядит код, не сильно важно (кроме отчасти python'а)
В отличии от визуальных ЯП. Где все смешалось в кучу. Где визуальное представление не отделима от кода программы.
И да с текстом работать удобнее, чем с пиктаграммами.
Тупо за счет того, что текст компактнее.

+1
Тупо за счет того, что текст компактнее.

Странно, обычно картинка favicon.ico (иконка сайта) компактнее названия всего сайта. Например, модуль подключения facebook можно обозначить двумя иконками — f (на синем фоне)+вилка (которую в розетку). 2 иконки будут короче целых слов, но могут посоревноваться по длине только с аббревиатурами, у которых есть ограничения по количеству допустимых вариантов — количество букв в алфавите всегда будет меньше количества доступных пиктограмм.
Мало того — есть много стандартных иконок, типа «сохранить» (дискета), «открыть» (папка), «создать» (лист с загнутым уголком или зеленый плюсик), «удалить» (красный минус). Соответственно, эти иконки будут заменами даже для слов «save», «open», «create», «delete». Можно набрать ключевое слово, которые позже будет отображаться иначе. Мало того — даже скобки можно представить в виде контейнеров, а это уже визуальщина. И Lisp благодаря этому может избавится от скобочек — в IDE отрисовывать выражение в скобках в виде выражения внутри прямоугольника или иной фигуры. И именно этот язык разбивает ваше утверждение про
с текстом работать удобнее, чем с пиктаграммами.


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

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

И последний аргумент: символ — это частный случай пиктограммы из специального набора под названием «алфавит». Отсюда — любой текст — это набор пиктограмм. Отсюда ваше выражение приобретает противоречивый характер в стиле «с символами работать удобнее, чем с символами»
0
И последний аргумент: символ — это частный случай пиктограммы из специального набора под названием «алфавит». Отсюда — любой текст — это набор пиктограмм. Отсюда ваше выражение приобретает противоречивый характер в стиле «с символами работать удобнее, чем с символами»
Пиктогра́мма (от лат. pictus — нарисованный и греч. γράμμα — запись) — знак, отображающий важнейшие узнаваемые черты объекта, предмета или явления, на которые он указывает, чаще всего в схематическом виде.
Буква алфавита такими свойствами не обладает, только набор букв формирующий слово целиком.
0
Буква современного алфавита, причем только для некоторых языков, не обладает свойствами пиктограммы. История развития многих языков на это намекает, те же «Азъ Буки Веде Глаголь...» и последующее сокращение лишних или неполиткорректных сущностей до современного уровня или заимствования от других народов. Возможны позднего придумывания, например, «ё».
Также во многих языках существуют ситуации, когда буква может обозначать целое слово. Аббревиатуры
Не забываем, что многие народы «перескакивали» целые эпохи развития и могли получить свою письменность относительно недавно, особенно это касается малых народов, не являющимися на момент получения письменности государствообразующим.
И еще было упущено иероглифическое написание, когда даже сейчас можно каждой букве подставить свою пиктограмму-иероглиф, что даже так и делается — азбука для детей или шифрованные сообщения (простая замена написания), но особо не распространено среди остальных, т.к. является усложнением написания и влияет на скорость письма. Скорость письма отходит на второй план только при появлении доступного аудио- или иного фиксирующего оборудования, но до этого всю историю развития человечества именно скорость письма была критична, особенно до широкого распространения книгопечатания.
Соответственно, в будущем вполне возможен переход на иероглифичные стили письма. На это намекает широкое распространение эмоджи/смайликов, которые даже стало удобно набирать в различных мессенджерах/общалках/смс с поддержкой на уровне ОС (андроид и прочие). Но этому явлению в сверхшироком массовом сегменте буквально два десятилетия — первое десятилетие у каждого свои иероглифы-смайлики, второе — смайлики уже на уровне целых экосистем и операционных систем. Почему выделил только последние два десятилетия? До этого телефоны и компьютеры, как и интернет, не были доступны широкому кругу пользователей, в т.ч. домохозяйкам, обычным работникам, студентам, школьникам и другим не IT-специалистам, которым хочется писать в чате да котиков рассматривать, а не «изучать новое, неопознанное и очень сложное» без онлайн-сервисов, без связи с другими ПК, высокая стоимость этих самых ПК, никакая функциональность телефонов (максимум — телефонная книга в крошечном экране, и то не всегда). И т.д.
0
1) Иероглифы действительно близки к пиктограммам, но они не являются буквами — это не алфавит, это принципиально другая система письменности. Причем пиктографичны именно иероглифы, но не слоговая азбука в японском (хирагана и катакана) и не корейский фонетический хангыль.
2) Смайлики не стоит рассматривать как альтернативу письменности, по сути это аналог жестов (типа рукопожатия, махания рукой) и невербальных эмоций (улыбка, нахмуривание и т.п.) при реальном общении. Полноценно на них никто не общается.
3) Абревиатуры — это не буквы алфавита сами по себе, это своего рода слова и они имеют смысл только в виде конкретного набора букв, но не сами буквы по отдельности.
4) Есть редкие исключения, когда одна буква может являться целым словом: я (местоимение), и (союз), о! а? (междометия), но сами буквы в составе слова не несут отдельного смысла.
+1
1. различие достигнуто по причине, о которой я уже упоминал — скорость письма. А также из-за звукопроизношения и необходимости делить на более простые формы-атомы.
Проще это демонстрировать на диаграмме Венна, когда по вложенности идут следующие множества:
Изображения/фото->рисунки->пиктограммы->иероглифы->базовые элементы->буквы->буквенные модификаторы (точки над ё).
Да, по мере вложенности часть информации теряется. И это больше похоже на слои абстракции, т.к. более вложенное множество не может продемонстрировать все достижения предыдущего слоя. Но получаем универсальность.
Картину зимнего леса не получится использовать для объяснения принципа работы компьютера. Но зато картина зимнего леса может эффективно заменить текст описания этого зимнего леса.
Имеет три параметра — скорость письма, универсальность применения, сложность обучения, сложность написания и информативность. Человечество ориентировалось на первые четыре в ущерб информативности, поэтому и дошли до букв. Тот же значок банана трудно нарисовать черным цветом, отсюда упрощение и сложность обучения иероглифу.

2.1) «Гулливер» Джонатана Свифта. Описание общения с помощью предметов. Они не знали про пиктограммы, поэтому таскали с собой целые мешки. А так достаточно одной книги со всеми возможными заменами слов в виде пиктограмм и просто тыкать на нужной странице.
2.2) Сейчас некоторые диалоги можно строить с помощью пиктограмм, этим даже пользуются. Например — когда пишут про 18+, используя (отпечаток помады от женских губ), (банан), (клубника) и т.д. IT специалисты пока вынуждены ждать, т.к. пиктограмм Shift, Ctrl, Tab и прочего еще не завезли. Названия клавиш не сильно интересны, а вот всякие faceboot, google и прочие значки могут пригодится.
2.3) Язык глухонемых. Извините, зашел с козыря. Мало того, язык глухонемых можно использовать для общения с теми существами, у которых человекопонятная речь в принципе невозможна из-за принципиально другого строения, например — собаки, обезьяны и прочие. Просто вместо жестов применять картинки.

3,4) некоторые иероглифы/пиктограммы могут не иметь самостоятельного значения или оно бессмысленно отдельно. Даже для слов встречается — есть слово «ненавидеть», но нет слова «навидеть». В остальном — повторение п.1.

5) Смысл букве именно сейчас обрести отдельный смысл?
6) Вы отрицаете, что буквы при ныне отсутствующем самостоятельном смысле когда-либо ранее имели отдельный смысл?
+1
«Значок банана трудно нарисовать черным цветом» — это почему?
«собаки понимают язык глухонемых» — это сильное заявление…
0
«Значок банана трудно нарисовать черным цветом» — это почему?

В целом можно. Ч/б фотку сделать можем же. Есть лишь одна проблема — ложные пересечения, свойственные при упрощении. Например, как банан отличить от дольки мандарина, если пиктограмма будет элементарна и одинакова в обоих случаях.
Задачка посложнее — как отличить зеленое яблоко от красного? если оба нарисованы схематично черным цветом. Или красный от зеленого сигнала для горизонтально расположенного светофора, нарисованный черным цветом. А если не применять серый или доп.иконки — то задача действительно усложняется. Еще вариант — отличить полностью наполненную водой бутылку от пустой, тут даже фото не всегда поможет. Подразумеваю наполнение без воздушного промежутка сверху, т.е. до уровня крышки. Морскую волну и радиоволну, хотя тут можно выкрутится за счет широкой трактовки.

«собаки понимают язык глухонемых» — это сильное заявление…

Собаки поддаются дрессировке и способны понять 1-2 жеста и больше. Даже десяток вполне смогут. Или вы отрицали, что собаки могут понять до десятка жестов?
Я не говорил про всю полноту языка, тут даже люди не способны знать всю полноту родного языка, особенно всякой терминологии, названия инструментов и явлений и редко используемых слов. Максимум — художественную полноту осознают. А перечислить по памяти названия врачебных инструментов (кроме врачей и причастных)? Вряд ли рядовой обыватель справится. Я молчу про диалекты и местные наречия, когда одному и тому же явлению находятся разные слова.
0
Задачка посложнее — как отличить зеленое яблоко от красного? если оба нарисованы схематично черным цветом.

зато вы достаточно хорошо описали их текстом. Заметьте, текстом любого цвета. поэтому текстовое описание — более точное, позволяет выделять существенные признаки вещей.
Собаки поддаются дрессировке и способны понять 1-2 жеста и больше
— понимание языка сильно отличается от запоминания жестов. Далеко не все слова в языке глухонемых описываются одним-двумя жестами. но немой вполне может одними и теми же жестами обьяснить, высокий или низкий он слышал звук, и высоко или низко прыгнула собака. вы можете выучить собаку в зависимости от жеста прыгать высоко или низко, но этим же жестом-модификатором вы не сможете ее заставить выть выше или ниже, и наоборот. Хотя вы можете заставить собаку запомнить названия медицинских инструментов (типа, «скальпель — гав», «шприц — гавгав»), но классифицировать иглу от шприца и иглу для взятия пункции как «иглы» она не сможет. а человек сможет выбрать иглу для пункции из груды скальпелей, зажимов и тампонов даже если никогда не знал о ее существовании.
0
текстом любого цвета. поэтому текстовое описание — более точное, позволяет выделять существенные признаки вещей.

Во-первых — не любого! Как минимум — не совпадающего с фоном, а желательно вообще контрастным
Во-вторых — позволяет абстрагироваться с потерей информации. Т.е. при описании фото растения вы можете пропустить информацию о том, что это растение болеет (нейросети уже учатся). Также вы не можете описать то, чего не знаете. Например, некоторые не знают что такое штангенциркуль, соответственно — не смогут его опознать.
В-третьих — занимает больше места. Одна иконка размером с 2-3 буквы заменит словосочетание «красное яблоко» (13 букв+спецсимвол пробела)
Еще пример — как мужчина попытайтесь описать название нескольких розовых помад разных оттенков и покажите это описание женщине. Тут большинство мужчин будет бессильно описать разницу между помадами, даже если вы ее заметите. Бессилие растет с ростом количества помад, для 2-3-х единиц могут и кое-как справится.
человек сможет выбрать иглу для пункции из груды скальпелей, зажимов и тампонов даже если никогда не знал о ее существовании.

Нет, не сможет. Если не знал даже очень похожих аналогов. Можете проверить — открыть рабочий набор инструментов перед студенткой гуманитарной специальности и попросить дать гаечный ключ, крестовую отвертку, различные биты для шуруповерта. Вот на словах «любой бит для шуруповерта» даже я засомневался, т.к. знаю про «насадки», но не про «биты», которые синонимы «насадкам», а не которые из IT.
Девушки, которые не от мира IT и специально или случайно не изучавшие, не смогут подать материнскую плату (которая не алименты), оперативную память (а отличить DDR2 от DDR3? DDR4? Или хотя бы ноутбучную DDR от полноразмерной?), процессор (который не системный блок под столом). А про всякие радиодетали — тут даже я буду бессилен, т.к. не всегда могу их различить, даже если видел их ранние версии, т.к. современные могут очень сильно отличаться или быть очень нестандартными в связи с миниатюризацией.
Еще пример с музыкой — тут первично графическое отображение (ноты). Не принято пытаться музыку записывать текстом. И обычный человек не способен описать музыку как она есть, максимум — выразить чувства и какие-то базовые характеристики — интонации, темп и прочее. Только для людей с абсолютным слухом возможно описать музыку «дословно», т.е. буквально каждую ноту.
0
Как минимум — не совпадающего с фоном, а желательно вообще контрастным
— требованияе несовпадения с фооном есть требование выделения сигнала на фоне шума. Текст, кстати, отличается этим от картинок в лучшую сторону.
как вообще у пиктограмм с пмхозщищнстью?
В-третьих — занимает больше места. Одна иконка размером с 2-3 буквы заменит словосочетание «красное яблоко» (13 букв+спецсимвол пробела)
— пожалуйста, нарисуйте всем понятную иконку, обозначающую «зеленое кисло-сладкое яблоко, весом 150 граммов, с плотной сочной мякотью, пролежавшее под деревом несколько дней в начале октября».
как мужчина попытайтесь описать название нескольких розовых помад разных оттенков и покажите это описание женщине.
— колористами прекрасно работают и мужчины. и парфюмерами тоже. Более того, можно не «описывать словами» (аналог вашей «пиктограммы»), а указать конкретный цвет на палитре.
Еще пример с музыкой — тут первично графическое отображение (ноты). Не принято пытаться музыку записывать текстом.
— «не принято» — это не значит, что невозможно (в студенчестве на Корветах вполне записывали в знаковом виде, взаимно однозначно переводимом в стандартную музыкальную нотацию). и более того, само понятие «нота»- это «знак». Т.е современная нотная нотация — это знаковое письмо. аналог формул — но не пиктограмм.
некоторые не знают что такое штангенциркуль, соответственно — не смогут его опознать.
Это ндывается «бинго!». Давно-давно, несколько более 30 лет назад, ко мне в гости пришли одноклассники. на рабочем столе обычный рабочий беспорядок — паяльник, инструменты, детали… И вот девочка, гуманитарий, музыкантка-пианистка, ненавидящая естественные науки, задумчиво смотрит на стол и спрашивает — «это что, паяльник? — да. А это штангенциркуль? — да. Так вот он какой! — в смысле? — Ну, отец с кем-то говорил, сказал, что померил штангенциркулем. Я его никогда не видела, но поняла [тут описание цепочки рассуждений] что это штангенциркуль.» Вот так.
0
С помехозащищенностью — никак. Впрочем, как и у текста. Почерк врачей или jpeg-фото на старый телефон — и текст не разобрать.

зеленое кисло-сладкое яблоко, весом 150 граммов, с плотной сочной мякотью, пролежавшее под деревом несколько дней в начале октября

Решается, но несколькими иконками (кроме цифр и единиц СИ):
(яблоко (зеленый; вкус: лимон, сахар; вес 150г; мякоть: сок, плотный; место: под деревом; срок давности: несколько дней; время года: октябрь)
Теперь каждое из слов можно заменить на свою иконку. Всего было 236 символов (включая пробелы), Русский язык. Можно заменить на 18 иконок + до 6-10 спецсимволов.
Вкус — рисунок губ+языка (на одной иконке)
Сахар — кубики сахара
Вес — Гиря+ перо (на одной иконке)
150г — остается без изменений, т.к. цифры и единицы СИ итак имеют максимальное сжатие, пиктограммами тут можно только увеличить размеры; также цифры общеприняты и не переводятся, кроме некоторых народов.
Мякоть — нож, воткнутый в арбуз
сок — стакан рядом с пакетом (одна иконка)
под деревом — стрелка вниз под кроной иконки дерева; посчитал за две иконки, но по факту тут одна
срок давности — часы и стрелка влево над часами, т.е. «в прошлое»
несколько дней — сдаюсь. Вот тут я не придумал что нарисовать.
Время года: октябрь — тут надо учитывать, что названия месяцев по звучанию — белиберда, т.к. никаких ассоциаций с реальными предметами. Логично, ведь название месяцев по факту — иностранные имена, числительные и прочее. Поэтому проще взять какие-нибудь народные названия, типа тех же украинских, у них «октябрь» = «жовтень». Итого 2 иконки — календарь отрывной + желтый цвет (можно совместить). Падающий лист уже будет «листопад» = «ноябрь»

Итого — не подобрал замену только для «несколько дней».
0
почерк врачей — это отдельная тема. как и почерк вообще. и, имхо, больше имеет отношение к шифрованию, нежели передаче информации.
по «пиктограммам» — вы не смогли обойтись без знаков. Но даже с ними — проведите эксперимент: дайте ваш рисунок нескольким людям, померьте время на расшифровку «мгновенного восприятия образа», и сравните для смеха их понимание вашей пиктографики с тем, что вы пытались изобразить. ну, можете им еще сравнить их версии между собой — тоже весело будет.
я думаю, вывод понятен?
0
Я думал, в первую очередь, о животных, когда писал этот комментарий.
Но сейчас обнаружил и вариант получше:
ИИ! Точнее, пиктограммы/знаки для общения с ИИ.

Про собак — их вполне обучали даже вождению, например
У ИИ с этим некоторые сложности

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

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

I) Есть два принципиальных типа письменности
— Фонети́ческое письмо́ — вид письма, в котором графический знак (графема) привязан к определённому звучанию.
— Логографическое — главное отличие логограмм от других письменных систем состоит в том, что графемы напрямую не связаны с произношением.
У этих двух систем есть ряд вариаций, но это уже детали.

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

III) Язык глухонемых — это не козырь по следующим причинам:
— он очень специфичен и узкозаточен под конкретную задачу, точно также как и другие языки жестов.
— мы спорили не о языках, а о системах письменности. Какая письменность у языка глухонемых?

6) Вы отрицаете, что буквы при ныне отсутствующем самостоятельном смысле когда-либо ранее имели отдельный смысл?

Да, именно так и именно из этого началась наша дискуссия.
+1
Благодарю за понимание! Я стараюсь давать развернутые ответы, а также иногда даю рискованные утверждения, дабы получить критику. С момента первого моего комментария к этой статье (он корневой) благодаря дискуссии я смог и сам, и с помощью других найти много интересной информации. Согласно утверждению «В споре рождается истина».

II) А я склонен, что это не просто параллельные, а одновременные. Т.е. грубо — 50% произошло от первого вида, 50% от другого. А у другого народа другие пропорции в пределах от (0%; 100%) до (100%; 0%). Мало того, в этих пропорциях могут быть поправки, например — третий вид, суррогатный. Когда и произношение, и письмо — заимствованное от более высокоразвитых цивилизаций, например — белые в Африке.

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

6) а я думал, что был иероглиф (который ближе к картинке), потом его расчленили на составные части, которые стали более универсальными, потом слишком сложные части еще раз порезали. И более простые элементы стали письменностью, как та же слоговая азбука в японском (хирагана и катакана). Я не утверждаю, что так появилось 100% букв. Мне для подтверждения хватит 1% от общего алфавита, причем для какого-нибудь одного языка. Тогда автоматически получается признание, что система работает и такое возможно. А дальше лишь установить точную границу в том, сколько именно букв получилось от иероглифов и когда-либо имели самостоятельно значение.

Эх, я сразу же выиграл. «Я» и сейчас имеет самостоятельное значение, а это более, чем 1%. Даже для пиктограмм свойственно утрачивать собственное значение, в зависимости от контекста и модификаторов, например — черта сверху может обозначать инверсию, т.е. было значение «красный», стало «не красный».
0
Кстати, в некоторых инструкциях действительно заменяют слова на иконки, например в инструкции к пульту управления будут не названия кнопок, а их графические изображения.
Тут всё проще: иконки в инструкции позволяют её не переводить и, главное, не разделять модели с разными инструкциями. Сильно упрощает логистику.
0
но, к сожалению, на данный момент чисто графических инструкций очень мало. Видел — у Google и некоторых других была инструкция для онлайн-продукта в стиле — весь экран затемняется и только нужная часть подсвечена. И выполняется в песочнице. Но все равно текст не всегда воспринимается, типа — что происходит? т.к. иногда встречались даже на китайском, язык поменять можно только если закончить инструкцию, но повторно инструкция уже не запустится. Глюки с локалью или с тем приложением (игра на андроид от китайских разработчиков)
0
I) По поводу языка глухонемых.
— Врядли изображения их жестов будут простыми и удобными и легко читаемыми, так как там жесты объемные, а так же еще и масса жестов с движением.
— Интересно было бы услышать мнение человека владеющего и языком глухонемых и речью, насколько вообще этот язык удобен.

II) По поводу пультов, иконок и т.п.
Это все удобно в отдельных узких сферах, и даже там применяется частично, а не заменяет все.
Например есть дорожные знаки — визуально, удобно, понятно. Но, даже там есть еще доп. информационные таблички с текстом, хотя казалось бы, ну сделай знаков больше и откажись от текста вообще. Но ведь не отказываются, потому что это создаст больше путаницы, чем удобства.

III) В целом, я считаю, что есть отдельные задачи, где использование пиктограмм, иконок, смайликов и т.п. визуальных элементов очень удобны, но они удобны именно для узкого подмножества задач, но не формируют полноценный гибкий универсальный язык.
Эх, я сразу же выиграл. «Я» и сейчас имеет самостоятельное значение, а это более, чем 1%.
В даном случае, я думаю просто была фонема означающая личное местоимение я и совпало что есть буква с таким звучанием (в английском тоже совпало, а вот в немецком и французском уже нет).
Если бы это не было случайностью, то скорей всего так было бы во многих языках и для многих местоимений.
0
1) не обязательно копировать именно этот язык. Достаточно факта, что он существует. Для реального текста проще придумать лаконичную адаптацию. Я даже чуть выше дал пример описания
habr.com/company/edison/blog/432334/?reply_to=19476468#comment_19480142

2) тут есть труднокодируемые сочетания: названия городов, улиц и т.д., аббревиатуры, числа, единицы СИ (скорость, масса) и т.п.
100% достигнуть не получится. Но заменять на слова типа «скользко», «ограничение скорости» и прочие — слова декодируются дольше, а сейчас еще и появляются те, кто читают с трудом. Видел одного, который до 11 класса читал по слогам, но сейчас нормально, т.к. научился из-за игровых чатов и субтитров к кинофильмам.

3) настаивал на том, что формируют, получаясь что-то вроде разборчивых иероглифов. 5-6 тыс таких знаков вполне могут дать адекватную замену для многих. А специализированные термины или редкие слова можно оставить текстом.
0
«читающие с трудом» были всегда. (И существовали даже «нечитающие»). начиная от времен «ликбеза», включая вполне вроде бы благополучные советские (например, был знакомец из соседнего двора, читающий в 7 классе (это 1982 год) по слогам. Впрочем, у него были другие качества, благодаря которым он успешно сел на малолетку, а затем спился и умер. Был муж сокурсницы — тоже выпускник советской школы, читавший ребенку сказку тоже по слогам… Надеюсь, вы не считаете, что такие люди крайне необходимы в разработке программ?
0
II) Я нигде не нашел детального обоснования того, что фонетическое письмо произошло от логографического, есть очень древние примеры и того и другого типа. Я склонен считать, что это две параллельные ветви письменности.
Любой логографический язык неизбежно сталкивается с необходимостью фонетической записи тех слов, которые нельзя обозначить картинкой. Например имена в древнем египте.
Как правило — используется первая буква/слог
При «импорте» письменности иноязычным народом остаётся только фонетическая часть. А сами иероглифы упрощаются — ведь они теперь обозначают только звук, сохранять визуальное сходство уже не надо.
0
Любой логографический язык неизбежно сталкивается с необходимостью фонетической записи тех слов, которые нельзя обозначить картинкой.
В Китае так и подбирают по созвучию, но стараются подобрать еще и иероглифы с положительным смыслом.
А в Японском изобрели дополнительную фонетическую запись. Кстати, сейчас посмотрел — она действительна произошла от иероглифов, это удачный пример появления фонетического письма из логографического. Но является ли это общей практикой или редким частным случаем?

При «импорте» письменности иноязычным народом остаётся только фонетическая часть.

Так как в случае китайских иероглифов пример прямо противоположный — они распространялись именно как графическое изображение слова, а вот их произношение в разных языках было совершенно разное. Что объяснимо, так как речь появилась раньше письменности.
Хотя да, в Японии паралельно с этим еще и создали слоговую азбуку упростив иероглифы.
0
В Китае — не было импорта, был навязываемый сверху государственный язык.
А импорт (добровольный) был например в средиземноморье. Сначала финикийцы непонятно у кого, потом от них остальные.
И угадать вполне можно, если присмотреться
А — бык, D — дверь, М — вода(море), О — око, S — крючок, R — голова, W — зубы, Y — рука
0
В Китае — не было импорта, был навязываемый сверху государственный язык.
Я говорю про экспорт китайских иероглифов в соседние регионы в дальнейшем — в Японию, в Корею. И они туда пришли именно как логографическая письменность, на слух их произносили так, как обозначаемое слово произносилось в языке нового региона, а не как в исходном Китайском.
0
Ну там неизвестно как оно было, финикийцы же через торговлю т.е. точно без навязывания.
0
Я нигде не нашел детального обоснования того, что фонетическое письмо произошло от логографического, есть очень древние примеры и того и другого типа.

Зато есть замечательный пример письма, которое является их гибридом: египетские иероглифы. Короткие слова обозначаются логограммами, а длинные — строятся из коротких по принципу ребуса.
+1
Но зато картина зимнего леса может эффективно заменить текст описания этого зимнего леса.

Только ту часть, где даётся описание визуальной информации. А вот как на картине изобразить следующие фразы:
«В лесу раздавался топор дровосека.»
«Смолою и дымом пахнет зимний лес.»
0
как в комиксах. Дополнительная информация дается в виде новых картинок, но с группировкой, что это об одном и том же.
0
То есть вместо точного описания получаем ребус, который разные люди могут понять по разному. А ведь в тексте может ещё присутствовать тактильная информация (бархатистые иголки пихты), временна́я (лишь изредка можно услышать стук дятла), взаимосвязи (ветер содействует естественному возобновлению леса, распространяя пыльцу, семена и плоды древесных пород) и многое другое.
0
Зато в некоторых случаях этот ребус может примерно разгадать не умеющий читать индивидуум… из которого, видимо, должен получаться «визуальный программист»
+2
Иногда говорят, что одна картинка стоит тысячи слов. Это не совсем так, но… похоже.

Посмотрите на картинку нового процессора AMD:
Там (в маленьких квадратиках по краям) 64 ядра. А вот та здоровенная хрень посередине — это хаб. Условно — «стрелочки», соединяющие эти ядра с шикой данных и друг другом. И нет — это не кеш.

Собственно из этой картинки понятно в чём беда «графических сред программирования».

Их бич — не пиктограммы. Они и компактнее текста могут быть.

Их бич — это рамочки и стрелочки. То есть то самое, что, собственно, и является основным достоинством и что помогает их освоить людям, незнакомым с программированием.

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

А в тексте — никаких стрелочек нет. Они подразумеваются. Что, с одной стороны, позволяет делать всё компактнее, а с другой — требует обучения, да.
0
Я не видел аргументов, чтобы JMP-инструкции ассемблера (или goto-инструкции ЯП высокого уровня) можно было легко читать. Даже есть название для этого — спагетти-код. Мало того — даже отказ от JMP/GOTO инструкций не исключает появления плохо читаемого кода, который достигается методом «все вместе» без разбиения на процедуры, функции и т.д. А еще есть неявные вызовы, которые расцвели у скриптовых ООП-языков.

Теперь посмотрим на визуальные языки и видим, что им JMP/GOTO-инструкции не запретили, какого-либо обучения не дают и получаем спагетти-код или всякие другие варианты, в которых и похуже может получиться.

И видя, что и в тексте можно поломать и отстрелять себе ноги и все на свете, мы продолжаем ругать визуальные языки. Причем обучение не гарантирует получение знаний, которые позволят писать хороший и качественный код. Это не из-за «самоучителей для чайников», а просто потому, что чем сложнее создаваемая система, тем меньше людей, достигший того же уровня, соответственно — меньшему количеству людей потребуется решение. А сами решения могут быть сопоставимы по сложности с другими сложными системами, разве только на порядок проще, но все равно остаются на несколько порядков сложнее задач из самоучителей.
+1
другими словами, на*овнокодить можно хоть в визуальной форме, хоть в текстовой.
Отсюда преимущество визуальных языков ничуть не очевидно.
Правда, есть нюанс — в связи с низким порогом вхождения овнокодить на визуальном языке будет больше овнокодеров. Хорошо, если таковые вовремя остановятся, и не полезут овнокодить ответсвенные системы.
Хотя, безусловно, у визуальных систем есть куча применений, в которых они удобнее систем текстовых- только к программированию это никакого отношения не имеет.
0
Я соглашусь про Овно-кодинг.
Но ваш комментарий практически типичен (убрал одно слово):
в связи с низким порогом вхождения овнокодить на ______ языке будет больше овнокодеров. Хорошо, если таковые вовремя остановятся, и не полезут овнокодить ответсвенные системы.

Впишите любой язык «для широкого круга», типа PHP и прочие (извините, адепты языка PHP и языков из «прочие») и получите точно такую же ситуацию, с началом холивара в стиле «Язык для широкого круга VS некоторый другой более сложный язык», коих на просторах сети навалом.

Я чуть выше уже писал — мы уже пишем на визуальных языках, но видя текст, думаем, что это текст, набор строк. На самом деле уже давно нет и даже от иных авторов требуем добавить визуальные стили тегами Code lang=«язык программирования», чтобы удобнее читать, а это именно визуализация. Просто мы недалеки от того, что в том же ассемблере инструкцию MOV (переместить данные) можно заменить на обычную стрелочку, типа
Ячейка1 U--> Ячейка2 // да, я помню, что ранее нельзя было из оперативы в оперативу перемещать, только через регистр проца, как сейчас — не знаю. Вряд ли разрешили на х86. Поэтому просто немного пошалю
Ячейка2 += 115 // Вместо инструкции ADD, добавить
Ячейка2 =? Ячейка3 // вместо инструкции CMP, сравнить
(>0?)===> Goto1 // вместо JPM с условием (JMP с условиями забыл, поэтому тут для примера больше нуля)
Развить тему и мы получим действительно визуальный ассемблер с низким порогом вхождения. А вот как избавиться от кодинга Овнов — это сложнее, но реализуемо современными средствами. Точнее, если разработать на базе имеющихся средств. Правда, бюджет потребуется серьезный, а как привлечь деньги на подобные разработки я не знаю, где есть обязательное применение страхующих методов (для случаев невозрата инвестиций).

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

Кроме x86 существует много других систем. и у PDP-11, насколько помню, можно было и выполнять операции передачи память-память. Равно и как и ассемблеров существует много. И это дело автора ассемблера — как записать команду — словом MOV или словом-стрелочкой. Более того, такой «визуальный ассемблер» для атмеги существует. как думаете, кто им пользуется? :-) да-да-да, именно неспособные к нормальной записи нормальных слов. в полном соответствии с «принципом Шоу»: «Создайте систему, которой сможет пользоваться дурак, и только дурак захочет ею пользоваться».
вообще, у меня складывается ощущение, что вы плохо представляете себе, что такое «ассемблер», что такое «макрос», и что такое «компиляция» (и даже функционал опрационной системы)
0
Про ромбик — не согласен. Этому учатся. Да и еще возле самого ромбика проставляют ±, т.е. куда идем в зависимости от того, ложное или истинное условие. И только потом, спустя время, придет автоматизм, а потом и понимание:
«если так, то делаем это, а если иначе — то делаем то»


Учил только ASM (на базе TASM!), макросы и компиляцию в рамках университетского курса и самостоятельно для собственного интереса. ASM для х86. Позже FASM, но на уровне хобби.
Для Itanium не было визуального ассемблера, но архитектура приказала долго жить. Значит, не в визуальном ассемблере дело.
А кто пользуется обычным ассемблером? При написании веб-сайтов, веб-сервисов, игр, бизнес-приложений и т.д. И тут видно, что для сложных систем нужны слои абстракции, макросы и куча готовых компонентов с автоматизацией, чтобы не описывать «пересылку каждого байта».
неспособные к нормальной записи нормальных слов

А вот это недостаток, причем серьезный. Я за то, чтобы можно было переключить режим отображения. Хочешь — вот тебе ламповый текст, хочешь — вот картинками тоже самое. И если я в тексте что-то изменю, то картинки соответствующим образом изменятся. И обязательно — эквивалентность! Даже сейчас GUI для консольных программ чаще всего имеет усеченную функциональность по сравнению с написанием команд в консольке. Хотя для некоторых программ GUI может дать всю полноту управления при условии полного описания всех параметров либо с помощью читерского «добавить к команде» и дописывайте свои ключи и команды. Не касается вызова средств ОС.

«принцип Шоу»: «Создайте систему, которой сможет пользоваться дурак, и только дурак захочет ею пользоваться»

андроид, iOS изначально настроены дружелюбно, а еще MS-DOS(в виде первых Windows) и Linux получили графический интерфейс, дружелюбный пользователю. Вопрос — это считается за «систему, которой сможет пользоваться дурак»?
Я в курсе, что ныне Windows далеко ушла от MS-DOS и строится во многом на других принципах, хотя многие базовые понятия пока остались, типа — управление мышью и клавиатурой (сенсорный экран и жесты пока не всеохватывающие), хранение на жестком диске (а не в оперативной памяти — энергонезависимая память только-только появляется), 2D монитор, а не голографический или нейроинтерфейсный и т.д.

Мое понимание указанных вами слов
ассемблер — машинные коды, записанные в более понятном для человека виде, но с потерей некоторой информации (в человекочитаемом виде), например — адреса меток высчитываются динамически (и не человеком).
Из вики: транслятор исходного текста программы, написанной на языке ассемблера, в программу на машинном языке.

Макропроцессор — одни последовательности заменяются на другие, согласно заданным правилам. Ближе к трансляторам по логике работы. Отсюда — макрос — последовательность инструкций, которая будет заменена на другую последовательность (чаще всего такую же или более длинную).

Компиляция — анализ, компоновка исходного текста (если несколько файлов, которые не транслируются отдельно), трансляция и сборка. Анализ необходим для той же оптимизации.

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

А как сами понимаете эти понятия?
0
Теперь посмотрим на визуальные языки и видим, что им JMP/GOTO-инструкции не запретили, какого-либо обучения не дают и получаем спагетти-код или всякие другие варианты, в которых и похуже может получиться.
В ДРАКОНе вроде как раз запретили.
0
Да, действительно. Одно из таких ценных правил, которое следует переносить на другие языки, вне зависимости — визуальные или нет.
К сожалению, спагетти очень нравятся большинству именно из-за простоты создания. И я не про макаронные изделия, а про описание алгоритмов и схем. А некоторые топологии с определенного уровня даже распутать будет невозможно (в памяти всплыло число 19, но подробности той лекции уже утеряны).

Я расцениваю ДРАКОН именно как свод полезных правил, парадигма против спагетти. А его ругают как будто он самостоятельный язык. Почему ООП не ругают? У него вообще нет своего языка, все время какие-то посторонние языки его используют. Все потому, что ООП — не язык, а парадигма!

И получаем, что ДРАКОН — плохо, а ООП (ООяП) — хорошо. Но у обоих нет своих языков! Даже на Википедию зашел — вот там нету самостоятельного языка с названием "Объектно-Ориентированный язык Программирования", зато полно языков с поддержкой ООП (ООяП).

Тогда можно ввести понятие «Дракон-совместимость» и любой язык с поддержкой структурного программирования является ДРАКОН-совместимым.
0
Я расцениваю ДРАКОН именно как свод полезных правил, парадигма против спагетти.
К сожалению это не просто «свод правил» — это некоторый, вполне определённый, язык. Там есть вполне определённые иконки, построенная над ними нотация и прочее.
0
Которая ближе к блок-схемам и не имеет транслятора в машинное представление. Ранее (в прошлом веке) транслировался ручками инженеров, а сейчас пытаются придумать транслятор через си/паскаль/другие. Тут ситуация как с UML. И UML, и ДРАКОН не являются языками программирования (у них для этого не определены ключевые слова), но можно выполнить генерацию кода по схеме, в отличии от блок-схем.
Мало того — у ДРАКОН даже с типами более, чем никак, вообще никак. Поэтому типы берутся от языка-посредника, от которого берутся и ключевые слова.
Также у ДРАКОНа пока все плохо с процедурами и функциями. Нет, не с реализацией, а с логикой. Создается косвенная логическая связь, которая усложняет программу. Хотя ситуация типичная для всех языков программирования, но намного лучше неявных вызовов, т.к. есть хотя бы упоминания. При вызове процедуры вы по умолчанию считаете, что она работоспособна и без ошибок.
Еще у ДРАКОНа все плохо с ООП. Т.е. методы объекта описать еще можно, а вот объекты, их наследования и прочее — уже нет.

Было бы интересно увидеть сравнение на уровне ключевых слов/действий.

Например, ДРАКОН VS паскаль — у дракона определены циклы, ветвления, процедуры (с функциями беда — нет типов).
Никак с экспортом, операторами, типами, прерываниями и исключениями (как отдельные сущности), режимами работы.
+2
Но самое важное, что все эти D, кроме первого — ничуть не обязательны. И их отсутствие влияет лишь на удобство работы.
0
Спасибо за наводку. На хабре была такая статья: Моноширинные шрифты с программистскими лигатурами
Но я подразумевал не только символы <=, >=, !=, := и прочие, но и ключевые слова false, true, if then else, for и т.д. А также символы, определяемые пользователем или библиотекой — названия функций, переменных и т.д.

И тогда да, действительно будет близко даже к 1.85D, останется добавить Drag&drop панельки для готовых наборов. Еще пару деталей — и 2D, практически визуальный язык, который получили эволюционным путем, сохранив всю мощь по пути
+14

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

0
Скорее визуал от реального отличается как владелец бизнеса по производству лего, от технолога, который процесс её изготовления разработал. Владельцу не нужно знать, как оно там устроено, но нужны результаты нижестоящих процессов.
0
Визуальное программирование — это хорошая идея для обучения детей (до 8-10 лет) алгоритмам и программированию. Во главе угла стоят алгоритмы, а программирование — это средство их реализации.
+1
А чего никто не пишет про Дракон? или он не визуальный?
Побольше бы научпопа про него.
+4
это, что называется, «упаси господи».
Во-первых, сама концепция: она возникла в конце 70-х — начале 80-х годов, когда перелазить с традиционной электроники на программируемую уже понадобилось, а специалистов еще не было. А традиционные инженеры, особенно сформировавшиеся профессионально в середине -конце 60-х, хорошо воспринимали схемы, но не воспринимали программы. Вот и сделали это.
во-вторых, все эти притянутые за уши Паронджановым «исчисления икон» (несмотря на все «доклады и прочее»). Я не буду ничего криттиковаить — просто почитайте сами, вам этого будет достаточно.
в третьих, «заслуги» Дракона в создании того же Бурана сильно преувеличены. я попытал Паронджанова про использование… «мы нарисовали [на бумаге], и отдали программистам на кодирование». ну, и Дракон-Флокс почти из той же оперы (все переменные глобальны, формальная верификация не предусмотрена и т.п. Т.е. на уровне развития подходов к проограммированию — это 80-е годы прошлого века).
в четвертых, качество генерируемого «продукта» (извините, но кодом это язык не поворачивается назвать. хотя написать нормальный транслятор несложно. но нормальному человеку это не нужно, а авторы и пользователи «дракон-редакторов» не могут. Да, кстати, они делают свои дракон-редакторы без использования дракона.)
в пятых, использование Дракона хотя бы для описания бизнес-процессов (своего рода «русский BPMN»). Если примитивные процессы описать еще можно, то сложные (с передачей между зонами отвественности, и т.п.) — без извратов не получалось. Ну и, естественно, нет программного продукта для моделирования/симуляции.
Ну и самое главное: он метит не меньше чем на «спасителя мира». почитайте его «почему мудрец похож на обезьяну», «почему врачи калечат пациентов» и т.п. — и увидите, что это своего рода «юницкий в сфере программирования».
0
Во многом согласен. Хотя обычные языки программирования любят не используя горизонтальное пространство максимально использовать вертикальное. Это приводит к распечаткам кода, когда весь код в один столбик и не используется большая часть листа. Ну хотя бы в 2 столбца! Особенно для всяких IF актуально — на уровне логики там действительно 2 столбца. Первый — для true, второй — для false ветки. Мало того — даже обозваны ветками, что подразумевает дерево, но в тексте стоят последовательно.
Читал книжки в меру и давно лишь с целью почерпнуть интересные идеи, которые можно применять сегодня или даже в качестве извращений аналогично Brainfuck. Си языки с их не всегда логичной работой (i++ + i++ и прочие) тоже являются своеобразным Brainfuck. Я молчу про регулярные выражения, которые больше инопланетный язык.
0
Один из прародителей «Дракона» — ещё и язык ПРОЛ-2. Вот история про то, как Д.Ю.Караваев создал транслятор ПРОЛ-2 для PC (до этого всё работало на ЕС ЭВМ) и что из этого вышло. В сокращении, взято отсюда: «Права доступа к переменным».
Часть транслятора была написана на ассемблере и поэтому летал он ласточкой.
Для повышения надежности в языке ПРОЛ-2 описание нелокальных переменных должно было включать и права доступа в виде списка имен процедур, которым разрешается к этой переменной обращаться.

            Так вот, проверочный транслятор выдал большое число сообщений, что идет обращение к переменным без права доступа. Штатный транслятор давно отлажен и многократно проверен. Таких нарушений он бы просто не пропустил. Откуда в проверенных программах взялись сотни ошибок доступа?

            Но разбирательство показало, что таки-да, в штатном трансляторе помарка. Вероятно, она проникла в транслятор, когда выяснилось, что ресурсов одной БЦВМ не хватает и приняли решение поставить в «Буране» две машины, разделив ПО между ними. Транслятор подправили для двух ЭВМ, но он перестал проверять доступ переменной из процедуры на соседней БЦВМ. Выключилась одна из проверок.

            После выяснения этого даже было совещание. Не столько на тему помарки в трансляторе, сколько на тему технологи разработки. Ведь рассчитывали на что? Что разработчики проанализируют сферу действия каждой переменной и явно и осмысленно укажут множество объектов, которые могут эту переменную читать/писать. А что получилось в реальности? Разработчики чихали на анализ и совали свои модули в транслятор. Ругнулся он по поводу прав — так и быть допишем список, не ругнулся — и так сойдет. В текстах даже нашли издевательские описания нелокальных переменных с пустыми списками, т.е. по правилам языка к ним вообще никто не мог обращаться. И при этом все работало нормально и казалось, что защита от порчи «чужих» данных хорошо обеспечена.

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

            А что, разве при отработке не было случаев, когда один процесс портил переменную другому процессу? Конечно, были. Только во всех этих случаях как раз с доступом все было хорошо.
Вопрос: как права доступа к переменным нарисовать в «Драконе»? А никак. «Дракон» — это про алгоритмы. А права доступа — это про данные.
0
Хорошая цитата оттуда же
С тех пор прошло уже десятка три лет. Программирование и теоретически и практически ушло далеко вперед и добилось больших успехов.

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

В такой схеме например принципиально невозможна была бы авария разгонника на союзе — поскольку объект физический и реальный, в модели угол ограничен 360 градусами. И физическое представление тоже ограничивалось бы размерностью и диапазоном аргумента (например при uint16 представлении — преобразование K*360/65536) т.е. на второй круг ничего пойти не может по определению.
+3
Delphi удобно совмещает визуальное проектирование с текстовым. То, что получается хорошо — делается максимально визуально: формы, собственно весь интерфейс, связи с базами, LiveBindings, тысячи различных невизуальных компонент. Остальное делается кодом. Зачем противопоставлять, если можно взять лучшее из обоих миров? Вместе, а не вместо :)
По поводу контроля версий тоже всё отлично: используется свой формат, а не xml/json:

object Form3: TForm3
  Left = 0
  Top = 0
  Caption = 'Form3'
  ClientHeight = 299
  ClientWidth = 635
  Color = clBtnFace
  Font.Charset = DEFAULT_CHARSET
  Font.Color = clWindowText
  Font.Height = -11
  Font.Name = 'Tahoma'
  Font.Style = []
  OldCreateOrder = False
  PixelsPerInch = 96
  TextHeight = 13
  object Button1: TButton
    Left = 280
    Top = 137
    Width = 75
    Height = 25
    Caption = 'Button1'
    TabOrder = 0
  end
end
0
Помниться во времена DOS был Clarion (вроде бы до сих пор жив)
Вот там как раз можно было «визуально» наваять приложение работающее с БД.
Причем было несколько шаблонов приложения, которые генерировались на основании структуры БД.
Когда работал с Delphi было ощущение «WTF?», все надо делать вручную :-)
0
Это ты первый Visual C++ (и первые версии Visual Basic) не видел, вот где было всё в ручную!
(а сейчас там всё уже нормально)
+1
Кстати, да — когда я увидел первый раз VisualC++, то возник вопрос: «Где ж тут Visual ???»
0
В названии же!

Как и у многих «визуальных IDE», которые обычный блок с подсветкой синтаксиса и некоторыми базовыми настройками под конкретный язык. Все тот же текст, все тот же хардкор.

В одной мобильной игре было задание: «Напечатайте Название игры». Правильный ответ: «Название игры» (т.е. не надо было вспоминать, как называется игра, а просто набрать текст ответа посимвольно, который в кавычках, регистр неважен)
0
Не, ну как — message pump заготовку он давал, по двойному клику добавлял обработчик.
+1
Ну, подобное кроме Delphi очень много где есть. Что WinForms/WPF в .Net, что даже современные среды разработки под Android, где элементы можно потаскать мышкой, а потом при необходимости посмотреть в в виде текстового файла и наоборот.
Но статья-то совсем не об этом :)
Вот всякие визуальные билдеры для ORM/БД уже ближе, хотя там всё-таки не алгоритмы, а связи между данными.
0
Это появилось раньше чем XML и намного дружественнее к человеку чем XML.

Но, поскольку внутрь DFM файлов всё равно никто не заглядывает (есть же визуальный редактор), новые версии Delphi/Lazarus мигрируют на XML.
0
я помню времена, когда это появилось :-)
но вопрос-то был в принципиальных отличиях, например,
Caption = 'Form3'
от
<_Caption>Form3</_Caption>
Да, xml многословнее… но опять же — текстовое (декларативное) описание графического элемента…
впрочем, еще до dfm в том же Clipper'е были конструкции типа
@ nRow, nCol PROMPT «QUIT» MESSAGE «RETURN TO DOS»
которые прекрасно выносились в отдельный «файл интерфейса»
0
Совсем принципиальных конечно нет.

Речь изначально шла про контроль версий при визуальном программировании. А в этом аспекте DFM даёт более чистый результат при использовании diff-а.
0
в таком аспекте — бесспорно.
Я, конечно, не задавался вопросом — есть ли diff для xml, но почему-то предполагаю, что должен быть…
0
1) Ни на какой XML Delphi/Lazarus не мигрируют.
2) Даже если при разработке не лазить руками в DFM файлы, при использовании контроля версий текстовой формат очень кстати.
+1
Читаемость выше и вот такой беды, как на скриншоте, нет в принципе:
Снимок4
вот dpr:
Снимок3
0
Все-таки эти файлы предназначены не столько «для человеков», сколько «для компутеров»
Кроме того, есть другие инструменты сравнения.
image
кроме того, вы можете опять же иметь схему для верификации xml. Ну и любой стандарт лучше, чем нестандарт.
Хотя сам я xml не люблю — «советское воспитание», когда занятые лишние сотни байт на диске считались почти что хищением социалистической собственности…
+2
>Все-таки эти файлы предназначены не столько «для человеков», сколько «для компутеров»

«для компутеров» естественнее бинарный формат, а тут человекочитаемый текст «для человеков»
0
Автор себя обезопасил, сказав, что «визуальное программирование прижилось в некоторых сферах», а именно: на языках визуального программирования типа Simulink и SCADE вполне успешно делают safety-critical проекты вроде ПО авионики самолётов, с формальной верификацией и вот этим всем, которые работают получше «этих ваших» Windows/Linux.

Тут, скорее, вопрос, в другом: что не так с обычным программированием, что к нему не подходят обычные способы проектирования систем из кубиков с взаимосвязями, которые широко применяются почти во всех областях техники? Отсутствие формальной верификации в традиционном программировании, опять же, намекает, что это именно с традиционным программированием что-то не так.
+2
Вы забыли уточнить, сколько стоит это вот все, с формальной верификацией :)

>с традиционным программированием что-то не так.
Ну, в каком-то смысле. Что вас удивляет? Традиционное программирование — оно неоднородно.

По сути только ФП основано на математических принципах, и к нему в итоге применимы как раз достаточно формальные методики, и иногда удается добиться того, что если продукт скомпилировался — то он работает. Но есть большая часть традиционного же программирования, включая скажем C++, где формальная верификация практически невозможна.

>систем из кубиков с взаимосвязями
Дайте угадаю? Из кубиков можно построить как ациклический граф (дерево), так и произвольный. По взаимосвязям можно передавать либо простой сигнал (0 или 1), так и произвольные структуры данных (в случае например BPMN). И это все в итоге очень разные вещи получаются. Обычное программирование, в его самом общем виде, оно местами просто сложнее, чем тот класс задач, который хорошо удается описывать в виде кубиков и связей.

Ну вот простой вопрос — связь передает от кубика к кубику какие-то данные. Какие? Какова их структура? Как вы их описываете (в терминах кубиков?). Как только встают подобные вопросы — так кубиков и стрелочек быстро становится недостаточно.
-1
сколько стоит это вот все, с формальной верификацией

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


большая часть традиционного же программирования, включая скажем C++, где формальная верификация практически невозможна

Просто в статье автор натягивает традиционные методики программирования на визуальные, но так уж ли эти традиционные методики хороши? Может быть это "традиционные программисты", которые до сих пор кодят на вариантах Алгола и Фортрана, застряли в каменном веке?


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


Как вы их описываете (в терминах кубиков?)

Зачем описывать данные в терминах кубиков? Данные можно описать таблицей, например. Или картинкой. Или графом. Да, тут нужна нормальная поддержка со стороны IDE. Также не имеет смысла описывать кубиками, например, математические формулы, для которых есть свой язык. Зато кубиками удобно описывать системные взаимосвязи на высоком уровне, которых не видно, когда перед тобой тупо список файлов. Видимо поэтому от системности пытаются уйти через SOLID и прочий полиморфизм: чтобы, в идеале, можно было открыть один файл и править его, даже не зная о существовании всех остальных. При этом код-клей раздувается до космических масштабов.

0
Мне кажется, вы тут о чем-то не о том. Формальная верификация — это не стоимость какого-то софта. Это стоимость работы по определению требований. Без этого никакое ПО, ни за какие деньги (во всяком случае на сегодня) вам не ответит, правильный ли у вас код — просто потому, что не знает, что именно он должен делать.

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

Ну, ок. Не вопрос. Я так понимаю, вы агитируете за визуальное программирование. Можете показать, как чисто визуально сделать простую вещь — выполнить REST (для определенности пусть будет POST и JSON body) запрос к какому-либо сервису, получить ответ в виде JSON, и распарсить его, попутно проверив на соответствие некой схеме? Зоть кубиками, хоть таблицами — но чтобы чисто визуально.

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

Язык математических формул точно также встроен в большинство языков программирования. По-сути то, что вы относите к преимуществам текстового программирования, относится именно к преимуществам расширенного языка описания математических формул, потому как ещё один компонент текстовых языков — контрольные структуры — как раз хорошо описываются визуально.

0
управляющие структуры описываются визуально ровно с той же степенью успешности, что и текстово. Но визуально — занимают гораздо меньший размер пространства.
в остальном — нарисовать некую фигуру с входящей стрелкой и двумя выходящими, и вписать туда текстовое условие — занимает больше времени, нежели написать «если-то-иначе» текстом. на экране это занимает больше места. «сворачиваются» графические ветки тоже хреновато.
то же самое относится и к описанию данных.
0
Я по большей части не возражаю, только вы незаметно ушли от основного вопроса. Так что там с JSON-то и с REST?

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

И да, к преимуществам текстового программирования я вообще-то отношу совсем другое. То что формулы встроены в большинство языков — это частность. Во многие языки еще и SQL встроен, или скажем XML с JSON. То есть, любое текстовое представление для чего угодно можно встроить в текстовый в основе язык. В этом смысле любая визуальная среда как раз оказывается замкнутой внутри себя — и это не очень хорошо.
0
что там с JSON-то и с REST

Я в это не умею.


Я клоню к тому, что в графическом виде удобно проектировать ПО на системном уровне, а в блоки можно встраивать хоть математические выражения, хоть код на C. Проблема текстового представления — не видна общая структура проекта. Поэтому пользуются спросом различные средства визуализации уже написанного кода в виде графов и т.д.

0
Т.е. «на системном» — на уровне эскиза? На большее «визуальное проектирование» не способно? ну так это вам и пытаются объяснить.
0
На уровне работающей спецификации, компилируемой в код. Ну а насколько глубоко кодить блоками — можно смотреть по ситуации. Можно хоть формулы в виде блоков описывать, если нужно.
0
Можете показать, как чисто визуально сделать простую вещь — выполнить REST (для определенности пусть будет POST и JSON body) запрос к какому-либо сервису, получить ответ в виде JSON, и распарсить его, попутно проверив на соответствие некой схеме? Зоть кубиками, хоть таблицами — но чтобы чисто визуально.

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

0
Текст чего именно? Я прекрасно понимаю, что на самом деле и парсер JSON, и выполнение HTTP-запросов — это совсем не маленькие куски кода, если все сделать как положено. И в большинстве языков никто не будет это все писать сам — а просто воспользуется библиотекой. Меня вполне устроит аналогичное решение. Мне просто интересно, как вы визуально представите как http-запрос, так и json (запрос и ответ), которые надо этой самой библиотеке передать (и принять обратно).
0

Текст того, как бы вы написали эти действия на удобном вам языке программирования.

0
Я бы возможно написал эти действия парой десятков способов. Например, на груви:

println new JsonSlurper().parse(
new URL(«maps.googleapis.com/maps/api/geocode/json?latlng=?lat=${y},${x}»)
).formatted_address

Но это зависит от того, какие именно «эти» действия. Про это я и спрашивал.
0

Замените в своём примере точки на стрелочки — и будет вам пример парсера в видео блоков.

0
Не, погодите. Я в курсе, что точки можно заменить стрелочками :) Речь немного не про это. Гляньте на структуру JSON, которую возвращает google maps, я привел почти реальный пример, только x и y нужно заменить на координаты. Вы увидите, что .formatted_address это лишь одно из множества полей, пожалуй самое простое. Но там их еще куча. То есть это лишь пример.

maps.googleapis.com/maps/api/geocode/json?latlng=?вот тут координаты через запятую

Реальный парсер будет содержать что-то подобное реальной структуре JSON документа, а она сложнее, чем просто адрес. И тут на мой взгляд проблема в том, что в визуальном виде это удобно смотреть, но очень неудобно писать. Во-первых, не очень компактно (мягко говоря), во-вторых, это совершенно не поддается рефакторингу, в отличие от текста, в третьих, обычно очень плохо с поиском, автодополнением (и вообще навигацией) по такому виду кода.

Я не исключаю, что все эти проблемы можно решить — но мне ни одно такое решение не попадалось.
+3
которые работают получше «этих ваших» Windows/Linux.
А они точно «работают лучше»? Ну там, обрабатывают десятки тысяч сообщений в секунду, запускают тысячи потоков, рендерят 3D и т.д. и т.п.?

Или они делают что-то, что гораздо проще, на несколько порядков проще, чем задачи, которые решают «эти наши» Windows/Linux?

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

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

Тут, скорее, вопрос, в другом: что не так с обычным программированием, что к нему не подходят обычные способы проектирования систем из кубиков с взаимосвязями, которые широко применяются почти во всех областях техники?
Очень просто: в каком-нибудь Боинге количество разных видов деталей — несколько десятков тысяч. В вашем смартфоне отдельных процедур — несколько миллионов (недавно как раз запускал Vulkan CTS… 285 388 тестов — и это только один компонент, хотя и довольно сложный). Проектирование самолёта — занимает лет 10, написание операционки для сматрфона — года 2-3… вот и всё.

На Земле просто нет достаточного количества конструкторов, чтобы писать код «обычными способами проектирования систем из кубиков» — а даже если кто-нибудь и смог создать мега-корпорацию с десятью миллионами конструкторов, то разработка занаяли бы столетия… потому приходится придумывать что-то и обходиться без формальной верификации, да…
-1
обрабатывают десятки тысяч сообщений в секунду, запускают тысячи потоков, рендерят 3D

А это всё точно благодаря софту, а не железу, делается? Некоторый современный софт даже миганием курсора способен проц на 10% загрузить.


задачи, которые решают «эти наши» Windows/Linux

Рисовать красивые карты/MFD/будильники софту современных самолётов тоже приходится. В риалтайме. Без продёргиваний.


я вас разочарую: если задачи у вас на несколько порядков проще, чем в любой 3D игрушке

Я вас разочарую: программирование взаимодействий 3D-объектов и анимации во большинстве случаев тоже визуально делается.


Вымрут динозавры — и эпоха завершится

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


в каком-нибудь Боинге количество разных видов деталей — несколько десятков тысяч

В B787 Dreamliner — 2.3 миллиона деталей, например. Это самолёт средних размеров.


В вашем смартфоне отдельных процедур — несколько миллионов

В самолёте бортовые компьютеры тоже есть, если что.


написание операционки для сматрфона

А сколько лет заняло бы написание операционки, если за каждый мелкий баг можно было бы вылететь с позором из бизнеса или даже отъехать на зону?


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

Зато есть достаточное количество "конструкторов", чтобы выпускать новые версии какого-нибудь Word с перетасованными кнопками. Поюзайте софт 90-х — с тех пор мало что качественно изменилось, разве что памяти он стал жрать на порядок больше.

+3
А это всё точно благодаря софту, а не железу, делается?
Даже самое мощное железо абсолютно бесполезно без софта, который правильно и эффективно использует его возможности.
Некоторый современный софт даже миганием курсора способен проц на 10% загрузить.
А некоторый нет. И что?
Осталось только выяснить, кто тут динозавры — с учётом нынешней популярности функциональого и реактивного подходов, которые по-сути те же кубики, только текстом.
«А мужики-то не знали!» (с)
Функциональный подход, так-то, по сути дела растет из математики, которая изначально текстовая, за исключением отдельных глав, если так можно выразиться. А реактивность лишь инструмент, помогающий в определенных задачах натянуть функциональщину на реалии компьютерной техники.
Поюзайте софт 90-х — с тех пор мало что качественно изменилось, разве что памяти он стал жрать на порядок больше.
Я помню те времена. Некоторый софт изменился, очень сильно, и в лучшую сторону. Некоторый особо не поменялся, но стал просто удобнее.
-2
бесполезно без софта, который правильно и эффективно использует его возможности

Вот с этим у современного софта очевидные проблемы.


Функциональный подход, так-то, по сути дела растет из математики, которая изначально текстовая

Систему можно описать как графически, так и функциями от функций.


А реактивность лишь инструмент, помогающий в определенных задачах натянуть функциональщину на реалии компьютерной техники

Я бы сказал приблизить компьютерную технику к реальности.

+2
Вот с этим у современного софта очевидные проблемы.
Если вы под «современным софтом» считаете только «игры и сайты», или просто десктопное и мобильное ПО, то у меня возникают большие сомнения в вашей квалификации как IT-специалиста.
Я бы сказал приблизить компьютерную технику к реальности.
Вы не с той стороны подходите к реальности. Реальность информационных технологий — она в логических вентилях, ячейках памяти и электрических импульсах и зарядах, которые заставляют всё это работать так, как оно работает. А всё остальное уже — это как раз-таки попытки эмулировать модели реальных объектов и процессов окружающего мира с помощью алгоритмов и структур для этих самых логических элементов и ячеек памяти.
Ну, может быть, когда-нибудь еще квантовые компьютеры достигнут успехов в развитии и станут использоваться более обширно.
-1
под «современным софтом» считаете только «игры и сайты», или просто десктопное и мобильное ПО

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


Реальность — она в логических вентилях, ячейках памяти и электрических импульсах и зарядах

Которые никому не нужны, если Вася не сможет закачать котиков или Маша не сможет провести платёж.

+1
Представьте себе, она нужна была даже тогда, когда Маша проводила платеж с помощью поездки в банк (а Даша из банка — проводила платеж почтой). А Вася не то что котиков не закачивал — а таблицами Брадиса пользовался. причем успешно.
0
Окей, если хотите академичненько: реальные процессы хорошо описываются во временной области, для которой как раз подходят все эти data-flow диаграммы — отсюда их популярность в реальных штуках типа самолётов, радио и электростанций.

С другой стороны современные популярные языки программирования являются потомками FORTRAN и Algol, которые создавались, чтобы крутить формулы и алгоритмы, соответственно для описания процессов из реального мира с событиями, реакция и потоками данных во времени к ним приходится как-то прикручивать реактивность и функциональность — то есть опять-таки data flow, только описанный в совместимой манере.
+2
я вас, наверное, расстрою — но формулами и алгоритмами описывали процессы реального мира.
и «все эти data-flow диаграммы» — всего лишь другое отображение формул. Для тех, кому проще работать с таким методом отображения.
0
формулами и алгоритмами описывали процессы реального мира

А Fortran и Algol предназначались для последовательного скармливания этим формулам цифр для расчёта. Поэтому в них и им подобных современных языках есть понятие и семантика вызова функции и последовательного выполнения, но семантика параллельного выполнения или событий эмулируется через те же вызовы функций. В блок-схемах и текстовых языках, которые их описывают, блоки существуют параллельно и всегда реагируют на входные значения, в императивных языках это всё реализуется через циклы, потоки и прочие сложности, которые конфликтуют с изначально заложенными концепциями последовательного исполнения и состояния.

0
Это всего лишь вопрос языка.
во времена фортранов и алголов комптютеры были «однопоточными». современные — многопоточные. и как бы вы красиво не описывали в блок-схемах параллельное выполнение — оно может быть параллельным только в некоторых пределах, определяемых «железом»…
0
Поэтому в них и им подобных современных языках есть понятие и семантика вызова функции и последовательного выполнения, но семантика параллельного выполнения или событий эмулируется через те же вызовы функций.
Нет, не поэтому. А потому что процессоры исполняют операции последовательно.

В Verilog, который тоже вполне себе текстовый, всё происходит параллельно.

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

в императивных языках это всё реализуется через циклы, потоки и прочие сложности, которые конфликтуют с изначально заложенными концепциями последовательного исполнения и состояния.
Так SCADE или интерпретатору FBD приходится делать то же самое — причём они делают это куда менее эффективно.
0
процессоры исполняют операции последовательно

Процессоры уже много лет как многоядерные.


В Verilog, который тоже вполне себе текстовый, всё происходит параллельно

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


Так SCADE или интерпретатору FBD приходится делать то же самое — причём они делают это куда менее эффективно

Как я уже сказал, процессоры уже давно научились в параллелизм.


Они пришли к SCADE потому что им нужно решать простые задачи максимально надёжным образом

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


А вот уже для самоуправляемых автомобилей — нет

Тут в комментах один товарищ уже писал, что текстовое программирование не справилось даже с ЭБУ — когда адептов текстовых редакторов уволили — сэкономили кучу ресурсов. Потому как разработка ПО и программирование — это не одно и то же.

+2
с которого чуть ли не каждый месяц утекают персональные данные миллионов пользователей… Или ПО для шифрования с уязвимостями типа Heartbleed.
Вы так говорите, как будто 20 лет назад не было проблем с безопасностью в ПО. А вот и нет. Всё было гораздо хуже. Просто сети были еще не настолько развиты. Но тех историй, что были, хватало. Даже более того, если бы современный софт делали по тем же канонам и с таким же отношением к безопасности, что и в 90-х годах, то сегодня были бы не единичные случаи сливов и уязвимостей, а давно бы настала катастрофа.
Которые никому не нужны, если Вася не сможет закачать котиков или Маша не сможет провести платёж.
Которые и нужны как раз для того, чтобы Вася мог смотреть котиков, а Маша проводить платежи. Причем быстро, удобно, безопасно, и за разумные деньги.
Разговор не про сами задачи, разговор про инструменты для решения этих задач. Когда это электронный вычислитель из кремния — языки описания задачи будут одни. Когда это квантовый компьютер — другие. Когда это специально обученный человек-курьер, бегающих с деньгами или доставляющий фотоальбом с котиками, язык описания задач тоже будет отличаться. А вы же пытаетесь инструмент для описания задач малограмотному курьеру с 9 классами образования использовать для электронного вычислителя.
-1
20 лет назад не было проблем с безопасностью в ПО

А формальной верификации как не было, так и не появилось. Качественно ничего не поменялось в мейнстриме.


Причем быстро, удобно, безопасно, и за разумные деньги

Ну вот мы и наблюдаем теперь прикручивание реалий из мира в языки, основанные на FORTRAN и Algol — в виде функционального и реактивного программирования.

+3
А формальной верификации как не было, так и не появилось.
Вам выше уже вполне четко объяснили, почему именно. Где это было экономически обоснованно — там появилось, где нет — там нет. Да и понятие «информационная безопасность» в мире ПО ей далеко не ограничивается.
Качественно ничего не поменялось в мейнстриме.
Если вы не хотите это видеть, это не значит, что этого нет.
Заголовок спойлера
image

Ну вот мы и наблюдаем теперь прикручивание реалий из мира в языки, основанные на FORTRAN и Algol — в виде функционального и реактивного программирования.
Прикручиваются только их отдельные элементы, которые удобно вписались, а основу оставляют ту, которая и была. А чисто функциональные языки так и остались малоиспользуемыми за исключением отдельных узкоспецифических ниш.
+1
Где это было экономически обоснованно — там появилось

А ещё её не появилось там, где производителю плевать — пипл и так схавает. Речь в статье не о том, что фрилансер Валя не использует SCADE для формальной верификации сайтов-визиток производителей туалетной бумаги, а о том, что раз она это не использует, то оно и не нужно в принципе (кроме "некоторых отраслей"), потому что ещё диды завещали ООП, юнит-тесты и diff.


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


Там, куда индустрия движется, вполне обосновано применение графических описаний в том числе — как я это, надеюсь, смог показать на примере того же Boeing и Airbus (Airbus сделал первый пассажирский самолёт с компьютером ещё в 1980-х, так что в плане IT авиация — передовая отрасль).

0
так что в плане IT авиация — передовая отрасль
В какой-то мере может и да, но в остальном нет. Наоборот, в IT-плане отрасль очень консервативная, настолько консервативная, что кому-то даже сложно будет себе представить.
Да, этому есть весомые причины. Но называть разработку авионики «передовой в IT» я бы в здравом уме не стал.
0
отрасль очень консервативная

И тем не менее они применяют гораздо более продвинутые инструменты и методики типа той же формальной верификации, чем условный среднестатистический модный фуллстек с его реактом (концепции которого уже ~30 лет) и юнит-тестами (верим, что алгоритм работает как надо, если он работает на этом списке граничных значений и никто не жаловался).

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

Более надёжными? Да, наверное? Но и более ограниченными…
0
решить меньше задач и с гораздо большими затратами

Откуда такой вывод?

0
Вот про граничные значения вы зря. Юнит тесты уже давно не только про это. Возьмите например scala check (или его прародителя QuickCheck), ну так, в качестве примера. Или property based testing, в целом. И между прочим, это 1999 год.
+3
посыл в том, что текстом можно выразить гораздо больше, лучше, точнее и компактнее.
Графическое представление позволяет человеку оценить некий предмет гораздо быстрее. но для точного определения все равно потребуются текстовые описания.
именно поэтому для проектирования «в целом», на уровне взаимосвязей подсистем — графические представления применимы. а на уровне детального описания — они громоздки.
+3
Посыл статьи в том, что графическое описание программ — фигня, потому что на нём плохо описываются любимые автором паттерны ООП и прочие традиционные подходы, при этом у автора не возникает мысли, что эти традиционные подходы, возможно, не самый лучший способ программирования.
А какой ещё способ программирования вы знаете? Тот же самый SCADE, вокруг которого вы подняли столько шума — это всего-навсего графическая оболочка для тех, кто не освоил Lustra. А построен он поверх, вы не поверите, нифига не верифецированных C++ и/или Ada.

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

Но они ни в коем случае не может выступать как что-то самостоятельное. Так, в частности, мне не известна ни одна среда графического программирования, которая сама была бы написана на подобном же языке — это всегда такая маленькая примочечка сверху над кучей года, написанного традицонным способом. Ни одного исключения мне неизвестно.
0
от же самый SCADE, вокруг которого вы подняли столько шума — это всего-навсего графическая оболочка для тех, кто не освоил Lustra

A Lustre program is a series of node definitions. То есть те же блоки и стрелки, только текстом. Специально для любителей diff, но ООП отдыхает.


А построен он поверх, вы не поверите, нифига не верифецированных C++ и/или Ada

"Поверх" — это в смысле "написан на них"? Или в смысле "поддерживает кодогенерацию в [верифицируемое подмножество] C++ и/или Ada"?


где вы не можете найти нужных специалистов, могущих написать программу

А "нужный специалист" — это какой? Который перенесёт спецификацию в программный код быстрее, чем это сделает SCADE или Simulink?


мне не известна ни одна среда графического программирования, которая сама была бы написана на подобном же языке

Вы слишком фиксируетесь на "графический vs. текстовый язык", это всё — разные способы представления одного и того же. Графический язык удобен на системном уровне, текстовый — для написания чего-то эквивалентного математическим формулам, например.

+1
А построен он поверх, вы не поверите, нифига не верифецированных C++ и/или Ada
«Поверх» — это в смысле «написан на них»? Или в смысле «поддерживает кодогенерацию в [верифицируемое подмножество] C++ и/или Ada»?
Я так понимаю — в случае со SCADE он и написан и кодогенерирует. Второе, впрочем, не критично, можно тот же LLVM просто в среду влинковать.

А вот так, чтобы подобное писалось без ООП — такого я не знаю.

где вы не можете найти нужных специалистов, могущих написать программу
А «нужный специалист» — это какой? Который перенесёт спецификацию в программный код быстрее, чем это сделает SCADE или Simulink?
Который может написать программу вместо того, чтобы тратить время на создание спецификаций.

То есть если у вас спецификация — неотъемлемая часть рабочего процесса (из-за требований сертификации или по иной причине), ничего страшного в графических примочках нет.

Вот только далеко не всегда люди могут себе позволить роскошь написания спецификации.

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

Однако не всё, что можно записать в виде текста, можно изобразить в виде обозримых графиков.
+1

Java, как и многие современные языки, написана на C++, кодогенерирует в JIT, потом в ASM. Что это доказывает?


А вот так, чтобы подобное писалось без ООП — такого я не знаю

Когда-то ООП тоже было игрушкой для симуляции, не прошло и 40 лет — как получило широкое распространение.


Который может написать программу вместо того, чтобы тратить время на создание спецификаций

Такой подход для сайта-визитки подойдёт (пока его хакеры не крякнут). Если проект посерьёзнее и у вас один человек — ему просто придётся и писать спецификацию, и программировать.


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

Если спецификация формально не описана — это не значит, что её вообще нет. Поэтому хорошо бы, чтобы спецификация автоматически преобразовывалась в код и документацию.


не всё, что можно записать в виде текста, можно изобразить в виде обозримых графиков

Например?

+1
Java, как и многие современные языки, написана на C++, кодогенерирует в JIT, потом в ASM. Что это доказывает?
Java-компилятор и среда таки написаны на Java. А что JIT написано на C++ — это показатель того, что да, Java хуже подходит для написания низкоуровневого кода.

Однако чисто теоретически написать JVM как Java class, выплёвыващий готовый JIT — я могу (ничем принципиально от Go не будет отличаться).

Когда-то ООП тоже было игрушкой для симуляции, не прошло и 30 лет — как получило широкое распространение.
Не совсем так. Все «большие» операционки всегда пишутся с использованеим ООП. Даже MS-DOS начиная с версии 2.0.

Просто не всегда это делается на ООП-языках.

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

Если спецификация формально не описана — это не значит, что её вообще нет.
Ну если рассматривать код в качестве специкации, тогда, наверное, да.

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

Например всё ту же SCADE. Почему она написана на ООП-языке?
-1
Однако чисто теоретически написать JVM как Java class, выплёвыващий готовый JIT

Чисто теоретически всё тоже самое можно написать на чём угодно.


Все «большие» операционки всегда пишутся с использованеим ООП

MS-DOS написана с инкапсуляцией, полиморфизмом и наследованием? Точно также можно натянуть сову на глобус и сказать, что они написаны в функциональном стиле: "объекты" — всего-лишь аргументы функции в конце-концов.


никакой спецификации там нет

Может ещё и юнит-тестов нет?


Почему она написана на ООП-языке

Наверное потому, что ООП подходит для создания пользовательского интерфейса также, как C++ — для создания JVM? И потому, что гомоиконичность целью не была.

+1
MS-DOS написана с инкапсуляцией, полиморфизмом и наследованием?

А они-то тут причём? Может хватит тиражировать идиотизм, что ООП это про них?
+1
ООП, может, и не про них, но любая операционка, кроме самых примитивных — таки да.

Если у операционки есть драйвера (а если операционка не заточена строго под фиксированное железо без этого не обойтись), то у них будет абстрактный интерфейс и реализация, вся логика будет в них инкапсулирована и так далее.
0
А про что тогда? Расскажите, что «не идиотизм» про них.
Только учтите, что контекст — процедурное написание в однонитевой среде (соответственно, ООП стиля «рыбы в аквариуме», как в Simula и Smalltalk, не годится).
0
А про что тогда?

Побуду Капитаном Очевидность: про объекты, которые имеют внутреннее состояние и внешний интерфейс. Наследование и полиморфизм — штука полезная, но не обязательная — встречались языки без наследования и практически без полиморфизма (не считать же таковым позднее связывание?), приходилось крутиться.
Без инкапсуляции ООП, пожалуй, не выйдет, — она древнее.
+1
MS-DOS написана с инкапсуляцией, полиморфизмом и наследованием?
Именно так. Абстрактное устройство «диск» может иметь много реализаций: сетевой диск, электронный диск, CD-ROM и так далее.

Там у вас «классика жанра»: интерфейс, реализация и всё в этом духе. И в любой ОС, умеющей работать с железом, которого нет в момент её создания так же будет.

Наверное потому, что ООП подходит для создания пользовательского интерфейса также, как C++ — для создания JVM?
Тогда что это за «более передовые методы», которые, оказывается, простых вещей не позволяют сделать?
0
Также можно спросить, зачем эта Java, если её нужно писать на C++.

С другой стороны — что такого магического в ООП, что оно непременно нужно для написания графического интерфейса? Есть ведь и функциональные фреймворки, так что каких-то принципиальных ограничений тут нет. Просто вопрос сложившихся подходов в индустрии.
0
> MS-DOS написана с инкапсуляцией, полиморфизмом и наследованием?

1. MS-DOS сложно отнести к «большим» операционкам.

2. На самом деле, таки да. Потому что когда вы зовёте write (через какой-то вариант int 21h с конкретным AH) у конкретного хэндла, это инкапсуляция, потому что вам недоступны внутренние структуры напрямую, лишь через хэндл, и полиморфизм, потому что вы зовёте его универсально для файла на локальном диске, файла по SMB и вывода на экран.
Наследование, да, в этих реализациях обычно не присутствует, или очень урезанно. Но остальные два компонента есть в полный рост.

И это никак не «сову на глобус». Хотя именно у MS-DOS это слегка сбоку от основной логики (позаимствовали механизм из Unix, хоть и заметно испортили).
+1
В B787 Dreamliner — 2.3 миллиона деталей, например. Это самолёт средних размеров.
А в процессоре какого-нибудь iPhone — 10 миллиардов транзисторов. А там же ещё и память есть! Там их может и под триллион быть…

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

А вот отдельных процедур в операционке — миллионы. Более того — их были сотни тысяч уже в 90е. Иначе не поставлялся бы софт на 20-30-40 дискетах — это было для производителей довольно-таки накладно.

Вот софт начала 80х — тот сравним по сложности с самолётами… ну так он и умел много меньше…
-2
А в процессоре какого-нибудь iPhone — 10 миллиардов транзисторов

Которые разводят в графическом виде.


А вот отдельных процедур в операционке — миллионы

В ядре Linux — около 400 системных вызовов. Не такие уж миллионы. А когда хотят объяснить, как это всё работает — рисуют диаграммы на системном уровне — каких, например, много в документации Apple.

+3
А в процессоре какого-нибудь iPhone — 10 миллиардов транзисторов
Которые разводят в графическом виде.
Это только в вашем воспалённом воображении их разводят в графическом виде. В реальном мире существует Verilog и прочие разные HDL — такие же текстовые, как и языки программирования (хотя и со своими особенностями).

В ядре Linux — около 400 системных вызовов.
Вот только за многими из них стоят тысячи операций. Или вы хотите сравнить сложноть болтика или какого-нибудь элерона с каким-нибудь clone с десятком видов неймспейсов?

А когда хотят объяснить, как это всё работает — рисуют диаграммы на системном уровне — каких, например, много в документации Apple.
Вот только все эти диаграммы, как правило, оказываются весьма и весьма упрощённым описанием реальности. Потому что если все детали в неё засунуть — её понять будет нельзя. И опять-таки, для clone вы получите несколько дюжин диаграмм — на каждый флаг плюс на некоторые «интересные» сочетания. Но чтобы понять всё до конца — всё равно придётся смотреть в исходники.
+3
В реальном мире существует Verilog и прочие разные HDL — такие же текстовые, как и языки программирования (хотя и со своими особенностями).
— более того, у них есть возможности верификации. В отличие от «графического вида»
0
у них есть возможности верификации. В отличие от «графического вида»

Data flow легко представляется в функциональном виде и формально верифицируется, как в SCADE — в отличии от паттернов ООП и прочих завещанных дидами методик программирования, за которые топит автор статьи.

0
Вот только с помощью ООП SCADE создать можно, а с помощью data flow — чёт не получается. Во всяком случае никто не сделал.
0
Без графического языка GUI (с кнопками, меню, блоками) ООП не помогло бы.
+1
Драконисты очень сильно нахваливают возможности своего дракона. но пишут свои поделки почему-то не на драконе…
Лабвью — неплохая система. но писана почему-то на «завещаных» методиках, но не на себе, новомодной…
0

Java написана на C++, а не на Java. Движки JavaScript пишут на C++, а не на JavaScript. Python написан опять на C++, а не на Python. Почти все высокопроизводительные библиотеки к ним написаны на C++. Вывод — С++ единственный нужный язык программирования?:)


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

+1
Java написана на C++, а не на Java
Компилятор Java написан-таки на C++.

Вывод — С++ единственный нужный язык программирования?:)
Нет. Go написан на Go и C++ не требует. Тоже самое с FPC.

И даже Java-машину можно написать на ассемблере и в комплекте с Java компилятором — это будет рабочая система.

При этом все используют как минимум один графический язык для описания интерфейса...
Называть «языком» пассивный XML, гда написано какие кнолпочки где находятся — как-то странно.

Впрочем при желании всё те же самые кнопочки можно и вызовами функций создать, XML тут необязателен.
+1
нет. Вывод другой: на графических языках нельзя создать ничего серьезного — это потребует слишком много ресурсов.
второй вывод — все Джавы/Джаваскрипты/Питоны — это надстройка для того, чтоб не писать на С++. Можно рассматривать как библиотеку, можно как кросс-компилятор. Этакое «средство для упрощения жизни». Утрированно, конечно.
Ну и xml, как вам справедливо заметили ниже — ничуть не графический язык, а совершенно текстовый. То, что описанное на нем можно представлять в т.ч. и в графическом виде — не делает его графическим.
0
на графических языках нельзя создать ничего серьезного — это потребует слишком много ресурсов

Это следует из?...


Ну и xml, как вам справедливо заметили ниже — ничуть не графический язык

Графический язык — это кнопки и меню, а на низком уровне это всё равно не текст, а нолики и единички, раз уж на то пошло, как и всё остальное. И даже промежуточное представление — не обязательно XML: WYSIWYG ещё до XML появился на самом-то деле.

+1
И даже промежуточное представление

ну вот это промежуточное представление и является языком, который «описывает кнопки и меню».
Реализовано ли оно в виде , class Button или @nCol, nRow Say — уже не важно. Важно, что оно точнее, им можно манипулировать, его можно создать без графического представления на этапе создания.
0
можно создать без графического представления на этапе создания

Можно всё, но это не значит, что это удобно делать.

+1
Это следует из?...

Из того, что мышкой работать труднее и медленнее, чем пальцами.
0

А потом 50% ресурсов и более тратится на тестирование и отлов багов, внесённых быстрыми работниками пальцами.

+1
И всё равно общее время меньше, чем если сперва тыкать мышкой, а потом искать, где не так натыкал.
0
А ещё нужно делать спецификацию, потому как в ответственных областях эксперт и программист — разные люди. А потом третий человек будет писать тесты, которые по определению не полны.
0
Если спецификацию разрабатывает другой человек, а тесты пишет третий — то у непосредственного программиста отлов багов времени практически не займёт. Вообще становится непонятно, зачем он нужен: почему бы «эксперту» не написать спецификацию сразу в виде кода (код — это же и есть предельно подробная спецификация).
0
почему бы «эксперту» не написать спецификацию сразу в виде кода

А тестировать потом этот код на основании чего будете?

0

На основе требований и результатов эксплуатации предыдущих версий или аналогов, например. V-model в помощь.

0
В предлагаемом мной варианте спецификация и код — тождественны.
0
Это было бы хорошо, если бы существовал полностью абстрактный код. А так пока не получается абстрагироваться от деталей реализации, которые замусорят спек. Я думаю не случайно Boeing и Airbus пришли к SCADE.
0
Я думаю не случайно Boeing и Airbus пришли к SCADE.
Они пришли к SCADE потому что им нужно решать простые задачи максимально надёжным образом.

Для них — это нормально. Среда, в которой «работает» самолёт — крайне проста (на самом деле нет, но все эти системы, созданные на SCADE, как раз сложные ситуации типа «мы попали в крайвой вихрь от A380» обрабатывают), а цена ошибки — очень высока.

В этой ситуации наглядные графические средства — могут иметь смысл.

Похожая ситуация также с АЭС (там тоже сложных ситуаций, где нужна мгновенная реакция на сложные исходные данные просто избегают) и некоторыми другими вещами.

А вот уже для самоуправляемых автомобилей — нет, потому как вся конструкция гораздо сложнее и в графические среды «не лезет».
0
«Java написана на C++, а не на Java. Движки JavaScript пишут на C++, а не на JavaScript. Python написан опять на C++, а не на Python.» — это минус этим языкам, значит серьёзные, высокопроизводительные проекты на них нельзя написать. C# написан на С#, Delphi написан на Delphi.
0
> C# написан на С#

Нет. Вот если бы машинный код его рантайма генерировался кодом на C#, вплоть до выходных бинарников — это было бы правда.
Сейчас это только полуправда — компилятор IL работает на C#, но дальше включается нижний уровень.

То же для Delphi.

> значит серьёзные, высокопроизводительные проекты на них нельзя написать

Ничего не значит. Реализация на себе же — достаточный, но не необходимый признак, причём _полноты_ реализации, а никак не высокопроизводительности, и тем более не какой-то неконкретной «серьёзности».

Рекомендую прекратить откровенные подтасовки, не получится.

> Python написан опять на C++, а не на Python

PyPy, к слову, существует давно и достиг вполне промышленного качества. Он не имеет собственный бутстрап вплоть до генерации бинарников, но такая задача и не ставилась.
0
Нет. Вот если бы машинный код его рантайма генерировался кодом на C#, вплоть до выходных бинарников — это было бы правда.

Почему вы так считаете? C# преобразуется в IL, IL преобразуется в машинный код, машинный код интерпретируется процессором переводя его в микрокод.


Почему "C# написан на С#" должно обозначать что-то кроме первой фазы?


см, кстати, статейку про то, какие усилия идут в этом направлении, но это не будет "C# на C#", это будет "IL на C#".

0
Delphi написан на Delphi.

IDE некоторых версий — возможно.
Компилятор написан точно на C.


Но все же паскаль использовался для написания компиляторов.
На объектном паскале написан компилятор FPC.

0
IDE некоторых версий — возможно.
Насколько я знаю все Delphi IDE написаны на Delphi. Правда, в новых средах кода Delphi там не 100%.
Lazarus/FPC написан полностью на pascal. Компиляторы, среда. Среда, к слову, работает, в отличие от Delphi прямо по месту — Линукс, МакОС, Распбери. Работает почти на любом железе и операционках.
0
> Java написана на C++, а не на Java. Движки JavaScript пишут на C++, а не на JavaScript.

На самом деле это в чистом виде проблема бутстраппинга компилятора, а не самого языка. Сделать реализацию рантайма в машинном коде, который дальше запустит основной движок, который будет в состоянии компилировать и исполнять код на таком же языке — концептуально тривиально, и есть практические примеры перед глазами — Go создаёт свои бинарники сам, компилятор написан на том же Go, в Erlang часть сборки выполняется готовым кодом на Erlang. В случае managed языков (Java, Javascript...) потребуется прослойка unsafe-управления памятью, но она опять же может быть скомпилирована кодом на этом же языке.
Мешает этому лишь то, что аналогичная среда на C/C++ уже давно сделана, вылизана в деталях и мало кому хочется повторять этот путь и дублировать усилия.

И для графического языка было бы то же самое. Но — это значит, что он должен быть таким, чтобы уметь описать всё вплоть до команд ассемблера какого-нибудь аналога crt1.o (то, что в Unix подходе стартует первым в запущенном процессе и готовит среду для libc и main(), настраивая стек, формируя параметры argc/argv, и так далее). И к обычной сложности (не уровневой, а просто множества сущностей) добавляется ещё один очень специфический слой, потребность в котором у 0.0001% юзеров, а работы — много. Поэтому всем обычно облом, и используют C как базу.
+2
Об чём и речь. Компилятор Java — написан на Java. Компилятор C# — на C#. Компилятор C — на C, а компилятор C++ — на C++. И даже FPC написан на Pascal!

А вот как берёшь Дракон, LabView, SCADE и прочее — так почему-то выясняется что нужен C++, Java или C#, но никак не Дракон, LabView или SCADE.

Это ни в коем случае не значит, то это плохие и бессмысленные вещи. Всего лишь значит, что они — не универсальные, вот и всё.
-3
В реальном мире существует Verilog и прочие разные HDL

А потом приходит добрая фея и делает layout, ага.


Вот только за многими из них стоят тысячи операций

400*1000 — всё равно меньше, чем деталей в Boeing. А в Boeing ещё три компьютера и софт, и всё это гарантированно работает, а не как в Linux "DELIVERED AS IS, USE ON YOUR OWN RISK, THE DEVELOPER CAN'T BE HELD ACCOUNTABLE etc.".


если все детали в неё засунуть — её понять будет нельзя

В main тоже "все детали" никто не засовывает, засовывают только вызовы функций (= блоки) и переменные (= провода). Это всё эквивалентно, но на высоком уровне граф понятнее, чем страница текста или, хуже того, список файлов. Что-то типа математических формул проще писать текстом — это понятно.

0
но на высоком уровне граф понятнее, чем страница текста

Граф, который понятен — эквивалентен максимум десятку строчек текста.
0
Нагуглите схему, например, радиоприёмника, а затем опишите её на C++.
+1
Описывали. и что? И даже не на С++, а на фортране.
Кстати, в матричном виде ошибки вычисляются очень легко.
А теперь к вам встречное предложение — нарисуйте в графическом редакторе схему усилителя, и постройте его АЧХ.
0

И то, что текстовое описание на языке типа C++ менее прозрачно и требует введения ненужных переменных.

0
Смотря для чего ненужных. и смотря для кого менее прозрачно.
И да, вы по рисунку АЧХ построите? а я вот по матричному описанию и ошибки найду, и спаяю, и ахч построю.
0
проектирование на системном уровне не подразумевает характеристик системы и подсистем? Или вы характеристики системы тоже рисуете? Или для вас «системный уровень» — это квадратик с надписью «приемник»?
0
Я бы описывал иерархически — сначала структурную схему типа вот этой:
image

потом детализироовал каждый блок.
0
Ну ок. Есть языки описания данных. XML как пример. Схема радиоприемника — графическое представление данных. Можно закодировать данные с виде обьектов С++? Почему бы и нет, но зачем это может понадобиться? Можно изготовить радиоприемник только по его схеме? Ответ нет. Нужен еще как минимум сборочный чертеж, и не один.
Есть языки для обработки данных. В случае радиоприемника — это технологические карты для его производства. На С++ можно описать последовательность инструкций для изготовления радиоприемника?
+2
«только по схеме» изготовить можно. почему нет?
более того, мы умудрялись «передавать схему по телефону». два больных (простывших) юных радиолюбителя, паять можно — на улицу нельзя. Одному журнал пришел, второму еще нет. а схема интересная. И «время зря пропадает»…
0
Вымрут «динозавры» ;) Это ж вряд ли, пока формальные методы анализа и верификации могут давать гарантии для конечных автоматов, и будут жить ДРАКОН, IBM Rational Real-time и прочие, прочие в наших и ихних космических программах и промышленности.
0
Про вымрут — я говорил в самом прямом, а не переносном смысле. Все эти Драконы и Rarional Real-time имеют смысл пока людей, умеющих программировать, не хватает на все конструкторские места. А не хватает их — ровно пока у нас нет кризиса и безработица низка.

Один-два полномасштабных кризиса уровня «Великой Депрессии» — и динозавры вымрут.
0
Вы исходите из неверной предпосылки, что языки визуального программирования предназначены для «программистов», которые не умеют програмировать. ;)

Но это не так. Они, ДРАКОН, IBM Rational Real-time и т.п., ориентированны на весьма квалифицированых программистов, в частности, требуют владения C/C++/Python в совершенстве.

У них фишки совсем в ином. Задачи управления механикой, пилотирования и пр. в реальном времени формулирутся, верифицируются и тестируются в концепции конечных автоматов, функций управления, с одной стороны. Да и подход к повторному использованию кода там существенно отличается, с другой стороны.
+1
на языках визуального программирования типа Simulink и SCADE вполне успешно делают safety-critical проекты вроде ПО авионики самолётов
но при этом же, при разработке ПО авионики самолетов ничуть не меньше прекрасно используют C++, посмотрите, например, стандарты DO-178B и DO-178C (КТ-178В), или например стандарт JSF++, названный так по имени проекта разработки истребителя-бомбардировщика F-35.
Про Ada (классический текстовый язык) и говорить нечего — например, на нем написан практически весь набортный софт Boeing 777.
0
DO-178B описывает процессы и подходы. JSF++ — да, уже ближе. С другой стороны, F-35 оказался самым дорогим проектом многоцелевого истребителя в истории, в котором находили баги даже после принятия в эксплуатацию.

А софт B787, B747-8 и всех новых Airbus уже написан на SCADE, кстати.
0
DO-178B описывает процессы и подходы.
Да. И там же в статье упоминается софт для автоматизированного тестирования и верификации по этим подходам. И основные языки там — C++ и Ada.
+1
В самом конце поста — отвратительный бессмысленный опрос для галочки, создающий ощущение, что его автор даже не читал статью.
0
Тенденция повышения уровневости языка рано или позно приведет к визуальному программираванию в той или иной форме.
+1
> декупликация

Вот это IMHO уже слишком. Нет такого слова. Даже в жаргоне. Чем вас не устраивает «уменьшение связности» которое вы же и привели? Вполне устоявшийся и понятный термин.
0
А по-моему полезно давать таким новым терминам просачиваться в язык там, где с ними обоснованно удобнее.

> Чем вас не устраивает «уменьшение связности»

Длинно и неудобно для выговаривания и написания.
-1
Осталось выяснить какое отношение Scratch и аналоги имеют к визуальному программированию.

Это обычный текстовый язык, но с какими то рамочками вокруг каждого слова.
0
вообще, «слова» оттуда можно и убрать. оставить только блоки. это ничуть не затруднит детям использование этого самого скретча. Вот русскоязычные школьники совсем не понимают, что там написано — но справляются.
+2
Mike_soft
Драконисты очень сильно нахваливают возможности своего дракона. но пишут свои поделки почему-то не на драконе

Это не так.
Степан Митькин (Норвегия, город Колсас Kolsås) разработал свой дракон-конструктор, используя язык ДРАКОН.

sourceforge.net/projects/drakon-editor/files
drakonhub.com

С уважением,
Владимир Данилович Паронджанов
Mobile: +7-916-111-91-57
Viber: +7-916-111-91-57
E-mail: vdp2007@bk.ru
Skype: vdp2007@bk.ru
Website: drakon.su
Webforum: forum.drakon.su
+2
Да он тут давно уже. и «Будущее во врачебном деле за ДРАКОНом», и «Будущее в патентном деле за ДРАКОНом», ну и «программирование без программистов», конечно, куда ж без этого.
(хотя на хабре он так не заявлял, но на других ресурсах...)
+1
Зато Тышов не смог. Ну да ладно — пусть развлекается.
все равно практического применения кроме «голоден-свари себе каши» не будет.
-3
Хорошая попытка ретрограда вставить палки в колеса.
Человек мыслит образами, и визуальные языки — это попытка приблизить программирование к образному мышлению, это следующий эволюционный шаг, как в свое время языки высокого уровня были попыткой приблизить программирование к человеческому языку или к формальному языку.
+5
Человек мыслит образами

А наиболее абстрактный образ — это слово.

Человек либо хорошо излагает свои мысли словами, и тогда ему не трудно описать их на любом языке, либо сам не понимает чего хочет, и тогда от его образов никакого толку.
+2
Вообще-то он словами мыслит. Если бы он мыслил образами, чтобы сказать «палка» ему надо было бы представить себе палку. Это очень долго. Собственно визуальные языки и являются «долгими», это их проблема.
0
Mike_soft
на языке ДРАКОН можно делать лишь «поделки», «что называется, упаси господи»

Это не так. На визуальном языке ДРАКОН делаются серьезные вещи.
Вот две статьи, где говорится про применение языка ДРАКОН в серьезных космических проектах:

1. Морозов В. В., Трунов Ю. В., Комиссаров А. И., Пак Е. А., Жучков А. Г., Дишель В.Д, Залихина Е. Е., Паронджанов В. Д. Система управления межорбитального космического буксира «Фрегат» \ Вестник ФГУП «НПО им. С. А. Лавочкина», 2014, № 1. — С. 16-25.
bit.ly/2RtCdaU

2. Паронджанов В.Д. Визуальный алгоритмический язык ДРАКОН в ракетной технике и
медицине // Современные автоматизированные системы управления реального
времени как прикладное развитие научных достижений кибернетики» (К 100-летию со
дня рождения И.А. Полетаева). Материалы межведомственной конференции 24
марта 2016 г. — ФГБУ «3 ЦНИИ» Минобороны РФ, 2016. — 218 с. — С. 57-78.
bit.ly/2BDhYCB

Вот еще одна статья, где речь идет о применении языка ДРАКОН в Немецком космическом агентстве (German Aerospace Agency).

Marc Schwarzbach, Sven Wlach, Maximilian Laiacker. Modifying a Scientific Flight Control System for Balloon Launched UAV Missions // German Aerospace Center DLR // IEEE, 2015.
drakon.su/_media/ballon_ap_final.pdf
+1
трансляторы есть. но на результат «трансляции» лучше смотреть сидя или лежа.
вообще, лучше всего знакомиться именно с проектами, ссылки на которые регулярно дают Паронджанов или Тышов. это как раз из принципа «с такими друзьями и враги не нужны».
ну, можете еще ознакомиться с системой Графит-Флокс. Видимо, из-за ее наличия в Лавочкине — «у буржуев» Куриосити на Марсе, а «у нас» Фобос-В-Грунт…
0
Я читал ТЗ на «Фобос» и там уже на этом уровне было «В грунт» — возможно код методы и СУ не при деле…
+2
угу.
«Так что сейчас мы живем в мире 16-символьных идентификаторов. Из которых первые шесть символов отводятся на префикс. Префикс состоит из 5-символьного классификатора и эргономичного разделителя (точки). Точка-разделитель находится в 6-й позиции.

Вопрос. Что отсюда следует?
Ответ. На смысловую часть (то есть на описание ФИЗИКИ ОБЪЕКТА) остается всего 10 символов (16 — 6 = 10).

10 символов — это очень мало. Если бы идентификатор был 24-символьным, то смысловую часть пришлось бы 18 символов. 18 символов — почти вдвое больше чем 10. Но сегодня это только мечты.

Сегодня мы живем в трудных условиях. Приходится вводить режим жестокой экономии символов. Приходится ногами утаптывать СМЫСЛОВУЮ ЧАСТЬ (символы 7—16), чтобы поместить ее в узкое горлышко из 10 символов. Это очень трудно.»
© Паронджанов. О Графит-Флоксе.
добро пожаловать в волшебный мир ДРАКОНа…
зы. обсуждается «КС1УФ.ОТКЛЮЧИТЬ.ФИДЕР.УМ1»©
0
emmibox

Вы повторяете недостоверные сведения (анекдоты), которые не имеют отношения к действительности и серьезной работе. Инженеры разрабатывают на языке ДРАКОН по методу " программирование без программистов" исходный код программы (а не картинки, как вы предположили). Прочитайте статьи, на которые я дал ссылки. После этого многие вопросы отпадут.

Вы правы, получаемая модель памяти загружается в БЦВМ (и НЦВМ) Бисер.
Именно для этого и служит дракон-технология в Роскосмосе.

Если же вы хотите работать не с Бисером, а с другим компьютером или контроллером,
надо использовать технологию Степана Митькина, как это делают в Немецком космическом агентстве (см. ссылку, которую я дал). Или технологию Геннадия Тышова. Или разработайте свою собственную.
0
Короче если я правильно понял — ответ на мой вопрос «нет».
надо использовать технологию Степана Митькина, как это делают в Немецком космическом агентстве (см. ссылку, которую я дал). Или технологию Геннадия Тышова. Или разработайте свою собственную
.
Увы это будет «велосипед». Я не могу с специально обученными людьми соревноваться.
image host

0
А что из описанных в статьях задач, нельзя выразить на традиционных языках?
«Программирование без программистов» появилось очень давно — с появлением языка Фортран, идеей которого было дать математикам возможность общаться с машиной «без этих ваших программистов, которые бубнят об адресах и переходах». Только очень быстро оказалось, что составление инструкций на Фортране — это тоже программирование. У вас — программирование на ДРАКОНе, суть та же — есть специальное знание, которым надо овладеть. Поэтому «создание программ без программиста» в этом контексте — это утопия.

Приведенные статьи не дают обзора принимаемых при создании языка решений, нет сравнения с другими инструментальными средами при решении тех же задач.
0
Нафиг не надо, вот есть у нас CRM от террасофт, там есть такое понятие как бизнес процесс, вот он как раз и базируется на методах визуального программирования. Если описывать сложные последовательности, то получается не-читаемая муть, в которой черт ногу сломит, так еще и глючно все это
0
В переводе Майк (автор оригинального текста) стал проповедующим разработчиком, хотя в оригинале an itinerant developer — странствующий, ну или путешествующий разработчик.
0
Игрушка Factorio имеет нулевой порог вхождения — это игрушка. Однако мне, devops'у с многолетним стажем, она доставляет моменты бессилия и отчаяния, потому что «ну на этот раз я всё сделаю правильно» натыкаются на постоянное желание локальной оптимизации, которая портит возможности общесистемного рефакторинга.

Программирование — сложно, software engineering — ещё сложнее.
0
Нулевой порог вхождения? Вы шутите?) Первые попытки поиграть мне дались с трудом, это наравне с изучением нового языка программирования или схемотехники — только посмотрев некоторое количество туториалов на ютубе я смог развиться до запуска ракеты. В неё играют преимущественно программисты и инженеры, у большинства остальных мозг взрывается на уровне организации нефтянки, если не раньше) Авторы сейчас предпринимают усилия чтобы упростить порог входа там, где это не скажется на геймплее, удаляя сущности, напрямую не влияющие на геймплей(кирка, множитель эффективности бойлеров), плюс перепиливают туториал.
+1
Да ладно, таториалы вполне понятные, а дальше просто надо делать автоматизацию. Подозрительно напоминает мою обычную работу, вместе с обычными проблемами (legacy vs from scratch, do it by yourself, etc).
0
emmibox
А транслятор во что нибудь кроме «бисера» (что обычный человек может руками пощупать) с него есть

Да, есть.
Посмотрите четыре видеоролика Сергея Ефанова (общая длительность 1 час).
Вот ссылка на 1-й видеоролик

Видео. Использование языка ДРАКОН для программирования микроконтроллеров. Часть 1. Разработка программы управления автоматическим дверным замком.
www.youtube.com/watch?v=Ua9dUUONjdk&feature=youtu.be

Если вам это интересно, я могу прислать вам книги по языку ДРАКОН
+1
вы для завершенности еще скиньте ссылку на Араптанова.
Чтоб все поняли, для «программистов» какого уровня необходим ваш ДРАКОН.

0
Могли бы просто дать ссылку drakon-practic.ru Да мне интересно в каком состоянии это находится сейчас, хотя бы для сравнения с другими решениями в области «визуального программирования».
+1
Почему там одно сплошное «кино»? Авторы писать не умеют? И почему «кино» запаковано в .exe? Что они курили?
0
Я думаю это какой то, свой сложный не имеющий аналогов путь… ;)
Но вообще у них там содержимое кино написано в ПДФ-ах.
0
А о визуальном программировании для ПЛИС вроде не писали? В каком-то смысле оно аналогично рисовании схем на ватмане:
image

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

Программирование под ПЛИС вообще неплохо поддается визуализации, так как там все также и работает, как мы представляем себе визуально — линия связи между блоками так и реализуется, как линия связи. Сигналы остаются сигналами. Все блоки работают параллельно и т.д.
Это ведь и немудрено — ПЛИС задумывались как замена железу, а железо изначально описывалось схемами, а не текстом. Это потом уже придумали VHDL, Verilog и т.д.


Поэтому в том же Vivado ихний Block Design был воспринят весьма положительно — намного визуальней отслеживать связи между блоками в виде линий, а не текста. Ну и возможности совершить ошибку стало гораздо меньше.

+2
Изначально программы писались текстом, а схемы рисовались. Потом схемы стали тоже писать текстом. Когда я сказал одному инженеру, что проблем с пониманием схем у меня нет, а вот с восприятием «программы» выполняющей одновременно все что написано, наверняка возникнут, и мне проще работать со схемами, он мне ответил: Зато если мне надо поменять ширину шины, я просто меняю одну цифру. Представь сколько всего пришлось бы перерисовать на схеме.
Вывод: графическое представление проще для понимания, но годится только для мелких несложных проектов. Для больших и сложных проектов лучше текст.
+2
… И вот, все программисты кончились, перепрофилироввшись в фермеров, а домохозяйка пытается понять как ей в этом визуальном редакторе набросать по быстрому блок-схему для нового айфона, чтобы хоть звонки совершал.
+1
Но ведь эта домохозяйка научилась грамоте всего лет 100-150 назад, и арифметрике тогда же. А лет 50-20 назад — водить.
+1
Зато, возможно, будет иметь куда более полезный навык для поиска по информационным системам.
0
Представь сколько всего пришлось бы перерисовать на схеме

Это если схема на ватмане? Вроде в нормальных средах шины пучком и задаются.

+1
"Нормальная среда" так же и кишки катомных блоков подключенных к этой шине изменит? Речь о программировании FPGA.
0

А как поменять кишки блоков одной цифрой в Verilog? Это разве что в специфических случаях сработает — например поменять разрядность шины.

0

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


Вопрос — кто этот человек? Ребенок? Ученый? Менеджер? Электрик/Электронщик? Домохозяйка? Трудно сказать. Но что я знаю точно — это точно не программист. И поэтому оценивать значимость и преимущества визуального программирования программистам не стоит.


А теперь по поводу кто динозавр в этом мире.
Так вот предположим, что тот самый ученый, менеджер, электронщик и домохозяйка хотят сделать так, чтобы компьютер сделал то, что им надо. Без визуального программирования у них есть два варианта — выучить язык программирования и самим сделаться программистами(что им нафиг не надо, так как у них своих проблем достаточно), либо описать задачу знакомому программисту и попросить его запрограммировать ее в компьютер для них. Но тут мы сталкиваемся с классической проблемой — само по себе такое описание, это уже полно работы, причем часто это не текст, а диаграммы состояний, блок-схемы, формулы, стрелочки связей и прочее. Иначе программист не поймет и программа будет делать совсем не то, что надо человеку, а то, что понял программист.


И тут воаля — появилось решение — визуальное программирование! Вместо того, чтобы описывать задачу программисту, ученый, менеджер, домохозяйка, ребенок, могут описать ее сразу машине, причем в той форме, в какой они сами ее понимают и машина ее выполнит! Понимаете прикол? Программист исключен! Как и исключен порядок взаимодействия — ученый, менеджер, домохозяйка -> программист -> машина, на каждом этапе которого могут появиться ошибки! А еще у нас появляется одна единственная точка правды — исходное, одновременно и машино- и человекочитаемое описание работы (в простонародье — модель), и нет никаких разногласий между ней и исходным кодом. И эту модель может прочитать не-программист и внести в нее изменения, если нужно.


Насчет того, что это годится только для описания простых процессов — это все запугивания и непонимание. У меня в работе есть модель, которая генерит примерно 200 тысяч исходных строк Си-кода. Причем это очень оптимизированный код. А разрабатывает ее один кандидат наук — специалист по автоматической теории управления плюс один специалист по силовой электронике. То, что у них в этом тандеме выходит, не осилила бы команда даже из 10 программистов, хотя они ни Си, ни микроконтроллеры вообще не знают

+3
Насчет того, что это годится только для описания простых процессов — это все запугивания программистов, которые не хотят, чтобы клиент от них ушел.

Интересно, почему же вокруг не видно миллионов инженеров, ученых, и менеджеров которые на языке схем и блоков пишут высоконагруженные сервисы для сбора и обработки данных с IoT, ПО базовых станций для операторов сотовой связи, автопилоты для автомобилей, системы диспетчерского контроля аэропортов, прошивки медицинских приборов… Это всё чисто инженерные и научные задачи, но вот почему-то за несколько десятков лет развития графических языков, эти самые языки для этих задач не используют. Интересно, почему?
-4

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

+2
Если вы их не видите, это не значит, что их нет. Просто их в этом случае надо меньше, чем обычно и работают они эффективнее, так как их идеи идут сразу в код.
Просто я за свою профессиональную карьеру имел отношение к перечисленным выше вещам, либо близко знаком с людьми, которые этим занимаются. И графическими языками там даже близко вообще не пахло.
Поэтому и было бы интересно, если бы вы привели реальные примеры таких проектов и статистику использования инструментов разработки в целом по перечисленным отраслям. Раз вы так уверенно говорите, что они есть и используются очень активно, то это должно быть просто.
Иначе это все звучит как-то не убедительно.
А там, где программисты сами придумывают новые вещи, оно не приживется, так как для них это костыли. Поэтому и вряд ли вы увидите это в IoT или на серверах, например.
В том то и дело, что это реально в первую очередь инженерные либо научные вещи. Что IoT (это по сути дела следущее поколение АСУ ТП + аналитика), что сотовая связь (радио и телекоммуникации), что автопилоты (и автомобилестроение), что медицинские приборы. Поэтому, если следовать вашим словам, там оно должно использоваться в первую очередь и вообще на каждом шагу.

Даже всевозможный банковский и биржевой софт придуман не программистами для своих нужд, а делается для экономистов и финансистов. Казалось бы, можно легко исключить прослойку разработчиков и описывать все правила движения денег и ценных бумаг графически. Почему этого не происходит?
0
Я тут уже давал ссылку на использование «визуального программирования» в 450+ миллионов ЭБУ для автомобилей. (Сейчас кстати их Симулинк вытесняет). >5тыс А4 страниц графических схем транслируются в сотни мегабайт исходных текстов на С99, и далее собирается под целевую систему (коих 10-ки очень и очень разных) — все это продолжается более 20 лет. И это то, что вы видите каждый день сотнями. И если можно говорить о каком то прогрессе в этой отрасли — то он весь суть прогресс «визуального программирования» и автоматической генерации кода! Потому, что на этом уровне сложности никакие другие методы создания ПО не применимы в принципе — вы не можете поддерживать исходник в сотни мегабайт под один единственный проект, при том, что проектов тысячи.
0
Я тут уже давал ссылку на использование «визуального программирования» в 450+ миллионов ЭБУ для автомобилей.
Спасибо за ссылку. А какой примерно процент рынка занимают эти разработки по сравнению со сделанными другими инструментами? А то будет обидно, если окажется что не смотря на красивые цифры, это все-таки далеко не самая большая часть рынка, либо подобные подходы использует меньшинство вендоров.

Ну и вопрос изначально был все-таки про немного другие проекты.
0
При текущей сложности например для ДВС-КПП ЭБУ это 100% и вариантов нет. Однако таких ЭБУ в машине 2-3 а в целом их 10-20… В мелких восьмибитках конечно еще могут, что то писать руками. Но в целом все, кто там могут, что то писать руками — HAL пишут и драйвера на железо, некогда им ерундой в userspace заниматься.
0
При текущей сложности например для ДВС-КПП ЭБУ это 100% и вариантов нет.
У Toyota, одного из ведущих автопроизводителей в мире, прошивки ЭБУ двигателя написаны на C.
0
У всех на С. Вопрос о том руками или автогенератором кода? и когда перешли на автогенерацию…

Хотя тойота отсталая… не удивлюсь если до сих пор все руками пишут…
0
А как, извините, тойота умудряется оставаться лидером рынка? Или новые, прогрессивные, методы не гарантируют создания автомобилей, которые люди будут хотеть покупать? А для чего они нужны тогда?
0
Каким лидером? — какого рынка?
Как насчет того, что тойота ЭБУ не производит — их Denso делает.

Денсо конечно игрок крупный, у меня нет достоверной информации по использованию ими MBD. Но если сложить Бош (с асцетом) и всех его лицензиатов и Континенталь-Сименс (с симулинком) и всех его лицензиатов — то это уже доля 2/3 рынка мира. Даже если предположить что Денсо там все руками пишет (что вряд ли) — технология MBD уже победила — и рыночек порешал.

Хотя я уверен что и denso MBD использует после тойотовских скандалов — японцы конечно тупые но отстают не далее 10-ти лет. А технология повсеместно используется уже 20лет.

К тому же тойота разная бывает — вся европейская тойота=бош. китайская=бош… денсо с их отсталостью это лишь американская и японская тойоты…
0
В том то и дело, что это реально в первую очередь инженерные либо научные вещи. Что IoT (это по сути дела следущее поколение АСУ ТП + аналитика), что сотовая связь (радио и телекоммуникации), что автопилоты (и автомобилестроение), что медицинские приборы. Поэтому, если следовать вашим словам, там оно должно использоваться в первую очередь и вообще на каждом шагу.

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


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

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

-3
почему же вокруг не видно миллионов инженеров, ученых, и менеджеров которые на языке схем и блоков пишут

Да пожалуйста:


Civilian programs include:
Wide-Bodied
Airbus A318 Elite, A340, A380, A350, A320 Neo
Boeing 787, 747-8
COMAC C919
Irkut-OAK MS 21
Regional
ARJ-21 (Chinese Regional Jet)
ATR 42/72-600
Bombardier CRJ 1000, C Series
Mitsubishi MRJ
Business Jets
Cessna Citation Mustang, Encore+, XLS+
Dassault Falcon 7X, Falcon SMS
Eclipse 500
Embraer Phenom 100/300
Gulfstream G280, G500, G650
Learjet 85, Learjet 200


Special Purpose
Beriev 200 (civil protection)
Helicopters
Eurocopter AS 350
Eurocopter EC135/145/155/225
Sikorsky S76D
MHI programs
KHI programs
Fuji HI programs
UAV
Watchkeeper (UK)
ANKA (Turkey)
VEGA Pipeline surveillance (Russia)
Space Systems
ESA/Astrium ARIANE 5 and 5 ME Launcher
ESA/Astrium HORACE Lander
ESA ATV “Jules Verne” Cargo System
ESA VEGA Launcher
Shenzhou System and Long March Launchers


И это только по гражданской авиации.


P.S.: печальненько видеть, как догматики от текстовых редакторов тут яростно минусуют всех, кто посмел не согласиться с их убеждениями о безальтернативности их любимых тёплых ламповых текстовых исходников. IT, которое мы заслужили :|

+3
И все-все-все пишется с нуля??? Это больше напоминает составление схемы из микросхем — большая часть работы уже сделана за тебя, тебе остается только собрать блоки в кучку, соединить их и настроить.
Только вот какая странность: инженеры-схемотехники не катят бочки на инженеров низкого уровня которые разрабатывают эти самые микросхемы. А вот приверженцы "графического программирования" почему-то это делают.
0
А вот приверженцы "графического программирования" почему-то это делают.

Откуда вы это взяли?

+2
А вот туточки:
так уж ли эти традиционные методики хороши? Может быть это «традиционные программисты», которые до сих пор кодят на вариантах Алгола и Фортрана, застряли в каменном веке?

Вы можете понять это как-то иначе?
0
не катят бочки

А вы саму статью читали? Из статьи кажется, что графическое программирование — удел каких-то малолетних д*билов, и примером аж целый Scratch выступает. Комменты под статьёй про "вымрут динозавры" не сильно лучше.


И это в то время, как к традиционным методикам вопросов, на самом деле, немало.

+2
И это в то время, как к традиционным методикам вопросов, на самом деле, немало.
К современным методикам вопросы есть, но когда нам в качестве «супердостижения» преподносят некоторый аналог структурного программирования (основное достоинство ДРАКОНа) и говорят, что они, тем самым «опередили всех»… непонятно — то ли смеяться, то ли плакать.

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

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

Массовое появление школьных компьютеров и соотвествующее обучение — это 90е. Соременные школы чертить на ватмане не учат, а программировать — таки учат (пусть не очень хорошо и формально, но учат). То есть лет ещё 20-30 мы будем вот-это-вот-всё наблюдать. Потом всё — вопросы использования «графических сред для программирования без программирования» будет закрыт.
0
ыучить язык программирования и самим сделаться программистами(что им нафиг не надо, так как у них своих проблем достаточно)

Программистами они от этого не станут хотя бы потому, что требования к наколенным поделкам от домохозяек и к реальному ПО для промышленных- и бизнес-задач совершенно различны.
Не путайте разработку ПО и программирование.
0

Ну в моей области действительно были т.н. кодеры, целый отдел — им приносишь до ужаса разжеванную спецификацию софта, и они согласно ей пишут и отлаживают программу. А потом они все садились вместе с теми, кто писал спецификацию и втыкали сутками, пытаясь понять, что и где эта программа делает неправильно. Нашли баг — если дело в спецификации, подправляли ее, передавали кодерам, те исправляли программу и все по новой.
Когда подготовка спецификаций и такая отладка стала занимать более 80% времени, отведенного на софт, они перешли на визуальное программирование и уволили всех кодеров нафиг. В итоге затраты на софт уменьшились на 70%, как и время выполнения проекта с 1 года до 2-х месяцев. И это был достаточно сложный софт.

-3
Когда подготовка спецификаций и такая отладка стала занимать более 80% времени, отведенного на софт, они перешли на визуальное программирование и уволили всех кодеров нафиг

Причины истерики в статье и комментариях у адептов текстовых редакторов начинают проясняться :)

+2
Адепты текстовых редакторов абсолютно спокойны, на их век работы хватит еще более чем. Как минимум потому, что без их работы, адепты графических инструментов ни байта программы скомпилировать не смогут в принципе :) Уровни абстракции они такие, да.
0
ИМХО стоит отметить, что под визуализацией программирования разные люди и фирмы понимали очень разные подходы. Нпр., сегодня опубликовал рассказ о старом продукте фирмы, которая называлась Visible Software.
0
У визуального программирования есть своя устойчивая ниша, например: Simulink Matlab, labVIEW NI. В таких приложениях и в такой реализации это работает.
+2
С тем, что у них пока что есть определённая ниша — я готов согласиться. А вот с рассказами про то то, что это — типа, новое слово, и программисты отстают… как бы не стоит забывать, что программисты тоже через это прошли. Блок-схемы в 60е-70е, UML в 90е и нулевые, вот это вот всё.

А потом, когда сложность достигла определённого предела — всё кончилось. Нет больше никаких ватманов с графиками в разработке ПО.

И непонятно почему другие инженерные дисциплины, которые сейчас находятся в начале этого пути, пытаются сделать вид, что они тут — «в первых рядах».
-2

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


другие инженерные дисциплины, которые сейчас находятся в начале этого пути

В других инженерных дисциплинах самолёты не зависают на подлёте. Может быть, есть чему поучиться?

+3
визуальных языков — тоже было немало. в 1993 году на выставке было изрядно всяких таких case-систем (в те времена считали это потенциальной «серебряной пулей»)… и тоже забыто и закопано…
+2
В других инженерных дисциплинах самолёты не зависают на подлёте.
И именно поэтому в других дициплинах люди могу экспериментировать и использовать новые технологии. В то время как в авиастоении и космосе используются проверенные временем технологии — слегка подрихтованные вещи из 60х-70х годов.

Может быть, есть чему поучиться?
Тому как тратить 100 рублей на то, что в других отраслях делают за рубль? Да, может быть строителям АЭС и стоит поучиться. Но если ошибка не ведёт к катастрофическим последствиям — то можно использовать другие, более прогрессивные, подходы.

Среди визуальных сред выживаемость, кстати, значительно выше оказалась, хотя их и существенно меньше.
Я вот в этом не уверен. У вас есть статистика? Или только «чуйка»?
-2
в других дициплинах люди могу экспериментировать и использовать новые технологии

Это вы про программирование? А много ли в современном программировании технологий, которым меньше 30-40 лет? Не языков и фрейморков, которые громко любят называть "технологиями", а технологий — в смысле способов и подходов?


Тому как тратить 100 рублей на то, что в других отраслях делают за рубль

Сейчас картина несколько другая: разработчик потратил рубль, продал за 10, потом клиенты совокупно потеряли ещё 1000 из-за взломов, глюков и утечек данных. Потому как разработчик продаёт SOFTWARE AS IS и ни за что не отвечает. Я бы посмотрел, сколько бы стоил тот сайт-визитка и на чём бы его писали, если бы ввели жесткую сертификацию как по авиационным стандартам.


Я вот в этом не уверен

Сколько сейчас используемых языков программирования и сколько их всего? А визуальных сред? Причём выжившие языки программирования выжили не потому, что на них удобно и безопасно программировать синтаксически и семантически, а потому, что лучше всего подходят под конкретные задачи (вроде тех же C и C++).

+2
Я бы посмотрел, сколько бы стоил тот сайт-визитка и на чём бы его писали, если бы ввели жесткую сертификацию как по авиационным стандартам.
Нисколько не стоил бы. Его бы просто не было. И компьютера у вас, скорее всего, тоже не было. И смартфона. Были бы перфокарты, в лучшем случае. И ваших любимых визуальных языков бы, кстати, тоже не было. Ну может были бы вещи типа ДРАКОНа, которые бы на ватмане бы рисовались.

А много ли в современном программировании технологий, которым меньше 30-40 лет? Не языков и фрейморков, которые громко любят называть «технологиями», а технологий — в смысле способов и подходов?
30-40 лет… от какого момента, извините? От момента, когда была высказана идея: «да, можно такую штуку сделать», до момента, когда она реально даст выхлоп часто десятилетия проходят. Нейронные сети какие-нибудь известны с 60х — но долгое время они не давали никакого выхлопа… а сейчас, наконец, «дозрели» — без них бы, скажем, самоуправляемые автомобили не появились бы.

Очень хороший, кстати, пример: ваши чудесные графические программы так и не привели к появлению чего-либо подобного — прищлось привлекать программистов с их «неправильными» технологиями…

Сколько сейчас используемых языков программирования и сколько их всего?
Вопрос в том, что такое «используемые языки программирования» и «всего». Все языки, на которых было написано хоть сколько-нибудь осмысленное количество приложений — всё ещё в строю. Хоть dBase (нынче его величают Vulcan.NET), хоть Turbo Basic (сегодня его зовут PowerBasic), хоть Turbo Prolog (он получил приставку «Visual», но графическим языком от этого не стал).

Да, вокруг них мало Хайпа, но они — вполне живы. Умерли разве что совсем экзотические языки, на которых и в 80-то три с половиной разработчика писали.

А визуальных сред?
А это уже у вас стоит спросить. Если вы так уверены, что у них «выживаемость лучше» — то, наверное, у вас есть какая-то статистика.

Причём выжившие языки программирования выжили не потому, что на них удобно и безопасно программировать синтаксически и семантически, а потому, что лучше всего подходят под конкретные задачи (вроде тех же C и C++).
Нет, они выжили потому, что существует достаточное количество программистов, готовых за их разработку платить. То же и с графическими средами.

К качеству собственно языков всё это имеет весьма и весьма опосредованное отношение.
+1
Подобные вопросы обсуждал в статье (включая SCADA и Scratch):
Бизнес-процессы: Как все запущено и запутано. Глава Третья. Общая классификация BPM и философия BPMS
habr.com/post/305720
см. в районе параграфа
3.4 Причины популярности BPMS или «на пути к великой цели человечества»: создание программ без программистов

Резюме. Визуализацию алгоритмов разделил бы на три направления (причем в обе стороны — прямая и обратная трансформация):
а) схема — код исполняемый, в том числе через промежуточную трансляцию в программный код высокого уровня (например, С++): CASE\UML, SCADA\TraceMode, BPMS\BPMN;
б) имитационное моделирование, сюlа же отнес бы и системы типа Graphviz;
в) схема — алгоритм человеческий (программа для человечка, в противовес — программа для машины): BPwin\IDEF, ARIS\EPC. Алгоритм человеческий — это фактически программа из русских букв для формализации регламентов взаимодействия и просто логики, в том числе, для целей дальнейшего ее программирования.

«схема — код исполняемый» — или «программирование без программирования»: ИТ-человечество к нему идет уже 30 лет. На смену CASE\UML пришел BPMS\BPMN и low code. Однако, они не оправдали наши ожидания и классическое программирование облегченно «выдохнуло». Но Эволюция продолжается и придут новые решения (не сомневаюсь), т.к. это востребовано и с каждым годом противоречия усугубляются.

Есть много программистов — сторонников «программирование без программирования» (их видимо обвинят в предательстве), но основным «клиентом» данной технологии будет бизнес-пользователь. Сейчас бизнес-пользователь пишет ТЗ и кидает его за стенку программерам. Те, что-то делают, но долго и не так и не за ту стоимость, особенно по «водопаду». Всемогущий ИГИЛе часто не помогает, а решиться на него в крупной компании совсем не просто.

Когда сам бизнес-пользователь сможет САМ своими руками менять бизнес-логику — тогда будет революция и классическое программирование вынуждено будет потесниться и уступить визуальному. Такое «nocode будущего» я сзываю с развитием визуального программирования. Картинки появились намного раньше алфавита — и намного более интуитивно понятны человеку, даже современному. Кроме того, что программы будут делать «люди из бизнеса», идея и в том, что сами программы станут понятны и пользователям, а не только программистам.

А может быть будет так: навел камерой смартфона на текст программы, а на экране отобразился сгенерированный алгоритм в виде схемы (или фрагмент). Или наоборот, навел на схему алгоритма — а смартфон запустил «на лету» сгенерированную программу.
«схема — алгоритм человеческий».
Пример. Есть подробный регламент взаимодействия подразделений компании только по одному направлению, но на 300- 400 листах. Понять, как по нему работать понятно, что непросто (совсем не понятно). Первое, что нужно сделать — упаковать его в формализованную таблицу. Далее из такой таблички автоматически строить схему процесса. И наоборот (BPwin так хорошо делал).

Однако нормально эту функцию сегодня никто делать не умеет (BPMS-BPA). Уверен, что со временем это станет «обычным делом», т.к. алгоритмы усложняются, но технологии их описания не развиваются.
Интересно, где раньше прорвет? В «схема — код исполняемый» или в «схема — алгоритм человеческий».

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

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

Как не стало кочегаров и массы других профессий, видимо не станет и программистов.
А почему вы считаете, что профессия программиста исчезнет не как профессия кочегара, а как профессия писаря и секретаря? Я лично общался с дедом моего знакомого. Который был довольно-таки большим начальником в 80е. И даже перестройку умудрился пережить. Но он отказывался общаться с компьютерами. Приказы за него набирал секретарь и почту электронную он же читал. А потом, где-то ближе к концу 90х, он был поставлен перед фактом: с такого-то числа секретаря у него больше ну будет и он будет сам чистать почту и писать приказы… или он может уволиться. Так как ему оставалось до пенсии пару лет — он предпочёл уволиться.

«схема — код исполняемый» — или «программирование без программирования»: ИТ-человечество к нему идет уже 30 лет. На смену CASE\UML пришел BPMS\BPMN и low code. Однако, они не оправдали наши ожидания и классическое программирование облегченно «выдохнуло». Но Эволюция продолжается и придут новые решения (не сомневаюсь), т.к. это востребовано и с каждым годом противоречия усугубляются
Почему в качестве решения не может подойти самое простое: уволить всех, кто не умеет программировать?

Программирование — не самая простая область человеческой деятельности, но освоить какиой-нибудь Python — не сложнее, чем изучить английский или немецкий. Тем не менее знание иностранного языка — не является чем-то редким и уникальным. А знание питона, скажем, для «бизнес-человека» считается немыслимым. Почему, собственно, и откуда уверенность, что так будет всегда?

Иными словами: почему вы считаете, что бизнес-люди, которым нужно писать программы будут всегда обходиться некоторым, специально для них созданным «языком-огрызком», возможно графическим — вместо того, чтобы воспользоваться инструментом, которым пользуются для написания программ программисты?

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

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

+2
Несомненно. Вот только есть ньюянс: заменяют автоматами и увольняют как раз людей низкой квалификации, не способных, в частности, научиться программировать.

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

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


Понимаете — вот опять получается — вы смотрите на проблему со стороны программиста, а я смотрю на проблему со стороны бизнеса. И у нас разные цели.


Как пример — вот этот самый человек, знающий и предметную область и умеющий программировать — да это ж ужас для компании. Например, уволился он и привет, давайте-ка попытаемся разобраться, что он там по напридумывал и понапрограммировал. В результате в 90% его последователь начнет все переписывать с нуля, так как просто не сможет разобраться с исходниками. Ну да — с каким-нибудь вебсайтом или фреймворком этот номер пройдет на ура. Но вот с ПО для какой-нибудь системы управления самолетом — уже не очень.


Вы не знаете, но именно для этого многие большие фирмы придумывали свои внутренние графические языки программирования, которые вы никогда не увидите — они не выходят за пределы ихних отделов. Но они пытаются решить именно вышеуказанную проблему. Например — HiDraw от ABB Обратите внимание — там картинка от Windows 3.1.

+2
Но вот с ПО для какой-нибудь системы управления самолетом — уже не очень.
С чего вдруг? Люди, разрабатывающие эти системы не могут научиться программировакть? Извините — не верю. Возможно не все — но больша́я часть — могут это сделать.

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

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

Однако если количество людей, умеющих программировать, будет расти (а оно таки растёт: количество таких людей в 70е измерялось десятками тысяч, сегодня — миллионами), то потребность в людей, не умеющих программировать будет, соотвественно, падать.

А наступление хорошего кризиса (сравнимого по масштабам с Великой Депрессией) — ускорит этот процесс. И очень сильно.

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

А вот с тем, что это какой-то «шаг вперёд» по сравнению с текстовыми языками — нет.

Графическими блок-схемами программисты развлекались 20-30-40 лет назад. Сегодня этим занимаются непрограммисты… но где уверенность, что они так и будут продолжать?

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

И тут-то мы наступаем на заботливо разложенные программистами для себя самих грабли: популярных языков — десятки, фреймворков — по десятку под каждый из них, если ты знаешь фреймворк X под язык Y — это ещё не значит, что тебя возьмут программировать на фреймворке Z под этот же язык. Нужно постоянно учиться, чтобы знать, что сейчас модно, и получается, что найти нужного специалиста даже под чисто программистские задачи сложно, а у специалиста в предметной области времени изучать весь этот зоопарк вообще нет.


Графическими блок-схемами программисты развлекались 20-30-40 лет назад

С тех пор появился WYSIWYG почти во всех местах: когда-то, чтобы сверстать документ, вы должны были знать теги LaTeX, сейчас все делают это кнопочками в Word. Та же история с GUI. То, что авиационная отрасль, бизнес-аналитика, промышленность уходят от прямого программирования — тоже звоночек: 20-30 лет назад игрались с Ada, теперь — со SCADE, Simulink и т.д.

+2
С тех пор появился WYSIWYG почти во всех местах: когда-то, чтобы сверстать документ, вы должны были знать теги LaTeX, сейчас все делают это кнопочками в Word.
Что приводит к тому, что результат получается хуже и рождается дольше.

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

То, что авиационная отрасль, бизнес-аналитика, промышленность уходят от прямого программирования — тоже звоночек: 20-30 лет назад игрались с Ada, теперь — со SCADE, Simulink и т.д.
С Ada игрались совсем другие люди, извините. Те люди, которые сейчас что-то делают со SCADE и Simulink'ом 20-30 лет назад не общались с компьютерами вообще.

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

В 80е-90е — казалось, что за ними будущее… но в 2000е все эти среды, позволявшие программировать базы данных и прочее мышкой — оказались не у дел. Когда накопилась критическая масса людей, способных обходится без этих костылей.

Вопрос: почему в других отраслях всё должно будет на них остановиться?
0
результат получается хуже и рождается дольше

Звучит довольно голословно, как и ваше утверждение о простоте ПО авионики.


С Ada игрались совсем другие люди, извините

Я говорю не о людях, а о компаниях. Компании одни и те же.


В 80е-90е — казалось, что за ними будущее… но в 2000е все эти среды, позволявшие программировать базы данных и прочее мышкой — оказались не у дел

Оказались ли? Судя по популярности SCADE, Simulink и разработке новых продуктов типа SAS Viya, Node Red и т.д. этого не скажешь. Причём большинство этих продуктов стоят дорого, но всё равно многие готовы за них платить — а вот за компилятор C++ никто платить не хочет, за среду разработки под C++ готовы заплатить максимум пару сотен долларов. Даже несмотря на бесплатность, 99% разработанных языков программирования сейчас почти не используются — чего не скажешь о графических средах.


Кстати 20-30 лет вообще не срок — в 80х, через 30 лет после появления языков высокого уровня и функционального программирования, многие «настоящие программисты» вообще считали, что нужно только на ASM кодить. Высокоуровневые языки всё ещё были слишком сырые и "несерьёзные", да и железо для них было слабовато.


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


Здесь, конечно, можно сказать, что ПО, написанное программистом, лучше и эффективнее автоматически сгенерированного кода, но с популярной сейчас концепцией good enough code и hello, world-ами на мегабайт это тоже не факт. Аргумент о сложности написания низкоуровневых алгоритмов тоже не в кассу — в большинстве случаев программисты так же пользуются готовыми библиотеками и фреймворками, собирая из них систему под требования на высоком уровне. А где высокий уровень — там уже можно говорить о графических средах, которые позволяют убрать синтаксический шум, присущий текстовым языкам.

0
Звучит довольно голословно

Так может сказать только тот, кто этот результат не видел. Если цель — получить распечатку, то да, Word покатит. Но если нужно получить код, который будет адекватно отрисовываться в разном окружении — то это адский ад.
0
А с преимуществом Word в скорости вы согласны? По вопросу отрисовки — PDF в помощь. Но можно, конечно, и на LaTeX — до сих пор же есть любители чистого ASM, которые на нём всю ОС пилят, а кое-где без него вообще никуда.
0
А с преимуществом Word в скорости вы согласны?

Согласен. Но только в описанном случае.
PDF в помощь

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

У Word-а кстати есть огромный недостаток — отсутствие возможности работать непосредственно с кодом. Я помню, как проклинал всё, при составлении более-менее сложных таблиц. Застрелишься, пока настроишь все ширины и высоты столбцов и строк, мышью — вообще невозможно (шаг сетки не позволяет), приходится вбивать через форму.
0
Для особо продвинутых пользователей в Word-е вроде возможность кодить есть — правда мало кто пользуется.
0
VBA там не столько для отображения, сколько для автоматизации. заполнить формочку, и получить готовый документ. Или наоборот, подцепиться к некой базе, выбрать там некие данные (тоже в форме), и создать документ на их основании. Или подключиться к ворду, и управлять его поведением.
Это не совсем «управление оформлением». Хотя и это тоже можно делать.
0
Для особо продвинутых пользователей в Word-е вроде возможность кодить есть — правда мало кто пользуется.

Возможность верстать документ с помощью кода?
0
Он вам про Фому, он вам про Ерёму. Речь идёт не про программирование, а про банальный Reveal Codes.

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

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

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

Другой вопрос, что тут, как бы, всегда всё упирается в «а что мы хотим в результате?»… если качественный результат нам не нужен и строки/таблицы с пробелами в километр нас устраивают, то Word и быстрее может быть…
0
знать теги LaTeX

Говорят, что в науке это стандарт де-факто. Сам утверждать не берусь, но от научных работников слышал.
0
С чего вдруг? Люди, разрабатывающие эти системы не могут научиться программировакть? Извините — не верю. Возможно не все — но больша́я часть — могут это сделать

Вы исходную предпосылку читали? Этих людей нет — они уволились. А новые должны мочь поддерживать существующий код, например. Который очень ответственный.


держать людей, которые не слишком эффективны (могущих «склепать в Матлабе модель, не могущих её эффективно запрограммировать»),

Унижаете, товарищ. Это часто очень эффективные люди, если их не отвлекать на такую мелочь, как программирование. Они думают другими категориями.


Однако если количество людей, умеющих программировать, будет расти (а оно таки растёт: количество таких людей в 70е измерялось десятками тысяч, сегодня — миллионами), то потребность в людей, не умеющих программировать будет, соотвественно, падать.

Не вижу здесь связи.


Графическими блок-схемами программисты развлекались 20-30-40 лет назад. Сегодня этим занимаются непрограммисты… но где уверенность, что они так и будут продолжать?

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


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

Не знаю, но вот сравнительно недавно придумали же NodeRed — визуальный язык программирования? Не для программистов, случайно?

+2
Не знаю, но вот сравнительно недавно придумали же NodeRed — визуальный язык программирования? Не для программистов, случайно?
Нет. Всё для той же категории «людей, которым нужна программа, но лень учить python».

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

Количество новых продуктов и развитие старых позволяет судить о том, что продолжать будут еще долго.
Можно даже сказать сколько. Лет 20-30 — пока люди, не общавшиеся с компьютером на уроках в школе не уйдут на пенсию.

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

У текстовых языков программирования тоже свои узкие ниши: сайты делают на JS и PHP, операционные системы и утилиты — на C/C++, бизнес-сервисы — на Java и т. д. И занимают они свои ниши не из-за своего удобства для программирования и синтаксической красоты, а из-за уже созданной под них инфраструктуры, инструментария, истории, экономических соображений, политики и прочих вещей, весьма далёких от коддинга.


узкая ниша простых задач

"Простых задач" типа управления самолётами, атомными реакторами и бизнес-аналитики, с которыми почему-то не справились текстовые языки:) Просто потому, что в разработке серьёзного ПО коддинг занимает меньше половины ресурсов, соответственно скорость набивки программы, предоставляемая текстовыми языками, играет третьестепенную роль.

+3
Серьезно? А на чем все эти ваши SCADE и Simulink написаны? А можно ли на них сделать все что хочешь или если соответствующего блока нет то придется слезно просить поставщика этого ПО напрячь своих "текстовых" программистов для вас их написать?
0
на чем все эти ваши SCADE и Simulink написаны

Наверное на C++, а что?


можно ли на них сделать все что хочешь

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

0
Т.е. если по вашему на Simulink нельзя написать Simulink — то ой все что ли?
А можно сделать молоток исключительно с помощью молотка?
Может отвертку, используя только отвертку?
Или нож используя нож?
Стоит ли отказаться от всех тех инструментов, используя которые, нельзя воспроизвести эти же инструменты?! Или может все таки для решения конкретной задачи, достаточно лишь способности к решению этой задачи. Это проблемно ориентированный язык — как молоток для гвоздей.

Посмотрим с другой стороны: В каком текстовом языке у нас например в стандартной библиотеке есть «PID регулятор» или набор из десятка фильтров? Выходит, что эти языки не пригодны для решения простейших задач построения управляющих систем и обработки данных, потому что инженер не должен изобретать эти штуки — ему хватит и проблемы подбора их параметров.

Так вот Cимулинк работает с потоком данных. Откуда эти данные будут получены и куда потом отправлены, вы конечно же можете написать самостоятельно в виде HAL и драйверов для своего железа или API для своей бизнес системы — чем полностью удовлетворить свое желание, написать что нибудь руками в виде печатного текста. Хоть на универсальных языках, хоть в той же среде матлаба.

На самый тяжелый случай — графическая модель ведь тоже в текстовом файле описана… Рассматривайте это как еще один узкоспециализированный текстовый язык.
+2
Т.е. если по вашему на Simulink нельзя написать Simulink — то ой все что ли?
Именно так.

Это проблемно ориентированный язык — как молоток для гвоздей.
А кто и где с этим спорит, а?

Спор идёт как раз о сложности и унивесальности. На все попытки объяснить, что задача, которая 70 лет назад решалась с помощью палки и верёвки (шучу, шучу, там электромеханические приспособы были) ну аж никак не могу быть сложными — следует очередная попытка «задавить авторитетом». Ну как же: авия, атом, бальшие деньги… а что это говорит не о сложности задачи, а только лишь о её важности — aeeneas почему-то понять отказывается.

В каком текстовом языке у нас например в стандартной библиотеке есть «PID регулятор» или набор из десятка фильтров?
А зачем вам нужен PID регулятор и этот десяток фильтров, извините? Не для того ли, чтобы превратить схему «из палок и верёвок» в что-то, что исполняется на компьютере? Ну так это — только первый этап. Дальше — нужно будет заставлять компьютер выдавать результат лучше, чем может «PID регулятор и десяток фильтров» (а иначе зачем вообще нужно было огород городить?).

И вот совершенно не факт, что графические схемы в этот момент по-прежнему будут адекватны.

На самый тяжелый случай — графическая модель ведь тоже в текстовом файле описана…
Вопрос как она там описана. Вот тут про «новые технологии» спрашивали. Так их есть у меня. Правда новой её можно назвать только лишь с некоторой натяжкой, но… patch. Прошу любить и жаловать. Это — то, что убило нафиг все потуги что-то делать в графическом виде.

Вернее, конечно, не patch, как таковой, а то, что за ним последовало. Git и Mercurial. Это — то, что позволяет одному человеку рассмотреть (и принять или отвергнуть) десять тысяч изменений за пару недель.

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

В некоторых современных визуальных средах тоже что-то подобное есть, но когда я общался с людьми их пользующими — они про них не знали. То есть они ими не пользуются. Что, собственно, и показывает, что они решают простые задачи — если бы речь шла о задачах сложных, то работать в одиночку над тем или иным проектом или использовать тыкву у них бы уже не получилось.
0
ну аж никак не могу быть сложными

Зачем мы платим летчикам по полмиллиона рублей?! (программистам не платим). Ведь задача которую решали братья Райт 120 лет назад никак не может быть сложной. Разве может быть сложным управляющий компьютер Буран-а который еще с магнитофона загружался и 25 лет назад ее решил?! Или может вся сложность, возникает где то совсем в другом месте — а вовсе не в превращении некоего алгоритма в некий код, и не в объеме того кода и алгоритма, и не в возможности молотка заворачивать шуруп…
А зачем вам нужен PID регулятор и этот десяток фильтров, извините? Не для того ли, чтобы превратить схему «из палок и верёвок» в что-то, что исполняется на компьютере?

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

Вернее, конечно, не patch, как таковой, а то, что за ним последовало. Git и Mercurial. Это — то, что позволяет одному человеку рассмотреть (и принять или отвергнуть) десять тысяч изменений за пару недель.


Вы не очень понимаете, что такое программирование на основе физических моделей и стараетесь сравнивать его с каким то говнокодингом (10тыс изменений в неделю)… Модель — это или труд огромного числа ученых, за много лет, или сложный вывод на базе автоматического анализа огромного потока данных — она обычно сразу получается в готовом виде и проходит верификацию. После этого либо принимается либо отвергается. На ее разработку, проверку адекватности объекту, и развитие могут тратится годы… Модель реализованная в неком релизном ПО сейчас — обычно разработана и проверена 5 лет назад и с тех пор в нее не внесено ни одного изменения. А на изменении (если его удастся внести на этапе разработки) диссертацию можно защитить… С того момента, как для модели выполнен весь набор тестов и доказана адекватность объекту — модель неприкасаема до момента, когда условия новой задачи вновь делают ее старую реализацию неадекватной текущему или новому объекту… Тогда модель усложняется и весь цикл разработки повторяется.

В этих условиях хорошо, если за всю свою жизнь вы накопите аж 5 версий модели…

Так вот задача трансляции финальной модели в живую полностью гарантированно реализующую ее копию железяку, очень плохо решается мешками с костями обладающими знаниями ЯП. И именно по этому фобосы грунты не летают. Молодежь туда тащит модные гиты и «10к вариантов говнокода» — а нужен один единственный вариант кода, на 100500% соответствующий модели движения КА, в котором вообще нельзя ничего менять под страхом расстрела. Поэтому не важно выполнен ли он в стиле спагетти или с goto или еще как — важно, что он обязан быть один и асболютно адекватен модели движения = нельзя его трогать, чтоб не сломать!

В частности в нейросети — можно потерять связь между нейронами. Можно напутать с весами — можно банально опечататься и применить 1 вес к 2-м связям… И в результате реализация будет работать, обучатся, проходить тесты — но не будет соответствовать исходной модели… Что приведет к тому, что потом придет инженер — загонит данные из исходной модели и все сломается непонятно почему…

Кроме того документация в этих языках генерируется автоматически (по сути модель это и есть документация лишь коментарии добавить).
+2
Зачем мы платим летчикам по полмиллиона рублей?! (программистам не платим).
Ну это у вас надо спросить. Вы ж платите. Средний инжинер в Гугле получает $141,614 в год, пилот в Американской Армии $75,540, а в American Airlines — $180,685. Вполне сравнимые величины.

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

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

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

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

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

Собственно вот всё что вы описали, почти 1-в-1 программная индустрия прошла в 70е годы.

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

И этот подход — уже начинают применять и в тех областях, про которые вы говорите. Вот, например. Да, конечно, аэрокосмческая отрасль и АЭС никак не могут тут быть в передовиках: потенциальный выигрыш невелик, а потенциальные потери — огромны. Но и говорить, что они находятся «впереди планеты всей» в области программирования — просто глупо. Нет — она аутсайдеры. По понятной и уважительной причине — но аутсайдеры.

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

а нужен один единственный вариант кода, на 100500% соответствующий модели движения КА, в котором вообще нельзя ничего менять под страхом расстрела. Поэтому не важно выполнен ли он в стиле спагетти или с goto или еще как — важно, что он обязан быть один и асболютно адекватен модели движения = нельзя его трогать, чтоб не сломать!
Аплодирую стоя. Вот ровно те же самые слова говорились людьми, которые объясняли что водопад — это то, что обеспечит нам всё, что нужно, если правильно его подготовить. Лет этак 20-30 тому назад. Большинство из них сейчас на пенсии, а их компании обанкротились… но вы верьте, что проблемы в Git'ах и неправильно сделанной «единственно верной» модели…

Молодежь туда тащит модные гиты и «10к вариантов говнокода» — а нужен один единственный вариант кода, на 100500% соответствующий модели движения КА, в котором вообще нельзя ничего менять под страхом расстрела.
Объясните только мне, идиоту, почему у Space X как-то получается ракеты запускать без модели, которую они пять лет разрабатывает, а у Роскосмоса — нет?

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


Для бизнеса нет понятия сложный-не сложный — есть понятие дешево или дорого. Этот код дорог… Автогенерация для него обеспечивает гарантированное отсутствие ошибок и ненадобность выплат кучи зарплат — так получается чуть дешевле, но все равно очень дорого.

Но из этого вовсе не следует, что там будет всегда.

Ну новую ТАУ то вряд ли в ближайшие 50 лет изобретут, она слишком фундаментальна — а вот новых ЯП точно придумают как грязи, так что выкинуть всегда успеют.

А потом — ракета улетает неизвестно куда, и большинство запусков уходят к конкурентам.

У конкурентов просто нет места программистам в текстовых редакторах. В спейс-x просто физически такого числа народу нет, сколько там работы по разработке ПО было произведено! Так что, там только ВП на физмоделях и место.

Вы накопите их ещё меньше, когда люди, строящие свои модели не 5 лет, а 5 дней — вытеснят вас с рынка.

30 лет слышу эти сказки — по факту только сложность растет. Цикл разработки год+ и одних экспериментов по неделе на модель.
Вот ровно те же самые слова говорились людьми, которые объясняли что водопад — это то, что обеспечит нам всё, что нужно, если правильно его подготовить.

Зачем его правильно готовить — если это промышленный стандарт разработки, благодаря которому все это 40 лет так работает! С «всем остальным» играться конечно можете — но вот когда стандартизируете, тогда и поговорим…
Объясните только мне, идиоту, почему у Space X как-то получается ракеты запускать без модели, которую они пять лет разрабатывает, а у Роскосмоса — нет?

Ровно потому, что это как раз у Space-X и MBD и автогенерация кода и тестирование а у Роскосмоса нормально ТЗ писать не кому — поэтому, что там дальше не важно.
+2
«Простых задач» типа управления самолётами, атомными реакторами и бизнес-аналитики, с которыми почему-то не справились текстовые языки:)
Во-первых — почему у вас там вдруг кавычки появились? И да, речь идёт о простых задачах типа управления самолётами и атомными реакторами.

Вы путаете сложность задачи и её важность. Автопилоты в авиации появились, я извиняюсь, в 40е годы, когда никаких компьютеров в самолётах и в помине не было. Управлять автомобилем сложнее и даже «тривальная» задача типа «взять бумажку с инструкцией и засунуть её в коробку с лекарством» или «взять конфетку с конвеера и положить в ячейку правильной формы» — далеко выходит по сложности за рамки того, что вы можете запрограммировать на ваших графических схемах.

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

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

Но непонятно с какого перепугу вы решили, что решаемые задачи так и останутся простыми и через 20 лет и через 30.
0
А вот цена ошибки — тут ситуация совсем другая: если самолёт упадёт — то у вас десятки трупов, а если конфетку не в ту ячейку положили — ну и чёрт с ней, выкинули и забыли.

И почему вы вдруг выкидываете этот факт и начинаете говорить о том, что «серьёзность» ПО не важна, а важна исключительно его сложность? Что толку от сложного ПО, если оно не может выполнить "серьезную", хоть и простую задачу?


Я в пример всегда привожу домашнюю автоматизацию, куда с большим энтузиазмом всунулись всевозможные программисты — ну да ж, ведь появились всякие Arduino и ESP8266, которые можно запрограммировать на питоне, все супер.
Ну давайте, запрограммируйте-ка мне контроллер управления отопительным котлом на вашем питоне, чтобы измерял температуру и выключал котел, если она слишком высокая. Только котел у вас такой, что если его не выключить во время — он перегреется и выключится намертво. А еще все это дело должно работать автономно 24/7 и рядом людей нет.


И самое смешное — такие "простые" задачи останутся такими и через 10 и через 40 лет.

+1
Что толку от сложного ПО, если оно не может выполнить «серьезную», хоть и простую задачу?
Сейчас покажу на вашем же примере.

Ну давайте, запрограммируйте-ка мне контроллер управления отопительным котлом на вашем питоне, чтобы измерял температуру и выключал котел, если она слишком высокая. Только котел у вас такой, что если его не выключить во время — он перегреется и выключится намертво. А еще все это дело должно работать автономно 24/7 и рядом людей нет.
А сколько у вас этих котлов? Если он вообще один — то не факт, что вся эта возня с Arduino и прочим вообще себя окупит. А вот если у вас их много и вы можете обеспечить достаточною экономию за счёт сложной программы на Питоне… то, возможно, общая цена всей конструкции даже с учётом страховки — будет дешевле, чем если вы сделаете всё в лоб с PID регуляторами…

И самое смешное — такие «простые» задачи останутся такими и через 10 и через 40 лет.
А зачем вы туда вообще компьютеры пихаете, если они «останутся такими же»?

Или тут та же история, что и с Роскосмосом: пока Маск не сделал альтернативу (дешевле она реально или нет — сейчас оставим «за кадром»), так и «задачи оставлись такими и через 10 лет и через 40 лет»… а как рынок «ушёл» — так срочно движуха началась?
0
А сколько у вас этих котлов? Если он вообще один — то не факт, что вся эта возня с Arduino и прочим вообще себя окупит. А вот если у вас их много и вы можете обеспечить достаточною экономию за счёт сложной программы на Питоне… то, возможно, общая цена всей конструкции даже с учётом страховки — будет дешевле, чем если вы сделаете всё в лоб с PID регуляторами…

Подождите, а почему вы сразу спрашиваете о количестве котлов? Если программисту дают задачу "напиши программу", он же не спрашивает "а сколько у вас этих компьютеров"? Не надо гадать — вас просят, как программиста, решить задачу — напишите мне программу управления котлом по заданному алгоритму, чтобы я мог применить ее в контроллере. Даю подсказку — с Питона вам придется опуститься до уровня Си, а потом вам придется познакомиться и с ОСРВ. И "простая" задачка вдруг становится "сложной". Необычно, да?


А зачем вы туда вообще компьютеры пихаете, если они «останутся такими же»?

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

+2
Если программисту дают задачу «напиши программу», он же не спрашивает «а сколько у вас этих компьютеров»?
Спрашивает, конечно. Потому что он этого сильно зависит вообще подход к решению задачи. Если мы делаем что-то, что будет работать на миллионе компютеров, то делать год что-то что даст экономию в один доллар — разумно. А если у нас этих компьютеров три штуку — то дешевле будет вместо ардуино туда какой-нибудь многоядерный процессор на пару гигагерц поставить.

Потому что компьютеры могут часто решить эти задачи быстрее, одновременно, в них можно заложить гибкие, изменяемые алгоритмы.
И всё это можно сделать за совершенно разные деньги и с совершенно разными подходами. Если учесть, что в цена Arduino Uno (самая дешёвая модель) почти такая же, как цена Raspberry Pi Zero… с процессором 1GHz и памятью в 512MB… то вопрос «а сколько у нас будет этих котлов» становится отнюдь не праздным.
-1
Спрашивает, конечно. Потому что он этого сильно зависит вообще подход к решению задачи.

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


А не размышляйте, что тут лучше — Ардуино, Raspberry или многоядерный процессор — это же не компетенция программиста?

0
разовую задачу (вот получить прямщазз один раз данные, и забыть об этом) можно написать по любимой многими методике ХХП. для регулярной — скажем, еженедельной а то и ежедневной работы — десятка сотрудников нужно уже тщательно обдумать задачу. В итоге по ХХП сделано за час- пару часов, и работает примерно 13 минут. При обдумывании сделано за день или в районе того, и работает около 25 секунд на тех же данных.
0
А не размышляйте, что тут лучше — Ардуино, Raspberry или многоядерный процессор — это же не компетенция программиста?
Я такую фразу слышал несколько раз от потенциальных работодателей. Ни один из них не стал реальным — и я об этом не пожалел, так как все они закрылись через год-два после того, как я с ними разговаривал.

При этом я много чего видел: и реализацию AES на 4-битном процессоре и web-сервер на 8-битном… но всё это должно было получить экономическое обоснование. Ибо решение одной и той же программистской задачи может отличаться по цене на 4-5 порядка, в зависимости от того, под какое железо она делается — и вовсе не факт, что эти затраты окупятся.
0
речь идёт о простых задачах типа управления самолётами

Вы разбираетесь в системах управления самолётами или реакторами, что с такой уверенностью заявляете об их простоте? Конкретно в самолёте даже просто устройств ввода-вывода в несколько раз больше, чем в обычном компьютере, и связанность там гораздо выше: какой-нибудь датчик тангажа не получится просто абстрагировать от РЛС, например.


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

0
Вы разбираетесь в системах управления самолётами или реакторами, что с такой уверенностью заявляете об их простоте?
Я разбираюсь в истории. Не слишком сильно, да, но достаточно для того, чтобы понять что ни электромеханический автопилот, ни механические системы на Р-7 не могли решать сложных задач.

Как не может доказывать математические теоремы червь.

Конкретно в самолёте даже просто устройств ввода-вывода в несколько раз больше, чем в обычном компьютере, и связанность там гораздо выше: какой-нибудь датчик тангажа не получится просто абстрагировать от РЛС, например.
Тем не менее вся эта информация невелика по объёму (одна-единственная USB-камера в роботе, который заворачивает конфетку даёт больше данных, чем все датчики самолёта, вместе взяты) и хорошо структурирована.

быструю сортировку или HTML-движок руками сейчас всё равно мало кто пишет, а вот собрать систему из блоков на графических языках — в самый раз.
И, тем не менее, это «прокатывает» только в самых простейших случаях. Любой мало-мальски серьёзный сайт сибрается не из блоков на графических языках.
0

Современные системы fly-by-wire относятся к электромеханическому автопилоту и Р-7 примерно как iPhone к ENIAC.


роботе, который заворачивает конфетку

И как его программируют заворачивать конфетку?


«прокатывает» только в самых простейших случаях

Создание «простейшей авионики» что-то не осилили ни в Китае, ни в РФ. Видимо им нужна ваша помощь:)

0
Попробую еще раз пояснить ту же мысль, которую вначале показывал в своей статье см. в районе параграфа
3.4 Причины популярности BPMS или «на пути к великой цели человечества»: создание программ без программистов
а потом выше.
Кстати, то, что я и многие остальные здесь не могут «буквами» донести ясно свои мысли — это как раз наглядное подтверждение ограничениям естественного «языка букв», поэтому к тексту часто и прикладывают схемы и чертежи. А если вместо чертежа токарю на стол положат талмуд с буквами, описывающими размер и форму детали, — то его работа займет намного больше времени и сил (а уж как он будет при этом материться ...). Это все про визуальное представление информации, алгоритмов и самих параметров изделий (деталей).

Визуальное программирование — примерно про это же: изготовление программных изделий по чертежам. А если посмотреть дальше — станки с ЧПУ, где ЧПУ изготавливает деталь не на основе программы, а классического чертежа, то мы фактически говорим о ситуации, когда бизнес-пользователь нарисовал на понятном ему языке схем, например, «BPMN ++», решение своей задачи (не постановку задачи), потом «по кнопке» отправил это решение в движок исполнения и радостно заявил (если получилось задуманное): наконец-то я обхожусь без программеров!

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

Относительно «BPMN ++»: прогресс от от CASE\UML времен 2к (Rational Rose или ARIS с модулем кодо генерации в С++ силами ARIS script) до современных BPMS\BPMN и «low code \ no code» — колоссальный. Главное что есть большой интерес к этому направлению и появилось много инструментов (продуктов). Но это пока все еще инструменты скорее для программеров, нежели для бизнес — пользователя, поэтому «все еще впереди», но движение идет пусть и не так быстро, но в верном направлении.

Относительно обучить бизнес-пользователя — питону (хорошо, что не ассемблеру). Это утопия. Инженера по АСУТП без навыков программирования можно обучить Trace Mode (SCADA), исследователя — mathcad, схемотехника — LAbView и т.п.
Редкого Бизнес-пользователя можно обучить: а) хорошо пользоваться Excel и делать ровно такие же запросы (селекты и прочее) и обработку посредством связанных таблиц и другого инструментария Excel.
б) использовать подобное через встроенный инструментарий в генераторы отчетов, например, к хранилищам данных. Это тоже схожее направление к рассматриваемой теме — т.е. визуальное проектирование отчетов, когда селекты формируется без знания SQL.
Обучить бизнес — пользователя даже VBA — почти нерешаемая проблема, не говоря уже о питоне и т.п.
-1
Macin
«Программирование без программистов» появилось очень давно — с появлением языка Фортран, идеей которого было дать математикам возможность общаться с машиной «без этих ваших программистов, которые бубнят об адресах и переходах». Только очень быстро оказалось, что составление инструкций на Фортране — это тоже программирование.

Это не совсем так.
История идеи «программирование без программистов» выглядит иначе.

ПРЕДЛОЖЕНИЕ ДЖЕЙМСА МАРТИНА

В 1982 году известный специалист по информатике Джеймс Мартин опубликовал книгу под названием «Прикладное программирование без программистов»:

James Martin. Application Development without Programmers, Prentice-Hall, Inc., Englewood Cliffs, New Jersey, 1982. 350 pp.

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

Для справки приведу аннотацию к этой книге.

Applications development without programmers, James Martin, Prentice-Hall, Inc.,
Englewood Cliffs, NJ, 1982. 350 pp. (ISBN 0-13438943-9).
With the development of comprehensive nonprocedural languages, many organizations have found significant benefit in providing users with the tools to meet their own information processing requirements.
The author reviews the capability of such offerings including query facilities, report generators, graphics languages, applications generators, very-high-level programming languages, and parameter-driven applications packages.
Each development methodology is illustrated with scenarios from applications created using commercially available software. The implementation of these capabilities has significant implications for the entire data processing organization. Also discussed are management considerations for the implementation, control, and operation of an Information Center.


НОВОЕ НАПРАВЛЕНИЕ ИССЛЕДОВАНИЙ

Книга Мартина дала начало новому направлению исследований, которое обычно для краткости называют «Программирование без программистов» (хотя фактически речь идет только о программировании без ПРИКЛАДНЫХ программистов»).

Чтобы оценить масштаб и разнообразие ведущихся исследований, можно задать в Гугле запрос «Программирование без программистов»

С уважением,
Владимир Данилович Паронджанов
Mobile: +7-916-111-91-57
Viber: +7-916-111-91-57
E-mail: vdp2007@bk.ru
Skype: vdp2007@bk.ru
Website: drakon.su
Webforum: forum.drakon.su
+1
Это не совсем так.
История идеи «программирование без программистов» выглядит иначе.

Это выглядит именно так, как я сказал.

A draft specification for The IBM Mathematical Formula Translating System was completed by November 1954.[8]:71 The first manual for FORTRAN appeared in October 1956,[8]:72 with the first FORTRAN compiler delivered in April 1957

John Backus said during a 1979 interview with Think, the IBM employee magazine, «Much of my work has come from being lazy. I didn't like writing programs, and so, when I was working on the IBM 701, writing programs for computing missile trajectories, I started work on a programming system to make it easier to write programs.»[12]

Как видите, «система трансляции математических формул для расчетов траекторий ракет» появилась в 1954 от того, что человек не хотел писать программы (в терминологии тех лет — на мнемокоде).

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


P.S. отвечайте, пожалуйста, ветками — так легче отслеживать беседу.
0
Macin
John Backus said during a 1979 interview with Think, the IBM employee magazine, «Much of my work has come from being lazy. I didn't like writing programs, and so, when I was working on the IBM 701, writing programs for computing missile trajectories, I started work on a programming system to make it easier to write programs.»[12]
Спасибо за интересную цитату их Бэкуса. Но в этой цитате нет термина «программирование без программистов.

Как видите, «система трансляции математических формул для расчетов траекторий ракет» появилась в 1954 от того, что человек не хотел писать программы (в терминологии тех лет — на мнемокоде).
Вы трактуете „программирование без программистов“ расширительно, я же склонен обращаться к первоисточнику (Джеймс Мартин), где этот термин впервые появился.

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

Приведенные статьи не дают обзора принимаемых при создании языка решений, нет сравнения с другими инструментальными средами при решении тех же задач.
Принимаемые при создании языка ДРАКОН решения описаны в моих книгах.
Наиболее полно — в книге
Паронджанов В.Д. Учись писать, читать и понимать алгоритмы. Алгоритмы для правильного мышления. Основы алгоритмизации. — М.: ДМК-Пресс, 2012, 2014, 2016. — 520 с. — Иллюстраций 272.

0
Спасибо за интересную цитату их Бэкуса. Но в этой цитате нет термина «программирование без программистов.

Это вопрос инженерного «маркетинга» и стремление назвать свое творение как-то иначе, даже если оно по сути, принципиально то же самое.

Вы трактуете „программирование без программистов“ расширительно, я же склонен обращаться к первоисточнику (Джеймс Мартин), где этот термин впервые появился.

Это лишь новое название для старого принципа — сведение программирования к языку, понятному предметникам. В случае Фортрана — математикам.
Моя идея — соединить идею алгоритма с идеей когнитивной эргономики. Полученный результат некорректно называть блок-схемами. Дракон-схемы принципиально отличаются от блок-схем.

Почему же, чем именно они отличаются? Судя по приведенным примерам (например, 4 видео про замок, рекомендованные вами) это именно блок-схемы. Не те, что гостированы, но вариация оных.
Принимаемые при создании языка ДРАКОН решения описаны в моих книгах.
Наиболее полно — в книге

Спасибо, но тем не менее — есть ли стандарт языка, инженерное (не учебное) описание и сравнение с аналогичными решениями? Все как всегда — предлагая новое, надо делать анализ имеющегося.
0
Macin
Это вопрос инженерного «маркетинга» и стремление назвать свое творение как-то иначе, даже если оно по сути, принципиально то же самое.
Это лишь новое название для старого принципа — сведение программирования к языку, понятному предметникам. В случае Фортрана — математикам.
Вы правы и я согласен с вами. Ваша трактовка насчет Бэкуса, Фортрана и математиков изящна и обогащает содержание обсуждения.
Почему же, чем именно они отличаются? Судя по приведенным примерам (например, 4 видео про замок, рекомендованные вами) это именно блок-схемы. Не те, что гостированы, но вариация оных.
Говоря кратко блок-схемы не эргономичны, не формализованы, не структурированы, не упорядочены.
Дракон-схемы, напротив, лишены подобных недостатков и во всех отношениях превосходят их. Чтобы пояснить эти слова, нужно ввести новую систему понятий, новые критерии и новую теорию. Для этой цели я написал ряд книг:
  1. Паронджанов В. Д. Как улучшить работу ума (новые средства для образного представления знаний, развития интеллекта и взаимопонимания). — М.: Радио и связь, 1998, 1999. — 352 с.
  2. Паронджанов В. Д. Как улучшить работу ума. Алгоритмы без программистов — это очень просто. — М.: Дело, 2001. — 360 с.
  3. Паронджанов В. Д. Дружелюбные алгоритмы, понятные каждому. Как улучшить работу ума без лишних хлопот. — М.: ДМК-пресс, 2010, 2014, 2016. — 464 с.
  4. Паронджанов В. Д. Учись писать, читать и понимать алгоритмы. Алгоритмы для правильного мышления. Основы алгоритмизации. — М.: ДМК Пресс, 2012, 2014, 2016. — 520 с.
  5. Паронджанов В.Д. Почему врачи убивают и калечат пациентов, или Зачем врачу блок-схемы алгоритмов? Иллюстрированные алгоритмы диагностики и лечения — перспективный путь развития медицины / Предисл. члена-корр. РАН Г.В. Порядина. — М.: ДМК Пресс, 2017. — 340 с.
  6. Паронджанов В. Д. Алгоритмы и жизнеритмы. Основы алгоритмизации. Быстрый способ изучить алгоритмы. — М.: ДМК Пресс, 2019. — 300 с. Это пока еще рукопись


есть ли стандарт языка, инженерное (не учебное) описание и сравнение с аналогичными решениями? Все как всегда — предлагая новое, надо делать анализ имеющегося.
Сравнение с имеющимся в моих книгах есть. Формального стандарта языка нет, но есть почти равноценное стандарту техническое задание на разработку программы «дракон-конструктор».

Несколько энтузиастов создали свои варианты дракон-конструктора.
Например, дракон-конструктор Степана Митькина имеет открытый код и позволяет преобразовывать дракон-схемы в исходный код 13 целевых языков: Java, Processing, D, C#, C/C++ (with Qt support), Python, Tcl, JavaScript, Lua, Erlang, AutoHotkey и Verilog.
0
большое спасибо за ваш труд! обязательно в ближайшее время приобрету ваши книги на озоне!
0
usbstor

Благодарю вас.
Кое-что можно скачать бесплатно

Паронджанов В. Д. Как улучшить работу ума. Алгоритмы без программистов — это очень просто. — М.: Дело, 2001. — 360 с.
bit.ly/2AQaZV1

Паронджанов В. Д. Язык Дракон. Краткое описание.— М., 2009. — 124 с.
drakon.su/_media/biblioteka/drakondescription.pdf

Паронджанов В. Д. Алгоритмы и жизнеритмы. Основы алгоритмизации. Быстрый способ изучить алгоритмы. — М.: Препринт, 2018. — 313 с.
drakon.su/_media/zhizneritm.pdf

С уважением,
Владимир Данилович Паронджанов
Mobile: +7-916-111-91-57
Viber: +7-916-111-91-57
E-mail: vdp2007@bk.ru
Skype: vdp2007@bk.ru
Website: drakon.su
Webforum: forum.drakon.su

0
Кстати, хорошая статья.
… Но давайте вернёмся к «языку визуального программирования». Блок-схемы схемы страдают одним хроническим недостатком: они описывает только алгоритм! А как же данные?
В.Ш. Кауфман, «Языки программирования. Концепции и принципы», стр. 42:
«Между тем в программистском фольклоре бытует крылатая фраза, довольно точно отражающая трудоемкость и значимость отдельных аспектов программирования: «Дайте мне структуру данных, а уж программу я и сам напишу!».»
Возьмём классику жанра: Д.Кнут, «Искусство программирования», том 3, «Сортировка и поиск». На восьмистах с лишним страницах лишь 23 раза встречается то, что может попасть под определение «схема алгоритма». Зато этот труд просто изобилует рисунками и таблицами, которые можно назвать «схемой данных». Соотношение «схема данных»: «схема алгоритма» более 10:1. Вероятно, это достаточно точная оценка приоритета данных над алгоритмами.

А еще довольно неплохо объяснено, почему визуальное программирование было полезно и актуально в 60-е года, но не сейчас, и чем опасно «программирование не-программистами».
Хорошая статья, в общем :)
0
А как же данные

Автор видимо никогда не слышал о бесточечной записи, что как-бы намекает.

0

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


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

0
Тенденция настоящего времени — привлечение внимания к запискам случайных блоггеров, вместо того чтобы переводить хоть и старые, но действительно полезные материалы.
Автор этой заметки путается в определении базовых понятий. По своему определению Computer-aided software engineering (CASE) обозначает проектирование (конструирование/разработку) программного обеспечения, что с «визуальным программированием» связано лишь отдаленно.

Первая проблема заключена в buzzword'е CASE, в настоящее время исчезнувшем даже из рекламных материалов самих некогда «CASE» продуктов. Вероятно, автор имеет в виду не CASE вообще, а UML-средства проектирования. Возникает вопрос — считать ли UML-проектирование «программированием»?

Вторая проблема заключена в слишком обобщенном понятии «программирование», которым тоже можно назвать слишком многое. Отсюда второй вопрос — что именно понимать под «программированием», чтобы делать какие-то выводы?

Третье, это неправильное понимание «полного провала». UML-средства не провалились, они занимают свою нишу корпоративных инструментов с ценой аренды порядка ~$1500/мес.
Впрочем, все это риторика, с целью показать, что ложна уже сама изначальная постановка вопроса. При этом вряд ли стоит обвинять именно автора, т.к. у него указано: “Notepad, thoughts out loud, learning in public, misunderstandings, mistakes. undiluted opinions.”

P.S.
О «декуплицировать».
Крайне неудачное заимствование. Правильно — «ослабление взаимосвязи».
0
Автор просто зашорен, и как то раз увидев детскую игрушечную машинку, почему то решил, что взрослая индустрия производства машинок работает по тем же принципам — следовательно невозможна…
Только полноправные пользователи могут оставлять комментарии. , пожалуйста.