Каким должен быть язык программирования? Анализ и критика Описание языка Компилятор
Отечественные разработки 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

ОценитеОценки посетителей
   ███████████████████████ 17 (54.8%)
   ██████ 4 (12.9%)
   ███ 2 (6.45%)
   ███████████ 8 (25.8%)

Отзывы

     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/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.
...

     2018/04/25 19:21, Геннадий Тышов

О "Checklists" смотрите по ссылке https://forum.drakon.su/viewtopic.php?f=144&t=6008 тему "ИС Дракон для чек-листов" от Вторник, 11 Апрель, 2017 20:02

     2018/05/23 17:21, Александр Коновалов aka Маздайщик

Как я понял из ссылки на Хабр (https://habrahabr.ru/post/345320/), которую выше скинул Геннадий Тышов, «Дракон» — это некий визуальный препроцессор для того или иного императивного языка программирования (например, JavaScript или C++).

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

«Компиляция» «Дракона» представляет собой порождение императивного кода на целевом языке из диаграммы — конечный код компонуется из диаграммы — содержимое «квадратиков» встраивается в скелет, построенных из обычных if/while/for/goto.

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

Т.е. «Дракон» используется только для визуального описания алгоритмов внутри функций/методов/процедур, структуры данных описываются где-то отдельно.


Кстати, интересная мысль: объединить UML-диаграммы для описания классов с блок-схемами «Дракона».

     2018/05/24 13:25, Автор сайта

обвинения автора сайта ... вызваны плохим пониманием идеи

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

«Дракон» используется только для визуального описания алгоритмов внутри функций/методов/процедур, структуры данных описываются где-то отдельно

Т.е. приведённая выше цитата Кауфмана остаётся остаётся актуальной:

«Дайте мне структуру данных, а уж программу я и сам напишу!»

     2018/05/24 23:26, Александр Коновалов aka Маздайщик

Геннадий Тышов отвечал же выше, что проверок переполнения в «Драконе» не производится.

«Дракон» — надстройка над существующим языком программирования. Если он работает поверх Си++, то проверки переполнения целого не производится, поскольку не производит её C++. Если он работает поверх JavaScript’а, то тоже не производится, потому что в JavaScript’е нет целых чисел, сначала получим потерю точности (для чисел больших 2↑52), а потом уже +INF/−INF (бесконечное вещественное число, особое значение вроде NaN).

Если будет сделан «Дракон» поверх C#, то при использовании режима checked проверка переполнения производиться будет.

Т.е. приведённая выше цитата Кауфмана остаётся актуальной: „Дайте мне структуру данных, а уж программу я и сам напишу!“

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

Кстати, вот Вам другая цитата (по памяти):

«Покажите мне ваши блок-схемы, скрыв таблицы данных, и я останусь в заблуждении. Покажите мне таблицы данных, и блок-схемы будут не нужны, они будут очевидны и так». Фредерик Брукс «Мифический человеко-месяц»

     2018/05/25 23:19, Автор сайта

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

     2018/05/27 16:59, Александр Коновалов aka Маздайщик

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

     2018/05/27 23:08, Автор сайта

А надо ли? Можно, к примеру, сделать транслятор из языка Хаскелл в язык Пролог. В итоге одних выразительных средств не будет хватать, и это приведёт к раздуванию кода. А другие средства останутся невостребованными. Перевод из одной системы координат в другую может пройти с потерями.

И чисто личное: у меня никогда не было проблем с написанием алгоритма. Зачем мне инструмент для решения второстепенных проблем?

     2018/05/31 18:52, rst256

И чисто личное: у меня никогда не было проблем с написанием алгоритма. Зачем мне инструмент для решения второстепенных проблем?

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

     2018/11/11 15:57, Попов Михаил

Паронджанов В.Д. — учитель уровня Кадочникова А.А., Тарасова В.К. ...

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

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

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

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

Кадочников уже не объясняет, а говорит несущему пургу: Вы правы. Повторю слова мастера: Вы правы ...

     2018/11/11 23:28, Автор сайта

Михаил, в вашем сообщении исправил десяток ошибок. Пожалуйста, будьте внимательнее.

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

     2018/11/12 14:18, Попов Михаил

Как много программ Вы написали, применяя «Дракон» или обычные блок-схемы? Сколько тысяч строк кода?

Применяю «Дракон», как только без него не справляюсь. Вот здесь склад черновиков https://drakonhub.com/ide/doc/forall/1
Тыщи не считал. Части кода лежат тут https://inexsu.wordpress.com/

Как часто Вы в своей работе применяете декомпозицию программ?

С августа 2018 https://inexsu.wordpress.com/%D0%BE%D0%BE%D0%BF-%D0%B2%D0%B5%D1%81%D1%82/

Какими парадигмами, кроме императивной, Вы ещё владеете?

Антропологической.

Контролируют ли Ваши программы арифметические переполнения и каким образом они это делают?

Нет. Пользователи ещё не жаловались.

     2018/11/14 12:44, Автор сайта

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

Не густо у Вас на складе.

Тыщи не считал. Части кода лежат тут

И там ошибки

С августа 2018 (ссылка…)

Много заумного мудрствования и якобы философии. А вот тема декомпозиции не раскрыта.

Антропологической.

Википедию, что ли, почитали бы.

Нет. Пользователи ещё не жаловались.

Работоспособность сегодня не даёт гарантий работоспособности завтра.

     2018/11/20 20:13, ivan.ee

Паронджанов В.Д. — учитель уровня Кадочникова А.А.

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

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

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

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

     2018/11/21 08:59, Геннадий Тышов

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

     2018/11/24 00:05, Попов Михаил

Статья уважаемого Автора сайта, где он «изобретал» «Дракон» — «Продолжение цикла и выход из него». Прочитал статью по диагонали, набросал краткий реферат: https://drakonhub.com/ide/doc/forall/54

Мыжежпрограммисты? Сравните описание природы словами и фото. Дракон — фото.

     2018/11/26 12:59, Автор сайта

Эквивалент Вашей блок-схемы:
(Цикл 1
Выход при условии 1
(Цикл 2
Двойной выход при условии 2
Выход при условии 3))
Не правда ли, так лаконичнее?

Сравните описание природы словами и фото. Дракон — фото

А программирование — математика. Весьма специализированный её раздел. Но всё равно математика. Как её изобразить на фото?

     2018/11/30 13:09, Попов Михаил

Лаконично? Да. Понятно? Нет.

Куда ведут Ваши выходы? В какое место алгоритма?

Хорошая схема в разы нагляднее и понятнее хорошего текста, ибо физиология.

математика. Как её изобразить на фото?

«Дракон» про алгоритмы. Не про изобразить невпихуемое.

Где тут подписка на обновления?

     2018/12/01 09:12, Автор сайта

Куда ведут Ваши выходы? В какое место алгоритма?

Программирование ступеньками даёт наглядность. Выход — это на одну ступеньку влево. Двойной выход — на две ступеньки и т.д.

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

Ну так и сложение в столбик нагляднее, чем a+b. Просто после освоения азов мозг переходит на более высокий уровень осмысления абстракций. На элементарных действиях внимание даже не задерживается. Вы прочитайте вышенаписанное, да не по диагонали. Там написано, что на практике схема алгоритма востребована в 10 раз реже, чем схема данных. Всё, что мы с Вами обсуждаем, в той или иной степени уже было затронуто выше.

«Дракон» про алгоритмы. Не про изобразить невпихуемое

«Дракон» — это императивная парадигма. Использование же функциональной парадигмы даёт некоторые преимущества, например, повышение надёжности ПО. Чем больше функциональщины, тем меньше места алгоритмам. Поинтересуйтесь на досуге.

Где тут подписка на обновления?

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

Да и зачем Вам подписка? Если бы Вы были заинтересованы в основной тематике сайта — это было бы совпадение интересов. А так можно констатировать их противоположность.

     2018/12/02 00:21, Comdiv

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

Есть такая разновидность веры. Но подтверждается ли она практикой?

Чем больше функциональщины, тем меньше места алгоритмам.

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

     2018/12/03 13:02, Автор сайта

Есть такая разновидность веры. Но подтверждается ли она практикой?

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

Насчёт «веры» и её разновидностей. Хорошо бы, чтобы программисты не становились сектантами, обращёнными в какую-то «веру», и слышали аргументы извне. Чтобы не было сект Форта, «Дракона», Оберона. Чтобы не далали из того же Оберона культ, где «Отче наш» — «Арифметика синтаксиса», где поют осанну «O santa simplicitas». Надеюсь, функциональное программирование тоже не станет культом. Тем более, что Haskell и прочие — гибридные языки (а не чисто функциональные, чтобы там не рекламировали!), раз без императивщины не могут обойтись.

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

map() и reduce() во многих языках применяет к элементам контейнера какую-то функцию. В императивных же языках это делается в цикле. Цикл — это последовательность операторов, которая имеет ветвления, это можно наблюдать на блок-схемах. map() и reduce() на блок-схеме — это прямоугольники один под другим, не имеющие ветвлений. Таким образом, эти элементы функционального программирования делают блок-схему одномерной. Блок-схема деградирует вплоть до вырожденного состояния — без единого ветвления, с единственным маршрутом. Формально это можно продолжать называть алгоритмом и блок-схемой, а по факту такая блок-схема никому не нужна. Тот же SELECT в SQL — какие ветки в блок-схеме он образует?

А вот как реализованы map(), reduce() и SELECT — это уже детали. Возможно, «под капотом» — это циклический последовательный процесс, а может и параллельный — раскиданный на разные процессоры.

     2018/12/03 17:52, Comdiv

Функциональное программирование стимулирует написание кода, не имеющего состояния. Уменьшение числа состояний в программе уменьшает её сложность

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

Формально это можно продолжать называть алгоритмом и блок-схемой

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

Надеюсь, функциональное программирование тоже не станет культом.

Если Вы на это только надеетесь, то у меня есть плохие новости.

     2018/12/03 23:19, MihalNik

Есть толковая книга Стива Круга по веб-дизайну, где именно на диаграммках показано как правильно делать понятные для людей алгоритмы ИХ действий. Так вот, «Дракон» — язык записи алгоритмов для людей, а не машин. Отдельных алгоритмов, а не многофункциональных приложений. Форма документации, если угодно. По аналогии с некоторыми диаграммами UML.

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

Вот автор написал про то, что для понимания достаточен текст, но сам же в качестве альтернативы блок-схеме написал ПЛОХОЙ текст, потому что возникли вопросы, о том, что значат некоторые слова в этом тексте:
(Цикл 1
Выход при условии 1
(Цикл 2
Двойной выход при условии 2
Выход при условии 3))
Хотя мог бы написать, что, там где нужно, «завершается Цикл 1» или «завершается Цикл 2». Ни текст, ни «ступеньки» не говорят о том, когда именно проверяются условия 1, 2 и 3: в указанном ли порядке или при изменении входящих в них данных в рамках соответствующих областей? Контекст, который никак не выражен явно.

Такой вещи, как идеальный текст, не существует. Как не существует идеального отчаяния.

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

Так начинается «Слушай песню ветра» у Х.Мураками.

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

Отличия «Дракона» от UML обсуждали тут: remdev.org/viewtopic.php?id=240 У них там «универсальный язык моделирования» очень глубоко проработан, а «Дракон» у нас — нет. Но это потому ли, что он изначально плох? Или потому, что развалили и позаморозили проекты, где он применялся? По совершенно другой, независящей от него причины — такой, как всеобщий развал страны?

IBM купила Rational Rose. Та самая компания, в которой был сделан самый первый в мире транслятор с ЯВУ (с Фортрана), получивший практическое применение. Купила разработчика «универсального языка», который ругают за неточность передачи смысла. И автор по сути говорит, что такой язык специфичен. Но расшифровка аббревиатуры UML утверждает, что это не так. И если уже речь шла про совпадение между падающими ракетами и разработчиков «универсальных языков»:

В 1977 Гради Буч закончил обучение в Академии ВВС США. Затем он проходил службу на базе ВВС в Ванденберге, где руководил разработкой целого ряда проектов, управляющих полетом ракет.

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

     2018/12/04 00:48, Попов Михаил

Как Вам не стыдно обсуждать «Дракон» словами!? :-) Вот как надо:
https://drakonhub.com/ide/doc/forall/60

     2018/12/04 13:22, Автор сайта

