Каким должен быть язык программирования? Анализ и критика Описание языка Компилятор
Отечественные разработки Cтатьи на компьютерные темы Компьютерный юмор Прочее

Программирование без программистов — это медицина без врачей

Однажды в книжном магазине ...

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

            И вы покупаете эту книгу и летите с ней к своему начальнику: «Шеф! Смотрите, какую книгу я Вам принёс. Я прочитал название и понял, что это как раз для Вас. Владимир Паронджанов насквозь Вас рассмотрел!». Представьте, как шеф обрадуется предложению подправить свои мозги? Ну а если он откажется умнеть, подарите книгу жене. «Дорогая! Прочти. Ты даже не понимаешь, как эта книга нужна тебе. Именно тебе!»

             Но все почему-то предлагают поумнеть именно вам. Смирившись с участью стать одиноким гением, вы осиливаете эту книжку... В ней рассмотрены важные для программиста вопросы: «Что такое интеллектуальный терроризм» и «Кто такие камикадзе умственного труда». Там даже про «математический терроризм» написано! Ставятся мессианские цели и задачи: каждая кухарка должна уметь программировать («Запомните: программирование должны знать все!» © В.Паронджанов). Нам наконец-то раскрываются глаза: «Кстати, программирование — это тоже деятельность». Такой вывод может сделать только индивидуум, улучшивший работу ума!
Программирование без программистов = медицина без врачей

О тупых кодерах

             Чтобы не оказаться белой вороной, роемся в Интернете и читаем про чудодейственное влияние «Дракона» на идиотов. Добираемся до форума на «Компьютерре», там иногда звучат речи относительно «Дракона»: достаточно нарисовать драконовскую блок-схему — и задача почти решена! Остаётся заполнить все эти ромбики-квадратики операторами языка программирования, и дело сделано! Это можно поручить даже тупому кодеру. И тут что-то зашевелилось в памяти. Когда-то о тупых кодерах я уже слышал.

Страшно далеки были они от двоичной системы счисления ...

             Позвольте здесь отвлечься на лирическое отступление. Однажды в отпуске довелось пообщаться с таким же отдыхающим, слушателем военной академии. В разговоре неожиданно выяснилось, что мы оба «айтишники». Удивились, но в следующий раз об этом вспомнили, когда мой новый знакомый пригласил меня к себе:
— Заходи в 512-й номер.
— Как легко запомнить! — отвечаю.
— А почему легко?
— Ну как почему? Ты же «айтишник», должен знать почему.
— Ну и что, что «айтишник». Что я должен знать?
— Это же 2 в 9-й степени!
— Ну и что? Почему я это должен знать?
— А ты программист или электронщик? Да хоть так, хоть эдак — ты это должен знать...

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

             Через какое-то время я зашёл в этот 512-й номер. Мой знакомый показал мне свою дипломную работу: здоровенные листы ватмана были изрисованы блок-схемами. Тема работы была примерно такая: «Алгоритм действий войск ПВО при отражении воздушного налёта противника». Он мне объяснил, насколько сложна задача. Нужно выявить типы воздушных целей, их штатное вооружение, количество, высоту, скорость и направление. С учётом множества факторов запланировать оптимальное использование имеющихся сил и средств ПВО: авиация, зенитно-ракетные комплексы и проч. Постановка задач этим силам: кто, где, когда и в каком порядке будут действовать войска. Напоследок говорю:
— Конечно, алгоритм сложный. Но ведь его ещё запрограммировать надо.
— Это как раз то не сложно. Подумаешь — программу составить... Алгоритм-то уже готов!
— Думаешь, программировать — это легко? В этом нет ничего сложного? Это тоже непростое занятие...
— Да ладно тебе! Не набивай цену. Сейчас программированию даже в ПТУ учат.

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

«Дракон» = программа — данные

             Но давайте вернёмся к «языку визуального программирования». Блок-схемы схемы страдают одним хроническим недостатком: они описывает только алгоритм! А как же данные?

            В.Ш. Кауфман, «Языки программирования. Концепции и принципы», стр. 42:

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

            Возьмём классику жанра: Д.Кнут, «Искусство программирования», том 3, «Сортировка и поиск». На восьмистах с лишним страницах лишь 23 раза встречается то, что может попасть под определение «схема алгоритма». Зато этот труд просто изобилует рисунками и таблицами, которые можно назвать «схемой данных». Соотношение «схема данных» : «схема алгоритма» более 10:1. Вероятно, это достаточно точная оценка приоритета данных над алгоритмами.

            Программисты нуждаются, в первую очередь, в визуализации данных, а не алгоритмов. Сложны и разнообразны чаще всего именно данные, а алгоритмы вполне тривиальны. Вспомним формулировку Вирта: «Алгоритмы + структуры данных = программы». Если считать алгоритмическую полноту «Дракона» доказанной, то для признания его языком программирования необходимо иметь средства описания данных. Но «Дракон» подобен флюсу: полнота его односторонняя (почти по Пруткову).

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

             «Дракон» напоминает машину времени, застрявшую в 1960-х годах. Он похож на учебник физики 19 века: глава «электричество» уже есть, а глава «электромагнитное поле» — ещё не написана. Изготовленные В.Паронджановым чертежи паровоза великолепны, но несколько запоздали.

Вывод об оптимальности 32-символьных идентификаторов согласуется с анализом истории развития языков программирования, который обнаруживает отчетливую тенденцию: от абстрактных кодов и имен к 8-символьным мнемоническим именам, а затем — к 32-символьным смысловым идентификаторам. Вместе с тем многие программисты, следуя устоявшимся привычкам, “застряли” на этапе 8-символьных имен, так что опыт использования новых возможностей, связанных с разрешением использовать 32 символа, пока еще относительно невелик. Между тем, эргономические перспективы, открывающиеся с увеличением длины до 32 символов, обещают существенно изменить наши прежние представления и привычки, так как благодаря этому замечательному нововведению язык формальных идентификаторов по своей доходчивости значительно приближается к естественному человеческому языку

            Эта цитата из гл. 10 книги В.Паронджанова как раз говорит о том, что «застряли» не программисты, «застрял» таки её автор. Разве это нововведение? Эту тему все давно уже разжевали, переварили и утилизировали. Она уже 30 лет ни нова, ни интересна. А Владимир Даниелович до сих пор открывает нам америки.

Программирование «ступеньками» vs «Дракон»

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

