об абстрактном

[avva]

(эта запись - примерный перевод моей же записи в англоязычном блоге)

В новом и довольно интересном блоге математика Джона Армстронга (The Unapologetic Mathematician) появилась запись, объясняющая начала теории групп для широкой публики.

Конечно, подавляющее большинство читателей, не знакомых с математикой на университетском уровне, не смогут понять это введение. Это само по себе довольно очевидно; что менее очевидно - почему Джон Армстронг искренне считает, что написал что-то простое и понятное любому нематематическому читателю (и тут я не пытаюсь как-то его выделить или обидеть: со мной тоже такое случалось в прошлом, да и у множества других людей я наблюдал такое отношение). Желание автора блога объяснить начала "настоящей" математики широкой публике понятно и похвально, но вместе с тем затея обречена на неудачу.

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

Почему? Понятия не имею.

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

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

Второй пример приведу из блога Джоэля Спольского, запись "The Perils of JavaSchools" годичной давности (есть также русский перевод), которая тогда вызвала жаркие дебаты (в целом я, кстати, совершенно согласен с высказанными в ней мыслями). Многим показалось странным, что Джоэль привел указатели (pointers) в качестве жизненно важного понятия для любой академической программы изучения Computer Science. Конечно, верно то, что во многих областях и на многих языках сегодня можно писать вполне "настоящие", сложные программы, которые никак не пользуются указателями. Но тем не менее, говорит Джоэль,

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

Однако тем из нас, кто знает и понимает указатели, не так уж легко понять, в чем, собственно, проблема, как кто-то может не просто, скажем, ошибаться в их применении, но вообще не понять саму идею, даже после многих попыток объяснить. Указатели - абстрактная идея, которую мы усвоили, переварили, сделали частью своего ментального аппарата. Так и математик, усвоивший алгебраические структуры, не понимает, что сам язык, которым он пытается "просто" и "не требуя предварительных знаний" объяснить их широкой публике все равно полон определенных допущений, способов рассуждать, понимания того, что такое множества и алгебраические операции, способности достаточно уверенно манипулировать в уме этими понятиями - итд. итп. - и всего этого у представителя широкой публики просто нет. Я лично считаю очень полезным для себя опыт преподавания начал программирования (языка C) студентам-первокурсникам на компьютерном факультете много лет назад - именно тогда мне пришлось как следует понять и осознать тот факт, что нелегко приобрести понимание того, как другие не понимают, но без него не может быть качественного преподавания.

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

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

Comments

[mfi.livejournal.com]

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

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

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

[ltwood.livejournal.com]

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

[mfi.livejournal.com]

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

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

Можно обобщать как угодно - например, впихать в указатели URLы или порты ввода-вывода или ссылки на обьекты на других машинах. Можно заниматся их учетом, контролем и своевременным уничтожением при помощи различных средств языка, околоязыковых наворотов (те же smart pointers) или мониторов времени исполнения.

Но пока не сменится архитектура, попытки скрыть их существование от новичков - это все танцы с бубнами, и попытки преступные, ИМХО.

П.С. Если я скажу что и код можно менять в процессе исполнения - Вы в обморок не упадете? :-)

[ltwood.livejournal.com]

Смешивание имен массивов с указателями на оные может пугать языковых пуристов, как и нестрогая типизация, но переменная, буфер и указатель на них, лежат глубже языковых средств. [...] Но пока не сменится архитектура, попытки скрыть их существование от новичков - это все танцы с бубнами, и попытки преступные, ИМХО.

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

Они прямое следствие архитектуры машины фон Неймана.

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

Если я скажу что и код можно менять в процессе исполнения - Вы в обморок не упадете? :-)

Не первый год замужем, не упаду ;) Но ИМХО языки должны быть выше архитектуры и все особенности архитектуры должны быть жестко локализованы в системно-зависимых модулях. А пока этого нет, приходится следить за строгой инкапсуляцией всех таких мест, где инкрементируются/вычитаются... указатели и увольнять разработчиков за явное манипулирование ими в коде. Иначе ни о какой надежности говорить не приходится.

P.S. Кстати, на C вполне можно писать и код для процессоров с кембриджской архитектурой, знаете ли...