Это утверждение было бы верно, если бы состояние было бы единственным аргументом некой функции сложности, но это не так.

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

использовали функциональное программирование -> написали программу в R раз быстрей при прочих равных

Я говорил не о скорости, а о надёжности. Но поскольку я и мои коллеги не могут подкрепить или опровергнуть утверждение о надёжности цифрами (впрочем, как и Вы), то остаётся дождаться, что кто-то когда-то соберёт статистику.

Каким образом вы свалили в одну кучу алгоритм и блок-схему?

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

«Поинтересуйтесь на досуге». Это был хороший совет.

Ну хоть одна хорошая оценка. Кстати, Вы интересовались оптимизациями, в которых помогают чистые функции? Об этом говорилось чуть выше. Представьте себе такое: Вы описали в программе функцию, а потом вызвали с входными параметрами, и все параметры — константы. Вопрос: «Вы можете выполнить эту функцию на этапе компиляции, подставив константы? Чтобы вызов функции заменить другой константой — результатом работы этой функции?». Примерно так: вместо sin(π/6) подставить ½. Ответ очевиден: «Нет, потому что функция может оказаться недетерминированной или производящей побочный эффект. Такие функции нельзя выполнять на этапе компиляции». Тогда следующий вопрос: «А если эта функция гарантированно чистая?». Ответ: «Тогда можно».