Программирование в эпоху «холодной войны»

            Блок-схему, по мнению Паронджанова, надо рисовать всегда, при этом она должна целиком обозреваться тем, кто её рисует. Если она потребует плаката размеров два на два метра, значит именно такой медиа-носитель и следует выбрать. Стоит заметить, что блок-схемы были популярны тогда, когда программисты не могли иметь компьютеры, а лишь имели «машинное время». Дефицит «машинного времени» был так велик, что программу часто можно было прогнать на ЭВМ только один раз в сутки. Если программа должна быть готова через 30 дней, то её можно было прогнать примерно 30 раз. Студентам при написании программ для курсовых работ давали только 3 прогона. Поэтому к прогону программы тщательно готовились: сперва на бумаге рисовалась блок-схема, потом писалась (тоже на бумаге!) программа, которая тщательно прокручивалась в уме. Ведь положение было безвыходное: «машинное время» страшно дефицитно, поэтому за шанс получить правильно работающую программу боролись всеми доступными способами. Рисование блок-схем было одним из способов «прогона в уме». Но ни один из этих способов умозрительного тестирования не давал гарантий работоспособности.

            Вот как описывает Г. Г. Степанов процесс разработки языка Сигма в 1960-х гг.:

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

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

            Кстати, иногда встречается мнение, что раньше не только трава была зеленее и солнце ярче, но и программы были надёжнее. Потому что их тщательнее обдумывали. Чуть ли не доказывали правильность программ так же, как доказывали правильность теорем. Поэтому написанные программы выполнялись с первого раза. Хочу заметить, что слухи о надёжности ПО того времени сильно преувеличены. Если времени на обдумывание программ было много, то времени на тестирование было как раз очень мало.

            Мой преподаватель по программированию рассказывал об опыте программирования с транслятором Алгол-60:

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

Причиной описанного могла стать как раз нехватка времени для тестирования транслятора: «... бессбойное время работы машины составляло 10 — 15 минут», программисты имели «1 — 2 подхода к машине в сутки».

            Согласен с Паронджановым в том, что хорошее графическое оформление помогает понять суть. Но не согласен в том, что графика имеет главенствующую, в сравнении с текстом, роль. Графика желательна, но роль её второстепенна!

            Если Владимира Даниеловича вооружить карандашами, кистями и прочими «графическими инструментами», смог бы он переписать в графике «Войну и мир» с сохранением глубины авторской мысли? Cнял бы одноимённое кино, немое и без титров? Или глухонемой девушке Кончите из латиноамериканских сериалов своё имя лучше объяснять всё-таки не жестами?

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

            Конечно, В. Паронджанов может возразить, что не надо доводить мысль до абсурда, что Windows разбита на множество модулей и нет необходимости обозревать весь код целиком. Что разбиение программ на логические части позволяет избежать чрезмерного объёма обозреваемого кода. Так и я говорю о том же, читаем далее.

О чём помалкивают предлагающие нам поумнеть

             Среди иконок «Дракона» есть одна такая, которая обесценивает существование самого «Дракона». Она называется «вставка» (глава 6 и 7). О ней пишется как-то вскользь, внимание на ней не заостряется. Эта иконка позволяет разбивать блок-схему на части.

            Умение разбить программу на части — это основа основ профессии программиста. Эти части могут быть функциями, классами, модулями. Программисту зачастую не важно, что там у них внутри. Главное, что они решают ровно ту задачу, которую должны решать. Поставленная задача кажется сложной? Её надо разбить на части! Получившиеся куски опять сложны? Значит надо разбивать ещё! В итоге мы получим множество мелких несложных задач, которые решаются легко. Рисовать же блок-схемы для несложных задач — лишняя трата времени. В итоге «Дракон» не нужен.

            Существует легенда, что в фирме IBM в эпоху текстовых дисплеев (80 x 25 символов) существовало негласное правило, что функция должна целиком помещаться на экран. Возможно ли такое? Конечно, если научиться сводить одну большую проблему к нескольким маленьким. Вот и весь секрет, почему весь мир так легко обходится без блок-схем вообще и без «Дракона» в частности.

            P.S. Цикл «for each» давно не новинка в программировании. Но почему такого цикла нет в «Драконе»? Не потому ли, что цикл «for each» уменьшает количество стрелок в блок-схеме? Т.е. уменьшает «визуальность» программирования и уменьшает потребность в «Драконе»?

            P.P.S. К сожалению, В.Паронджанов очень мало пишет об иконке «вставка». Было бы интересно посмотреть на «вставку» перегружаемых или виртуальных функций. Или рекурсивную «вставку».

Миф об универсальности и всеядности «Дракона»

            В. Паронджанова, «Как улучшить работу ума», глава 1, «Полная декомпозиция программ»:

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

            Из этого утверждения следует, что алгоритм решения задачи является независимым от языка программирования, применяемого внутри иконок «Дракона». Тогда рассмотрим строку SQL-запроса:
SELECT fld1, fld2, fld3 FROM table WHERE fld2 >= 321 ORDER BY fld1, fld2
В блок-схеме при использовании SQL это займёт один квадратик. При использовании языка более низкого уровня придётся рисовать 3 циклических алгоритма:
  • первый в цикле проверяет условие отбора и переписывает данные из указанной таблицы в результирующую,
  • второй занимается сортировкой полученной таблицы по значению fld1,
  • третий цикл внутри второго сортирует по значению fld2.
            И где тут независимость? А если текст SQL-запроса поместить в прямоугольник блок-схемы, то в чём тогда заключается преимущество такого представления теста программы, если он будет состоять из одних прямоугольников? Или программисту надо отказаться от SQL, чтобы наслаждаться блок-схемами «Дракона»? А от регулярных выражений типа
