Это вторая вводная часть обзора, посвящённого применению теории категорий в программировании. В первой части представлены некоторые основные определения теории, в том числе, hom-типы, их значения-морфизмы, а также их композиция, позволяющая строить пути вычислений в рамках одной категории. В данной же публикации мы рассмотрим, как пути вычислений можно прокладывать через разные категории.
Моя повседневная работа с основном связана с языком Elm. Благодаря сочетанию функционального языка и архитектуры Elm, многие архитектурные решения в нём получаются практически незаметными (подробнее об этом я рассказываю в этом посте у меня в блоге). Вы получаете четкое разделение задач, а язык по умолчанию подталкивает вас к хорошему проектированию.
Но моя работа не ограничивается Elm. Я часто создаю функции, которые охватывают как фронтенд, так и бэкенд — пишу новые конечные точки, а иногда даже проектирую новые таблицы баз данных. Когда я выхожу за пределы мира Elm, я вспоминаю, что архитектура — это то, к чему я должен снова относиться сознательно.
Этот пост не о том, какой код идет в какой слой, и не о конкретных паттернах проектирования. Прежде всего, я хочу поговорить об обманчиво простом выборе: следует ли просто реализовать то, что вам нужно, или же лучше начать с создания абстракции?
«Лень‑матушка вперёд нас родилась»
В этой статье я хочу рассказать о технике «Expression Templates» и её применении в библиотеке simstr.
Как известно, «хороший программист — ленивый программист». Именно лень толкает нас на поиск оптимальных решений и экономию ресурсов. А человек, проводящий много времени с компьютером — волей‑неволей начинает его «одушевлять» и беспокоится о нём. Поэтому не знаю, как у вас, а у меня сердце кровью обливается, когда я вижу, что для получения конечного результата тем способом, который написан в программе, бедному процессору придётся выполнять много лишней работы, зазря тратить тактики и бестолку гонять байтики туда‑сюда. Это прямо вызывает боль.
Вот, к примеру, давайте рассмотрим такой простенький код.
В этой статье я коротко опишу один приём, который помогает мне писать код быстрее и с меньшим числом ошибок. Я говорю «приём», но по факту это просто практика, которой я начал следовать с опытом, сам того не замечая.
Когда вы работаете над чем-то сложным, формируйте в уме некое подтверждение, что ваш код будет делать именно то, что вам нужно. Звучит вроде просто, но на деле всё оказывается сложнее. Чтобы начать делать это «на лету», не прерывая рабочий поток, потребуется упорная практика. Зато, когда вы освоите эту технику, то удивитесь, насколько чаще ваш код будет полноценно работать с первой или второй попытки. Невероятно впечатляет.
Добиться этого можно по-разному, и я не хочу давать какие-то категоричные рекомендации. Просто приведу несколько примеров тех вещей, о которых я сам рассуждаю «на лету», чтобы вы могли сформировать общее представление.
Работа со строками в С++ - зачастую больная боль.
Однако за 25 лет я сумел найти лекарство от этой боли и после 13 лет разработки и испытаний готов поделиться им со всеми страждущими.
simstr — библиотека для использования строк в C++, в которой пишется легко и удобно, а выполняется быстро и оптимально.
Итак, йоу, юзеры!
Я Hilrein, 18-летний разработчик мобильных и веб-приложений. В этой статье я расскажу вам про базовый Dart - язык программирования, лежащий в основе Flutter. Он отлично подходит как для новичков, так и для тех, кто хочет перейти в кроссплатформенную мобильную разработку.
Эта статья рассчитана на начинающих и охватывает всё, что нужно знать до перехода к объектно-ориентированному программированию (ООП).
На пути изучения Haskell стоит много абстракций, без понимания которых нет смысла двигаться дальше. Один из таких рубежей — аппликативный функтор.
Разберем пример: напишем простой валидатор и посмотрим каким образом пригодится Applicative.
Определим пользователя:
В финальной статье цикла про функциональное программирование в Android мы соберём знания, полученные в предыдущих частях. И, конечно, применим их на практике — соберём скелет приложения для медитации.
Практиковаться будем не на ViewModel, а на The Elm Architecture — это паттерн управления состоянием, заимствованный из функционального языка Elm. Заодно узнаем об этом паттерне побольше, разобрав суть его ключевых компонентов. В общем, погнали!
Данный обзор посвящён применению теории категорий в программировании. Акцент сделан на то, что стремление к повышению качества программ неизбежно приводит к абстракциям («функтор», «монада» и прочие), которые уже появились в математике при решении другого рода задач.
В этой части будет рассказано об основных свойствах категорий, приведены примеры наиболее важных для дальнейшего изложения. Но сразу предупреждаю, что это лишь «скучное введение» — полезность представленных здесь сведений раскроется лишь в последующих частях обзора.
Привет, меня зовут Марат Зимнуров, я тимлид в кросс-функциональной команде HR Admin Tech Авито. Тема функционального программирования не обделена вниманием — и все же тяжело найти действительно понятный и структурно изложенный разбор данного инструмента. Нет нормального гайда для старта — ни у нас, ни на Западе. Многие говорят про иммутабельность и монады, но путаются в основах. В статье разбираю, что такое функциональное программирование на самом деле и зачем оно нужно.
Мы ковыряли поиск пути через A* на протяжении двух глав и при этом были сосредоточены на синтаксических изысках F#. В этой главе мы отдохнём от синтаксиса и посмотрим на то, как этот алгоритм мог бы развиваться в более функциональном стиле.
Кульминация цикла о функциональщине в Android! Сегодня изучаем чистые функции — ещё один важный принцип функционального программирования.
Учтём контекст и познакомимся с сопутствующими терминами, раскрывающими суть чистых функций. А ещё обсудим место концепции Dependencies Injection в функциональном программировании. В общем, вперёд за новыми знаниями!
Серия статей с очередным разбором MV* шаблонов, но с интересными деталями
Даже опытные разработчики смогут найти что-то новое для себя
Это четвертая статья из серии,
в которой разбираем как собирается MVI и что же такое Model
Статья 4: Готовим MVI
- 🧩 Собираем MVI-пазл воедино
- 🤔 А что если вообще написать свою реализацию MVI?
- 📜 Ты так и не понял, что такое Model?
Серия статей с очередным разбором MV* шаблонов, но с интересными деталями
Даже опытные разработчики смогут найти что-то новое для себя
Это третья статья из серии,
в которой подробно разбираем из чего состоит MVI
Статья 3: Из чего готовят MVI
- ⚓️ Парадигма Реактивное программирование (Reactive programming)
- 🌯 Как завернуть все в шаурму Intent?
- 🌽 Как собрать урожай состояние?
- 🚜 Зачем трактору нужен редуктор?
- 🏪 Как открыть магазин с перехватчиками?
- 👷🏼♀️ 5 менеджеров и 1 работник
Основная проблема IT-отрасли, на мой непросвещенный взгляд, заключается в том, что жизнь обучает нас профессии примерно так же, как учителя начальной школы — арифметике. Сначала нам говорят: делить на ноль нельзя. А потом оказывается, что ещё в XVII веке один маркиз по имени Гийом Франсуа Лопиталь научился. Нам говорят: квадратный корень можно извлекать только из положительных чисел. А потом — хоба — оказывается комплексными бывают не только обеды. И так далее.
С чего начинается обучение компьютерным наукам? — С некоторого количества теории, которая скучная и непонятная, как и любая полностью оторванная от практики теория, — а потом — с примеров. Мы открываем REPL и некоторое время забавляемся с ней, как с калькулятором.
Продолжаем погружение в мир функционального программирования! Тема новой статьи — функциональные типы данных и их структуры. Из неё вы узнаете о принципе неизменности данных, о понятии State Machine и о способах его применения в программировании.
А ещё мы исследуем функциональную библиотеку Kotlin Arrow, обсудим поддержку Null, поток данных и функциональную обработку ошибок, а также начнём проектировать Data и Domain слои демонстрационного приложения. В общем, скучать не придётся!
Я не верю, конечно, ни в какую демократию (кроме оригинальной афинской 2½ тысячи лет назад, где кворум состоял из трёх с половиной образованных богатых неглупых людей, а остальные были безголосыми рабами и женщинами). Как я уже где-то говорил, существуют исторические свидетельства того, к чему привели первые проявления этой самой демократии: пару тысяч лет назад люди проголосовали распять одного там назаретянина.
Поэтому когда в качестве аргумента за ту, или иную парадигму, — я вижу какие-то индексы, голосования и прочую статистически значимую оценку vox populi, меня это раздражает. «Миллионы мух не могут ошибаться» — так себе аргумент. Поэтому мнение «коммьюнити разработчиков» — практически всегда облыжное, поверхностное, и, в целом, неверное. У каждого в руках свой молоток, а про многообразие саморезов люди en masse если и слышали, то краем уха и в качестве анекдота.
Если экстраполировать мнение большинства и принять его за аксиому, то в мире будут существовать только банковские приложения и круды с базами данных в качестве узкого места и дополнительными серверами вместо корректного горизонтального масштабирования. Тем не менее, многие даже в своей работе используют инструменты, которым никакая база не требуется, а обеспечение роста гарантируется размазыванием нагрузки по кластеру, а не приклеенными (sticky) сессиями. И я говорю не про десктоп.
Несмотря на то, что сам я ушел из большого ООП¹ более десяти лет назад, причем, надеюсь, навсегда, я всегда крайне вяло и неохотно участвую в баталиях тупоконечников и остроконечников: я абсолютно убежден, что для разных типов задач лучше подходят разные инструменты, и выхолощенное ФП заставит всех вокруг создавать тонны никому не нужного бойлерплейта для тривиального круда, а кристальное ООП — воткнет все возможные палки в колёса при реализации бизнес-процессов. Любой из современных языков программирования позволяет смешивать эти подходы, а микросервисная архитектура — даже гостеприимно приютит несколько языков и сред под одной крышей.
Тем не менее, хотя я никогда не считал себя евангелистом функционального подхода, и уж, тем более, не примыкал к стану воинствующих пуристов, меня постоянно свербил вопрос: что же все-таки не так с ООП, если лично мне быстрее, проще и понятнее — реализовывать свои проекты на функциональном эликсире?
И вот, наконец, меня озарило. Объектная модель всем хороша в однопоточной среде. Даже банальная асинхронность приносит кучу совершенно нерелевантных проблем: мьютексы любого сорта — это порождение дьявола. В игрушечных примерах из книжек они езе как-то работают, но действительно _многопоточный_ код на них написать фактически нереально. Среда, которая буквально приглашает разработчика ошибиться и разрушить тотальность функций потенциальным дедлоком — не должна иметь права на существование в принципе.
В современном обучении программированию, как правило, основное внимание уделяется парадигме объектно-ориентированного программирования (OOP) и вытекающей из неё методологии объектно-ориентированного проектирования (OOD). Определённый ренессанс в наше время испытывает парадигма функционального программирования, но практически никогда в связке с ней не рассматривается функциональное проектирование. Попытаемся осветить наше видение этих вопросов.
Расширяем кругозор. Слышали про парадигму функционального программирования? Если вы iOS-разработчик, то, наверное, да, а если вы Android-разработчик, то, скорее всего, нет. Пришло время это исправить.
Привет! Меня зовут Женя Бондарев. И сегодня мы поговорим о теории функционального программирования, её особенностях и о том, что она может дать вашему Android-приложению. А ещё начнём писать pet-проект на функциональной архитектуре. Поехали!