Языки типа Си или Оберона не могут гарантировать чистоту функции. А вот язык D может, там есть для этого ключевое слово «pure». А в Haskell функции и так по умолчанию чистые. А может ли Оберон обзавестись ключевым словом «pure»? Нет, там взят курс на максимально компактный язык, на минимальное количество правил в языке. А зря, ведь чистые функции имеют и другие замечательные свойства, о которых Вы, думаю, уже читали.

Если Вы на это только надеетесь, то у меня есть плохие новости.

Ничего страшного. Достаточно просто иметь холодную голову и оставаться прагматиком.

     2018/12/06 00:14, Comdiv

Любой инженер, изучавший теорию надёжности систем, скажет Вам

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

Я говорил не о скорости, а о надёжности.

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

Там не куча, а некоторая взаимосвязь.

Это опять не то. Я веду речь о том, что Вы ошибочно противопоставляете код в функциональной парадигме алгоритмам. В то время, как алгоритм не привязан к понятию императивной парадигмы, и алгоритм в функциональной символике всё равно будет алгоритмом.

Ну хоть одна хорошая оценка.

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

Кстати, Вы интересовались оптимизациями, в которых помогают чистые функции

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

Ничего страшного. Достаточно просто иметь холодную голову и оставаться прагматиком.

Недостаточно думать о том, что голова холодная.

     2018/12/06 14:20, Автор сайта

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

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