|[-0-9a-z_.]+@[[-0-9a-z^.]+\.[a-z]{2-6}|i
тоже надо отказаться в пользу «Дракона»? А как же его всеядность?

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

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

             В. Паронджанов пишет:

При решении практических прикладных задач инженеры досконально владеют материалом и прекрасно знают постановку задачи. В отличие от них программисты не знают «физику процесса» и становятся «лишними людьми»... Это позволяет ... полностью избавиться от ошибок «испорченного телефона»...

            Хорошо. Допустим, что инженеры хорошо знают свою «физику процесса», но так ли хорошо они знают «математику процесса программирования»? Знают ли они о возможных неочевидных ошибках программирования? Простейшее «a + b» тоже может таить в себе опасность! Это наглядно доказывает Х.Меликян в статье «Клиника плохого кода»:

Попробуем написать очень простую программу (а на самом деле функцию — какая разница?), которая вычисляет среднее значение двух аргументов: int avg(int a, int b) { return (a + b) / 2; } Правильно? Вы конечно узнали язык Си, и скорее всего не заметили в чем тут подвох. Не отчаивайтесь: согласно одному исследованию, подобные вещи не замечают 95% программистов. Дело в том, что при сложении (a + b) может произойти переполнение, когда как результат — ведь он же среднее двух аргументов — никогда не должен переполняться. Значит надо переписать функцию так, чтобы она не была подвержена переполнениям:

int avg(int a, int b) { return a + (b - a) / 2; }

Правильно?
Уже лучше, но опять не то. На этот раз мы забыли, что аргументы могут быть отрицательными. Если, например, один из аргументов будет негативным, то выражение (b - a) может дать переполнение. Проверим так же случай, когда оба негативные — нет, вроде все нормально. Следовательно, окончательная версия нашей функции будет выглядеть так:

int avg(int a, int b)
{
    if (sign(a) != sign(b))
            return (a + b) / 2;
    else
            return a + (b - a) / 2;
}

            

            Забвение такой теории ведёт анекдотическим сбоям в программах. Так, шведская биржа была парализована лотом на покупку -6 фьючерсов: число -6 было истолковано как 4294967290. Стоимость получившегося лота в 131 раз превысила ВВП Швеции. В другом случае француженка получила счет на 12 квадриллионов евро. А вот небезобидный случай: авария ракеты «Ариан-5» из-за ошибки в программе системы инерциальной ориентации. Некорректное преобразование 64-битного числа с плавающей точкой в 16-битное целое со знаком принесло ущерб в сотни миллионов долларов. Если уж профессиональные программисты совершают ошибки с очень серьёзными последствиями, то как можно полагаться на программу, сделанную непрофессионалами в программировании?

            На основании успешных запусков «Бурана» и другой космической техники В.Паронджанов делает вывод об успешности «Дракона», поскольку бортовое ПО было написано с использованием «Дракона». Но почему В.Паронджанов не пишет о постоянных авариях в космической технике, где тоже применяется «Дракон»? То «Фобос» падает на грунт, то полторы тонны лишнего топлива не дали взлететь «Глонассу». Никого не удивляет, когда марсоходы и "Вояджеры" годами бороздят просторы вселенной. И никого не удивляет качество ПО NASA, которое написано без блок-схем. Точно так же не удивляет качество ПО в нашей космической отрасли, которое не реагирует на перелив полутора тонн топлива. А вот 29 октября 1988 года программное обеспечение отменило запуск «Бурана» (он был перенесён на 15 ноября): оно среагировало на нештатную ситуацию. Это ПО было написано на PL/I, без «Дракона»; участие в его написании принимал один из моих бывших коллег. Однако пропаганда «Дракона» одни факты умалчивает, а другие выпячивает.

            Не кроется ли за «Драконом» и «программировании без программистов» желание банально сэкономить? Можно сравнить зарплаты по вакансиям пилюгинского центра (место работы В.Д. Паронджанова) и МЦСТ. Обе организации занимаются прикладной наукой, но разница в зарплатах — раза в три. Только потом эта экономия выливается в позорные аварии.

Чем «Дракон» отличается от блок-схем?

            «Дракон» отличается от традиционных блок-схем другой формой блоков. Красивые иконки — это не повод заявлять о революционности продукта. Но есть ли в нём что-то новое, принципально отличающее его от блок схем? Таковым является такие правила маршрутизации алгоритма, которые исключают пересечение этих маршрутов. В традиционных «текстовых» языках программирования это равносильно исключению из программ операторора «goto». Вот и вся новизна «Дракона». И про эту одну-единственную «революционную» особенность «Дракона» В.Паронджанов написал уже несколько книг! В каком году Дейкстра поднял тему «goto»? И когда В.Паронджанов исключил пересечение маршрутов в блок-схемах?

Есть ли «Дракону» применение?

            Иногда мы сами, без врачей, способны понять, что нужно принять аспирин. Но всегда ли мы готовы претворять в жизнь лозунг «Медицина без врачей»? То же самое и с «Драконом». Каждый продукт может найти свою нишу. Как ни звучало бы нелепо «программист Excel», но умение писать формулы в Excel доступно немногим и в принципе востребовано. Всему своё место.

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

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

            Если бы существовал «Дракон», созданный В.Паронждановым. Но его не существует! Т.е. он где-то есть, на неких мифических для большинства людей компьютерах «Бисер» (хотелось бы фото в студию! Хоть «Бисера», хоть «Дракона» на «Бисере»). Но на самом деле его нет, потому что этот «Дракон» с «Бисером» никто не может купить.

                         Есть сторонние разработки «Дракона». Но ситуация с этими разработками достаточно комична:
  • Сам автор «Дракона» оказался не в силах его реализовать на платформе Wintel. Видимо, чтение книги «Как улучшить работу ума» плохо помогает. Или был плохо интенсифицирован интеллект («интенсификация интеллекта» — © В.Паронджанов).
  • «Дракон» сделали программисты. Как видим, принцип «программирование без программистов» здесь почему-то дал пробуксовку.
  • Эти программисты, начитавшись материалов, которые «носят ярко выраженный рекламный характер» (определение «Википедии»), создали инструмент, который, по идее, должен оставить их без работы. Но почему-то они этого совсем не боятся.


            Есть один замечательный способ написания компиляторов — метод раскрутки, когда компилятор языка пишется на самом языке. Почему-то этот метод оказался неприменим по отношении к «Дракону», несмотря на его универсальность.

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

Википедия — рекламная площадка для «Дракона»


             А можно ли обойтись без «Дракона»? Да запросто! Всего два простых рецепта:
  • разбивайте алгоритм на части; если вы не умеете этого делать, то вы, возможно, ошиблись в выборе профессии;
  • записывайте программу «ступеньками»; это обеспечит достаточный уровень наглядности.

Есть другие способы придать программе большую наглядность?

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

Вместо послесловия

Навеяно аварией ракеты-носителя «Протон-М»: Электроника без электронщиков

Что ещё почитать на эту тему:

Последняя правка: 2016-02-26    14:01

ОценитеОценки посетителей
   ███████████████████████ 16 (53.3%)
   ██████ 4 (13.3%)
   ███ 2 (6.66%)
   ████████████ 8 (26.6%)

Отзывы

     2013/02/10 12:01, Владимир Паронджанов

Я, Владимир Паронджанов, прочитал Ваш материал про язык ДРАКОН.

Написано интересно, остроумно, весело, задиристо. Мне понравилось. Это главное.

Теперь о мелочах.

1. ДРАКОН не так прост, как там написано.

2. Посмотрите статью ДРАКОН в Википедии. Вы удивитесь. Сейчас она выставлена Кандидатом в "Хорошие статьи" Википедии.

3. В 2012 году вышла в свет книга (по ДРАКОНу). Название такое "Паронджанов В.Д. Учись писать, читать и понимать алгоритмы. Алгоритмы для правильного мышления. Основы алгоритмизации. — М.: ДМК пресс, 2012. — 520с. Это учебное пособие по ДРАКОНу.

4. Приглашаю Вас в гости сюда.

     2013/02/17 13:29, Автор сайта

Ещё раз почитал. Там опять об алгоритмах.

Возьмём действие «насади червяка» из Вашего алгоритма «рыбная ловля». «Насади червяка» - ведь это не присвоение какой-то переменной нового значения. Это функция. А функции должны иметь аргументы: какого червяка вы насаживаете? Первого или десятого? А откуда Вы его берёте? Это ещё один аргумент. Третий аргумент - собственно крючок. Функция «насади червяка» - типовое действие, его лучше выполнить в виде отдельного абстрактного действия, чтобы не загромождать алгоритм. Это действие, разбиение сложного на более простое, принято называть декомпозицией.

Декомпозиция в «Драконе» почему-то напрочь игнорируется. Ведь это мощнейший и незаменимый метод борьбы со сложностью систем! Как в «Драконе» обособить некоторые повторяющиеся части алгоритма? Это неправильно, когда одни и те же действия повторяются сотни раз.

Возьмём, к примеру, обобщённое программирование. Ведь это самые что ни на есть алгоритмы. Как в неком множестве выполнить поиск элемента? Как выполнить сортировку? Вот где логично попробовать «Дракон». Но как это сделать с его помощью? Хотелось бы увидеть «живые» примеры из «живых» программ.

     2013/04/07 15:56, Алексей К.

Нашёл в сети
В. Паронджанов: все идентификаторы глобальные

Ему возражают: Глобальные идентификаторы — это крайне ужасно. Про параллелизм можно забыть сразу. А современная тенденция в программировании, и задача, которую не могут пока достаточно эффективно решить — это как максимально делать алгоритмы параллельными. В случае с глобальными идентификаторами хотя бы состояний — без шансов. Как мне сварить параллельно N каш? Да и даже если без параллелизма — тоже будут весьма интересные эффекты при многократном вызове какого либо алгоритма из разных мест.

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

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

     2013/04/08 14:37, Автор сайта

Согласен

     2013/05/05 06:48, Геннадий Тышов

Смотрите материал: "ИС Дракон на Луне".

     2013/05/05 21:21, Автор сайта

Спасибо за ссылку. Регулярно почитываю этот форум. Иногда хочется высказать своё мнение, но… Зарегистрироваться не получается. «Ваша учётная запись в настоящее время неактивна и должна быть одобрена администратором прежде, чем вы сможете войти на конференцию. После активации вашей учётной записи вам придёт ещё одно сообщение». Но оно не приходит. В этом году дважды пытался зарегистрироваться, последний раз – 9 марта.

     2013/05/05 23:10, Автор сайта

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

«Дракон» не на Луне, а лишь в журнале.

     2013/05/16 21:35, 217.113.122.31

Мои 5 копеек: тут пожаловались, что хотели использовать Матлаб совместно с Драконом, но не получается: в Матлабе нет «goto». Реакция Паронджанова:

«Геннадий Николаевич [это программист, который сделал реализацию «Дракона»], в чем дело? Почему возникла несовместимость с Матлабом? Можно ли сделать доработку, чтобы обеспечить совместимость…, чтобы… могли использовать транслятор? Или здесь есть какая-то принципиальная трудность? Если да, то в чем она заключается?»

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

     2013/10/31 05:14, Андрей

В свете вашей статьи особенно прикольно видятся комментарии на форумах в стиле: "забыл, что такое отладка, программы работают с первого раза!", или: "через год понадобилось изменить программу. Открыл алгоритм (в Драконе) через 15 минут все изменил и программа работает". Правда, это все с форумов, посвященным программированию микроконтроллеров. Интересно, у вас без "Дракона" так же получается?
Мой опыт такой - как-то не получалась функция вывода инфы на семисегментник через сдвиговый регистр. Несколько дней промучился. Нарисовал алгоритм в Visio и через пол-часа функция заработала как и планировалось. Тогда я о "Драконе" еще ни чего не знал, а может его еще  и не было.

Для любого продукта своя ниша. Автор, убейся ап стену!

     2013/10/31 18:04, Автор сайта

Вот именно, своя ниша. Мне в «Драконе» не нравится не столь сам «Дракон», сколь его агрессивное навязывание, его реклама как панацеи от всех бед. Инструмент вполне себе нишевый, но его же рекламируют, как универсальный!

Если Вам в работе помогает визуальное представление алгоритма (и «Дракон», как его вариант), то ради бога – я только рад за Вас. Все люди разные, у кого лучше развито абстрактное мышление, у кого-то образное. Кому-то трудно удержать алгоритм в голове, а другим это не сложно.

И я, бывает, при решении каких-то сложных задач берусь за карандаш. Но что характерно – я рисую не алгоритм, а общую картину решения с упором на данные. При этом нет какой-то общей схемы. Так же здорово помогает декомпозиция – разбиение сложных задач на маленькие. Увидеть эти маленькие задачи – это важное умение. Иногда приходится преодолевать себя, чтобы не торопиться, а окинуть задачу взглядом «с высоты птичьего полёта».

Посмотрел свой код: подавляющее число функций имеет условные операторы в количестве от нуля до двух. Зачем для такого короткого кода нужны блок-схемы?

В истории «я после сеанса Кашпировского стал безошибочно программировать» не верю. А в «я стал тщательнее обдумывать и результат – налицо» - вполне.

Не буду желать Вам «апстенного» самоубийства, я Вам лучше пожелаю доброго здравия.

     2013/11/02 14:20, Андрей

В школе нас в первую очередь учили составлять алгоритмы. Тогда мы еще не знали, что есть такая профессия - программист. Тогда мы еще даже не могли представить себе программу на 1000 строк кода. Но уже тогда учительница нам говорила, что любая наша программа должна начинаться с алгоритма! То же самое нам вбивали в техникуме на уроках информатики. Программистов из нас не делали, хотя наш курс назывался "обслуживание и ремонт ЭВМ". Сейчас я инженер-электроник, программированием занимаюсь для себя, в основном микроконтроллерами, и, честно сказать, открывая свои старые тексты программ, я не всегда могу сходу понять как она работает. Некоторые программы я сначала рисовал в Visio. Так спустя несколько лет я открываю алгоритм и сравнивая его с исходником - что-то поменять или просто разобраться дело пары минут, чего не скажешь о простом листинге исходного текста. ИС "Дракон" открыл для себя совсем недавно и еще только осваиваю его, и чувствую, что это именно то, что я подспудно хотел иметь в своих инструментах. Он действительно позволяет систематизировать мысли при обдумывании  будущей программы.

За пожелания "доброго здравия" спасибо! И вам того же.

     2013/11/03 17:35, Автор сайта

Меня тоже учили рисовать блок-схемы. И поначалу ими пользовался. Когда же навыки в программировании стали хороши, отказался от них за ненадобностью. Хотя язык ассемблера, с которого начинал путь программиста, таков, что в нём «программирование ступеньками», как в языках высокого уровня, невозможно.

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

Когда в своё время знакомился с VBA, то уже я возмущался: а где у программы начало и конец? Нас же учили, что у блок-схемы алгоритма программы есть блоки «начало» и «конец», а тут какие-то обрубки. Не понятно, что в какой очерёдности работает. Мне начали говорить, что это объектно-ориентированное программирование, поэтому так выглядит. Я возражал, что в C++ всё равно можно найти начало и конец, хотя там тоже есть ООП. На самом деле, причиной безначальности и бесконечности было событийно-ориентированное программирование.

Если у Вас мало практики в программировании, то читать программы будет естественно трудно. Даже если они свои собственные. Надо комментировать код кратко и ёмко. Ёмко – для того чтобы была понятна вся суть. Кратко – чтобы «за деревьями увидеть лес». Ещё бы мог посоветовать воспользоваться утилитой русификации C++ (если Вы, конечно, пишите на C++): программирование на родном языке снижает порог вхождения. Хотя и тут не без сложностей: почитайте Русский язык и программирование.

Что же касается идей наглядного представления текста программы, то есть некоторые идеи, которые пока остались только идеями: Условные операторы, Переключатель, Циклы, Продолжение цикла и выход из него.

Было бы интересно услышать мнение насчёт блок-схем и «Дракона» профессионалов с большой буквы из «Яндекса», «Лаборатории Касперского» и других наших лидеров. Может, кто-то из журналистов возьмётся за это?

     2013/11/16 11:24, Noname

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

     2013/11/20 01:32, Андрей

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

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

     2013/11/20 07:12, Андрей

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

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

     2013/11/20 12:36, Автор сайта

Алгоритм, которые был в голове, не остаётся там после написания программы в единственном экземпляре. Он получает своё воплощение в самой программе. Хранилищем алгоритма становится не голова программиста, а программа, им написанная. Хочешь узнать алгоритм? Смотри программу! Из программы алгоритм плохо понимается? Надо писать внятные программы. Если программы пишете не Вы, то делать приёмку программы на предмет её читаемости.

где это все разом пропадет (например, человек уволился)

Текст программы остался? Если нет, то плохая организация работы, если да, то алгоритм не исчез.

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

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

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

То, что Вы перед началом работы рисуете эскизы и обдумываете их – просто замечательно. Но в чем разница между Вашими электронными схемами и их исполнения в «железе» с одной стороны и блок-схема и программами с другой? Плату с электроникой Вы видите сразу целиком, на ней вам никто не обведёт в рамки: «это колебательный контур», «это усилитель» и т.д. А программы разбиваются на компоненты очень легко, от этого блок-схема зачастую теряет свой смысл.

Не работает его функция по алгоритму? Повод задуматься о его профпригодности или вменяемости.

Ну так ставьте оценку «2» с занесением в зарплатную ведомость или трудовую книжку.

     2014/06/17 05:25, utkin

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

Да, если все так плохо, то даже не знаю что и думать...

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

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

Ну да, подумаешь, программа 1С удержит с Вас налог за 30 лет и 3 года. Ничего страшного, сиди бухгалтер ищи ошибку, вбивай все цифры заново. Что за бред? Ошибка критична в ЛЮБОМ приложении – офисное, шмофисное – без разницы.

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

     2014/08/20 14:20, itfs

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

     2014/08/21 11:15, Автор сайта

А Вы скачайте ИС «Дракон», написанную Геннадием Тышевым, и попробуйте. Может, понравится. Я смотрел её. На что обратил внимание: алгоритм в «Драконе» хорошо было бы описывать на языке, близком к предметной области. Т.е. записывать термины на русском языке. Но в сгенерированном выходном тексте на целевом языке – латиница. Т.е. происходят некоторые смысловые потери при переходе от языка предметной области к языку программирования.

     2014/09/16 13:41, coder

Мне кажется, что автор ДРАКОНа – такой же теоретик, как болельщики у телеэкрана, которые рассуждают, как правильно играть в футбол. Похоже, что Паронджанов программировал так же много, как эти болельщики играли за команды чуть посерьёзнее, чем дворовые.

     2014/10/09 10:16, Роман

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

А просто критиковать... смысла мало. Как говорил один мой знакомый шизофреник: "Критикуя - предлагай, предлагая - делай")))

