Отправляет email-рассылки с помощью сервиса Sendsay
  Все выпуски  

Усилители интеллекта: теории, эксперименты, технологии


Усилители интеллекта: конструкторы алгоритмов 2

Уважаемые любители интеллектуальных программ!

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

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

Автор всемирно известной серии книг по программированию профессор Д.Э. Кнут в статье "Алгоритмическое мышление и математическое мышление" приводит статистику из разных источников, указывающую, что лишь 2% всех людей "мыслят алгоритмически" — в том смысле, что они могут легко рассуждать об алгоритмических процессах.
Опыт обучения программированию в Уральском педагогическом университете дает несколько лучший процент - там успешно осваивают курс 10-15% студентов, а остальные заучивают материал формально, для экзамена, и могут решать только типовые задачи. Впрочем, оптимизм педагогов в отношении результатов обучения хорошо известен ;0), так что и там вероятно фигурируют те же 2%.

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

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

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

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

Эта идея захватила В. Паронджанова - и ее он яростно пропагандирует в своих книгах. Добавим, что популяризация алгоритмического мышления, обучение программированию чуть ли не с детских садов - это сверхидея многих программистов и педагогов. Вот некоторые из множества проектов такого рода: BlackBox, Small Basic, PascalABC.NET, Algomaker... Уже и гигант Microsoft начинает разворачиваться в этом направлении с проектом Oslo (разработка программ на базе моделей).  Так что с темой этого выпуска мы в фарватере могучей реки! ;0)

Обратимся теперь к ДРАКОНу. В чем его суть?

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

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

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

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

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

  • разбиение алгоритма на простые этапы и размещение их слева направо в хронологическом или логическом порядке облегчает восприятие алгоритма целиком. Тому же способствует и верхняя строка иконок с именами этапов.
  • в схеме этапа основной маршрут действий уложен по вертикали, а варианты - правее. Т.е. первым при чтении схемы вам предъявляется наиболее вероятный вариант.
  • в дракон-схеме нет пересечений и обрывов соединительных линий - она всегда дается целиком, а сложные связи обеспечиваются адресами через общую линию. Кроме того, запрещены наклонные линии - что-то в них уклончивое, знаете ли ;0).

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

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

Несколько замечаний по опыту работы с дракон-редактором Тышова:

  • Когда Вы начинаете работу и открываете новый лист проекта, то по умолчанию на нем возникает заготовка горизонтальной дракон-схемы ("силуэта") - Паронджанов ориентирует именно на такие схемы. Если вам нужны другие заготовки ("примитив" или "гном"), то через контекстное меню можно удалить эту схему и выбрать другую.
  • Чтобы изменить надпись в иконке, щелкаете на ней левой кнопкой мыши - и тогда внизу экрана появляется поле с курсором, куда можно набивать текст. Если поле не появляется, то изменение надписи запрещено.
  • Чтобы добавить ветку слева или справа, нужно при нажатой левой клавише мыши выделить на экране прямоугольник, охватывающий уже имеющуюся ветку, - тогда появляется соответствующее контекстное меню.
  • Для добавления икон в схему щелкаем правой кнопкой мыши на точках ввода (мини-квадратиках) и выбираем пункт "Вставить".
  • Для установления связи адреса, расположенного  внизу ветки 1, с нужной нам веткой 2:
    задаем имя ветки 2 в ее верхней иконке,
    щелкаем правой кнопкой мыши на иконке адреса ветки 1 и выбираем пункт "Адрес: выбрать икону ИмяВетки",
    щелкаем правой кнопкой мыши на иконке имени ветки 2 и выбираем пункт "ИмяВетки: выбрать для иконы Адрес". 
  • При прорисовке узла иконы "Минимизация списка групп возможна?" понадобились операции заземления лианы, изменения порядка Нет-Да и рокировки ветвей. Все эти операции легко достигаются через контекстное меню.

Поупражняйтесь 10 минут с этими шестью операциями - и дракон-редактор раскроет Вам свои дружеские объятья!

* * *

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

Жена говорит мужу-программисту:
- Сходи в магазин, купи батон. Если есть яйца - возьми десяток.
Программист в магазине:
- У вас яйца есть?
Продавец:
- Есть.
Программист:
- Дайте десять батонов.
 

* * *

Вот и всё... Вопросы и замечания mailto:feod@narod.ru

До новых встреч!
Юлий Феодоритов
 


В избранное