Типы в этой схеме фиксированы, но тут играет роль понятие коммутативности путей. В данном случае пути "c" и "b * а" не коммутативны - не для всех исходных значений будет получен одинаковый результат. "Коммутативность" входит и в понятие универсального свойства - "существует единственный морфизм, делающий диаграмму коммутативной".
Типы изоморфные (при слабой типизации всегда можно переломать указатель с одного типа на другой и обратно без потерь), но разные. С этими типами могут быть связанные разные наборы функций, а типы как раз и отличаются разным набором входящих и исходящих отображений - положением на общей диаграмме типов.
Важный момент. Наверное стоило раскрыть его подробнее.
Вычисления обычно проводяься так: на входе у нас есть значение типа А (возможно, несколько значерий, объединённых типом-произведением), передав его в одну функцию, получаем значение типа В и так далее. Получаетя цепочка вида А->В->...->R - по сути это один из путей на диагрмме типов. Задача состоит в том, чтобы найти путь до R как можно короче.
Допустим есть три функции А->В, В->С и А->С. Очевидно, что если мы хотим получить значение типа С из А, то вызов последней функции будет оптимальнее, чем последоаптельный вызов пнрвых двух - путь на диаграмме короче. Уникальность универсального морфизма и определяет его оптимальность - из всех возможных путей он оказыаается самым коротким. Строя вычисления, основанные на универсальных свойствах типов как раз и получается находить наиболее коротеие пути вычислений.
Под факторизацией здесь понимается разделение длинного пути вычисления на отдельные шаги-функции. По сути, декомпощиция задачи. Возможно, не самое удачное использование слова "факторизация"...
По поводу типа Either я в статье отметил, что не зотел углублятся в тему обобщённых типов - что это и почему их можно захотеть. Надеюсь написать об этом отдельную статью, и её публикация окажется достаточно обоснованной))
Тут речь идёт об однозначности формулировки типа. Вопрос в том, какой тип мы можеи назвать "А1 или А2". Или же не получится выделить какой-то единстаенный тип, подходящий под эту формулировку?
Понятие универсального свойста позволяет однозначно формулировать новые типы. В этой статье подобные вопросы раскрываются очень хорошо, на мой взгляд.
Стрелки-то можно нарисовать какие угодно, но в теории типов принято ассоциировать такие стрелки с конеретными функциями, принимающие аргумент одгого типа и возвращающие значение другого типа (отображение между типами). Т.е. буквально, если у вас есть функция из А в В (написанная только что, или например, неявное преобразование к сурертипу от компиляьора...), то вы можете соединить на диаграмме эти типы стрелкой в соответствующем нарравлении.
Эволюция ФП следует за математикой. А вот традиционное императивное (процедурное, объектно-ориентированное...) программирование - это уже законченные идеи. Они очень вяло мутируют исключительно за счёт впитывания ФП-шных техник.
Да, последнее время больше пишу на Scala. У языка не мало проблем, по большей части из-за "беттерджавного" наследства. Но в нём сочетаются как традиционные для большинства популярных языков решения, так местами весьма глубокие ФП-шные вкусности. Так что несмотря не некоторые недоработки в плане ФП, мне кажется, он здорово подходит для демонстрации кода в подобных статьях.
Какое-то время назад попробовал в реальном проекте Tagless Final в экосистеме cats и остался доволен - ООП вынесена куда-то на периферию, а про опасную "нечистую" императивность вообще практически можно было забыть))
На всяких Haskel мало кто хочет писать продуктовый софт, а Scala приносит не только боль))
Первыми практиками были выдающиеся математики, спроектировавшие языки Ассемблера, Фортран и прочие. На ранних этапах типизация байтов была весьма условной - там скорее речь шла именно о множествах возможных значений а не о возможностях, которые предоставляет тип. Представление чисел с плавающей запятой появилось позднее. Понятие о типах, в появилось в математике задолго до первых ЭВМ.
Мотивом статьи было не столько снижение "сложности объяснения завышенного уровня абстракций", сколько объяснение неизбежности появления этих абстракций. Проблема в том, что обычно математики предоставляют уже готовую "красоту", не особо утруждаясь обоснованием. А потом практики смотрят на это с мыслями вроде "красиво, но нафига, а главное, зачем это мне?". Не считаю, что с поставленной перед собой задачей справился "на отлично", но всё же постарался донести, что в следствие неизбежности появления, эти абстракции являются фундаментом в том числе и в области обеспечения корректности компьютерных программ любых алгоритмов (да, теорию множеств и сейчас развивают в этом плане, но это дальше от программирования и там всё оказывается намного сложнее).
Популярность императивного (процедурного, если угодно) программирования обуславливается в первую очередь историей развития электронно-вычислительной техники. Первые языки программирования строились вокруг архитектуры процессоров. Тогдашние компиляторы просто не тянули абстракции, далёкие от железа. Для популярных тогда языков писалось множество книг, курсов обучения семинаров. Разрабатывались и популяризировались императивно-ориентированные техники программирования. Позднее появилось ООП, в пропаганду которого также влиты гигантские деньги... Но популярность, на самом деле, слабо коррелирует с качеством этих методов. Сейчас компьютеры и компиляторы сильно поумнели, функциональная парадигма стала весьма актуальной, но преодолевать огромную инерцию общественного мнения всё тяжело. Тем не менее, тенденции на изменение мира к лучшему прослеживается везде - в публикациях, в развитии языков программирования и т.п. Без относительно того, замечают ли это сами программисты))
Вообще, такую холиварную тему, как преимущества ФП, наверное, имеет смысл осветить в отдельной статье (угу, ещё одной на эту тему...). Если подумать, то фундаментальный набор абстракций, необходимых для качественного программирования гораздо меньше, чем всё то, чему сейчас традиционно учат в школах/вузах. А научить человека писать качественные программы в традиционной парадигме сложнее, чем в функциональной. Впрочем, данная статья не столько про ФП, сколько про фундаментальность фундамента ФП)))
Безусловно, автору есть многое, над чем нужно поработать. Прошу не судить слишком строго - это мой первый опыт публикации статьи. Большое спасибо за отзыв!
Типы в этой схеме фиксированы, но тут играет роль понятие коммутативности путей. В данном случае пути "c" и "b * а" не коммутативны - не для всех исходных значений будет получен одинаковый результат. "Коммутативность" входит и в понятие универсального свойства - "существует единственный морфизм, делающий диаграмму коммутативной".
Типы изоморфные (при слабой типизации всегда можно переломать указатель с одного типа на другой и обратно без потерь), но разные. С этими типами могут быть связанные разные наборы функций, а типы как раз и отличаются разным набором входящих и исходящих отображений - положением на общей диаграмме типов.
Важный момент. Наверное стоило раскрыть его подробнее.
Вычисления обычно проводяься так: на входе у нас есть значение типа А (возможно, несколько значерий, объединённых типом-произведением), передав его в одну функцию, получаем значение типа В и так далее. Получаетя цепочка вида А->В->...->R - по сути это один из путей на диагрмме типов. Задача состоит в том, чтобы найти путь до R как можно короче.
Допустим есть три функции А->В, В->С и А->С. Очевидно, что если мы хотим получить значение типа С из А, то вызов последней функции будет оптимальнее, чем последоаптельный вызов пнрвых двух - путь на диаграмме короче. Уникальность универсального морфизма и определяет его оптимальность - из всех возможных путей он оказыаается самым коротким. Строя вычисления, основанные на универсальных свойствах типов как раз и получается находить наиболее коротеие пути вычислений.
Под факторизацией здесь понимается разделение длинного пути вычисления на отдельные шаги-функции. По сути, декомпощиция задачи. Возможно, не самое удачное использование слова "факторизация"...
По поводу типа Either я в статье отметил, что не зотел углублятся в тему обобщённых типов - что это и почему их можно захотеть. Надеюсь написать об этом отдельную статью, и её публикация окажется достаточно обоснованной))
Тут речь идёт об однозначности формулировки типа. Вопрос в том, какой тип мы можеи назвать "А1 или А2". Или же не получится выделить какой-то единстаенный тип, подходящий под эту формулировку?
Понятие универсального свойста позволяет однозначно формулировать новые типы. В этой статье подобные вопросы раскрываются очень хорошо, на мой взгляд.
Стрелки-то можно нарисовать какие угодно, но в теории типов принято ассоциировать такие стрелки с конеретными функциями, принимающие аргумент одгого типа и возвращающие значение другого типа (отображение между типами). Т.е. буквально, если у вас есть функция из А в В (написанная только что, или например, неявное преобразование к сурертипу от компиляьора...), то вы можете соединить на диаграмме эти типы стрелкой в соответствующем нарравлении.
И ещё одна ремарка))
Эволюция ФП следует за математикой. А вот традиционное императивное (процедурное, объектно-ориентированное...) программирование - это уже законченные идеи. Они очень вяло мутируют исключительно за счёт впитывания ФП-шных техник.
Да, последнее время больше пишу на Scala. У языка не мало проблем, по большей части из-за "беттерджавного" наследства. Но в нём сочетаются как традиционные для большинства популярных языков решения, так местами весьма глубокие ФП-шные вкусности. Так что несмотря не некоторые недоработки в плане ФП, мне кажется, он здорово подходит для демонстрации кода в подобных статьях.
Какое-то время назад попробовал в реальном проекте Tagless Final в экосистеме cats и остался доволен - ООП вынесена куда-то на периферию, а про опасную "нечистую" императивность вообще практически можно было забыть))
На всяких Haskel мало кто хочет писать продуктовый софт, а Scala приносит не только боль))
Первыми практиками были выдающиеся математики, спроектировавшие языки Ассемблера, Фортран и прочие. На ранних этапах типизация байтов была весьма условной - там скорее речь шла именно о множествах возможных значений а не о возможностях, которые предоставляет тип. Представление чисел с плавающей запятой появилось позднее. Понятие о типах, в появилось в математике задолго до первых ЭВМ.
Мотивом статьи было не столько снижение "сложности объяснения завышенного уровня абстракций", сколько объяснение неизбежности появления этих абстракций. Проблема в том, что обычно математики предоставляют уже готовую "красоту", не особо утруждаясь обоснованием. А потом практики смотрят на это с мыслями вроде "красиво, но нафига, а главное, зачем это мне?". Не считаю, что с поставленной перед собой задачей справился "на отлично", но всё же постарался донести, что в следствие неизбежности появления, эти абстракции являются фундаментом в том числе и в области обеспечения корректности
компьютерных программлюбых алгоритмов (да, теорию множеств и сейчас развивают в этом плане, но это дальше от программирования и там всё оказывается намного сложнее).Популярность императивного (процедурного, если угодно) программирования обуславливается в первую очередь историей развития электронно-вычислительной техники. Первые языки программирования строились вокруг архитектуры процессоров. Тогдашние компиляторы просто не тянули абстракции, далёкие от железа. Для популярных тогда языков писалось множество книг, курсов обучения семинаров. Разрабатывались и популяризировались императивно-ориентированные техники программирования. Позднее появилось ООП, в пропаганду которого также влиты гигантские деньги... Но популярность, на самом деле, слабо коррелирует с качеством этих методов. Сейчас компьютеры и компиляторы сильно поумнели, функциональная парадигма стала весьма актуальной, но преодолевать огромную инерцию общественного мнения всё тяжело. Тем не менее, тенденции на изменение мира к лучшему прослеживается везде - в публикациях, в развитии языков программирования и т.п. Без относительно того, замечают ли это сами программисты))
Вообще, такую холиварную тему, как преимущества ФП, наверное, имеет смысл осветить в отдельной статье (угу, ещё одной на эту тему...). Если подумать, то фундаментальный набор абстракций, необходимых для качественного программирования гораздо меньше, чем всё то, чему сейчас традиционно учат в школах/вузах. А научить человека писать качественные программы в традиционной парадигме сложнее, чем в функциональной. Впрочем, данная статья не столько про ФП, сколько про фундаментальность фундамента ФП)))
Безусловно, автору есть многое, над чем нужно поработать. Прошу не судить слишком строго - это мой первый опыт публикации статьи. Большое спасибо за отзыв!