С уважением,

     2014/10/12 12:37, Автор сайта

Понравились идеи «Дракона» – скачивайте, пробуйте. Если Вам «Дракон» поможет в работе – я буду рад за Вас. Просто хотелось бы предупредить написанным выше, не всё в рекламе «Дракона» стоит принимать за чистую монету. Критика помогает потребителям сделать более осознанный выбор, а производителей стимулирует к совершенствованию своих изделий.

«Критикуя - предлагай, предлагая – делай». Делаем, работаем, чтобы было что предложить.

     2014/12/12 06:25, Мур

Обожаю, когда сравнивают "теплое" с "мягким".

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

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

Такая вот абстракция.

P.S.
Такие понятия, как код и алгоритм не идентичны.
Сколько я за свою практику видел костылей и прочего разного, не счесть. А почему? А потому, что каждый проект в итоге рождает эдакий диалект которым описана некая концепция.

Новая команда получает код, естественно они могут что-то с ним сделать, но концепция изменится, да и диалект претерпит изменение. И получается, что вместо молотка они последний микроскоп доламывают. Списывая свое недопонимание на тупость предшественников. Ведь предшественники использовали нечто_Игрек, а ведь все крутые кодеры должны юзать нечто_Икс :-)

     2015/01/31 10:44, Игорь