Всё правильно, f(g(h(x))) — это алгоритм. y=h(x); z=g(y); w=f(z) — это тоже алгоритм. Я так выше и написал:

Формально это можно продолжать называть алгоритмом

Пусть даже и вырожденный до графа, между начальной и конечной вершинами которого — единственный маршрут. Даже попробую угадать: Вам наверняка нравится рисовать блок-схемы для f(g(h(x))).

Напомните, где интересовался

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

А насчёт надёжности — тут можно и поспорить. Ведь объективных, общепризнанных результатов исследований на эту тему не существует.

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

     2018/12/06 16:16, Comdiv

Ну да, если система уменьшила число размерностей с n до n-1

Про размерности- это метафора, а не суть. Поэтому ирония неуместна.

Формально это можно продолжать называть алгоритмом

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

Даже попробую угадать: Вам наверняка нравится рисовать блок-схемы для f(g(h(x)))

Снова юмор. Я никогда не рисую блок-схем, даже в голове. Алгоритм — он алгоритм хоть на Java, хоть на Haskell.

это не утверждение, а вопрос. Просто выше рекомендовал Вам поинтересоваться

Спасибо за рекомендацию. Я знаком с чистыми функциями и использую их на практике даже в Си. Я много ещё с чем знаком, но ещё больше с чем не знаком, конечно. Пожалуйста, не делайте рекомендаций на основании Ваших предположений, о незнании собеседника. Похоже, что из моего сомнения об априорном или основанном на метафорах повышении надёжности от использования функционального программирования, Вы сделали вывод, что я вообще отрицаю пользу вещей, которые ассоциируют с функциональной парадигмой. Хотя мне известно, что начиная с Фортрана, большинство «императивных» языков содержат в себе элементы функциональной парадигмы.

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

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

     2018/12/06 18:21, Автор сайта

