DRAKON.SU

Текущее время: Четверг, 28 Март, 2024 20:10

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 27 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: Воскресенье, 26 Июль, 2009 13:47 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Я назвал книгу так:
"Дружелюбные алгоритмы, понятные каждому. (Как улучшить работу ума без лишних хлопот)"

Книга выйдет в издательстве ДМК-пресс.
http://www.dmk-press.ru/

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

О чем книга? Это значительно переработанная книга
«Как улучшить работу ума: Алгоритмы без программистов — это очень просто!».

Когда появится книга?

Книга еще не готова, она в работе. Выйдет в свет где-то осенью.

У меня просьба. В книге есть глава «Проект преобразования языков программирования». Я не успел тщательно все обдумать и отшлифовать. Короче, я не удовлетворен этой главой.

Ниже приводится текст главы. Буду благодарен, если вы выскажете критические замечания, укажете на мои ошибки и явные ляпы.
Заранее спасибо за критику.


Последний раз редактировалось Владимир Паронджанов Воскресенье, 26 Июль, 2009 15:23, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 26 Июль, 2009 13:58 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Глава 24

ПРОЕКТ ПРЕОБРАЗОВАНИЯ
ЯЗЫКОВ ПРОГРАММИРОВАНИЯ


Визуализация дает возможность увидеть невидимое — она интенсифицирует процесс научного открытия и способствует рождению глубоких и неожиданных озарений.
Александр Зенкин [1]

ВВЕДЕНИЕ

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

ДВА СЛОВА О ЯЗЫКЕ ПРОЛОГ

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

______________________________________________________
Для нашей цели важно подчеркнуть, что программа на Прологе не содержит управляющих конструкций типа if—then—else, while—do и т.д.
Между тем, управляющие конструкции, преобразованные в графическую форму, являются основной темой данной главы.
_______________________________________________________

УПРАВЛЯЮЩИЕ КОНСТРУКЦИИ