Ох-ох-ох. Даже не знаю – я ведь не программист! Но разрешите и мне вставить словечко: поскольку речь идет о Языке программирования и я, не являясь специалистом в области программирования, являюсь специалистом в области Языка как такового.
Я думаю - это тот самый случай, когда "со стороны виднее".
"Каждый кулик свое болото хвалит".
Мне доводилось встречаться и дискутировать с Параджановым, поскольку в своем языке программирования он обнаружил нечто, что выходило за рамки программирования. С этим нечто он обратился в Институт Философии и мой учитель отправил меня к нему. Мое впечатление от встречи - самое позитивное. Мне пришлось выступить в роли критика его позиции и его реакция на критику была на редкость конструктивной. Мы поняли друг друга и на этом разошлись.
Вы, уважаемые программисты, знаете программирование, но вряд ли кто-нибудь из вас знает то, как работает язык, на котором мы с вами общаемся и как, с помощью языка, вы обретаете саму способность к мышлению. И это не ваша вина: потому что этого не знают даже ведущие специалисты в области языкознания.
Вы спросите - к чему это я? А говорю я это к тому, что вы не увидели за блок-схемами то, что увидел Параджанов. Только мне он об этом говорил открытым текстом, а вам, "чтобы не дразнить гусей", сообщил в завуалированной манере. Возможно он прав: потому что иначе ему бы пришлось столкнуться уже не с "легкими укусами" коллег-программистов, но с критикой более серьезной.
На самом деле речь идет о Революции человеческого языка и мышления и о том, как наладить диалог человека и машины (чтобы они говорили на одном языке и понимали друг друга). Разумеется - это уже из области фантастики, у которой в некотором будущем есть возможность стать реальностью, но проблема диалога человека с искусственным интеллектом безусловно актуальна.
Вы скажете, что для этого существует программное обеспечение, созданное программистами и будете конечно правы. Но это так же будет значить, что вы ничего не поняли. Поэтому вынужден объяснить.
40 000 лет человек разумный общается на вербальном языке. Качество знака (сущность+форма=знак) этого языка является Условным. Однако, эпоха НТР свидетельствует о зарождении качественно нового - Контекстного знака, качественно нового - Виртуального (визуального) языка. Другими словами на смену вербальному языку грядет язык виртуальный.
Условная форма, обозначающая Контекстную сущность, порабощает человеческий интеллект: потому что нарушается Закон Качественного Соответствия Сущности и Формы в знаке коммуникации. То есть мы живем с вами в переходный период от одного знака коммуникации к другому, а это чревато кризисом условного интеллекта.
По сути условный язык - это условная символическая система, а контекстный язык будущего - это контекстная символическая система, в которой контекстная сущность, согласно Закону Соответствия, должна обозначаться контекстной формой.
Заслуга Параджанова заключается в том, что за своими блог-схемами он увидел прообраз языка будущего, который сделает возможным наладить оперативный диалог человека и машины с помощью смысловых визуальных единиц, вмещающих в себя программный код - контекст.
Разумеется у этого подхода есть недостатки и он не учитывает многих аспектов, говорить о которых сейчас не имеет смысла. Так или иначе данные блог-схемы основаны на вербальном коде и, следовательно, о контекстном знаке не может быть и речи.
Вербальный код - это условная форма обозначающая контекстную программную сущность и с данной точки зрения любой вербальный код - это анахронизм.
Полноценного - оперативного диалога с машиной не получится, но возможно создание виртуального языка будущего начнется именно с создания виртуального - визуального языка программирования, основанного не на вербальной - условной, а контекстно-смысловой форме, которая будет понятна не только человеку, но и машине.
Возможно примитивный искусственный интеллект и не сможет оперировать абстрактными категориями человеческого языка, но он будет способен понимать контекстные команды.
Лиха беда начало.

     2015/02/23 13:02, rst256