ирония неуместна... Круг замкнулся

А что уместно, когда замкнулся круг? Именно ирония уместнее всего!

не формально, а фактически

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

Не привязано понятие алгоритма ни к блок-схемам, ни к графам

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

Алгоритм — он алгоритм хоть на Java, хоть на Haskell

О! Если я Вас правильно понял, то Вы придерживаетесь мысли, что алгоритм — он и в Африке алгоритм, един и одинаков? Хоть он на Java, хоть на Haskell, хоть на ассемблере реализованный? Хоть для 8-битных процессоров, хоть для 64-битных? Что для процессоров с аппаратной реализацией плавающей арифметики, хоть для платформ с отсутствием оной? Что для современных процессоров, что для процессоров IBM/360, где отсутствовала аппаратная поддержка стека? Что при выполнении оператора «SELECT» в SQL, что при выполнении аналогичной задачи на ассемблере?

Я спорю ради установления истины

Ну если Вы так любите истину, то почему не признали, что чистые функции делают возможными оптимизации, которые невозможны в языках без этих функций?

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

не желание бесмыссленно поспорить или посамоутверждаться, а желание улучшить интересный ресурс

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

     2018/12/06 19:47, Comdiv

О! Если я Вас правильно понял, то Вы придерживаетесь мысли, что алгоритм — он и в Африке алгоритм, един и одинаков? Хоть он на Java, хоть на Haskell, хоть на ассемблере реализованный?

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

Ну если Вы так любите истину, то почему не признали, что чистые функции делают возможными оптимизации, которые невозможны в языках без этих функций?

Не в полной мере понимаю, о чём Вы. Конкретно я применяю чистые функции в Си для оптимизаций. Примеры Вы можете найти в документации gcc и в трансляторе, ссылку на который я приводил.

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

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

В любом случае, жму руку.

     2018/12/06 20:29, MihalNik

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

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

     2018/12/07 23:59, Автор сайта

Comdiv Не в полной мере понимаю, о чём Вы. Конкретно я применяю чистые функции в Си для оптимизаций.
MihalNik Они возможны, просто алгоритмы для получения аналогичного конечного результата оптимизации требуются другие.

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

Теперь представим, что Вы написали определение функции «fun(int, int)», а потом вызвали её с константными аргументами: «fun(2, 10)». Вопрос: мы можем вычислить эту функцию прямо во время компиляции? Допустим, у нас есть встроенный в компилятор интерпретатор. Он может вычислить константное выражение и вместо него в выходной код подставить одну-единственную константу? Нет, потому что «fun(int, int)» может оказаться «грязной». Если у вас в языке нет чистых функций, то и гарантий чистоты тоже нет. Почему?

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

Явное же определение чистоты функции (хоть с помощью ключевого слова, хоть по умолчанию) распространяется и на указатели на функции. Поэтому если чистота «fun(int, int)» гарантируется средствами языка, то и в исполняемом коде вызов «fun(2, 10)» можно заменить на константу.

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

     2018/12/08 00:41, Попов Михаил

Я никогда не рисую блок-схем, даже в голове

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

     2018/12/08 02:40, Comdiv

Вы написали определение функции «fun(int, int)», а потом вызвали её с константными аргументами: «fun(2, 10)». Вопрос: мы можем вычислить эту функцию прямо во время компиляции? ... Нет, потому что «fun(int, int)» может оказаться «грязной»

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

     2018/12/08 02:42, Comdiv

Как с такими глюками что-то фантазировать о «Драконе»

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

     2018/12/08 12:49, Автор сайта

почитайте

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

Михаил, не скажите, почему создатели антивируса Касперского, поисковой машины Яндекса, платформы 1С проигнорировали «Дракон»? «Трусость или предательство?» Или у них есть разумные объяснения?

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

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

     2018/12/08 14:56, MihalNik

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

