ADT — это просто. Серьёзно. Не обязательно легко доступно для понимания, но очень просто по сути.
Есть примитивные типы, которые имеют только один экземпляр. Есть их суммы (объединение множеств значений) и произведения (декартово произведение множеств значений). Есть параметрический полиморфизм: Bool не паметризован ничем и живёт сам по себе, Maybe a параметризован типом элемента. Всё. Больше в ADT нет ничего. Это намного меньше, чем то, что есть в системах типов классических ООП-языков, и при этом позволяет добиться схожей (а зачастую даже большей) гибкости. Где здесь создание проблем? Налицо устранение некоторых проблем сложности, присущих другим системам типов.
Монады и функторы пришли в программирование из теории категорий, и, действительно, монады изначально были призваны решить проблему языка Хаскель, хотя и никак не связанную с алгебраическими типами данных: проблему работы с IO в чистом функциональном языке. Только спустя некоторое время нашлись многие другие применения этого полезного в хозяйстве, хм, паттерна. Оказалось, что монады — это остроумный способ решения многих других проблем, не связанных с IO. Просто ещё один способ композиции вычислений, как и функтор, и аппликативный функтор, и всё в таком духе. Больше способов композиции — больше возможностей писать композабельные системы — налицо loose coupling.
Разумеется, это всё, вероятно, не попадёт в мэйнстрим ещё очень долго. Отчасти из-за высокого порога вхождения, отчасти из-за того, что бизнес предъявляет несколько отличные от внутренней простоты требования. Бизнесу нужна лёгкость. Лёгкость замены и обучения разработчиков, доступность инструментов и так далее. Остроумных решений этой проблемы теория категорий нам, к сожалению, пока не предложила.
Киллер-фича ADT, на мой взгляд — это простота в сочетании с гибкостью.
Классы смешивают воедино идентичность, состояние и поведение. Это сложно (не тяжело для восприятия, а просто объективно сложно: много сущностей, с которыми нельзя работать по отдельности)
Структуры недостаточно мощны: тип классических структур не может быть параметризован, и структуры представляют из себя произведение типов, но никогда — сумму (то есть если взять значение типа A И значение типа B, то можно получить значение структуры, содержащей A и B, но нельзя создать структуру, которая бы хранила значение типа A ИЛИ значение типа B)
ADT же просты, так как являются просто данными, без всяких смешений с какими-то идентичностями да поведениями, и при этом достаточно гибки, так как позволяют создавать сумму/произведение (алгебраическую композицию) других типов, да ещё и с параметрическим полиморфизмом (как в дженериках .net или java).
Благодаря этим двум свойствам ADT позволяют выразить очень много полезных типов данных и при этом достаточно удобно с ними работать посредством сопоставления с шаблоном, без написания горы методов для доступа к ним.
Например, в статье выше, определив в одну строку простейший тип данных Maybe, мы получили:
1) Параметризованный «контейнер» для 0 либо 1 элемента
2) Два конструктора: Just :: a -> Maybe a и Nothing :: Maybe a
3) Два «деконструктора» с аналогичными именами, которые используются при сопоставлении по шаблону и позволяют избежать условных операторов/операторов ветвлений, а также сравнений.
И всё это совершенно без дополнительных трудозатрат со стороны разработчика, то есть задаром.
К тому же можно было заметить строку deriving (Show), которая автоматически определила экземпляр класса типа Show для Maybe. Компилятор легко может создать этот и некоторые другие (например, Read, Eq, Ord) экземпляры автоматически, потому что ADT очень просты по своей сути.
Получается, что ADT — это удобный фреймворк для создания новых типов данных на основе композиции существующих.
Для этого существует типизация.
Используя сильно типизированные языки, будем защищены по крайней мере от таких ошибок. И чем сильнее система типов — тем больше будет множество ошибок, отсекаемых на этапе компиляции (при грамотном её использовании).
Есть примитивные типы, которые имеют только один экземпляр. Есть их суммы (объединение множеств значений) и произведения (декартово произведение множеств значений). Есть параметрический полиморфизм: Bool не паметризован ничем и живёт сам по себе, Maybe a параметризован типом элемента. Всё. Больше в ADT нет ничего. Это намного меньше, чем то, что есть в системах типов классических ООП-языков, и при этом позволяет добиться схожей (а зачастую даже большей) гибкости. Где здесь создание проблем? Налицо устранение некоторых проблем сложности, присущих другим системам типов.
Монады и функторы пришли в программирование из теории категорий, и, действительно, монады изначально были призваны решить проблему языка Хаскель, хотя и никак не связанную с алгебраическими типами данных: проблему работы с IO в чистом функциональном языке. Только спустя некоторое время нашлись многие другие применения этого полезного в хозяйстве, хм, паттерна. Оказалось, что монады — это остроумный способ решения многих других проблем, не связанных с IO. Просто ещё один способ композиции вычислений, как и функтор, и аппликативный функтор, и всё в таком духе. Больше способов композиции — больше возможностей писать композабельные системы — налицо loose coupling.
Разумеется, это всё, вероятно, не попадёт в мэйнстрим ещё очень долго. Отчасти из-за высокого порога вхождения, отчасти из-за того, что бизнес предъявляет несколько отличные от внутренней простоты требования. Бизнесу нужна лёгкость. Лёгкость замены и обучения разработчиков, доступность инструментов и так далее. Остроумных решений этой проблемы теория категорий нам, к сожалению, пока не предложила.
Классы смешивают воедино идентичность, состояние и поведение. Это сложно (не тяжело для восприятия, а просто объективно сложно: много сущностей, с которыми нельзя работать по отдельности)
Структуры недостаточно мощны: тип классических структур не может быть параметризован, и структуры представляют из себя произведение типов, но никогда — сумму (то есть если взять значение типа A И значение типа B, то можно получить значение структуры, содержащей A и B, но нельзя создать структуру, которая бы хранила значение типа A ИЛИ значение типа B)
ADT же просты, так как являются просто данными, без всяких смешений с какими-то идентичностями да поведениями, и при этом достаточно гибки, так как позволяют создавать сумму/произведение (алгебраическую композицию) других типов, да ещё и с параметрическим полиморфизмом (как в дженериках .net или java).
Благодаря этим двум свойствам ADT позволяют выразить очень много полезных типов данных и при этом достаточно удобно с ними работать посредством сопоставления с шаблоном, без написания горы методов для доступа к ним.
Например, в статье выше, определив в одну строку простейший тип данных Maybe, мы получили:
1) Параметризованный «контейнер» для 0 либо 1 элемента
2) Два конструктора: Just :: a -> Maybe a и Nothing :: Maybe a
3) Два «деконструктора» с аналогичными именами, которые используются при сопоставлении по шаблону и позволяют избежать условных операторов/операторов ветвлений, а также сравнений.
И всё это совершенно без дополнительных трудозатрат со стороны разработчика, то есть задаром.
К тому же можно было заметить строку deriving (Show), которая автоматически определила экземпляр класса типа Show для Maybe. Компилятор легко может создать этот и некоторые другие (например, Read, Eq, Ord) экземпляры автоматически, потому что ADT очень просты по своей сути.
Получается, что ADT — это удобный фреймворк для создания новых типов данных на основе композиции существующих.
Используя сильно типизированные языки, будем защищены по крайней мере от таких ошибок. И чем сильнее система типов — тем больше будет множество ошибок, отсекаемых на этапе компиляции (при грамотном её использовании).