Ликвидация «бумажного» программирования экономила массу времени, повышала производительность труда в разы.

У каждой медали две стороны... Дети никогда не любят строгих учителей, но часто уже повзрослев с благодарностью вспоминают о них.
И сейчас, гладя как молодые коллеги запускают код на проверку после ввода 2-3 новых строчек, я с благодарю тебя «Бумажное» программирование, спасибо тебе родное, ты научило меня писать программы без ошибок с первой попытки.

     2015/02/25 13:27, Автор сайта

Всему спасибо, что нас когда-то чему-то учило. Вопрос: Вы до сих пор сначала рисуете блок-схему, а потом пишете программу?

     2015/05/14 22:01, ka-va

Уважаемый автор сайта!

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

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

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

Конечно, «Дракон» далек от совершенства, и, к сожалению, его судьба предрешена: закрытый и платный продукт от одного разработчика обречен на небытие. Таких примеров кучи, и даже запоздало сделав их открытыми или бесплатными без ограничений, авторы убивают своих детищ. Взять хотя бы Algorithm Builder - прекрасная идея но... «Дракон» то же в конце пути, и слышно о нем все реже и меньше. Шансы выжить стремятся к 0. Конечно, жалко. Побольше бы таких идей, но Free Open Source плюс коллективный разум.

     2015/05/15 19:29, Автор сайта

Ни Вы, ни я не являемся Гераклами мысли. И для лучшего осознания предстоящей работы рисовать схемы – это правильно. Вот только потребность в схемах данных, как правило, на порядок выше, чем блок-схем. Об этом написано выше. Хотим, допустим, реализовать такую абстракцию, как дерево и функции для работы с ним. Рисуем схему дерева и многое становится прозрачным. А вот алгоритмы после хорошей схемы данных зачастую становятся тривиальны, их просто не хочется уже рисовать – и так всё понятно.

«Дракон», как свободный инструмент, появился недавно, так у него всё ещё впереди, о конце пути говорить ещё рано. Если хороши идеи и реализация, то шансы не нулевые.

     2015/06/01 13:42, Павиа

Маленькие люди – маленькие проблемы. Большие люди – большие проблемы. Вирт создавал свой язык для обучения. И делал его как можно проще. Ассемблер прост: команды и ничего более. Вирт сказал: «Да будут структуры». И сказал, что программы = алгоритмы + структуры. Это то, чему надо учить в первую очередь.

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

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

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

     2016/01/06 13:23, Noname

ИС Дракон как Форт IDE http://fforum.winglion.ru/viewtopic.php?f=2&t=2992&start=0
HiAsm конструктор программ http://hiasm.net/

     2016/01/06 13:38, Noname

Железо для ПО NASA
Чужие: странная архитектура инопланетных компьютеров
http://www.ferra.ru/ru/techlife/review/philae-computer/print/

     2016/03/06 12:36, Геннадий Тышов

Для использования языка Дракон есть "Интегрированная среда Дракон".
Скачать из облака Mail по ссылке: https://cloud.mail.ru/public/ecbde70c784a/%D0%98%D0%A1%20%D0%94%D1%80%D0%B0%D0%BA%D0%BE%D0%BD

     2016/03/06 12:45, Автор сайта

И как успехи, Геннадий? Много ли пользователей у Вашего инструмента? Можете огласить число скачиваний? Просто любопытно :)

     2016/04/11 12:19, Геннадий Тышов

ИС Дракон должен продолжаться. Нужен ли он Вам, решите сами.
Можно Вам помочь. Любопытство не удовлетворяем.

В качестве примера: http://www.sibsiu.ru/KNA/UMM/Informatika/MUDR.pdf - новое пособие по ИС Дракону, напечатано в 2016г., в СибГИУ преподается с 2010 года.

     2016/04/15 16:23, Автор сайта

Любопытство не удовлетворяем.

Напрасно. Ведь

ИС Дракон должен продолжаться.

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

     2016/04/23 15:19, Геннадий Тышов

За место рекламы спасибо. Но самой лучшей рекламой будет отзыв пользователя ИС Дракон. Похоже, здесь таковых нет.

     2016/11/19 12:18, Сергей

Разбираюсь с Дракон редактором недавно. Рекомендую ознакомиться...
http://drakon-editor.sourceforge.net/editor.html#downloads
https://github.com/stavro/drakon-node-chat
Надеюсь, WEB программисты, оценившие NODE JS, оценят и эту возможность редактора Дракон. Написан кстати на TCL/TK, который NASA использует...

     2016/11/20 11:21, Сергей