Можно. Даже с передачей указателей вычисление чистоты или нечистоты функции во многих случаях допустимо. Утверждение о невозможности просто абсурдно. Если в стандарте конретного языка и в реализации его компилятора этого нет, это никоим образом не значит, что этого принципиально нельзя сделать в таких случаях. Вот эта функция, например, чистая:
int f(int a,int b){return a+b;}
и если в ней заменить передачу значений ссылками или указателями с последующим разыменованием вручную — функция останется чистой. У Вас, скорее всего, путаница между фактической чистотой функции и передачей информации о чистоте через синтаксис в целях упрощения алгоритмов.

А что, в C++ чистые функции появились?

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

     2018/12/08 18:24, Автор сайта

Да, мне надо было быть точнее в формулировках. В общем случае чистоту функции нельзя определить. А в частных случаях — пожалуйста. Тот же «2+2».

У Вас, скорее всего, путаница между фактической чистотой функции и передачей информации о чистоте через синтаксис в целях упрощения алгоритмов.

Да, я имею в виду чистоту, закреплённую через синтаксис и гарантированную синтаксисом. В противном случае эту чистоту приходится определять.

     2018/12/08 21:22, Геннадий Тышов

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

Убедительным фактом является то, что все шесть лет на сайт приходят люди не согласные с Вами и которым Дракон нужен. От этих людей есть обратная связь и для них: С.Д. Паронджанов пишет очередную книгу (https://drakon.su/_media/zhizneritm.pdf), интегрированная среда ИС Дракон периодически обновляется (http://clc.am/wOt9kg).

     2018/12/08 23:03, Попов Михаил

Не закрыть ли комментирование этой статьи?

Закрывайте. Миссия выполнена. А то несистемная дискуссия про указатели бросает тень на «Дракон».

Я попробовал создать схему некоторых комментариев — но там провалы в рассуждениях и отсылки в никуда. Не справился. Нарисуйте, нарисуйте уже схему своего опубликованного комментария и увидите, УВИДЬТЕ, а не проговорите про себя, где в Ваших рассуждениях нарушения законов мышления. А не увидите, Вам быстрее подскажут, и Вы быстрее поймёте.

Капча прикольная :-)

     2018/12/11 13:47, Автор сайта

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

Михаил, я просил Вас о следующих вещах:

не скажите, почему создатели антивируса Касперского, поисковой машины Яндекса, платформы 1С проигнорировали «Дракон»? «Трусость или предательство?» Или у них есть разумные объяснения?

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

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

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

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

https://forum.drakon.su/viewtopic.php?p=102301#p102301 — В.Д. Паронджанов сообщает:

Доцент Сергей Гусев из Красноярского медицинского университета создал учебное пособие по языку ДРАКОН для врачей. Учебное пособие доцента Сергея Гусева можно прочитать здесь:
https://drakon.su/_media/algoritmy_i_blok-sxemy.pdf

Автор: канд. мед. наук, доц. С.Д. Гусев

Гусев, С.Д. Алгоритмы и блок-схемы в здравоохранении и медицине: учеб. пособие. С.Д. Гусев. — Красноярск: тип. КрасГМУ, 2018. — 122 с.

С.Д. Гусев внес свой вклад в практику алгоритмизации с Драконом. Предложил для контроля алгоритмов использовать "Чек-лист проверки алгоритма". В чек-листе предусмотрено 47 проверок.

     2018/12/11 16:57, Автор сайта

Доцент Сергей Гусев из Красноярского медицинского университета создал учебное пособие по языку ДРАКОН для врачей.

Что в этом удивительного? Вот если бы он написал пособие для пациентов «Лечение без врачей»! Берёт же В.Д. Паронджанов на себя смелость учить программировать без программистов. Пусть Сергей Гусев тоже научит лечить без врачей, и «Дракон» ему в помощь.

     2018/12/11 17:27, Comdiv

Скажите, а математика без математиков возможна? Вы для проведения математических операций, вывода формул, решения уравнений обращаетесь к профессионалам или это сквозной навык, которому учат в школе и который можно использовать не обращаясь к профессиональным математикам?

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

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

     2018/12/13 00:32, Попов Михаил

почему создатели антивируса Касперского, поисковой машины Яндекса, платформы 1С проигнорировали «Дракон»?

