Как заварить чашку чая?
Вот расскажите мне, как заварить чашку чая? По-простому, из пакетика.
Я задавал этот вопрос нескольким людям - со словами «дайте мне инструкцию, научите меня». Чаще всего это выглядело примерно так:
- Берем чашку, берем пакетик, кладем в чашку. Заливаем водой из чайника.
- А если в чайнике вода холодная?
- Ну, тогда сначала кипятим.
- А если там воды нет?
- Тогда наливаем, потом кипятим, потом заливаем. Но если ты хочешь, чтобы чай был правильный, то сначала надо, чтобы чашка была горячая...
Пошагово действуя по этой инструкции, я сначала залью пакетик холодной водой, потом сожгу чайник, включив его без воды, потом все-таки заварю чашку чая, и тут же узнаю, что чай получился неправильный и надо начинать сначала. А ведь задачка-то не такая уж и сложная.
Нормальный человек не способен сформулировать простой пошаговый алгоритм действия:
- Если в чайнике вообще нет или слишком мало воды, то налить ее
- Если вода в чайнике холодная, то вскипятить ее
- Если нет чистой чашки, то вымыть грязную
- Взять чистую чашку
- Налить полчашки горячей воды, дабы согрелась
- Положить в чашку пакетик, долить водой
- Ждать минуту, болтать пакетик
- Выкинуть пакетик
Большинство людей не обладают навыками алгоритмического мышления, до сих пор массово эти навыки есть только у программистов. Неспособность обычного человека сформулировать такую простую инструкцию была замечена довольно давно. Лет эдак много (20? 25?) назад Шеля Губерман и Лёня Кузнецов придумали язык программирования Либрал. В этом языке переменные можно было объявлять где угодно (в т.ч., после первого использования), исключительные ситуации (в чайнике нет воды) обрабатывать не до, а после их возникновения и т.п. - язык был расчитан на использование людьми, которые не могут разместить проверку исключительной ситуации перед основным действием, а сначала рассказывают самое главное. Я не знаю, в какой мере им удалось реализовать проект, продолжения у него не было, но многие из тогдашних идей уже давно реализованы в мейнстримовых языках - переменные объявлять вообще не обязательно, а обработку исключений (exception) действительно можно выкинуть в конец процедуры (try/catch блоки, On Error Goto и т.п.).
Либрал был хорошей идеей, но сейчас становится понятно, что двигаться-то надо, как раз, в противоположном направлении. Надо учить людей алгоритмическому мышлению, учить писать исполнимые инструкции и действовать по инструкциям, учить переключаться между разными типами мышления в зависимости от ситуации и текущих потребностей.
Сегодня в школах алгоритмическое мышление присутствует только на уроках информатики. Ни в математике, ни в физике его нет, там все происходит на «естественном» языке, всяческая теория автоматов и прочая алгоритмика в школьную математику не попадает. Но даже и на уроках информатики детей не учат алгоритмическому мышлению - их сразу учат программировать. 80% детей оказываются не в состоянии воспринять основные конструкции, необходимые для написания программ, поскольку алгоритмическим мышлением не владеют - они перестают воспринимать предмет с самого начала, происходит полное отторжение. Остальные 20% (а может и меньше, процентов 5-10) по каким-то причинам («врожденная» предрасположенность, случайность, родители, хороший учитель, в конце концов) схватывают базовый навык алгоритмического мышления (т.е., необходимость продумывать и обрабатывать исключения до, а не после), и дальше для них информатика оказывается чрезвычайно простой наукой. Но их - 5, 10, максимум 20%. В результате информатика оказывается маргинальным предметом, и алгоритмическое мышление вместе с ней. До сих пор подавляющее большинство детей, заканчивающих школы, не обладают базовыми навыками алгоритмического мышления, т.е. не способны сформулировать простейшую пошаговую инструкцию.
Вы думаете, эти навыки нужны только программистам? Почитайте законы. Почитайте нормативные акты, инструкции, почитайте какие-нибудь письма Минфина, описывающие правила, алгоритмы и методики ведения бухучета. Почитайте регламенты и правила в государственных органах и частных компаниях. Все эти документы написаны людьми, которые не очень сильны в обработке исключительных ситуаций. Послушайте, как какой-нибудь менеджер, бригадир или прораб объясняет своему сотруднику, что тот должен делать. А еще веселее - найдите менеджера, бригадира или прораба, способного сформулировать пошаговую инструкцию со всеми исключительными ситуациями, и посмотрите на его сотрудника, когда он будет пытаться воспринять эту инструкцию! Ведь навыка восприятия алгоритмов тоже нет.
PS. Хоть я и наехал выше на идею обработки исключений в конце процедуры, это действительно одна из важнейших инноваций, случившихся в программировании за последние 20 лет. Но связано это не только, а может быть и не столько с тем, что исключения удобно обрабатывать после основного действия, а не до него. Такая конструкция позволяет обрабатывать неучтенные ошибки. Например, описанная выше процедура заваривания чая предполагает, что в кране есть вода. Если ее там нет, то при обращении к крану произойдет исключительная ситуация, которая, в отличие от отсутствия воды в чайнике, автором алгоритма не учтена, и алгоритмом не обрабатывается. Для таких ситуаций пишется универсальный обработчик, который, как правило, показывает пользователю сообщение «Произошла такая-то ошибка, я не знаю, что делать дальше, думай теперь сам». По сути дела, такое сообщение есть переключение в другой тип мышления - алгоритмическое мышление (исполнение четкой инструкции) перестало работать, и нужно включать другое, начинать думать. И это - владение несколькими типами мышления и способность переключаться между ними по мере необходимости - и есть тот самый важнейший навык, которым нужно стремиться овладевать.
Я задавал этот вопрос нескольким людям - со словами «дайте мне инструкцию, научите меня». Чаще всего это выглядело примерно так:
- Берем чашку, берем пакетик, кладем в чашку. Заливаем водой из чайника.
- А если в чайнике вода холодная?
- Ну, тогда сначала кипятим.
- А если там воды нет?
- Тогда наливаем, потом кипятим, потом заливаем. Но если ты хочешь, чтобы чай был правильный, то сначала надо, чтобы чашка была горячая...
Пошагово действуя по этой инструкции, я сначала залью пакетик холодной водой, потом сожгу чайник, включив его без воды, потом все-таки заварю чашку чая, и тут же узнаю, что чай получился неправильный и надо начинать сначала. А ведь задачка-то не такая уж и сложная.
Нормальный человек не способен сформулировать простой пошаговый алгоритм действия:
- Если в чайнике вообще нет или слишком мало воды, то налить ее
- Если вода в чайнике холодная, то вскипятить ее
- Если нет чистой чашки, то вымыть грязную
- Взять чистую чашку
- Налить полчашки горячей воды, дабы согрелась
- Положить в чашку пакетик, долить водой
- Ждать минуту, болтать пакетик
- Выкинуть пакетик
Большинство людей не обладают навыками алгоритмического мышления, до сих пор массово эти навыки есть только у программистов. Неспособность обычного человека сформулировать такую простую инструкцию была замечена довольно давно. Лет эдак много (20? 25?) назад Шеля Губерман и Лёня Кузнецов придумали язык программирования Либрал. В этом языке переменные можно было объявлять где угодно (в т.ч., после первого использования), исключительные ситуации (в чайнике нет воды) обрабатывать не до, а после их возникновения и т.п. - язык был расчитан на использование людьми, которые не могут разместить проверку исключительной ситуации перед основным действием, а сначала рассказывают самое главное. Я не знаю, в какой мере им удалось реализовать проект, продолжения у него не было, но многие из тогдашних идей уже давно реализованы в мейнстримовых языках - переменные объявлять вообще не обязательно, а обработку исключений (exception) действительно можно выкинуть в конец процедуры (try/catch блоки, On Error Goto и т.п.).
Либрал был хорошей идеей, но сейчас становится понятно, что двигаться-то надо, как раз, в противоположном направлении. Надо учить людей алгоритмическому мышлению, учить писать исполнимые инструкции и действовать по инструкциям, учить переключаться между разными типами мышления в зависимости от ситуации и текущих потребностей.
Сегодня в школах алгоритмическое мышление присутствует только на уроках информатики. Ни в математике, ни в физике его нет, там все происходит на «естественном» языке, всяческая теория автоматов и прочая алгоритмика в школьную математику не попадает. Но даже и на уроках информатики детей не учат алгоритмическому мышлению - их сразу учат программировать. 80% детей оказываются не в состоянии воспринять основные конструкции, необходимые для написания программ, поскольку алгоритмическим мышлением не владеют - они перестают воспринимать предмет с самого начала, происходит полное отторжение. Остальные 20% (а может и меньше, процентов 5-10) по каким-то причинам («врожденная» предрасположенность, случайность, родители, хороший учитель, в конце концов) схватывают базовый навык алгоритмического мышления (т.е., необходимость продумывать и обрабатывать исключения до, а не после), и дальше для них информатика оказывается чрезвычайно простой наукой. Но их - 5, 10, максимум 20%. В результате информатика оказывается маргинальным предметом, и алгоритмическое мышление вместе с ней. До сих пор подавляющее большинство детей, заканчивающих школы, не обладают базовыми навыками алгоритмического мышления, т.е. не способны сформулировать простейшую пошаговую инструкцию.
Вы думаете, эти навыки нужны только программистам? Почитайте законы. Почитайте нормативные акты, инструкции, почитайте какие-нибудь письма Минфина, описывающие правила, алгоритмы и методики ведения бухучета. Почитайте регламенты и правила в государственных органах и частных компаниях. Все эти документы написаны людьми, которые не очень сильны в обработке исключительных ситуаций. Послушайте, как какой-нибудь менеджер, бригадир или прораб объясняет своему сотруднику, что тот должен делать. А еще веселее - найдите менеджера, бригадира или прораба, способного сформулировать пошаговую инструкцию со всеми исключительными ситуациями, и посмотрите на его сотрудника, когда он будет пытаться воспринять эту инструкцию! Ведь навыка восприятия алгоритмов тоже нет.
PS. Хоть я и наехал выше на идею обработки исключений в конце процедуры, это действительно одна из важнейших инноваций, случившихся в программировании за последние 20 лет. Но связано это не только, а может быть и не столько с тем, что исключения удобно обрабатывать после основного действия, а не до него. Такая конструкция позволяет обрабатывать неучтенные ошибки. Например, описанная выше процедура заваривания чая предполагает, что в кране есть вода. Если ее там нет, то при обращении к крану произойдет исключительная ситуация, которая, в отличие от отсутствия воды в чайнике, автором алгоритма не учтена, и алгоритмом не обрабатывается. Для таких ситуаций пишется универсальный обработчик, который, как правило, показывает пользователю сообщение «Произошла такая-то ошибка, я не знаю, что делать дальше, думай теперь сам». По сути дела, такое сообщение есть переключение в другой тип мышления - алгоритмическое мышление (исполнение четкой инструкции) перестало работать, и нужно включать другое, начинать думать. И это - владение несколькими типами мышления и способность переключаться между ними по мере необходимости - и есть тот самый важнейший навык, которым нужно стремиться овладевать.