UML редакторы – хороший продукт, но отсутствуют варианты для генерации кода на новые скрипты javascript и node js. Сегодня программирование шагнуло далеко от тех наработок проекта "БУРАН" и, конечно, не стоит сравнивать UML и Дракон . Но важно другое — результат, а он как раз лучше у "динозавра" с именем "Буран". Сделав два витка вокруг "шарика", он при сильном боковом ветре отклонился всего на метр, а "калибры" с современными возможностями программирования и техники навигации на 1500 км показали отклонение 3 метра . Стоит переосмыслить подходы к программированию.

     2017/03/14 13:29, Прохожий

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

     2017/03/15 10:13, Автор сайта

А что поняли Вы из прочтения этой обсуждаемой книги? Поняли ли Вы, к примеру, что «Дракон» на момент написания книги не был тьюринг-полным языком?

     2017/09/20 09:55, Comdiv

Программирование без программистов - это как математика без математиков, то есть норма жизни, которой следует способствовать. Правда, как таковой ДРАКОН тут ни при чём.

     2017/11/14 23:29, ivan.ee

To Сергей:

Аргументация с "Бураном" слишком слабая. Больше походит на то, что посадка была уж никак не в полностью автоматическом режиме. По крайней мере последние её этапы. Если же по-хорошему, то вообще походит на то, что большинство историй о "Буране" - типичная совковая "утка" из разряда "не имеющее аналогов в мире". При этом на последнюю фразу есть очень хороший анекдот (рассказанный мне единственным реальным инженером-электронщиком, которого я встретил в одном из двух ядерных центров в России – ситуация тоже показательная, когда на весь совковый институт находится только один реальный, а не дутый, человек, который является инженером):
Дикий Запад. Два ковбоя сидят в баре, выпивают. Вдруг с бешеной скоростью мимо бара кто-то проскакивает на коне. Ладно, чё, бывает. Через некоторое время этот же самый проскакивает в обратном направлении.
Тут один ковбой не выдерживает и спрашивает у другого:
— Слышь, а кто это там скачет?
— А-а, да это неуловимый Джо.
— А почему он неуловимый?
— Да потому что он нах*й никому не нужен.

По тему же статьи хотелось бы сказать своё большое спасибо автору. Также хотелось бы высказать свою благодарность за наводку на книгу Raymond E.S. The art of Unix programming (читаю её сейчас) и вообще за то, что открыли мне глаза на то, в каком направлении следует двигаться на пути освоения искусства программирования.

     2017/12/04 09:34, Взгляд со стороны

Здравствуйте!

Посмотри направо, посмотри налево, посмотри вокруг себя не е-байтит* ли кто тебя!

*- в оригинале начкурса говорил другое, ну вы сами догадались.

Почитал отзывы. Каждые стороны правы. Постараюсь донести свою мысль.

Здесь столкнулись те, кто ближе к железу и те, кто к ближе к виртуалам (ЯП высокого уровня). Есть компьютеры общего назначения, а есть спец. назначения (например: БЦВМ самолета). У них разное назначение и разные требования к их работе. В большинстве случаев компьютер спец. назначения – это система реального времени. Максимальное быстродействие, минимальное время отклика на внешние события и т.д. На данный момент "Дракон" больше подходит для микроконтроллеров и к системам реального времени (космос, авиация, авто и т.д., где за каждый грамм лишнего веса идет битва).

Пример на виду, айфон и андроид. "Эпл" проектирует железо и максимум выжимает из него программно, а андроид ложится на железо сторонних производителей. И там и там, есть плюсы и минусы. Если допилить "Дракон" и конкретно, то он может и пригодиться для виртуалов. Хотя его следует пилить для систем реального времени, т.к. где-то прочитал, что телефоны, смартфоны, фото и т.д. подпадают под системы реального времени.

Кажется донес свою мысль!

     2018/01/13 22:37, Геннадий Тышов

ИС Дракон живет и развивается. Изучается в университетах: ссылка для скачивания методички здесь — http://forum.drakon.su/viewtopic.php?f=139&t=5286&p=101115#p101115

     2018/01/14 16:01, Автор сайта

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

А вот в нашем отечестве недавно родился язык программирования Kotlin. Но, несмотря на свой юный возраст, уже добился успехов. Он стал вторым отечественным языком после Рефала, который знаком широкой мировой аудитории. И всё идёт к тому, что он будет весьма успешен.

Хотя о том, что Kotlin будет официально использоваться для разработки под Android сообщили только весной 2017 года, на конференции Google I/O 2017, он уже обрел немалую популярность и полюбился разработчикам. Еще прошлой осенью аналитики компании Realm сообщали, что Kotlin набирает популярность с огромной скоростью. К примеру, в мае 2017 года, до проведения конференции Google I/O, Kotlin использовали 7,4% девелоперов, а к концу сентября 2017 года этот показатель удвоился и составил 14,7%.

Исследователи Realm полагали, что если темпы роста сохранятся на таком же уровне, то уже к декабрю 2018 года доля Kotlin составит 51% рынка, то есть Java потеряет свое лидерство. В настоящее время Kotlin наиболее популярен в Германии, Японии, Индии, США и Бразилии.

В рейтинге Tiobe в январе этого года он на 39 месте с 0.313%.

     2018/01/15 10:59, Геннадий Тышов

Считал и считаю, что «Дракон» — нишевый продукт.

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

ИС Дракон является программой делового назначения. На начальном экране программы сообщается:

Не надейся на память, мысли ускользают, записывай в ИС Драконе.
Для практического алгоритмирования деятельности, знаний.
Для формулирования задач.

Инструмент:
• визуальной техники мышления и общения,
• визуального проектирования деятельности и алгоритмов программ,
• визуального программирования,
• формирования ДАБД - Дракон Алгоритмических Баз Деятельности и данных.

     2018/01/15 11:17, Геннадий Тышов

А вот в нашем отечестве недавно родился язык программирования Kotlin.

Приятная новость, но вроде бы не по теме "Дракона". Хотя, если вы вооружились Kotlin-ом, то предметную область своих задач алгоритмизируйте на Драконе и можете использовать ИС Дракон. Как использовать ИС Дракон для программирования на Kotline, это ваша проблемы, проконсультируйтесь у автора ИС Дракон, рассказывайте о своем положительном опыте.

     2018/01/16 13:48, Автор сайта

Автор сайта имеет ограниченное и ошибочное понимание о назначении Дракона.

Если я не согласен с чьими-то выводами относительно «Дракона», это не повод упрекать меня в некомпетентности. Вот скажите, пожалуйста, в «Драконе» налажен контроль за арифметическими переполнениями, о чём пишется выше в статье? Или и так сойдёт?