Они Вам лично сказали? Где Ваши пруфы? Вот мой пруф https://youtu.be/t8zwdpkSRWs?t=654

О врачах. Четыре года назад я не мог подняться на второй этаж без одышки, завязать шнурки без одышки и т.п. Думал отлежусь, отосплюсь, я же отличник боевой и политической. Становилось хуже. Меня вылечили врачи. Я взялся за ЗОЖ. А один из врачей (старше меня лишь на 4 года) уже умер. От нарушения ЗОЖа. Мне очень жаль. Кто лучше разбирался в медицине?

Даёт нам Кадочников рычаг, даёт нам Паронджанов Дракон — я взял, а Вы как хотите.

Почему я не прошёл мимо? Вот Вы узнаёте, что про Вашу знакомую распространяют недостоверную информацию? Вы пройдёте мимо? Имеете право.

     2018/12/15 15:41, Автор сайта

математика без математиков возможна? … уметь писать без писателей.

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

Они Вам лично сказали? Где Ваши пруфы?

О, будь это не так, об этом бы рассказывали из каждого утюга.

Меня вылечили врачи. Я взялся за ЗОЖ. А один из врачей (старше меня лишь на 4 года) уже умер. От нарушения ЗОЖа. Мне очень жаль. Кто лучше разбирался в медицине?

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

Вот Вы узнаёте, что про Вашу знакомую распространяют недостоверную информацию? Вы пройдёте мимо?

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

     2018/12/15 15:47, Автор сайта

Читаю ностальгическое, «Воспоминания советского программиста». И там блок-схемы упоминаются. Речь идёт о 1970-х, 80-х годах и об «обязаловке» — блок-схемах к сдаваемым в эксплуатацию программам.

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

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

Казалось бы, не нужны, так не пользуйтесь. А действительно не нужны — любой программист, хоть разработчик, хоть представитель заказчика предпочтет посмотреть исходный текст программы, а не эти картинки. Непрограммисту они — тем более до лампочки. И только ГОСТу, в лице его полномочного представителя — нормоконтролера, они нужны. Дороги как произведения изобразительного искусства. Он их проверяет на соответствие требованием оформления — такая-то ширина линий, столько-то миллиметров длина стрелочки, такой-то отступ квадратика от ромбика… Смысл схемы контролеру совершенно недоступен. Можете себе представить, какая халтура там процветала? В нашей конторе (как и в сотнях и тысячах таких же контор по всему Союзу) сидели тетки-чертежницы и тушью на кальках рисовали никому не нужные стрелочки и ромбики. Зато безработицы не было! Уже Союз загибался, но в девяностом году, если не ошибаюсь, успели под занавес выпустить новый ГОСТ все на ту же тему рисования блок-схем. Какая-то навязчивая, неотвратимая мания. Ну да ладно…

     2018/12/15 16:43, Автор сайта

А вот ещё оттуда же, на тему «программирования без программистов»: Программисты-профессионалы и программирующие инженеры.

     2018/12/15 19:04, MihalNik

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

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

     2018/12/15 19:29, Автор сайта

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

     2018/12/16 17:17, Геннадий Тышов

Даю определение назначения языка Дракон — «язык программирования деятельности». Это совершенно новый класс программного обеспечения.

     2018/12/16 19:25, Попов Михаил

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

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

     2018/12/17 12:08, Автор сайта

Вы знаете, лично я такие блок-схемы рисую, что Владимир Даниелович в жизни таких не видывал. Там не только не только алгоритм учитывается, но и связи между данными. Ведь схема данных в 10 раз чаще требуется. Я об этом выше писал, да Вы ж не читаете. А что декомпозиция животворящая творит — Вы даже не представляете. Вы ж не любите делить сложные задачи на простые. Я такие схемы рисую, что «Дракон» — это просто детский лепет! То ли в сторонке отдыхает, то ли нервы успокаивает. Но рисую не на бумаге и не на экране, а в голове. Когда-то давным-давно и я рисовал вживую. Но потом вырос из детских штанишек и перестал. Мы ведь почти все вырастаем: сперва перестаём складывать числа в столбик, потом алгоритм сортировки пузырьком программируем с ходу, без суеты с блок-схемами. Знаете, если мозг тренировать, то много чего можно добиться. Зря Вы не улучшаете работу ума.

