Ось уже деякий час я обмірковую ідею написати книгу про теорію категорій для програмістів. Не комп'ютерних теоретиків, програмістів - швидше інженерів, ніж вчених. Я знаю, що це звучить шалено, і я сам досить наляканий. Я знаю, що є величезна різниця між наукою і технікою, тому, що я працював по обидва боки барикад. Але у мене завжди був дуже сильний порив пояснити речі. Я захоплююся Річардрм Фейнманом, який був майстром простих пояснень. Я знаю, я не Фейнман, але я буду намагатися з усіх сил. Я починаю з публікації цієї передмови, яка повинна мотивувати читача вивчити теорію категорій, і сподіваюся на початок дискусії і зворотний зв'язок.
Я постараюся в декількох параграфах переконати вас, що ця книга написана для вас, і розвіяти всі ваші сумніви в необхідності вивчення цієї, однієї з найбільш абстрактних областей математики, у свій дорогоцінний вільний час.
Мій оптимізм заснований на декількох спостереженнях. По-перше, теорія категорій - скарбниця надзвичайно корисних ідей програмування. Haskell-програмісти черпали з неї вже довгий час, і ці ідеї повільно просочуються в інші мови, але цей процес йде занадто повільно. Нам потрібно його прискорити.
По-друге, є багато різних видів математики, і всі вони призначені для різних аудиторій. У вас може бути алергія на математичний аналіз або алгебру, але це не означає, що вам не сподобається теорія категорій. Не побоюся стверджувати, що теорія категорій - це саме той вид математики, який особливо добре підходить для мислення програмістів. Це тому, що теорія категорій замість того, щоб мати справу з деталями, оперує структурою. Вона оперує такими поняттями, які роблять програми компонованими.
Композиція в самій основі теорії категорій, вона - частина самого визначення категорії. І я стверджую, що композиція - суть програмування. Ми комбінували речі вже дуже давно, задовго до того, як якийсь великий інженер придумав підпрограми. Деякий час тому принципи структурного програмування справили революцію в програмуванні, - вони зробили блоки коду комбінованими. Потім прийшло об'єктно-орієнтоване програмування, суть якого в комбінуванні об'єктів. Функціональне програмування не тільки про комбінування функцій і алгебраїчних структур даних, ще воно робить паралелізм компонованим, що практично неможливо з іншими парадигмами.
По-третє, у мене є секретна зброя, ніж м'ясника, яким я буду шматувати математику, щоб зробити її зрозумілішою для програмістів. Коли ви професійний математик, ви повинні бути дуже обережні, щоб визначити всі ваші припущення точно, виписати кожен вираз належним чином, і будувати всі свої докази строго. Це робить математичні статті і книги надзвичайно важкими для читання непосвяченими. Я за освітою фізик, і у фізиці ми досягли дивовижних успіхів, використовуючи неформальні міркування. Математики сміялися над дельта-функцією Дірака, яка була придумана великим фізиком, П.О. М. Діраком, щоб вирішити деякі диференціальні рівняння. Вони перестали сміятися, коли придумали абсолютно нову галузь аналізу, що формалізує ідеї Дірака і названу теорією розподілів.
Звичайно, за допомогою розмахування руками ви ризикуєте сказати щось відверто невірне, тому я постараюся переконатися, що позаду неформальних аргументів у цій книзі є тверда математична теорія. У мене є потерта копія книги Сандерса МакЛейна «Теорія категорій для математиків» на моїй тумбочці.
Оскільки ця книга про теорію категорій для програмістів, я проілюструю всі основні поняття, використовуючи комп'ютерні програми. Ви, напевно, знаєте, що функціональні мови ближче до математики, ніж більш популярні імперативні мови. У них так само можна створювати більш потужні абстракції. У мене була природна спокуса сказати: ви повинні навчитися Haskell, перш ніж теорія категорій стане вам доступна, але це означало б, що теорія категорій не має ніякого застосування за межами функціонального програмування, а це просто неправда. Отже, я наведу багато прикладів на C++. Звичайно, доведеться подолати потворний синтаксис, і побачити патерни буде складніше через багатослівність, і вам, можливо, доведеться робити багато copy-paste, замість використання абстракцій вищого порядку, але це і так велика частина життя C++ -програміста.
Однак, не все так просто з Haskell. Не потрібно ставати програмістом на ньому, але доведеться його освоїти як мову для замальовок ідей, які пізніше будуть реалізовані на C++. Саме так я і почав програмувати на Haskell. Його короткий синтаксис і потужна система типів дуже допомогли мені з розумінням і реалізацією C++ -шаблонів, структур даних і алгоритмів. Однак, оскільки я не можу очікувати, що читачі вже знають Haskell, я введу його поступово і поясню все на ходу.
Якщо ви досвідчений програміст, ви можете думати: я давно програмую і не турбуюся про жодну теорію категорій або функціональні методи, навіщо ж щось змінювати? Звичайно, ви не можете не помітити, що в імперативних мовах стійкий тренд на додавання нових функціональних можливостей. Навіть Java, бастіон об'єктно-орієнтованого програмування, додала лямбди. C++ нещодавно почав розвиватися шаленими темпами, - нові стандарти кожні кілька років, - намагається наздогнати мінливий світ. Вся ця діяльність - підготовка до руйнівних змін або, як ми, фізики, називаємо це, зміна фази. Якщо ви нагріваєте воду, вона зрештою закипить. Зараз ми перебуваємо в положенні жаби, яка повинна вирішити, чи продовжувати плавання в воді, що нагрівається, або почати шукати альтернативи.
Одна з рушійних сил для великих змін - багатоядерна революція. Переважаюча парадигма програмування, - об'єктно-орієнтоване програмування, не дає вам нічого в області паралелізму, а замість цього заохочує небезпечний і схильний до помилок дизайн. Основні принципи об'єктної орієнтованості: приховування, співволодіння і мутація даних - ідеальне середовище для гонок даних. Ідея об'єднання даних з м'ютексом, який їх захищає, хороша, але, на жаль, блокування не компонуються, і приховування блокувань робить дедлоки більш імовірними і менш налагоджуваними.
Навіть за відсутності паралелізму, зростаюча складність програмних систем відчуває межі масштабованості імперативного програмування. Простіше кажучи, побічні ефекти виходять з-під контролю. Функції з побічними ефектами легко і зручно писати. Побічні ефекти можуть, в принципі, бути закодовані в їх назвах і коментарях. Функція з назвою SetPassword або WriteFile, очевидно, змінює якийсь стан і має побічні ефекти, і ми до цього звикли. І тільки тоді, коли ми починаємо писати функції, що мають побічні ефекти, що працюють з іншими функціями, що мають побічні ефекти, і так далі, тоді речі починають ставати складними. Не те щоб побічні ефекти спочатку погані, погано те, що вони приховані від очей. Через це, в більш великих масштабах, стає неможливим ними керувати. Побічні ефекти не масштабовані, а імперативне програмування повністю побудоване на побічних ефектах.
Зміни в залізі і зростаюча складність програмного забезпечення змушують нас переосмислити основи програмування. Так само, як будівельники великих готичних соборів Європи, ми, в нашому ремеслі, підходимо до меж матеріалів і структури. У Бове, у Франції, є недобудований готичний собор, який стоїть свідком цієї людської боротьби з природними обмеженнями. Задумувалося, що він поб'є всі попередні рекорди висоти і легкості, але в процесі побудови стався ряд обвалень. Від повного руйнування його захищають «милиці»: залізні прути та дерев'яні опори. З сучасної точки зору, диво, що так багато готичних споруд було успішно завершено без допомоги сучасного матеріалознавства, комп'ютерного моделювання, аналізу методом кінцевих елементів і загальної математики та фізики. Я сподіваюся, що майбутні покоління будуть так само захоплені навичками програмування, які ми демонструємо, будуючи складні операційні системи, веб-сервери та інтернет-інфраструктуру. І, чесно кажучи, вони і повинні, тому що ми зробили все це на дуже хлипкій теоретичній основі. Наше завдання - поліпшити ці основи, якщо ми хочемо рухатися вперед.
Милиці, що захищають собор у Бове від руйнування.
Продовження слідує.
Теорія категорій для програмістів: передмову
Категорія: суть композиції
Типи і функції
Категорії, великі та малі
Категорії Клейслі