ИС Дракон является программой делового назначения

По факту он применяется в вузах — и это логично: такие инструменты нужны новичкам. О деловом применении что-то не слышно. Если б таковое случилось, апологеты «Дракона» все уши об этом уже прожужжали бы.

Приятная новость, но вроде бы не по теме "Дракона".

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

     2018/01/16 20:39, Геннадий Тышов

О Kotlin пишу как о примере успешности технологии. Которая стартовала позже, но добилась больших успехов, нежели предмет обсуждения.".

И Дракон имеет известность, в частности у большого сообщества 1С программистов. Смотрите:
https://infostart.ru/public/504530/#comm
https://habrahabr.ru/post/345320/

"О деловом применении что-то не слышно.".

Смотрите:http://forum.drakon.su/viewtopic.php?p=101019#p101019

Вот скажите, пожалуйста, в «Драконе» налажен контроль за арифметическими переполнениями, о чём пишется выше в статье? Или и так сойдёт?

В Драконе нет такой проблемы, это алгоритмический язык, в нем нет арифметики.

     2018/01/24 21:36, Сергей К.

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

Как ни странно, языком «ДРАКОН» заинтересовался только сейчас. Слышал о нем и ранее, но более предметно стал вникать сейчас. Читаю сейчас книгу «Почему врачи убивают и калечат пациентов». И ни разу не доктор я, а сетевой инженер, хотя суть одна и похожа: найти болезнь и вылечить :-). И мне кажется, для моих задач «ДРАКОН» подходит. Мне как раз нужно формализовать процесс по диагностике и устранению неисправностей, операционной деятельности. Чтобы сменный персонал при устранении сбоев действовал максимально одинаково и не изобретал каждый раз велосипед, вспоминая что и как нужно делать. И мне кажется, что с «ДРАКОНом» это получится. Пробовали ранее в разных нотациях рисовать (в том же ARIS), но получается неудобно, и когда алгоритм действий большой, то возникает путаница. И соглашусь с мыслью, что «ДРАКОН-схема – это красивая, правильно построенная блок-схема».

     2018/02/11 18:43, ivan.ee

Я как-то читал об опыте освоения программирования МК (вроде бы это были AVR ATTiny или ATMega) от полного новичка, используя "Дракон". Сначала человек был в полном восторге — вся программа на виду, всё ясно и понятно. Но как только он стал писать программы чуть сложнее мигания светодиодом и простых обработок нажатия на кнопку, стали возникать проблемы. Короче говоря, чем сложнее программа, тем сложнее стало понимать, что за что отвечает и как внести те или иные изменения. Одним словом — стало сложнее управлять комплексностью программы. После некоторого мучения с "Драконом" человек понял всю бесплодность попыток использовать "Дракон" для написания более-менее сложных программ. И вернулся к, так сказать, традиционным методам программирования. По-моему, эту историю я читал на форуме сообщества easyelectonics.ru года три назад. Жаль, не сохранил ссылку, чтобы потом здесь разместить для сомневающихся.

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

Что в медицине, что у лётчиков, уже давно и очень успешно используются checklists, и я сильно сомневаюсь, что когда-либо их чем-то заменят.

     2018/02/15 17:31, Геннадий Тышов

Я как-то читал об опыте освоения программирования МК (вроде бы это были AVR ATTiny или ATMega) от полного новичка, используя "Дракон"

Это было давно, с того времени изменился ИС Дракон. Появились общеизвестные приемы использования и не стало завышенных ожиданий.

Что в медицине, что у лётчиков, уже давно и очень успешно используются checklists, и я сильно сомневаюсь, что когда-либо их чем-то заменят.

"checklists" это совсем другое, не алгоритм.

     2018/04/02 22:42, rst256

Это было давно, с того времени изменился ИС Дракон. Появились общеизвестные приемы использования и не стало завышенных ожиданий.

Т.е. теперь все в курсе что блок схемы, а следовательно и ИС «Дракон», нельзя использовать для написания более-менее сложных программ? Судя по этому коду (см. ссылку ниже), «Дракон» – это средство для того, что бы писать программы на других языках особым, гораздо более трудоемким, нечитаемым и запутанным способом, исключительно ради самой идеи писать код подобным образом, ибо никакой РЕАЛЬНОЙ выгоды это принести не способно.
http://1.bp.blogspot.com/-rmbBI5rYERg/U2ojFXPqWSI/AAAAAAAACf0/MbaYYNgkMfw/s1600/%D1%81%D0%B8+%D1%83%D1%80%D0%BE%D0%BA2.png

"checklists" это совсем другое, не алгоритм.

"Checklists" – это последовательность действий-проверок т.е. ЛИНЕЙНЫЙ АЛГОРИТМ, а не что-то совсем иное. Их даже можно записать на языке «Дракон», но зачем? Взрослые серьезные дяди не страдающие ГСМ, для которых они и написаны, пальчиком по картинкам с блок схемами водить не будут, это медленно и ненадежно.

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

P.S.
Вот пример чек-листа.
CESSNA 172 CHECKLIST. PRE-FLIGHT INSPECTION. CABIN.
1. Documents – A.R.R.O.W..
2. Control Lock – REMOVE.
3. Ignition Switch – OFF.
4. Avionics Switch - OFF.
5. Master Switch – ON.
6. Flaps – DOWN.
7. Fuel Quantity – CHECK.
8. Master Switch – OFF.
9. Fuel Valve – ON BOTH. EMPENNAGE.
...

Написать отзыв

Написать автору можно на электронную почту mail(аt)compiler.su

Авторизация

Регистрация

Выслать пароль

Карта сайта


Каким должен быть язык программирования?

Анализ и критика

Описание языка

Компилятор

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

Cтатьи на компьютерные темы

Двадцать тысяч строк кода, которые потрясут мир?

Почему владение/заимствование в Rust такое сложное?

Масштабируемые архитектуры программ

Почему Хаскелл так мало используется в отрасли?

Бесплатный софт в мышеловке

Исповедь правового нигилиста

Русской операционной системой должна стать ReactOS

Почему обречён язык Форт

Программирование без программистов — это медицина без врачей

Электроника без электронщиков

Компьютерный юмор

Прочее

Последние комментарии

2018/04/16 15:09, Олег
Русский язык и программирование

2018/04/02 22:42, rst256
Программирование без программистов — это медицина без врачей

2018/03/25 21:14, Денис Будяк
Энтузиасты-разработчики компиляторов и их проекты

2018/03/21 23:37, Marat
Почему обречён язык Форт

2018/03/10 20:05, Comdiv
«Двухмерный» синтаксис Python

2018/02/24 14:51, Эникейщик
Русской операционной системой должна стать ReactOS

2017/12/12 13:32, Comdiv
Отечественные разработки

2017/11/05 17:26, rst256
Электроника без электронщиков