И за программистов зря переживаете. Ведь они свои схемы тоже только в голове рисуют. В результате российский экспорт программного обеспечения превышает импорт. Вы лучше со своим «Драконом» ко врачам пожалуйте. Вы ж знаете, что медицина у нас плохая, а вот врачи хорошие. Им всего-то надо прочитать книжку «Как улучшить работу ума». Глядишь — жить начнут дольше пациентов. Идите в академию медицинских наук и каждому академику на стол — книгу «Как улучшить работу ума врачей». В каждую поликлинику — книгу «Лечение без врачей». Будут сопротивляться — носом тыкайте: «Ваш коллега меня вылечил, а сам помер, сердешный. Токмо потому, что не улучшил работу ума».

В качестве упражнения для извилин реализуйте «Дракон»-схему для такого алгоритма на Си:

#include <stdlib.h>
main () {
double x = 0.1;
if (x*6 == 0.6)
printf("Ура! Эта блок-схема работает! 'Дракон' рулит! "\
"Я прав, а критики 'Дракона' неправы, их надо носом потыкать.\n");
else
printf("Ох, я плохо читал книгу 'Как улучшить работу ума'. Надо опять читать. "\
"Критики 'Дракона' правы, а вот я неправ. Меня надо носом потыкать.\n");
return;
}
Запустите эту программу, а потом приходите сюда на сайт да расскажите, что программа Вам сообщила и почему. А если не хотите рассказывать — то что Вам тут делать? Если книга «Как улучшить работу ума» Вам не помогает, значит Вам попался фальшивый экземпляр. Знаете, так бывает. Если Вы читаете-читатете, а обещанный Владимиром Даниеловичем эффект не наступает — так и знайте: Вам контрафактная книга попалась.

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

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

Авторизация

Регистрация

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

Карта сайта


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

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

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

Компилятор

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

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

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

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

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

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

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

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

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

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

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

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

Программисты-профессионалы и программирующие инженеры

Статьи Дмитрия Караваева

●  Идеальный транслятор

●  К вопросу о совершенствовании языка программирования

●  О реализации метода оптимизации при компиляции

●  О реализации метода распределения регистров при компиляции

●  О распределении памяти при выполнении теста Кнута

●  Опыты со стеком или «чемпионат по выполнению теста Кнута»

●  О размещении переменных в стеке

●  Сколько проходов должно быть у транслятора?

●  Чтение лексем

●  Экстракоды при синтезе программ

●  Об исключенных командах или за что «списали» инструкцию INTO?

●  Типы в инженерных задачах

●  Непрерывное компилирование

●  Об одной реализации специализированных операторов ввода-вывода

●  Особенности реализации структурной обработки исключений в Win64

●  О русском языке в программировании

●  Формула расчета точности для умножения

●  Права доступа к переменным

●  Скорость в попугаях

●  Крах операции «Инкогнито»

●  Предопределенный результат

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

Новости и прочее

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

2018/12/17 12:08 ••• Автор сайта
✎ Программирование без программистов — это медицина без врачей

2018/12/07 08:57 ••• Автор сайта
✎ Почему обречён язык Форт

2018/12/07 08:36 ••• Автор сайта
✎ Нужны ли беззнаковые целые?

2018/12/03 13:51 ••• kt
✎ Экстракоды при синтезе программ

2018/11/30 17:56 ••• Freeman
✎ Изменение приоритетов операций

2018/11/30 17:20 ••• Автор сайта
✎ Почему языки с синтаксисом Си популярнее языков с синтаксисом Паскаля?

2018/11/26 14:23 ••• Автор сайта
✎ Так ли нужны операции «&&», «||» и «^^»?

2018/11/18 15:21 ••• Freeman
✎ Устарел ли текст как форма представления программы

2018/11/17 03:28 ••• Comdiv
✎ Изменение длины объекта в стеке во время исполнения

2018/11/16 12:53 ••• Автор сайта
✎ Помеченные комментарии

2018/11/11 14:01 ••• Александр Коновалов aka Маздайщик
✎ Нерабочий код

2018/11/11 13:39 ••• Александр Коновалов aka Маздайщик
✎ О русском языке в программировании