Развилки и циклы играют важную роль при создании алгоритмов и программ.
По мере развития языков программирования развилки и циклы становятся все более сложными (см. языки Ява, Си#, Питон, Перл, Руби, Оберон и т.д.).
Как решить эту проблему?

КАК УПРОСТИТЬ УПРАВЛЯЮЩИЕ КОНСТРУКЦИИ
С ПОМОЩЬЮ КОГНИТИВНО-ЭРГОНОМИЧЕСКИХ МЕТОДОВ?


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

______________________________________________
Особенность эргономических методов состоит в том, что работа человека становится БОЛЕЕ ЛЕГКОЙ, хотя объективная сложность решаемых задач (имеются в виду задачи с развилками и циклами) непрерывно УВЕЛИЧИВАЕТСЯ.
________________________________________________

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

        • Необходимо отказаться от текстовой формы управляющих конструкций, преобразовав их в визуальную форму согласно правилам визуального структурного программирования (см. главу 22);

        • Необходимо отказаться от ключевых (зарезервированных) слов (например, if—then—else, while—do и т.д.), заменив их графикой.

        • В шампур-методе активно используется операция вложения (ввод атома, ввод ветки), а также пересадка лианы и заземление лианы.

        • Графическое представление управляющих конструкций не изоморфно текстовым конструкциям. Оно принципиально отличается от традиционных управляющих ключевых слов.

        • В итоге привычный способ мышления пользователя при разработке алгоритмов и программ существенно меняется и становится более легким. Производительность труда повышается.

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

Рекомендуется использовать визуальные формулы равносильных преобразований алгоритмов (рокировка, вертикальное объединение, горизонтальное объединение). Упомянутые преобразования позволяют упростить дракон-схемы, сделать их более понятными.

Предусмотрены и другие эргономичные приемы (шапка, правило «чем правее — тем хуже») и многое другое.

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

ОТКАЗ ОТ ТЕКСТОВЫХ УПРАВЛЯЮЩИХ КОНСТРУКЦИЙ
В ПОЛЬЗУ УПРАВЛЯЮЩЕЙ ГРАФИКИ


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

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

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

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

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

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

При построении программ с помощью дракон-редактора пользователь не применяет понятия if-then-else, goto и т.д., ибо в этом нет никакой необходимости.

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

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

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

Повторим главную мысль. Текстовые управляющие конструкции (развилки и циклы) умерли. Им на смену пришла значительно более легкая и удобная управляющая графика.

КРИТИКА ЯЗЫКОВ ПРОГРАММИРОВАНИЯ

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

        • В языках программирования имеется слабое звено. Это касается не всех языков, но довольно многих.

        • Слабым звеном языков являются текстовые управляющие конструкции, служащие для организации развилок и циклов.

        • Чтобы устранить слабое звено, необходимо отказаться от использования текстовых управляющих конструкций, заменив их управляющей графикой.

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

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

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

ТРИ ЧАСТИ ЯЗЫКА

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

          • маршрутную;
          • командную;
          • декларативную.

Маршрутная часть языка программирования описывает маршрут движения рабочей точки от начала до конца программы и содержит элементы, организующие линейные, разветвленные и цикличные участки маршрутов. Маршрутная часть строится из управляющих конструкций. Пример управляющей конструкции: if—then—else, while—do и т.д.

Командная часть языка программирования описывает последовательность команд. Пример команды: a:=b+c.

Декларативная часть языка программирования содержит описания данных и классов.

В центр нашего анализа поместим маршрутную часть языка.

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

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

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

ПРОЕКТ
ПРЕОБРАЗОВАНИЯ ЯЗЫКОВ ПРОГРАММИРОВАНИЯ


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

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

Языки, подлежащие изменению, назовем кандидатами. Выберем в качестве кандидатов, например, 10 языков программирования (цифра совершенно условная).

С каждым из кандидатов выполняем следующие действия.

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

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

        3. Командную и декларативную часть языка-кандидата оставляем без изменения. (Имеется в виду, что команды записываются внутри икон дракон-схемы, а декларации — вне икон или даже вне схемы).

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

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

ВЫВОДЫ

1. В языках программирования есть слабое звено.

2. Слабым местом являются текстовые управляющие конструкции, служащие для организации развилок и циклов.

3. Чтобы устранить слабое звено, надо отказаться от текстовых управляющих конструкций, заменив их управляющей графикой.

4. В качестве управляющей графики предлагаются структурные, математически строгие блок-схемы (дракон-схемы).

5. Большинство языков программирования можно разделить на три части: маршрутную, командную и декларативную.

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

7. Проект преобразования языков программирования вкратце сводится к следующему:

        • Проверяем очередной язык, подлежащий изменению, и убеждаемся, что намечаемые преобразования улучшают качества языка.

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

        • Командную и декларативную часть языка-кандидата оставляем без изменения.

8. Дракон-схемы (маршрутная часть языка) позволяют устранить слабое звено языков программирования и за счет этого повысить производительность труда.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 27 Июль, 2009 16:15 

Зарегистрирован: Среда, 13 Май, 2009 21:05
Сообщения: 153
Откуда: Саратов
Владимир Паронджанов писал(а):
УПРАВЛЯЮЩИЕ КОНСТРУКЦИИ

Развилки и циклы играют важную роль при создании алгоритмов и программ.
По мере развития языков программирования развилки и циклы становятся все более сложными (см. языки Ява, Си#, Питон, Перл, Руби, Оберон и т.д.).
Как решить эту проблему?


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

С уважением, Бытко С.Ю.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 28 Июль, 2009 07:15 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 73
Откуда: Россия, Санкт-Петербург
Бытко Сергей писал(а):
Владимир Паронджанов писал(а):
УПРАВЛЯЮЩИЕ КОНСТРУКЦИИ

Развилки и циклы играют важную роль при создании алгоритмов и программ.
По мере развития языков программирования развилки и циклы становятся все более сложными (см. языки Ява, Си#, Питон, Перл, Руби, Оберон и т.д.).
Как решить эту проблему?


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

С уважением, Бытко С.Ю.

Очевидно, что проблема усложнения развилок. Т.е. множественный выбор явный (IF, CASE) и завуалированный (исключения).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 28 Июль, 2009 14:06 

Зарегистрирован: Вторник, 27 Май, 2008 13:24
Сообщения: 155
Владимир Паронджанов писал(а):
УПРАВЛЯЮЩИЕ КОНСТРУКЦИИ
Развилки и циклы играют важную роль при создании алгоритмов и программ.
По мере развития языков программирования развилки и циклы становятся все более сложными (см. языки Ява, Си#, Питон, Перл, Руби, Оберон и т.д.).
Как решить эту проблему?
А разве как раз не эту проблему уже (в значительной мере) разрешил ДРАКОН? Автор, представляется, намеренно преувеличивает трудность проблемы (на данном именно этапе) и тем поднимает значительность её найденного решения- ДРАКОНа. Пиар вещь конечно нужная, но здесь он похоже несколько грубоват и тем может вызвать негатив, обратную реакцию. Вряд ли они (развилки и циклы) становятся всё более сложными. Всё более сложными становятся структуры данных, "сущности". ДРАКОН здесь ещё и "не валялся".
Проблема по-видимому заключается в замене служебных имён и конструкций графическими образами дабы убрать из текстовой части т. н. "синтаксический мусор". Пока ДРАКОНу удалось это сделать только для конструкций маршрута (if - else, while..).

Пролог не знаю, но, судя по листингам, служебных конструкций в нём не меньше чем в императивных языках. С точки же зрения отсутствия "синтаксического мусора" ближе всего к идеалу по-видимому не пролог, а FORTH. Но именно это качество делает его код труднопонимаемым, ведь "синтаксический мусор" на самом деле не мусор, а подсказки чем являются, к чему относятся "немусорные" имена, слова. Значит отказываться от "мусора" всё же не есть хорошо.
А проблема, похоже, заключается в переносе по возможности всех текстовых синтаксических "подсказок" в графику. UML это делает.. ну не очень внятно, не столь гениально-просто как ДРАКОН для маршрутной части. Невнятность эта проистекает возможно из-за изначально иной классификации сущностей, нежели это потребно более простецкому "нашенскому" менталитету.
То есть следующая действительно проблема для ДРАКОНА - по отношению к языкам программирования- визуализация структур данных. Желательно столь же гениальная и "нашенская" как для маршрутной части.
Для ПРОЕКТА ПРЕОБРАЗОВАНИЯ ЯЗЫКОВ ПРОГРАММИРОВАНИЯ потребуется для начала выделить множество наиболее существенных и простейших структур данных самых наоборот неэкзотических языков, анализ, выделение необходимейшей и "ведущей" и одновременно простейшей "структуры порождающей структуры" (или нескольких первоэлементов, "клеток"), поиск визуального образа для неё, путей визуального строительства из неё прочих.. Страшно сказать, это задача уровня таблицы Менделеева :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 28 Июль, 2009 16:42 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 143
Откуда: Россия, Орёл
dvuugl писал(а):
Владимир Паронджанов писал(а):
УПРАВЛЯЮЩИЕ КОНСТРУКЦИИ
Развилки и циклы играют важную роль при создании алгоритмов и программ.
По мере развития языков программирования развилки и циклы становятся все более сложными (см. языки Ява, Си#, Питон, Перл, Руби, Оберон и т.д.).
Как решить эту проблему?
...Пиар вещь конечно нужная, но здесь он похоже несколько грубоват и тем может вызвать негатив, обратную реакцию. Вряд ли они (развилки и циклы) становятся всё более сложными
Согласен


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 28 Июль, 2009 18:28 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Да, так утверждать нельзя.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 28 Июль, 2009 19:21 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Огромное спасибо всем, кто высказал критические замечания.

Наиболее обстоятельно высказал свою критику dvuugl.
В качестве объекта для критики dvuugl выделяет мои слова:

Цитата:
УПРАВЛЯЮЩИЕ КОНСТРУКЦИИ
Развилки и циклы играют важную роль при создании алгоритмов и программ.
По мере развития языков программирования развилки и циклы становятся все более сложными (см. языки Ява, Си#, Питон, Перл, Руби, Оберон и т.д.).
Как решить эту проблему?


Dvuugl пишет:

Цитата:
А разве как раз не эту проблему уже (в значительной мере) разрешил ДРАКОН?


Отвечаю:
1. Я пишу только об уже найденных решениях в рамках Дракона. И ни на миллиметр не осмеливаюсь выйти за эти рамки
2. В книге ни слова не говорится о каких-либо новых решениях.
3. Я исхожу из того, что к общественном мнении Дракон не существует. Количество публикаций о Драконе недостаточно. Проще говоря, он неизвестен.
4. Поэтому можно было просто ограничиться переизданием книги. Но есть нерешенная задача. Это очень скромная задача: ОБЪЯСНИТЬ ТО, ЧТО УЖЕ ЕСТЬ. Но объяснить по возможности более выпукло, более тщательно, более подробно.
_______________________________________________

Dvuugl пишет:

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


1. Признаюсь, я не понял это место. Буду благодарен, если dvuugl, Евгений Темиргалеев и коллеги мне объяснят поподробнее.

2. dvuugl пишет:
Цитата:
Автор, представляется, намеренно преувеличивает трудность проблемы (на данном именно этапе) и тем поднимает значительность её найденного решения- ДРАКОНа.


Что мне непонятно? Я пишу о проблеме, которую можно решить с помощью Дракона. Я просто обязан рассказать об этой проблеме. Я обязан показать ее значимость (преувеличить, как говорит dvuugl). Я обязан поднять значительность её найденного решения — ДРАКОНа.

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

Уважаемый dvuugl! Я не понимаю, как я могу обойтись без указания на значимость проблемы.

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


Эту фразу я не смог понять. Простите, но я действительно не понимаю, что имеется в виду. Просьба, если можно, объяснить.

_________________________________________________

Dvuugl пишет:
Цитата:
Вряд ли они (развилки и циклы) становятся всё более сложными.

Эту фразу я тоже не очень-то понимаю.

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

__________________________________________________

Dvuugl пишет:

Цитата:
Всё более сложными становятся структуры данных, "сущности".


Согласен полностью. Это сложнейшая проблема.
Хочу, однако, включить тормоз.
Я к этой проблеме НЕ ИМЕЮ НИ МАЛЕЙШЕГО ОТНОШЕНИЯ.
Я решал частную задачу о маршрутах, развилках и циклах.
И не более того.

Dvuugl совершенно правильно ставит вопрос.
ОН РАССМАТРИВАЕТ ПРОБЛЕМУ ЦЕЛИКОМ, ВО ВСЕЙ ЕЕ МНОГОСЛОЖНОСТИ.

Но эта сложная, грандиозная проблема, поставленная Dvuuglом, состоит из частей.
Из этой грандиозной проблемы я рассматриваю ТОЛЬКО ЧАСТЬ.

Остальная часть (или, правильнее сказать, остальные части) ОСТАЮТСЯ ЗА РАМКАМИ МОЕГО АНАЛИЗА. И за рамками моей книги.

___________________________________________________

Dvuugl пишет:
Цитата:
ДРАКОН здесь ещё и "не валялся".


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

Я же не осмеливаюсь делать это, не осмеливаюсь замахиваться на столь сложную задачу. Я о ней даже не упоминаю. Почему? Потому что не имею на это ни малейшего права.
_______________________________________

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

Возможно, что dvuugl считает незаконным и недопустимым выражение «Проект преобразования языков программирования».

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

Что такое выражение недопустимо и неуместно использовать для решения рассматриваемой мною частной задачи о развилках и циклах.

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

Для удобства Вашей критики привожу точную цитату

Цитата:
ПРОЕКТ
ПРЕОБРАЗОВАНИЯ ЯЗЫКОВ ПРОГРАММИРОВАНИЯ

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

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

Языки, подлежащие изменению, назовем кандидатами. Выберем в качестве кандидатов, например, 10 языков программирования (цифра совершенно условная).

С каждым из кандидатов выполняем следующие действия.
1. Проверяем языки-кандидаты, и убеждаемся, что намечаемые преобразования действительно улучшают качества языка (делают его более выразительным, более понятным и удобным для работы).
2. Преобразуем маршрутную часть языка-кандидата (то есть, превращаем текстовые управляющие конструкции в управляющую графику). Маршрутную часть желательно делать универсальной для всех языков-кандидатов
3. Командную и декларативную часть языка-кандидата оставляем без изменения. (Имеется в виду, что команды записываются внутри икон дракон-схемы, а декларации — вне икон или даже вне схемы).

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


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

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

Или дело вовсе не в выражении «Проект преобразования языков программирования»?
Может быть, дело в чем-то другом? Просьба пояснить.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 28 Июль, 2009 22:50 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 143
Откуда: Россия, Орёл
Касательно себя уточняю: подписался под тем, что следующую фразу не считаю правильной.
Владимир Паронджанов писал(а):
По мере развития языков программирования развилки и циклы становятся все более сложными (см. языки Ява, Си#, Питон, Перл, Руби, Оберон и т.д.).
Мне кажется, достаточно указать, что:
- развилки и циклы в текстовых языках записываются по-разному.
- ДРАКОН предлагает одинаковое для всех графическое изображение, более наглядное, интуитивно понятное и т.п.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 29 Июль, 2009 09:43 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Евгению Темиргалееву

Критическое замечание с благодарностью принимаю.
Исправлю обязательно.
Формулировку после исправления дам после обдумывания


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 29 Июль, 2009 10:19 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
"Задача ОБЪЯСНИТЬ ТО, ЧТО УЖЕ ЕСТЬ".
и
"ПРОЕКТ ПРЕОБРАЗОВАНИЯ ЯЗЫКОВ ПРОГРАММИРОВАНИЯ"
как-то не особо стыкуются.. Народ, мало зная о Драконе, может просто не понять - зачем ещё и языки программирования менять, раз уже декларирован отказ от текстовых конструкций в пользу графики..

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


Последний раз редактировалось Рэйлвэй Каген Среда, 29 Июль, 2009 12:47, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 29 Июль, 2009 12:22 

Зарегистрирован: Среда, 13 Май, 2009 21:05
Сообщения: 153
Откуда: Саратов
Владимир Паронджанов писал(а):
Какой эффект будет получен в результате реализации проекта? Предположительно, повышение производительности труда и все, что с этим связано.


Мне кажется, надо подробнее расписать эффект, например, снижение числа критических ошибок и т.п.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 14 Август, 2009 11:34 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Приношу искреннюю благодарность всем, кто высказал
свои замечания.

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

Я принял решение полностью переработать главу,
то есть переписать ее заново.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 17 Август, 2009 16:05 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Опираясь на ваши замечания,
я полностью переработал текст главы.

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

Заранее благодарю за критику.

Переработанный текст главы приводится ниже


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 17 Август, 2009 16:24 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Глава 24

ЧТО ДЕНЬ ГРЯДУЩИЙ НАМ ГОТОВИТ?
(Проект преобразования
алгоритмического языка)


Визуализация дает возможность увидеть невидимое — она интенси-
фицирует процесс научного открытия и способствует рождению глу-
боких и неожиданных озарений.
Александр Зенкин [1]

ЦЕЛЬ ПРОЕКТА —
РАЗВИТЬ АЛГОРИТМИЧЕСКОЕ МЫШЛЕНИЕ
КАК СОЦИАЛЬНО НЕОБХОДИМЫЙ НАВЫК


Одна из важнейших задач книги состоит в следующем:

• Подвергнуть критике существующие (традиционные)
способы представления алгоритмов (но не программ);

• Предложить новый способ представления алгоритмов
(имеется в виду алгоритмический язык Дракон);

• Подчеркнуть, что существует возможность во многих
или даже в большинстве случаев полностью отказаться от тради-
ционных способов представления алгоритмов и безболезненно
заменить их на язык Дракон;

• Для обозначения отказа от традиционных способов
в пользу языка Дракон мы используем термин «Проект преоб-
разования алгоритмического языка»;

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

• Мы не рассматриваем практическую реализацию Проекта
как некую бюрократическую процедуру, требующую вмешательства
каких-либо влиятельных инстанций или авторитетных кругов;

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

• Проект будет осуществляться по мере распространения све-
дений о языке Дракон в результате добровольного решения и свобод-
ного волеизъявления людей, проявляющих интерес к данной теме;

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

• Важным каналом распространения информации о Драконе явля-
ются различные форумы в сети Интернет, публикации и т.д.

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

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

ТРАДИЦИОННЫЕ СРЕДСТВА ЗАПИСИ АЛГОРИТМОВ УСТАРЕЛИ
И ПРЕВРАТИЛИСЬ В ТОРМОЗ РАЗВИТИЯ ОБЩЕСТВА


Для наших целей необходимо развести два понятия:

• алгоритмический язык (именно на нем мы сосредоточим
внимание в данной главе);

• языки программирования (о них будет лишь кратко упомя-
нуто в конце главы в «Проекте преобразования языков программиро-
вания»).

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

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

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

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

По нашему мнению, большинство программистов недооценивает важность
проблемы, связанной с умением создавать сложные алгоритмы, пригодные
для быстрого понимания ЧЕЛОВЕКОМ.

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

Какие же средства предлагает нам традиция для записи алгоритмов (но не
программ)?
К числу наиболее известных можно отнести:

        • псевдокод (pseudo code);
        • блок-схемы алгоритмов (flowcharts).

ЧТО ТАКОЕ ПСЕВДОКОД?

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

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

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

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

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

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

Некоторые фрагменты псевдокода могут быть фразами естественного
языка (русского, английского и т. д.).

Нередко в псевдокоде применяют управляющие конструкции таких
языков программирования, как Паскаль, Си, Фортран и др. Их исполь-
зование можно объяснить как личными симпатиями авторов, так и рас-
пространенностью на момент написания книги или статьи.

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

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

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

Текст этой процедуры на псевдокоде занимает 12 страниц книги
[2, с. 120—131]. Легко убедиться, что запись сложного алгоритма
на псевдокоде создает неоправданные помехи для понимания и
требует значительных затрат труда и времени.

Итоговые замечания:

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

• Недостатки псевдокода являются продолжением его
достоинств. Сюда относятся принципиальная невозможность
стандартизации и принципиальная невозможность общепринятой
формализации управляющих структур.

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

БЛОК-СХЕМЫ АЛГОРИТМОВ

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

Действующий международный стандарт на блок-схемы (flowcharts)
ISO 5807—85 выпущен в 1985 году [3]. Отечественный стандарт
ГОСТ 19.701—90 [4] является точной копией международного.

По нашему мнению, указанные стандарты имеют множество
недостатков и являются устаревшими.

Существуют и другие средства для записи алгоритмов. В некоторых
англоязычных учебниках наряду с псевдокодом и блок-схемами
используются диаграммы Насси-Шнейдермана (см., например, [5]).

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


В медицинском руководстве [6] приведены блок-схемы диагно-
стических алгоритмов клинических синдромов, наиболее часто
встречающихся в общей врачебной (семейной) практике. В руко-
водстве представлены блок-схемы 24 диагностических алгорит-
мов, в том числе: остро возникшая головная боль, хроническая
головная боль, головокружение, синкопальное состояние, нару-
шение остроты зрения, красный глаз, боль в ухе, боль в горле,
боль в груди и т.д.
_________________________________________________________________________

ДОСТОИНСТВА И НЕДОСТАТКИ БЛОК-СХЕМ

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

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

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

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

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

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

ПРИЧИНЫ
МАССОВОЙ АЛГОРИТМИЧЕСКОЙ НЕГРАМОТНОСТИ


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

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

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

Допустима ли подобная алгоритмическая неосведомленность? В чем
причина алгоритмической неграмотности? Неграмотности подавляю-
щего большинства специалистов?

Это важный вопрос. Чрезвычайно важный.

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

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

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

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

ЧТО ДОЛЖНО СТАТЬ
ЧАСТЬЮ ПРОФЕССИОНАЛЬНОЙ КУЛЬТУРЫ
СПЕЦИАЛИСТОВ-НЕПРОГРАММИСТОВ:
АЛГОРИТМИЗАЦИЯ ИЛИ ПРОГРАММИРОВАНИЕ?


Наша позиция такова:

• Надо глубоко осознать разницу между понятиями «алго-
ритмизация» и «программирование».

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

• Массовое обучение алгоритмизации, наоборот, полезно
и необходимо.

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

ТРАДИЦИОННЫЙ АЛГОРИТМИЧЕСКИЙ ЯЗЫК
И ЯЗЫК ДРАКОН


Под традиционным алгоритмическим языком мы понимаем все
традиционные средства, предназначенные для записи алгорит-
мов (но не программ). Сюда относятся: псевдокод, блок-схемы
алгоритмов, диаграммы Насси-Шнейдермана и др.

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

Алгоритмический язык Дракон содержит две части: формальную
и неформальную. Первая является математически строгой. Вто-
рую пишут на естественном языке.

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

По этой причине язык Дракон претендует на то, чтобы стать меж-
дународным стандартом, принятым в соответствии с процедурами
Международной организации по стандартизации (International Stan-
dard Organization).

ЗАКЛЮЧИТЕЛЬНЫЕ ЗАМЕЧАНИЯ
ПО «ПРОЕКТУ ПРЕОБРАЗОВАНИЯ
АЛГОРИТМИЧЕСКОГО ЯЗЫКА»


Ниже указаны наиболее важные свойства и особенности алгорит-
мического языка Дракон. Он позволяет:

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

• изображать вложенные, последовательные и парал-
лельные алгоритмы.

• изображать логические элементы И, ИЛИ, НЕ и слож-
ные логические функции;

• преобразовывать логические элементы и сложные
логические функции из текстовой формы в визуальную и обратно;

• использовать эквивалентные преобразования алгорит-
мов (рокировка, вертикальное объединение, горизонтальное объе-
динение) для улучшения эргономических характеристик алгорит-
мов;

• изображать базовые управляющие структуры визуаль-
ного структурного программирования;

• строить алгоритмы из базовых управляющих структур;

• изображать алгоритмы реального времени с использо-
ванием элементов управления временем: пауза, период, пуск тай-
мера, синхронизатор по таймеру, параллельный процесс;

Концепция языка Дракон опирается на так называемый шампур-
метод. Напомним его основные черты:

• Необходимо отказаться от текстовой формы управля-
ющих конструкций, преобразовав их в визуальную форму сог-
ласно правилам визуального структурного программирования
(см. главу 22);

• Необходимо отказаться от текстовых управляющих
операторов (например, if—then—else, while—do и т.д.), заменив
их управляющей графикой.

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

• Графическое представление управляющих конструкций
не изоморфно текстовым конструкциям. Оно принципиально отли-
чается от традиционных управляющих ключевых слов.

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

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

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

На этом мы заканчиваем рассмотрение Проекта преобразования
алгоритмического языка.

ПРОЕКТ ПРЕОБРАЗОВАНИЯ ЯЗЫКОВ ПРОГРАММИРОВАНИЯ

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

Возможен ли аналогичный проект для программирования?

Можно ли говорить о Проекте (хотя бы частичного) преобразова-
ния языков программирования?

Это сложный вопрос. И у нас нет готового ответа.

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

ОТКАЗ ОТ ТЕКСТОВЫХ УПРАВЛЯЮЩИХ КОНСТРУКЦИЙ
В ПОЛЬЗУ УПРАВЛЯЮЩЕЙ ГРАФИКИ


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

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

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

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

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

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

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

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

При построении программ с помощью дракон-редактора пользова-
тель не применяет понятия if-then-else, goto и т.д., ибо в этом нет
никакой необходимости.

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

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

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

Повторим важную мысль. В языке программирования Дракон текс-
товые управляющие конструкции (развилки и циклы и др.) полно-
стью устранены. Им на смену пришла значительно более легкая
и удобная управляющая графика.

ТРИ ЧАСТИ ЯЗЫКА ПРОГРАММИРОВАНИЯ

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

          • маршрутную;
          • командную;
          • декларативную.

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

Маршрутная часть строится из управляющих конструкций.
Пример управляющей конструкции: if—then—else, while—do
и т.д.

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

Командная часть языка программирования описывает после-
довательность команд. Пример команды: a:=b+c.

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

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

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

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

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

Или такой подход следует признать спорным или даже ошибочным?

Ниже мы будем иметь в виду такие языки, как например, Ява, Си#,
Питон, Перл, Руби, Ада, Оберон и др.

КРИТИКА ЯЗЫКОВ ПРОГРАММИРОВАНИЯ

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

• В языках программирования имеется слабое звено. Это
касается не всех языков, но многих.

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

• Чтобы устранить слабое звено, необходимо отказаться
от использования текстовых управляющих конструкций, заменив
их управляющей графикой.

• В качестве управляющей графики предлагаются структур-
ные, математически строгие блок-схемы — дракон-схемы.

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

ГИПОТЕТИЧЕСКИЙ ПЛАН
ПРЕОБРАЗОВАНИЯ ЯЗЫКОВ


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

Этим слабым местом являются текстовые управляющие конструкции,
организующие маршрутную часть языка.

Языки, подлежащие изменению, назовем кандидатами. Выберем в
качестве кандидатов, например, 10 языков программирования (цифра
совершенно условная).

С каждым из кандидатов выполняем следующие действия.

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

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

3. Командную и декларативную часть языка-кандидата остав-
ляем без изменения. (Имеется в виду, что команды записываются вну-
три икон дракон-схемы, а декларации — вне икон или даже вне схемы).

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


ВЫВОДЫ

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

2. Для обозначения отказа от традиционных способов в поль-
зу языка Дракон используется термин «Проект преобразования алго-
ритмического языка».

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

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

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

6. Конечный результат Проекта подразумевает широкое рас-
пространение алгоритмического мышления и преодоление ныне суще-
ствующей массовой алгоритмической неграмотности.

7. Большинство программистов недооценивает важность проб-
лемы, связанной с умением создавать сложные алгоритмы, пригодные
для быстрого понимания ЧЕЛОВЕКОМ.

8. Блок-схемы алгоритмов, псевдокод и другие традиционные
средства не позволяют преодолеть нынешнюю массовую алгоритми-
ческую неграмотность.

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

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

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

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

13. В отличие от традиционных средств для описания алгорит-
мов (псевдокода, блок-схем и др.) визуальный синтаксис язык Дракон
опирается на безупречную математику и серьезные эргономические
проработки. По этой причине язык Дракон претендует на то, чтобы со
временем стать международным стандартом, принятым в соответ-
ствии с процедурами Международной организации по стандартиза-
ции (International Standard Organization).

14. Проект преобразования алгоритмического языка позволяет
создать задел для Проекта частичного преобразования языков прог-
раммирования.

15. В языке программирования Дракон текстовые управляю-
щие конструкции (развилки и циклы и др.) полностью устранены.
Им на смену пришла значительно более легкая и удобная управля-
ющая графика.

16. Большинство языков программирования можно разделить
на три части: маршрутную, командную и декларативную.

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

18. В языках программирования имеется слабое звено. Это ка-
сается не всех языков, но многих.

19. Слабым местом языков является маршрутная часть.

20. Чтобы устранить слабое звено, необходимо отказаться -
от использования текстовых управляющих конструкций, заменив
их управляющей графикой.

21. Проект преобразования языков программирования вкратце
сводится к следующему:

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

        Командную и декларативную часть языка-кандидата оставляем
        без изменения.


22. В качестве управляющей графики предлагаются структур-
ные, математически строгие блок-схемы — дракон-схемы.

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

ЛИТЕРАТУРА

1. Зенкин А. А. Когнитивная компьютерная графика. М.: Наука, 1991.
С. 19.

2. Саркисян А.А. Повышение качества программ на основе автомати-
зиро-ванных методов. М.: Радио и связь, 1991. С. 120—131.

3. ISO 5807—85. Unified System for Program Documentation. Data,
program and system flowcharts, program network charts and system re-
sources charts. Documentation symbols and conventions for flowcharting.

4. Гост 19.701—90. Единая система программной документации.
Схемы алгоритмов, программ, данных и систем. Условные обозначения
и пра-вила выполнения.

5. Robertson L.A. Simple Programm Design. A Step-by-step Appro-
ach. Fourth edition. Thomson, Australia, Canada, Mexico…, 2004.
Русский перевод: Робертсон Л.А. Программирование — это просто.
Пошаговый подход. Перевод с 4-го английского издания. М.: Бином
Лаборатория знаний, 2008.

6. Практическое руководство для врачей общей (семейной)
практики. Под редакцией академика РАМН И.Н. Денисова. М.: ГЭОТАР-
МЕД, 2001. — 720с.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 18 Август, 2009 11:14 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
В конец предыдущего сообщения я ввел два дополнения:
          Выводы
          Литература


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 18 Август, 2009 16:40 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 143
Откуда: Россия, Орёл
Владимир Паронджанов писал(а):
Нынешние алгоритмы, используемые во всем мире, имеют серьезный
дефект. Они чрезвычайно трудны для понимания.
Мне кажется, более точно будет так: Нынешние формы представления алгоритмов, используемые во всем мире, имеют серьезный дефект...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 18 Август, 2009 16:51 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 143
Откуда: Россия, Орёл
Владимир Паронджанов писал(а):
Четкое разделение понятий «программы и алгоритмы» означает, что мы рассматриваем языки программирования как средство для записи программ, но не алгоритмов. Языки программирования не приспособлены для записи алгоритмов. Поэтому мы исключаем их из рассмотрения.
...
Массовое обучение программированию невозможно и не нужно по двум причинам. Во-первых, оно неимоверно трудно. Во-вторых, оно дает знания, которые большинству просто не нужны.
...
В обществе знаний во многих случаях возникает острая необходимость формализовать собственные процедурные профессиональные знания специалистов.
Здесь нужно уточнить смысл "разделение понятий «программы и алгоритмы»", если ранее он не уточнён. Я понимаю смысл текста так: программа - запись алгоритма на языке программирования для исполнителя (алгоритма) компьютера. Когда идёт речь о передаче профессиональных знаний нужно уметь записать/изобразить алгоритм для исполнителя человека.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 18 Август, 2009 17:10 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 143
Откуда: Россия, Орёл
Владимир Паронджанов писал(а):
Рассмотрим случай, когда на псевдокоде записан многостраничный алго-
ритм. Например, «Алгоритм Global_Value_Numbering, реализующий проце-
дуру обнаружения неэффективных мест в программе на основе глобального
метода нумерации значений».

Текст этой процедуры на псевдокоде занимает 12 страниц книги
[2, с. 120—131]. Легко убедиться, что запись сложного алгоритма
на псевдокоде создает неоправданные помехи для понимания и
требует значительных затрат труда и времени.
....

В медицинском руководстве [6] приведены блок-схемы диагно-
стических алгоритмов клинических синдромов, наиболее часто
встречающихся в общей врачебной (семейной) практике. В руко-
водстве представлены блок-схемы 24 диагностических алгорит-
мов, в том числе: остро возникшая головная боль, хроническая
головная боль, головокружение, синкопальное состояние, нару-
шение остроты зрения, красный глаз, боль в ухе, боль в горле,
боль в груди и т.д.
Было бы очень хорошо предложить для сравнения ДРАКОН-схемы этих алгоритмов. Можно было бы создать на каждый по теме на форуме с предложением желающим помочь перевести их на ДРАКОН. Владимир Даниелович, можете указать ссылки на электронные версии этих изданий или выложить сканы страниц, где изложены эти алгоритмы?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 21 Август, 2009 11:34 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 42
Откуда: Бердск
Владимир Паронджанов писал(а):
Использование принципов объектно-ориентированного программирования еще более усугубляет проблему алгоритмизации. Оно исключает возможность целостного восприятия сложной алгоритмической картины. И превращает сложные алгоритмы в кусочно-рваную мозаику, непригодную для быстрого понимания


Владимир Даниелович, мне понятно, что в данной цитате речь идет именно о текстовом представлении ООП.
Но это мне понятно, потому-что я все (из Вами представленного) прочитал.
Мне кажется, что было бы правильнее употребить прилагательное "текстовое" либо в этом, либо - в предыдущем (не далее) абзаце.

Так мне кажется, потому-что для визуального представления ООП -- у меня как раз другое мнение, прямо противоположное.
А для текстового -- согласен с Вами, сам через это проходил, практически.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 27 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 7


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2024, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB