Haskell → Изучай Хаскель ради добра! Моноиды
Привет! Поздравляю всех с пятницей!
Сегодня я хочу вам представить мой очередной перевод гдавы Моноиды из учебника Learn You a Haskell for Great Good!, который является продолжением предыдущего поста.
Сегодня я хочу вам представить мой очередной перевод гдавы Моноиды из учебника Learn You a Haskell for Great Good!, который является продолжением предыдущего поста.
JavaScript → Streams.js: отложенные (ленивые) вычисления в Javascript
Javascript-библиотека stream.js вводит «новую»1 структуру числовых данных: поток (stream). Это контейнер, который похож на массив (array) и связный список (linked list), но содержит неограниченное количество элементов, реализованное методом отложенных вычислений.
Для аргумента
var s = Stream.range( 10, 20 );
s.print(); // prints the numbers from 10 to 20Для аргумента
Stream.range( low, high ) можно указать только начальную границу диапазона Stream.range( low ), тогда поток будет состоять из неограниченного количества натуральных чисел. По умолчанию Stream.range() начинается с 1.Программирование → Свёртки в Intel Cilk Plus
Допустим нам зачем-то нужно найти сумму элементов массива. Мы можем разбить массив на две части, просуммировать каждую часть отдельно и сложить результаты. При этом суммировать эти части можно параллельно. Но суммирование части массива это в точности исходная задача, и каждую часть снова можно разбить на две части и просуммировать каждую часть отдельно, а затем сложить результаты и т. д. Такая стратегия вычислений называется «разделяй и властвуй».
Таким способом можно вычислять много других функций от массивов, ниже в первой части статьи будет приведено математическое объяснение этой идеи, а во второй — как с помощью Intel Cilk Plus эту идею использовать в своих программах.
Итак, если есть желание посмотреть на математические формулы и куски кода на C++ в последние дни лета, то добро пожаловать под хабракат.
Таким способом можно вычислять много других функций от массивов, ниже в первой части статьи будет приведено математическое объяснение этой идеи, а во второй — как с помощью Intel Cilk Plus эту идею использовать в своих программах.
Итак, если есть желание посмотреть на математические формулы и куски кода на C++ в последние дни лета, то добро пожаловать под хабракат.
Программирование → Монады с точки зрения теории категорий
Введение
Кажется, монады в программировании стали загадкой века. И для этого есть две причины:
- недостаточное знание теории категорий;
- многие авторы стараюстся не упоминать категории вообще.
Это как говорить об электричестве не используя мат. анализ. Достаточно для замены предохранителя, не хватит, чтобы спроектировать усилитель.
Мы начнём с простого введения в категории и функторы, затем дадим определение монады, приведём простые примеры монад в категориях и в конце приведём монадическую терминологию используемую в языках программирования.
Я уверен, что монады с точки зрения категорий почти элементарны.
Содержание
- Категория
- Функтор
- Естественное преобразование
- Монада
- Монады исключения и состояния
- Монады в программировании
- Ссылки
Haskell → Изучай Хаскель ради добра! Аппликативные функторы из песочницы
Совсем недавно издательство No Starch Press подготовило и выпустило печатное издание замечательного учебника Learn You a Haskell for Great Good! (онлайн-версия), написанного Miran Lipovača.
Я хочу представить вам самый актуальный перевод главы 11 Аппликативные функторы, оригиналом для которого послужило именно издание от No Starch Press, адаптированное для печати.
Я хочу представить вам самый актуальный перевод главы 11 Аппликативные функторы, оригиналом для которого послужило именно издание от No Starch Press, адаптированное для печати.
JAVA → Функциональное программирование в Java из песочницы
Эта статья о:
Если вы программируете на языках Java, C#, C++, PHP, или любом другом ОО языке, хотели бы познакомиться с функциональным программированием, но не имеет возможности/желания изучать Haskell/Scala/Lisp/Python, — эта статья специально для вас.
Тем, кто знаком с функциональным программированием, но никогда не применял его в Java, думаю, это будет тоже интересно.
- О применении функционального стиля программирования в языке Java.
- О некоторых базовых паттернах для работы с коллекциями данных из функционального программирования в примерах на Java.
- Немного о библиотеке Google Collections.
Если вы программируете на языках Java, C#, C++, PHP, или любом другом ОО языке, хотели бы познакомиться с функциональным программированием, но не имеет возможности/желания изучать Haskell/Scala/Lisp/Python, — эта статья специально для вас.
Тем, кто знаком с функциональным программированием, но никогда не применял его в Java, думаю, это будет тоже интересно.
Функциональное программирование → Функциональное программирование в среде 1С: Предприятие 8 из песочницы
В последнее время наметилась тенденция прникновения идей функционального программирования в массы. Для меня, как программиста 1С, интереснее всего повышение уровня абстракции при работе с табличными данными. Одно дело кодировать циклы со множеством переменных, которые меняют свое значение от итерации к итерации, а через месяц надо проводить «отладку глазами» (а то и на самом деле отладчик запускать), чтобы понять как эти циклы работают. Гораздо изящнее использовать готовые отлаженные алгоритмы, которые можно применить к таблице в целом, и получить ожидаемый результат.
Год за годом кодируя похожие и не очень циклы, я проникался желанием изменить что-то к лучшему в этом унылом процессе. Первое время меня вдохновляли обощенные алгоритмы STL С++. Потом для общего развития я изучал Haskell — этот язык действительно переворачивает восприятие.
Примерно 2 года назад я начал писать библитеку универсальных функций, которые применял в повседневной работе. Практика убедила меня, что подход работает, и приносит ощутимую пользу. А совсем недавно я открыл для себя язык LINQ, который используется на платформе .NET для унифицированной работы с коллекциями, формирования SQL-запросов и других полезных вещей. Я завидую белой завистью шарперам, у которых есть такой замечательный инструмент!
Изучив библиотеку стандартных операторов запроса, которая составляет ядро LINQ, я решил написать аналогичную библиотеку для 1С Предприятия 8.
Год за годом кодируя похожие и не очень циклы, я проникался желанием изменить что-то к лучшему в этом унылом процессе. Первое время меня вдохновляли обощенные алгоритмы STL С++. Потом для общего развития я изучал Haskell — этот язык действительно переворачивает восприятие.
Примерно 2 года назад я начал писать библитеку универсальных функций, которые применял в повседневной работе. Практика убедила меня, что подход работает, и приносит ощутимую пользу. А совсем недавно я открыл для себя язык LINQ, который используется на платформе .NET для унифицированной работы с коллекциями, формирования SQL-запросов и других полезных вещей. Я завидую белой завистью шарперам, у которых есть такой замечательный инструмент!
Изучив библиотеку стандартных операторов запроса, которая составляет ядро LINQ, я решил написать аналогичную библиотеку для 1С Предприятия 8.
Программирование → Паттерны Command и Strategy с точки зрения функционального программирования из песочницы
В результате изучения функционального программирования в моей голове появились некоторые мысли, которыми я хочу с вами поделиться.
В умах многих разработчиков, привыкших к объектно-ориентированной парадигме, возникает впечатление, что проектирование программного обеспечения, как таковое, неразрывно связано с ООП и всё остальное — суть ересь. UML, большей частью нацеленный на ООП, используется как универсальный язык для проектирования — хотя он таким, конечно, не является. И мы видим, как мир объектно-ориентированного программирования постепенно погружается в пучину преступного переинженеринга (1).
В силу этого зачастую даже не ставится вопрос о выборе парадигмы программирования. Тем не менее, этот вопрос является весьма существенным, и зачастую правильный ответ даёт большие преимущества (3). Это, вообще говоря, выходит за рамки того, что мы привыкли называть проектированием — это вопрос из области архитектуры.
Не так давно я наткнулся на весьма интересное исследование — (2). В нём рассматривается задача формализации понятий «архитектура», «проектирование» и «реализация», которые чаще всего употребляются неформально. И авторам удаётся вывести весьма интересный критерий: критерий Intension/Locality. Я не буду углубляться в философию и просто приведу краткое описание критерия (эта часть — фактически перевод) и мои выводы из него.
Свойство Intension (интенсионность) означает способность некой сущности описывать бесконечное множество предметов: например, понятие простого числа. Ему противоположно свойство экстенсионности — сущность описывает конечный набор предметов: например, понятие страны — члены НАТО.
Свойство локальности — сущность влияет только на отдельную часть системы. Соответственно, глобальность — сущность влияет на всю систему в целом.
Дак вот, учитывая эти два свойства, авторы указанного исследования составляют такую таблицу:
Пользуясь ей легко определить, что относится к уровню архитектуры, а что — к уровню проектирования. И вот мой вывод: выбор парадигмы программирования, платформы и языка — это решение уровня архитектуры, т.к. этот выбор глобален (затрагивает все части системы) и интенсионен (парадигмы определяют способы решения бесконечного множества задач).
Тем не менее, решить столь глобальную задачу (найти критерии выбора подходящей парадигмы) мне пока не по силам. Поэтому я решил выбрать два уже существующих класса задач и показать, что для них стоит использовать не привычный для многих ОО подход, а функциональный, который в последнее время приобретает (заслуженно) всё большую популярность.
Классы задач я выбрал необычным методом — я взял два паттерна ОО проектирования и показал, что они, по сути — ограниченная реализация понятия из области функционального программирования — функции высшего порядка (higher-order function, далее: ФВП). Гипотеза заключалась в том, что паттерны — это устоявшиеся решения определённых проблем, а раз возникают проблемы и их устоявшиеся решения, видимо есть некие слабости и недостатки, которые приходиться преодолевать. Для рассмотренных паттернов это действительно так.
Кстати говоря, подобный подход был использован в (5) и (6). В (6) вообще было указано на возможность замены большинства паттернов, но подробный анализ каждого не проводился. В (5) было более подробное рассмотрение Command и Strategy, но немного с другой стороны. Я решил сделать что-то более практичное, чем в (6), и с другими акцентами, чем в (5). Итак, приступим.
Паттерны проектирования и функциональное программирование? Как это вообще связано?
В умах многих разработчиков, привыкших к объектно-ориентированной парадигме, возникает впечатление, что проектирование программного обеспечения, как таковое, неразрывно связано с ООП и всё остальное — суть ересь. UML, большей частью нацеленный на ООП, используется как универсальный язык для проектирования — хотя он таким, конечно, не является. И мы видим, как мир объектно-ориентированного программирования постепенно погружается в пучину преступного переинженеринга (1).
В силу этого зачастую даже не ставится вопрос о выборе парадигмы программирования. Тем не менее, этот вопрос является весьма существенным, и зачастую правильный ответ даёт большие преимущества (3). Это, вообще говоря, выходит за рамки того, что мы привыкли называть проектированием — это вопрос из области архитектуры.
Лирическое отступление: разница между архитектурой, проектированием и реализацией
Не так давно я наткнулся на весьма интересное исследование — (2). В нём рассматривается задача формализации понятий «архитектура», «проектирование» и «реализация», которые чаще всего употребляются неформально. И авторам удаётся вывести весьма интересный критерий: критерий Intension/Locality. Я не буду углубляться в философию и просто приведу краткое описание критерия (эта часть — фактически перевод) и мои выводы из него.
Свойство Intension (интенсионность) означает способность некой сущности описывать бесконечное множество предметов: например, понятие простого числа. Ему противоположно свойство экстенсионности — сущность описывает конечный набор предметов: например, понятие страны — члены НАТО.
Свойство локальности — сущность влияет только на отдельную часть системы. Соответственно, глобальность — сущность влияет на всю систему в целом.
Дак вот, учитывая эти два свойства, авторы указанного исследования составляют такую таблицу:
Пользуясь ей легко определить, что относится к уровню архитектуры, а что — к уровню проектирования. И вот мой вывод: выбор парадигмы программирования, платформы и языка — это решение уровня архитектуры, т.к. этот выбор глобален (затрагивает все части системы) и интенсионен (парадигмы определяют способы решения бесконечного множества задач).
Тем не менее, решить столь глобальную задачу (найти критерии выбора подходящей парадигмы) мне пока не по силам. Поэтому я решил выбрать два уже существующих класса задач и показать, что для них стоит использовать не привычный для многих ОО подход, а функциональный, который в последнее время приобретает (заслуженно) всё большую популярность.
Классы задач я выбрал необычным методом — я взял два паттерна ОО проектирования и показал, что они, по сути — ограниченная реализация понятия из области функционального программирования — функции высшего порядка (higher-order function, далее: ФВП). Гипотеза заключалась в том, что паттерны — это устоявшиеся решения определённых проблем, а раз возникают проблемы и их устоявшиеся решения, видимо есть некие слабости и недостатки, которые приходиться преодолевать. Для рассмотренных паттернов это действительно так.
Кстати говоря, подобный подход был использован в (5) и (6). В (6) вообще было указано на возможность замены большинства паттернов, но подробный анализ каждого не проводился. В (5) было более подробное рассмотрение Command и Strategy, но немного с другой стороны. Я решил сделать что-то более практичное, чем в (6), и с другими акцентами, чем в (5). Итак, приступим.
.NET → Введение в F#, the blue pill
[Предыдущий пост]
Вот и ожидаемое, или не очень, продолжение. Сегодня мы проглотим синюю пилюлю, гордо олицетворяющую FP (functional programming), и погрузимся в функциональную часть F# еще глубже. Поговорим о функциях, рекурсии, pattern matching'е и еще о нескольких интересных вещах. Интересно? Тогда глотаем таблетку и начинаем погружение.
Введение
Вот и ожидаемое, или не очень, продолжение. Сегодня мы проглотим синюю пилюлю, гордо олицетворяющую FP (functional programming), и погрузимся в функциональную часть F# еще глубже. Поговорим о функциях, рекурсии, pattern matching'е и еще о нескольких интересных вещах. Интересно? Тогда глотаем таблетку и начинаем погружение.
.NET → Введение в F#, или полезное о бесполезном из песочницы
Вступление
А зачем оно мне?
А почему бы и нет? К примеру, для общего развития, или просто для интереса, а впоследствии, может быть, для того, чтобы убедиться, что F# — не просто язык для ознакомления.